19301 - Distinct color change for active menu name: Win95 & WinNT

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, enhancement, P3)

Description

[marni894]

When indicating a selection of a menu, by pointing or pressing the alt key, the
selected menu should preferably be inverted in the same was as entries in the
menu. This would speed up the usage of the interface as well as better
indicating when one pressed alt by mistake.

Comment 1

[shuang (gone)]

don't know who is responsible for this: you or lake or no one but other FEs?

Comment 2

[Sean Richardson]

On Windows NT I am seeing shadowing (light grey lines) below and to the right
of the menu name when hovering over it, and then above and to the left
when it is activated - the impression is that the menu list is connected
to the menu name, rather than floating on a distinct palette as with 4.x

This looks intentional, but OTOH, this looks unchanged since at least M10,
perhaps earlier - it wasn't changed in the latest chrome update, IIRC.

I agree that the menu name should stand out more than it does - perhaps if it
and the menu list were both pale grey while the rest of the menubar remained
white, that would do it, if the current design stands otherwise.

Comment 3

[german]

Thanks, but one bug at a time please! I am forwarding this to Peter's group to
see whether something can be done to evoke/hilite the menu when the appropriate
menmonic key is pressed. This is Win32 and Linux only. Behavior: similar to when
a menu is clicked with the mouse, except the first item should be hilited, which
it is not when the menu is clicked on with the mouse.

Comment 4

[Peter Trudelle]

The behavior we are seeing now is essentially the same as in the shipping
Navigator, and other Windows apps. The Linux version goes further in this regard
than previous versions of the same apps.  What you're asking for is something
that can be done in a skin, so it really isn't an XPToolkit issue.
German, I'm not sure I understand your request.  Dropping down the menu and
highlighting an item in response to the Alt key would be counter to the Windows
UI guidelines and common usage, both of which we currently appear to be
following. Could you confirm that is what you want, or explain?

Comment 5

[marni894]

I'm essentially asking for the MS Windows 95 behavior, which ranked a bit higher
on the usability scale than its successors.

Comment 6

[Sean Richardson]

A quick comparison and clarification:

On Win32, Nav 4.x gives no indication when the mouse pointer hovers
over a menu name, highlights the menu name boldly (default: white text,
blue background); this highlighting remains when the mouse pointer
hovers over a menu item, which also gets the same highlighting. If the
menu is activated with ALT+letter, both the menu name and the first item
are highlighted the same way initially.

On Win32, Mozilla M12 gives a *subtle* indication when the mouse pointer
hovers over a menu name and another *subtle* indication of the selected menu
name when it is dropped down (described 11/25). When the mouse pointer hovers
over a menu item it gets a bold, white on blue, highlighting. If the menu is
activated with ALT+letter, the first item is initially highlighted white on
blue, but the menu name is indicated only by subtle shading around the top
and left.

The reporter is asking for the indication of the menu *name* (Edit, View, etc)
to be bolder on Win32 when the menu is dropped down, preferably matching what
is expected from other Win32 applications, including Nav 4.x. If this is done
it should be done for all menu activations, not just those done by ALT+letter.

Sorry if my 11/25 comment caused any confusion; I was trying to say that if
the resolution of this bug will not be to highlight menu names the way
that Win32 users expect, that is, if the current design prevails, the
current design could be tweaked to make both the menu and the menu name stand
out more than they do now: that would satisfy MS-Windows users' accustomed
expectation of a very clear, at-a-passing-glance, indication of the currently
active menu better than no action. This clear indication does, in practice,
help non-perfect keyboardists use the UI, as the reporter says.

Changing summary from "Change selected menu's color" to
"Indicate active menu's name with distinct color change"

Comment 7

[Peter Trudelle]

I don't think we should design for Windows 95, even if there was proof that it
was more usable in this regard.  On Win98, we appear to duplicate what other
popular apps do, which is the expected behavior, and therefore better than a
minor improvement that differs from the norm. I don't have an NT machine
handy, but I'd be curious how we fit in there, and even more concerned about how
we will fit in on Win2000.  If someone wants to make a Win95-specific skin, then
this is the kind of thing that might go in it. XPToolkit has no plans to do that
work though. Resolving as remind.

Comment 8

[Sean Richardson]

I'd not go so far as to say "duplicate" comparing the rendering of the
active menu's name in current builds of Mozilla to other Apps in Win98:
the rendering of the menu names in Explorer is much more distinct than that
in Mozilla. This is probably largely due to the Menubar in current Mozilla
being a very pale grey: All four sides of the menu name "button" are likely
being delineated, but the white edges of two sides just fade out into the
light grey - and two edges do not make a raised or detented button.

This is especially noticeable if the user presses and releases ALT without
pressing any menu accelerator keys: the File menu name is raised as a button
in both Explorer and Mozilla, but in Mozilla it is not anywhere near as
distinct.

As for Win95 and WinNT 4.0 - both use the same GUI, so everything said about
Win95 applies to WinNT 4.0 - and WinNT 4.0 will not be supplanted by Win 2000
immediately everywhere. Agreed that this isn't worth serious resources,
but it shouldn't require that: Win95 does not need a completely new skin.
The current one works as a Win95 user would expect except for this bug -
and for someone used to the distinct feedback given by Win95 (and Win 3.1),
it *is* a usability bug. So, agreed, if a skin is defined for Win95 and WinNT,
this should go in it.

Comment 9

[Sean Richardson]

The colouring of the menu name and menu item list in the current build,
if it stays, looks like it addresses the issue raised here completely.

The active menu name and manu item list currently have light grey backgrounds,
and narrow blue outlines. While this does not match the native Win32 menu
highlighting (White on Blue), it is at least as immediately distinctive,
is very easy to see at a glance, and should work well XP.

This look fits very well with the rest of the UI appearance, and is both easier
to "read" and cleaner-looking than the earlier menu appearance.

If this appearance will stay, further action is probably not needed for this
bug report.

Tested with: 2000-01-18-08-M13 nightly binary on Windows NT 4.0sp3

Comment 10

[marni894]

Yup, the current behavior was what I wanted.

Comment 11

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 12

[Christopher Hoess (gone)]

REMIND is deprecated per bug 35839.

Comment 13

[Christopher Hoess (gone)]

WFM.