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.
don't know who is responsible for this: you or lake or no one but other FEs?
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.
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.
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?
I'm essentially asking for the MS Windows 95 behavior, which ranked a bit higher on the usability scale than its successors.
Summary: Change selected menu's color → Indicate active menu's name with distinct color change
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"
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → REMIND
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.
Summary: Indicate active menu's name with distinct color change → Distinct color change for active menu name: Win95 & WinNT
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.
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
Yup, the current behavior was what I wanted.
Status: RESOLVED → VERIFIED
Moving all UE/UI bugs to new component: User Interface: Design Feedback UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
REMIND is deprecated per bug 35839.
Status: VERIFIED → REOPENED
Resolution: REMIND → ---
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago → 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.