16849 - [FIX] Radio menu item should be drawn with dot not tick

Status: VERIFIED FIXED

(Core :: XUL, defect, P3)

Description

[Michael Lowe]

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.

Comment 1

[Michael Lowe]

Attachment: screenshot

Comment 2

[Michael Lowe]

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

Comment 3

[Michael Lowe]

Attachment: radio check

Comment 4

[Michael Lowe]

Attachment: radio check disabled

Comment 5

[Michael Lowe]

Attachment: radio check hover

Comment 6

[Michael Lowe]

This bug is still relevant with new skin.

Comment 7

[hangas]

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.

Comment 8

[hangas]

Moving to M12.

Comment 9

[german]

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.

Comment 10

[Michael Lowe]

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.

Comment 11

[Michael Lowe]

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

[german]

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.

Comment 13

[Michael Lowe]

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

[hangas]

Mass move to M13.

Comment 15

[Paul MacQuiddy]

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

Comment 16

[leger]

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

Comment 17

[hangas]

Sending to our UI owner

Comment 18

[don]

Move to M16 for now ...

Comment 19

[Paul MacQuiddy]

spam, open xptoolkit qa contact moving over to jrgm

Comment 20

[don]

Move to M20 target milestone.

Comment 21

[John Morrison]

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

Comment 22

[Blake Ross]

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

Comment 23

[Blake Ross]

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.

Comment 24

[Blake Ross]

this has been fixed

Comment 25

[Blake Ross]

vrfy fixed in new win98 build