Closed Bug 103470 Opened 23 years ago Closed 15 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: 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.