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.

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"); }

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.

Moving to M12.

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.

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.

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.

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.

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.

Mass move to M13.

spam: changing qa contact from ckritzer -> paulmac for xul bugs

BULK MOVE: Changing component from XUL to XP Toolkit/Widgets: XUL. XUL component will be deleted.

Sending to our UI owner

Move to M16 for now ...

spam, open xptoolkit qa contact moving over to jrgm

Move to M20 target milestone.

*** Bug 43120 has been marked as a duplicate of this bug. ***

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...

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.

this has been fixed

vrfy fixed in new win98 build