Closed
Bug 16849
Opened 25 years ago
Closed 24 years ago
[FIX] Radio menu item should be drawn with dot not tick
Categories
(Core :: XUL, defect, P3)
Tracking
()
VERIFIED
FIXED
M18
People
(Reporter: michael.j.lowe, Assigned: bugzilla)
References
Details
(Keywords: platform-parity, Whiteboard: [FIX IN HAND])
Attachments
(4 files)
A radio menu item should be drawn with a round dot (to match a radio control),
not a tick to differentiate it from checkbox (on/off) menu items. See attached
screenshot for how Windows does it.
Reporter | ||
Comment 1•25 years ago
|
||
Reporter | ||
Comment 2•25 years ago
|
||
Here are the style rules needed for skin.css. Attached files provide
needed icons:
menuitem[type=radio][checked="true"] > .menu-left {
list-style-image: url("chrome://global/skin/menu-radio-check.gif");
}
menuitem[type=radio][checked="true"][disabled="true"] > .menu-left {
list-style-image: url("chrome://global/skin/menu-radio-check-disabled.gif");
}
menuitem[type=radio][checked="true"][menuactive="true"] > .menu-left {
list-style-image: url("chrome://global/skin/menu-radio-check-hover.gif");
}
Reporter | ||
Comment 3•25 years ago
|
||
Reporter | ||
Comment 4•25 years ago
|
||
Reporter | ||
Comment 5•25 years ago
|
||
Reporter | ||
Updated•25 years ago
|
Assignee: shaver → hangas
Reporter | ||
Comment 6•25 years ago
|
||
This bug is still relevant with new skin.
Michael: you seem to be busy. thanks.
German: what is the UE group point of view on this? I thought we decided on
checkmarks based on what other apps were doing.
Yeah we decided on checkmarks based on what lots of other apps are doing. Users
can discover the checkmarks much more easily and usually do not infer behavour
from the look only, but instead from context. Also we would like to use these
cross platform and I have only seen these radio button thingies on -some- windows
apps, but not on other platforms. Even the windows UI guidelines (to call them
guidelines is an insult IMO) do not clearly recommend one style over the other,
so should go by what works best for the envisioned set of end users.
Reporter | ||
Comment 10•25 years ago
|
||
I guess I take an idealistic view on this, rather than a view based on what has
been done in the past. Using the same iconic metaphor to represent two
completely diffent states, both radio and checkbox menus, is something that
really grates against my sense of what should be done. When I first saw a
radio box used in a Windows app menu I said to myself "ah, this is how they
should have always been done :-)". But I note that even now there is some
inconsistency in their use. I guess the only way to decide what is best would
be to try a well designed usabililty study. I suspect that even users on other
platforms would not have any trouble picking up what they mean.
Reporter | ||
Comment 11•25 years ago
|
||
A good example of why there should be some differentiation between the two icons
is the current "Use Stylesheet" submenu on the View menu. If the same icon is
used for both radio and checkbox menu items it is not really clear just by
looking at the menu whether multiple stylesheets are able to be selected
concurrently for display, or only one at a time. Changing the radio menu item
icon to a round dot would in this case clear up any confusion with this menu.
Comment 12•25 years ago
|
||
On a theoretical level I would agree with you.
You have a trained eye for these things, as it is your area of interest, but we
found in usability testing that it is the behavior that matters to end users,
almost all users couldn't tell the difference between the checkmark and the
bullet by just looking at it. I worked at Apple some long time ago where in
usability testing we found the same thing even for regular check boxes vs
regular radio buttons, users couldn't predict the behavior as a result of the
particular design. Instead users understand the behavior implicitly by trying
out the controls and seeing the reactions. They also infered behavior from
context (e.g. labels), but definitely not from the design.
In addition placing those meanings in menus means taking the visual design out
of context thus further reducing the meaning implied. E.g. therefore it is a
poor design choice to show the radio button without the round border. The fact
that Microsoft Office uses it in its UI does not make the design a better
choice.
Reporter | ||
Comment 13•25 years ago
|
||
German: I would agree with everything you said, to an extent. You say that
"They also inferred behaviour from context (e.g. labels)" and I would agree with
this. You say that "almost all" users couldn't tell the difference between
the checkmark and the bullet by just looking at it, and this may be true. But,
there is obviously a percentage of users who _can_ identify the difference in
behaviour associated with these icons - they have jumped a quantum level and
have associated some semantics with a particular icon.
Users obviously learn the behaviour of something by either trying it out or by
being told what it does. Once users have learned the behaviour (semantics) of
something, they form an association in their minds with some particular
representation of the behaviour (syntax). This representation may be a textual
label, or sometimes an icon, or both. I would speculate that visually oriented
people map semantics to visual syntactic queues to much greater extent than do
verbally oriented people, who probably rely more on textual labels. I would
assume that users will use all the available mappings that have been formed in
their mind between semantic and syntactic levels when determining the behaviour
of some representation. So, for those percentage of users who will form
mappings from visual representations to behaviour it is important to have a
clear mapping - this mapping must _not_ be overloaded with multiple behaviours.
Using the same icon (syntax) for two different behaviours (radio and checkbox
menus) allows some mapping to form between iconic syntax and semantics, but the
mapping will be a confused one. The same iconic representation is used for two
different behaviours, so the mapping is overloaded. In this case, those
percentage of users who do use visual mappings as an element in determining
behaviour will have to resort to other queues, like textual labels, or position
of a menu item in the tree. While they still may able to determine behaviour,
the overloaded visual mapping will introduce an element of confusion, and in
cases where other mappings between syntax and semantics have not yet formed,
they will be "flying blind" and will have to resort to first principles to
determine behaviour (either guess, resort to manuals, or experiment with the
actions of the item). So, I believe that a clear differentiation between
syntactic representation for different semantic actions is essential.
I would also agree with your statement "In addition placing those meanings in
menus means taking the visual design out of context thus further reducing the
meaning implied.". However, I believe that most users don't associate the
check or round dot icons in menus with their dialog box equivalents. This is
not necessary a bad thing. It is not particularly important that it is a
round dot that represents radio menu items (it could be a square or star or
whatever), but it is important that a *different* icon is used so that it is
differentiated from the icon representing checkbox menu items. It must be
differentiated so the syntactic<->semantic mappings are not overloaded with two
different semantics for the one syntax item.
Comment 14•25 years ago
|
||
Mass move to M13.
Comment 15•25 years ago
|
||
spam: changing qa contact from ckritzer -> paulmac for xul bugs
Updated•25 years ago
|
Target Milestone: M13 → M15
Comment 16•25 years ago
|
||
BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL
component will be deleted.
Component: XUL → XP Toolkit/Widgets: XUL
Comment 19•25 years ago
|
||
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Updated•25 years ago
|
Target Milestone: M16 → M17
Comment 21•24 years ago
|
||
*** Bug 43120 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 22•24 years ago
|
||
This hasn't been touched for awhile, so unless anyone objects, I'm going to
reassign to myself.
So what's the decision on this? I agree we should use bullets...even if most
users don't recognize the difference, at least it's better and more consistent
for the few that will. Let me know what I should do here...
Assignee: ben → BlakeR1234
Assignee | ||
Comment 23•24 years ago
|
||
I wish I'd known there were images attached to this...would have saved me a lot
of trouble. In any case, I have a fix for this. Ben wants me to wait until he
lands his next classic skin changes to avoid merge conflicts, so I'll check it
in after that happens...
Also, I'm only going to fix this on Windows, and perhaps only in the Classic
skin.
Status: NEW → ASSIGNED
Keywords: correctness,
pp
OS: All → Windows 98
Hardware: All → PC
Summary: Radio menu item should be drawn with dot not tick → [FIX] Radio menu item should be drawn with dot not tick
Whiteboard: [FIX IN HAND]
Target Milestone: M21 → M18
Assignee | ||
Comment 24•24 years ago
|
||
this has been fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in
before you can comment on or make changes to this bug.
Description
•