103417 - `View' > `Show/Hide' submenu must not have subsubmenus

Status: RESOLVED EXPIRED

Description

[Matthew Paul Thomas]

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

[Christopher Hoess (gone)]

Adding dependencies...we can't really fix this until we have decent perf.

Comment 2

[Matthias Versen [:Matti]]

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

Comment 3

[Jesse Ruderman]

Getting rid of the pref would mean locking it in the "show only as needed" 
state, right?

Comment 4

[Boris Zbarsky [:bz] (Vacation Jun 16-24) (no decent commit message means r-)]

I think the idea is to move the pref to prefs instead of having it in the menus.

Comment 5

[Stuart Ballard]

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

Comment 6

[Pierre Chanial]

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

[marlon bishop]

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

[sairuh (rarely reading bugmail)]

marlon: yes, that would be bug 108099 [adding this as a blocker for it].

Comment 9

[Stuart Ballard]

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

[simon.hetzer]

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

Comment 11

[Matthew Paul Thomas]

[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

[Alex Bishop]

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

[Jesse Ruderman]

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

[Christopher Hoess (gone)]

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

[Manish Jethani]

Created attachment 145844 [details] [diff] [review]
Patch for changing radio buttons to checkbox

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.

Comment 16

[Robert Kaiser]

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

Comment 17

[Robert Kaiser]

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