Closed
Bug 103417
Opened 22 years ago
Closed 13 years ago
`View' > `Show/Hide' submenu must not have subsubmenus
Categories
(SeaMonkey :: UI Design, defect)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
EXPIRED
People
(Reporter: mpt, Assigned: jag+mozilla)
References
(Depends on 1 open bug, )
Details
Attachments
(1 file)
3.08 KB,
patch
|
Details | Diff | Splinter Review |
Build: 2001100508, Mac OS 9.1 To reproduce: 1. In Navigator, open the `View' > `Show/Hide' submenu. What you see: * A `Site Navigation Bar' submenu. What's wrong here: * `Never use more than *one level* of submenus. A submenu at the second level would be buried too deep in the interface and would unnecessarily create another level of complexity. Also, it takes more time for the user to use and peruse a hierarchical menu than a pull-down menu. It is physically difficult to use a second level of submenus without slipping off the first submenu ... Don't even *think* of doing this.' -- Macintosh HI Guidelines What should happen: * There should not be UI in the menus for controlling the appearance of LINK links, just as there is not UI in the menus for controlling the appearance of A HREF links. (And before you ask, yes, there are bugs open on the other abuses of submenus in Mozilla.)
Comment 1•22 years ago
|
||
Adding dependencies...we can't really fix this until we have decent perf.
Comment 2•22 years ago
|
||
*** Bug 103416 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
Getting rid of the pref would mean locking it in the "show only as needed" state, right?
![]() |
||
Comment 4•22 years ago
|
||
I think the idea is to move the pref to prefs instead of having it in the menus.
Comment 5•22 years ago
|
||
While I agree with this bug in principle (and always have), it was I who added (with some reluctance) the sub-menu in question. The reason I did so is that, more than a year after I originally proposed this UI, nobody has ever suggested anything better: - Multiple people have insisted that they want the toolbar to NEVER show up, thus this option is necessary. - Multiple people have insisted they want the toolbar to ALWAYS show up (ie NEVER to pop up on demand), thus this option is necessary. - The majority of people want the toolbar to show up only when it applies, thus this option must be available. In addition, we cannot ignore any of these groups except the last without producing another UI nightmare: - if we ignore the first group and provide a toggle between "Always" and "As Needed", we'd be overriding the user's explicit choice to turn the toolbar off. - if we ignore the second group and provide a toggle between "Never" and "As Needed" we'd get a menu option which apparently did nothing at all (unless the user happened to be on one of the few sites that show this feature). Either of these courses of action would result in (legitimate) user complaints. The only other option is to ignore *everybody* except the last group, and lock it into "show as needed". This seems to be what this bug is suggesting; I don't like it very much because it alienates a large group of users (including many moz luminaries who have commented to this effect in bug 2800 or bug 84728 and on IRC), for a benefit which seems to only be "we'll be following a HI guideline". All other things being equal, I'd love to follow that guideline, but until someone proposes a viable alternative, I'm in favor of the status quo. I did wait a year for alternatives before implementing it ;)
Reporter | ||
Updated•22 years ago
|
Blocks: patchmaker
Comment 6•22 years ago
|
||
Here is an alternative that gets rid of the ugly subsubmenu. As Boris Zbarsky suggested, let's move the choice to the preferences in the smart browsing window.: - Site Navigation ---------------------------------------------------- | Some sites or html documents provide facilities for browsing. | | x Enables the Site Navigation Toolbar on ------------------------ | --------------------------------------------| these specific sites |-- | all sites | ------------------------ But note the wording "enable" not "show" in the text. Enabling the site navigation toolbar will not imply automatically to have a toolbar in the window. Case 1: disable the Site Navigation Toolbar (SNT) ******* option not checked: the SNT will never appear and the SNT item in the Show/Hide submenu (SNTI) neither. Case 2: "Enables the Site Navigation Toolbar on all sites" ******* SNTI will appear and will behave the same as the other items (personal, navigation, etc...). SNTI will toggle between Hidden and Always. At this stage: stuart's population 1 and 2 (Never,Always) are happy. What about the pop 3 (as needed)? Case 3: "Enables the Site Navigation Toolbar on these specific sites" ******* In order to prevent user to select it and seeing nothing happens, SNTI will be greyed out for the sites that have no valid LINK tags (let's call these sites NVL and VL the others). For VL sites, its appearence will be normal, if the user just want to get rid of the toolbar, he can do it and undo it. Problem arise if the user wants to re-show the toolbar. He could not to that unless he is on a VL site. That's why I suggest that the toggle Hidden->As Needed would be possible even on NVL sites (so even if the SNTI is greyed). The toggle As needed->Hidden on NVL sites will be prohibited because it makes no sense to hide something not present. To summarize the case "Enables the Site Navigation Toolbar on these specific sites": what will happen for a click on SNTI: (on and off for SNTI state means the presence (or not) of the little mark on the left of the items in the View submenu) VL site? | yes | yes | no | no | greyed SNTI? | no | no | yes | yes | ------------------------------------------------------- SNTI state | on->off | off->on | on->on | off->on | SNT? | yes->no | no->yes | no->no | no->no | Reactions?
Comment 7•22 years ago
|
||
does anyone know if there is a general menu redesign/tracking bug, upon which we should mark this bug dependent? Menu spec update is scheduled to happen in the next cycle, and we should keep these issues organized.
Comment 8•22 years ago
|
||
marlon: yes, that would be bug 108099 [adding this as a blocker for it].
Blocks: 108099
Comment 9•22 years ago
|
||
I think that as long as the link toolbar appears as part of the toolbars, it would be bad UI not to have the visibility control in the same place as the visibility controls for other toolbars. So this bug kinda-sorta-depends on bug 102990 which would make it no longer a "normal" toolbar, but a special one that lives inside the content frame. The only other possibility I can think of is to have: View -> Show / Hide -> ./ Navigation Toolbar ./ Personal Toolbar Site Navigation Bar... ./ Status Bar ./ Component Bar Then "Site Navigation Bar" would bring up either a dialog box or a prefs window (with the appropriate pane selected) that would allow the three-way option selection by means of regular radio buttons.
Comment 10•21 years ago
|
||
imho sometimes you should simply forget about "proper" UI design. I don't want to go through View/Prefs all the time I want to change the behaviour of my Navigation Toolbar. Just a little comment from a users point of view ;)
Reporter | ||
Comment 11•21 years ago
|
||
[Removed mistaken dependency on bug 108099.] > until someone proposes a viable alternative, I'm in favor of the status quo. Huh? The status quo is *not* viable; it's so bad that even Netscape aren't distributing it. We need to get our priorities straight here. Having an option to turn off presentation of REL/REV links completely is much less useful than having an option to turn off presentation of A HREF links completely. After all, those pestilent A HREF links are a blight on many, many more Web pages than REL/REV links are.
Comment 12•21 years ago
|
||
I'm surprised no-one has suggested moving the Site Navigation Bar submenu up to the top level of the View menu. Is it so obviously bad that everyone rejected it out-of-hand and has been sitting here waiting for the fool who thinks it's a good idea to turn up? Well, I'm here: | View | +-------------------------------+ | Show/Hide > |_______________________ |:::Site Navigation Bar:::::::>:|:::Show Always:::::::::| | Full Screen F11 | Show Only As Needed | |-------------------------------| o Hide Always | | Stop +-----------------------+ You could argue that this makes the Site Navigation Bar inconsistent with the other Show/Hide menu items but I don't think it's really the same anyway: the other items are simple toggles whereas the Site Navigation Bar is a bit more complicated.
Comment 13•21 years ago
|
||
mpt has argued for removing "hide always". I disagree for the reason Ben Bucksch gave in bug 102909 comment 11: most sites with "next" and "prev" links have the links duplicated as <a href>s, so forcing <link> elements to appear would primarily add clutter and would discourage use of the <link> element. I think we should instead remove "show only as needed" as part of the fix for bug 33684 and bug 32627. With those bugs fixed, "up" and "top" will be available on most sites, and "next" and "prev" will be available on many sites, even when the sites do not explicitly include those <link>s. "Show only as needed" will lose its meaning because all sites will have some site navigation bar buttons enabled. One nice thing about removing "show only as needed" is that the remaining options will be "hide" and "show", consistent with other toolbars.
Comment 14•21 years ago
|
||
Both of the bugs you mention are ridiculous hacks that people have adapted to work around missing navigation infrastructure. Adding these to the Site Navigation Bar would: a) possibly interfere with well-designed sites using proper <link> navigation. b) discourage authors from writing proper <link> tags (just as having alt-as-tooltip discourages authors from creating proper alt and title attributes). I would be strongly opposed to seeing either of them implemented in the <link> UI.
Comment 15•19 years ago
|
||
This patch changes the radio buttons, "Show Always", "Show Only As Needed" and "Hide Always", to a checkbox. The "Show Only As Needed" option is now not possible through the UI.
Updated•19 years ago
|
Product: Core → Mozilla Application Suite
Updated•15 years ago
|
Assignee: choess → jag
QA Contact: nobody
![]() |
||
Comment 16•14 years ago
|
||
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
![]() |
||
Comment 17•13 years ago
|
||
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 13 years ago
Resolution: --- → EXPIRED
You need to log in
before you can comment on or make changes to this bug.
Description
•