Closed Bug 103470 Opened 23 years ago Closed 14 years ago

Links Bar menu(s) should not contain any disabled items

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: mpt, Assigned: jag+mozilla)

References

Details

The `Document' and `More' menus in the Links Bar contain many disabled items for
no good reason. A particularly noteworthy example is <http://www.apple.com/>,
where in each of the two menus the only enabled item is the bottom one (and
where in the `Other' menu the only enabled item is hidden in a submenu
containing only itself).

There are two general problems here. Firstly, the presence of so many disabled
items in the menus slows the user down when looking for enabled items. Secondly,
many of the items in the menus implicitly encourage bad Web design by inviting
authors to specify them. In particular:
*   The suggestion that `Table of Contents' is distinct from `Up' or `Site
    Home' would encourage the creation of annoying splash pages which do not
    list the site's contents.
*   The inclusion of a `Glossary' item would encourage the author to make a
    dedicated glossary instead of using the DFN element and/or TITLE attribute
    appropriately.
*   The inclusion of a `Help' item would suggest that it's acceptable to
    provide a Web design which is so unusable that it needs separate help.
*   The inclusion of a `Search' item would suggest that the best UI for
    searching a site is to only have a dedicated search page, when in fact the
    best UI is to have a search box in a consistent place on every page.
*   The `Bookmarks' item would serve only encourage authors to link to
    unrelated bookmarks from their personal pages, and could also be mistaken
    by the user for a fifth access point for their own bookmarks.

I suggest that these menus (or menu, when bug 103459 is fixed) only contain
those items which the author actually put there.
Blocks: 103053
I think these arguments are, quite frankly, rather silly.  Many sites do have a 
poor user interface, and it's (IMO) more useful to let people navigate through 
such a UI (which is unlikely to be fixed anyway) than let them suffer 
collateral damage from our attempts to force site designers to design such UI.

Be that as it may, this really ties in to bug 103459.  The original rationale 
behind the separate menus was that we would have <link>s whose rel values 
we "understood" in Document, and values not defined by any spec would be in 
Other.  The values in Document were made always-present relatively late in the 
implementation, on the grounds, I believe, that having such links change in 
position depending on which ones the page happened to specify would be 
confusing.

I personally believe that we should "recognize" a larger number of rel types; 
since this would create an unwieldy and cumbersome menu under the current 
scheme, I'm inclined to support your idea of combining the two and making the 
advantages of "recognition" available elsewhere in a site-map-constructing 
sidebar or some other metadata foo.
There are two good reasons for disabling items instead of hiding them.  One,
promote the use of LINK by showing what's available.  Two, dynamic menus prevent
habituation.

The logic of your argument seems to be, "some of these menu items encourage bad
web design, so lets hide all unused items and hope that authors don't figure out
how to use the ones we don't like".  How much better it would be if we just
removed the offending items from the menu entirely.  There's still a safety net
for unrecognized link types.  They'll appear at the bottom of the More (or Other
Links) menu.

Useful link types deserve consistent, visible placement in the UI for the two
reasons cited above.  Any other types don't get prominent placement.  Assessing
which link types are valuable is part of what bug 103469 is about.
the [browser/mail/news/composer/ all MS app Toolbars] disables buttons in
Mozilla/MS stuff and not hide them.  People are used to this behavior, its the
way to go.
if they were hidden then half the time users would stay stuff doesn't work on
xxx page.. to disable tells the user two things:

1) the buttons are there

2) they function when necessary.

diabling helps to prevent clicking on things your didn't wanna click on, but
show that there is some functionality for it.
QA Contact: sairuh → claudius
> One, promote the use of LINK by showing what's available.

An infinite variety of LINKs are potentially available.

> Two, dynamic menus prevent habituation.

Habituation will never apply anyway, since the links will be extremely variable 
from page to page, and a bunch of disabled items won't help this situation.

> lets hide all unused items and hope that authors don't figure out how to use
> the ones we don't like

No, let's not *encourage* authors to introduce LINKs which will probably reduce 
the usability of their site, by taunting them with disabled menu items.

> How much better it would be if we just removed the offending items from the
> menu entirely.

Not at all. If the offending items are off by default and the author adds them, 
we can be a lot more certain that they were included for a good reason.
link toolbar bugs -->choess for triage
Assignee: blakeross → choess
The link toolbar is not chrome, it is rendered document content integrated into
the chrome. It's none of our business to insert things we may feel are important
into the document.

All links on the toolbar that were not included by the author are nonfunctional
random links inserted into the document against the author's will. This bug
report toting items such as 'Chapters' 'Subsections' 'Appendices' and what have
you is just silly and slightly confusing; on pages that are specifically not
made to be silly and confusing it could really hurt the experience.

http://www.apple.com that mpt mentioned is a good example: the bunch of disabled
items - those the page author chose not to make use of - bumping the 'Index'
link  - a method of navigation which the page author did choose to include - to
the bottom of the menu is, well, quite rude.
OS: Mac System 9.x → All
Hardware: Macintosh → All
> The link toolbar is not chrome, it is rendered document content integrated
> into the chrome.

Huh?  If it looks like chrome, smells like chrome, and walks like chrome, then
it's chrome.  The Site Navigation Bar is chrome.

Are you suggesting that the window title bar isn't a window decoration simply
because we include the page title in it?


> It's none of our business to insert things we may feel
> are important into the document.

So that would make us doubly rude, since we're already appending "- Mozilla
{Build ID: ..." to the title bar text?  No, I don't think so.

> This bug report toting items such as 'Chapters' 'Subsections' 'Appendices'
> and what have you is just silly and slightly confusing

I don't understand what poing your trying to make.  Stating that something is
confusing or silly does not make it so.  Please explain how you arrived at those
conclussions.


The purpose the this toolbar is to provide a consistent UI for the standard type
of link relationships.  Consistent means also having menu items in their same
position every time.

One problem with hiding items that aren't available is that it provides no
feedback to the user.  The user has to wonder "is the Search menu item
unavailable or am I misremembering where it's supposed to be".  Users can't
memorize hidden items.  Maybe they haven't used used the Search link often
enough to be certain where it is.  When they go looking for it, they'll have to
open up alot of menus hunting for it before deciding that it's not to be found.
 This is not a problem if the item is disabled.  Disabling provides visible,
immediate feedback that an item is unavailable.  Once they find the disabled
Search link, they can stop poking through menus, confident that the item was
were they thought it was, even though it's unavailable right now.

When it comes to making people happy, user comes before page author.  Static
menus may frustrate some page authors, but dynamic menus will frustrate users
even more.

The benefits of habituation and visible feedback far outweigh the cost of having
to move your mouse a bit further to reach a menu item.

> > One, promote the use of LINK by showing what's available.
> 
> An infinite variety of LINKs are potentially available.

And from this infinity, the W3C has selected a very few to *recommend* to page
authors.  This is what's called a standard.  We're allowed to promote
standards...encouraged even.


> > Two, dynamic menus prevent habituation.
> 
> Habituation will never apply anyway, since the links will be extremely
> variable from page to page, and a bunch of disabled items won't help
> this situation.

If the sites I visited were completely random, I would agree.  However, there
are a handful of sites that I use an order of magnitude more often than any
others.  Even if one of them were to use a healthy dose of LINKs, that's enough
for me to become habituated to their location.  Static menus means this
habituation pays off when I visit other sites that might also use these LINKs, a
distinct possiblity since they're a standard.


> > lets hide all unused items and hope that authors don't figure out how to use
> > the ones we don't like
> 
> No, let's not *encourage* authors to introduce LINKs which will probably
> reduce the usability of their site, by taunting them with disabled menu items.

See my previous comment for why visibility is better usability than hiding.
While I agree with the argument for disabling instead of hiding in general, I
have to side with Tuukka in that the links bar really serves as an extension of
the page content.  My first reaction upon opening the Document menu on a
Bugzilla list was "what the hell?"  One enabled item, and six that were in no
way possible relevant to the type of page I was viewing.  Yes, that's why
they're disabled, but things like subsections and appendices aren't relevant to
the vast majority of web content, and will probably never be enabled for most
everyday users who view things like news sites.  It turns into clutter, whereas
most menu items and buttons in other bars will be enabled a good percentage of
the time.

I think that if Next is enabled, Previous should be visible and disabled because
it is likely to be enabled in similar pages, and is therefore relevant.  You
could pair First and Last this way as well.  However, I think other items should
only appear as defined because otherwise they turn into a visual distraction. 
Inundating the user with disabled choices, particularly bad in the Document
menu, isn't good.
Just to comment on some of the habituation/consistency arguments:

Consistency is good.  However, displaying irrelevant options is bad.  That's why
the links toolbar only appears when needed.  That's why specialized toolbars
appear and disappear in other programs as well, depending on the type of work
you're doing within that program.  My problem is that Top/Up and many entries in
the Document menu will NEVER be relevant to certain types of pages, and
therefore should be hidden.

As for habituation, that can occur on a site by site basis.  You can get used to
Up appearing in a discussion but not in other types of pages where it isn't
relevant.  We're already used to the fact that some sites have a table of
contents, some just have Next/Back, and some have Next/Back with numbers for
intervening pages.  But I guess this argument depends on the philosophical point
that the links bar is closer to page content than application chrome.
> My problem is that Top/Up and many entries in the Document menu will NEVER
> be relevant to certain types of pages, and therefore should be hidden.

Top will mostly likely get renamed to "Site Home".  That's what it's intended to
be.  Almost all sites have a home/splash page.  Of those, almost all have a link
on every page that takes you home.  Of all the types recognized by the toolbar,
Site Home is the most valuable.

Up deals with hierarchical sites, which also describes most sites out there.  Up
should take you one level up in the hierarchy, presumably to a more general or
more inclusive topic.  Probably the best example would be Yahoo! or DMOZ. 
Whether the average user benefits from having this new navigation axis is
debateable.

Document links don't present much in the way of distraction when used properly.
 Bugzilla uses "Table of Contents" to link to the original search result list
when paging through individual bug search results.  This is a misuse of Table of
Contents.  Bugzilla also uses the "Up" link type to link to this same page. 
That's the right way to do it.

The Document menu should be reserved for pages that follow a book or book-like
layout.  Whenever an author provides a ToC, I also expect to find Chapters,
Sections or Subsections (and appendices and idexes if they have 'em).  In this
case, whenever the Document menubutton is enabled, there will be more than one
item active.  When these links aren't being used, it's only a single disabled
menubutton.  Hardly distracting.

Of course, we need documentation explaining recommended uses for the LINK types
to help page authors use them in ways that help users navigate their site. 
Currently we're still debating what the LINK types mean (bug 103469).  I'm sure
plenty of people will disagree with my suggested use of the Document LINKs.


> As for habituation, that can occur on a site by site basis.

You sound like you think that's a virtue.  The biggest purpose of the LINK
toolbar was to provide a consistent UI that *doesn't* change on a site by site
basis.  Users don't have to hunt for where your designer decided to put the
homepage link, or the search link, etc..  Keep in mind that LINKs and regular
anchor's aren't mutually exclusive.  You're designer can still put that Home
anchor wherever they want in the content frame.  The user can choose to hunt
down the link on your page, or go to the standard "Site Home" link in their
browser located in its standard location.


> But I guess this argument depends on the philosophical point
> that the links bar is closer to page content than application chrome.

The toolbar was designed to be chrome.  I suggest that anyone who disagrees with
this approach join bug 102990 and/or lobby to have bug 103204 reopened.  The
LINK UI proposed there is certainly more philosophically aligned with what
you're looking for.  In the meantime, this is the Site Navigation Toolbar and
it's part of the browser chrome.

The main purpose of the link toolbar IS to provide a consistent interface for
common operations in web sites.  But I agree with Greg -- the consistency can
still occur depending on the overall type of the site.  There are a few kinds of
sites...

- Simple sequences (Previous, Next)
- Sequences w/ begin & end (Begin, Previous, Next, End)
- Hierarchy (Top/Start, Up)
- Sequence & Hierarchy
- Book metaphor (Table of Contents, Glossary, etc.)

If a REL value in one of the above groups is used, then all items in the group
should be shown.  Otherwise, they should be hidden.  This is a compromise
between leaving all of the items visible and disabled (consistent but
cluttered), and hiding the disabled items individually (less cluttered but
inconsistent).

Of course, we'd have to decide what the appropriate groupings are.  Documention
should explain these different types of LINK categories to page authors, and how
to use them consistently.
I disagree that it's a compromise.  Either the UI is consistent or it isn't,
i.e. either the UI elements can be found in the same place, or they can't.
Think of a context menu.  If you right click on a page in Mozilla, you get:

   Back
   Forward
   Reload
   Stop
   ----------
   View Page Source
   View Page Info
   ----------
   ...

If you right click on a page with frames, you get:

   Open Frame in New Window
   Show Only This Frame
   ----------
   Back
   Forward
   Reload
   Stop
   ----------
   View Page Source
   View Frame Source
   View Page Info
   View Frame Info
   ----------
   ...

Things like View Frame Source are hidden when they are not relevant to the TYPE
of page.  Things like Stop and Forward are disabled when they are relevant but
not available.  By choosing what to display by relevance and not availability,
we limit the number of visible configurations while not inundating the users
with disabled choices.  This is the compromise.  If we group links bar controls
for display, we make an educated guess as to the type of page and which buttons
are relevant.  Tim's post spells out the types of pages very well.

The links bar, by having icons and limited choices, would be very easy to
understand at a glance; it doesn't need to be scanned like a long text menu.  By
having too many disabled choices, you actually force the scanning you're trying
to avoid because what's available isn't immediately apparent.  Maybe this
wouldn't be the case if the bar was enabled much of the time and people were
familiar with it.  But the reality is that few sites use it and people are only
likely to see it every once in a while.  You limit the usefulness of the bar in
these cases, which is by far the most common case.  For the minority that will
see the bar often because they spend a lot of time in certain sites, again,
hiding by relevance and not availability greatly reduces the number of visible
configurations.
> Think of a context menu.  If you right click on a page in Mozilla, you get:
[snip]
> If you right click on a page with frames, you get:
[snip]
>
> Things like View Frame Source are hidden when they are not relevant to 
> the TYPE of page.  Things like Stop and Forward are disabled when they
> are relevant but not available.

You're assuming this is good UI design.  What about framesets that are
graphically designed to look like a seamless page?  To the user, it's just
another page and the different context menu is an arbitrary change.

Context menus are a different animal.  And in Mozilla I think they're generally
implemented poorly in the content frame.  When I click on a link, why should I
see a context menu that is the union of link menu items and page menu items (or
link, page, and frameset menu items!)?  Just give me the items relevant to the
link, please.


>  By choosing what to display by relevance and not availability,
> we limit the number of visible configurations while not inundating
> the users with disabled choices.  This is the compromise.

No compromise.  The user loses the ability to become habituated to the
interface.  That is what I am objecting to.

The erroneous assumption is that the link toolbar is always going to consist
mostly of disabled items.  The correct assumption is that one day, LINK use will
be commonplace.  Otherwise, why waste development time, system resources, and
screen real-estate on the toolbar in the first place.  Make it a sidebar so it
can be ignored.  If LINKs never become commonplace, then a toolbar is the wrong
UI.  I'm not saying LINKs will become common, just that having a toolbar in the
first place is based on that assumption.

> The links bar, by having icons and limited choices, would be very easy
> to understand at a glance; it doesn't need to be scanned like a long
> text menu.

The current UI is already easy to understand at a glance.  It becomes even
easier to understand if we remove the words First, Previous, Next, and Last and
turn it into a composite widget that anyone who has used PowerPoint is familiar
with.

> By having too many disabled choices, you actually force the scanning
> you're trying to avoid because what's available isn't immediately
> apparent.

No, it doesn't work that way.  After you become habituated to the locations of
the toolbar and menu items, you don't scan anymore.  Instead, you look directly
at the widget you want.  Then you notice it's disabled.  Or maybe you click the
widget out of habit, then have to look at the widget to see why nothing
happened.  With an ever changing toolbar/menu, you have to scan each time to
find where the item you seek is located.

> But the reality is that few sites use it and people are only likely to
> see it every once in a while.  You limit the usefulness of the bar in
> these cases, which is by far the most common case.

So, the question becomes, do we design a UI that is sub-optimal in the medium to
long term to better support the short term?  I say design for the future we hope
the link toolbar will help bring about.  We already have an auto-show feature to
help transition from the present sparseness of LINKs to a future where LINKs are
common.  In that future, usrs may become confused when their link toolbar
disappears on some sites.

Habituation is an important attribute of good user interfaces.  You should never
discard it unless you have good reasons to.  None of the examples presented
justify doing away with habituation.

People either agree with me by now, or they never will.  So I'll make this my
last argument in this debate.

Whether you agree with me or not, read Raskin's "The Humane Interface".  He
makes more cogent arguments about this and many other topics than I could ever
make.  You'll be better for having read it even if you come away with your
philosophy unchanged.  Then follow it up with anything by Donald Norman... ;)

> If it looks like chrome, smells like chrome, and walks like chrome, then
> it's chrome.  The Site Navigation Bar is chrome.
Yes, that smelliness is covered in other bugs which (probably) need to be fixed 
before the UI will ever see the light of day in major Mozilla distributions.

> So that would make us doubly rude, since we're already appending "- Mozilla
> {Build ID: ..." to the title bar text?
Yes, that's bug 56995.

> Context menus are ... generally implemented poorly in the content frame.
Yes, that's bug 75338.

> So, the question becomes, do we design a UI that is sub-optimal in the medium
> to long term to better support the short term?
The current UI is highly sub-optimal in the long term, because it contains many 
items which it will *never* be a good idea to include in the vast majority of 
Web pages. And the usability loss from (1) having to wade past them and (2) 
misguided authors adding them where they're not relevant is much greater than 
the usability gain from (3) the other items being in a consistent position.
Product: Core → Mozilla Application Suite
Component: XP Apps: GUI Features → UI Design
Assignee: choess → jag
QA Contact: claudius
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
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: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.