"The top ten usability problems in Mozilla" - revisited
Back in December 2001, kiwi UI designer "mpt" (Matthew Thomas) wrote a list of "the top ten usability problems in Mozilla" - i.e. the Mozilla Application Suite. He kept it updated until June 2002. The release of Firefox 3 seemed like a good moment to revisit his list to see which, if any, of the problems have been addressed in the past six years. mpt now lives in London and does UI work for Ubuntu, but was kind enough to provide up-to-date comments on the original and on my comments.
The original text is in the left-hand column, my comments are in the middle (some stuff is better, some is still the same), and mpt's new comments on both of those are in the right-hand column. Where relevant, I have also compared the list to Thunderbird 3.0a1.
The top ten usability problems in Mozilla
“There’s so much wrong with mozilla. mpt’s top ten sums it up pretty nicely.” — Dave Hyatt
Mozilla has many serious usability problems which need to be fixed before any lightly modified distributions — such as Netscape — will be chosen by millions of users in the way that previous versions were. This article lists the worst of the problems in order of importance, in an attempt to focus the minds (and typing fingers) of those who are able to fix them.
This was written back when mozilla.org was a technology provider rather than a distributor of end-user products.
Note that “the top ten usability problems” is not the same thing as “the worst ten areas of the interface”. For example, the Forms Manager is so complex as to be almost useless, but its obfuscation means that few people will even try to use it, so it is not as much of a usability problem as it otherwise would be.
Firefox no longer has a Forms Manager - instead, there is just a checkbox to enable or disable remembering form data, and a way to clear it. Advanced users can also delete individual items using the Delete key when the item is highlighted in the options list. Fascinatingly, I can't find an extension to restore the original ability to view and edit the list. Clearly, not a missed feature.
Internet Explorer for Mac had an "AutoFill Profile" preference pane with 12 fields for you to fill in. Opera has a "Wand" preference pane with 14 fields. Mozilla's Form Manager had not 12 fields, not 14 fields, but 116 standard fields, plus fields for whatever custom data you'd saved. Crackarific.
This article will be regularly updated to reflect the current state of Mozilla, with links to bug reports, specs, and other information.
You won’t hear much about this problem from Mozilla contributors, the sort of people who can pick their way with ease through a plethora of badly structured and overly wordy menus. But for millions of other people, this is a deal-breaker. These are the people who prefer to avoid menus if possible, who would much rather click a big fat toolbar button to go to their home page or to get their e-mail.
For these people, Navigator’s current toolbar layout is fundamentally broken. The root cause is the Toolbar and Address Bar being welded together, leaving no room for any buttons besides the standard four (Back, Forward, Stop, and Reload), and preventing any meaningful customization of the Toolbar because there isn’t any space available to customize. There are other effects, however, which are worse than any lack of customizability: the Home button is shunted into the “Personal Toolbar” (Bookmarks Bar) where it doesn’t belong, and there are constant requests to add other buttons to the Personal Toolbar or to the Links Bar where they don’t belong either.
Firefox has fully-customisable toolbars with button-level granularity - it was one of the first features the team implemented. The Home button is now back in the standard toolbar by default.
My complaint about the toolbars was based on my experience at an Internet cafe, seeing the sheer number of people who used a Web browser and nothing else, and who never used menus. So they needed toolbar buttons for more than just Back, Forward, Stop, Reload, and Home. Several years later, Web users are a bit more skilled on average. And Safari and Camino can more easily get away with having five toolbar buttons visible by default, because menus are much easier to use in Mac OS than in other systems (other Apple apps have simpler toolbars than their Microsoft counterparts for the same reason). But it wouldn't surprise me at all if Windows Internet Explorer 7's bizarre toolbar layout was a result of Microsoft aiming for a single Safari-/Firefox-like toolbar, but then being driven by usability tests into adding another toolbar button, and another, and another.
Even for advanced users, the toolbar layout is annoying. The shortened address field doesn’t show as much of a URI, and the auto-completion menu doesn’t show as much of an auto-completion’s title, as it does in competing browsers. You can’t switch between 16px×16px and 24px×24px toolbar icons, and you don’t even have the ability (which was present in every previous incarnation of Mozilla) to choose between icons, text, or both for toolbar buttons.
Larger screen sizes mean that URL bars are longer, although the search box and the EV indicator encroach into the space. The AwesomeBar now shows full page titles. You can switch between large icons, small icons or text only.
- Design proposal: Navigator chrome overview
Over the last twenty years humans have become conditioned to expect that computers will take an absurdly long time to do things. Whereas televisions, CD players, VCRs, and other devices are usually ready for action a couple of seconds after being turned on, computers regularly take a minute or more, and then repeatedly make the user wait for several seconds while carrying out simple tasks.
Mozilla, however, performs worse than even these pessimistic expectations. On Windows, the Quick Launch feature makes it start up as fast as it should, though at the expense of memory consumption. And when loading Web pages, Mozilla is more usefully responsive than most other browsers. The problem is with everything else, where Mozilla is breathtakingly slow.
Quick Launch (a system where Mozilla 'cheated' and loaded itself at startup) is no more.
On platforms other than Windows, Mozilla takes considerably longer to launch than any other browser. Opening a new window is slow, regularly taking between three and ten seconds (anything over one second is highly frustrating), and there are similar problems with closing and redrawing windows. To a large extent the slowness is due to Mozilla’s memory consumption, which regularly sends it into the mire of virtual memory on machines which don’t have large amounts of RAM.
Consistency is almost always good in an interface, and in few places is this more true than when performing basic text editing operations. The exact effects of keys like Backspace, Delete, and the arrow keys with or without modifiers, are not advertised in the way that other keyboard shortcuts are advertised in a program’s menus; instead, they need to be almost exactly the same between programs.
Mozilla’s text editing control has always been very buggy — the insertion point often doesn’t move where you’d expect, arrow keys often don’t do what you want them to, and some functions just don’t work at all. To be sure, behavior is improving steadily, but it is still very frustrating to use.
Gecko's basic text editing is now good, although a lot of recent work on better rich text editing has not made it back to the trunk.
- Bug 28583: Focusing text widget (except on click) should select widget contents
- Bug 92851: wrap=virtual in a TEXTAREA element doesn't work as expected
- Bug 108125: Move to next word (Option/Ctrl+Right) gets stuck to the left of punctuation
- Bug 82160: TEXTAREAs should always have a vertical scrollbar by default
The first and third bugs in this list are now fixed; the second and fourth are not, although the second is a rare case and sites sometimes expand text areas vertically as you type to avoid the fourth.
In a Web browser window, some Web pages will be usable and some will not. In the long run, people will tend to favor those which are usable, and the unusable sites will die. E-mail messages, on the other hand, are mostly just plain text; there is relatively little to distinguish between them presentation-wise. Here, the usability requirement falls squarely on the mailer: those mail programs which present messages nicely will succeed, while those which don’t will fail.
Unfortunately, here Mozilla performs quite badly. A major part of this problem is in presentation of message headers — Mozilla shows them in a chrome block which cannot be selected, copied, or scrolled out of the way once you’ve read them. This in turn causes further problems: Mozilla heavily truncates long lists of addressees, and (when in “Normal Headers” mode) does not show the useful Organization and References headers which 4.x did because they would take too much space in the chrome block.
Message headers are still an unscrollable chrome block, although some elements are now selectable and copyable. Long lists of addressees are still truncated by default and Organization and References are not displayed. You can Show Full Headers, which shows everything, even the irrelevant, but there's no hotkey. If there are too many headers in this mode, you can't see any of the message at all.
In Ubuntu, Thunderbird is the best mail client I've found for my purposes, but the header display still annoys me greatly. With a typical three-pane layout, in a maximized Thunderbird window (with a small icons-only toolbar), and with the default Ubuntu panel layout, only about 10% of my screen ends up being available to show the text of e-mail messages. The header display is a big contributing factor to this problem.
In the message body, the problems continue. The message pane doesn’t obey your settings for preferred foreground and background colors — you can have any color you like, as long as it’s black on white. There are some nice features for styling messages — you can choose between fixed-width or proportional font, and *hacker-style* /formatting/ and smileys :-) can be rendered apropriately. However, these are the sort of features which will go wrong for individual messages, so you want to be able to toggle them on and off quickly; unfortunately, they’re buried in a panel of the Preferences dialog, making them difficult to get to.
Foreground and background colour-setting now works. Message-styling features are still toggled via the preferences.
It’s a fairly simple rule in interface design. Where there are two (or more) methods of carrying out a task, and those methods are similarly accessible, users will typically waste more time wondering which method is faster to use than they would have wasted by choosing the slower of the two methods. For example, when programs include a “Close” button at the bottom of a window which already has a close button in its title bar, users waste time wondering which one they should click.
There is one critical example of this problem in Mozilla: the Search function. There are no fewer than six built-in methods for carrying out a Web search in Navigator:
- Enter your search text in the address field, and hit the “Search” button.
- Enter your search text in the address field, and choose the search item at the bottom of the auto-complete menu.
- Hit the “Search” button, then enter your search in the resulting search page.
- Choose “Search the Web” from the “Tools” menu, then enter your search in the resulting search page.
- Choose “Search the Web” from the “Search” submenu in that same “Tools” menu, then enter your search in the resulting search page.
- Open the “Search” Sidebar panel, resize the Sidebar because it’s too narrow by default to show the entire panel, and enter your search.
Firefox has 3 methods of carrying out a search that I know of: typing a non-URL in the address field, typing in the search box, and Tools | Web Search (which just focusses the search box, like Ctrl-K does, so it's arguable whether it counts as different). There's also a search option on the right-click menu if you have a selection.
Bravo for the improvement, and I should have been imaginative enough to suggest a search field instead of a button.
To anyone who doesn’t spend hours a day using Mozilla and becoming blind to its flaws, this is hopelessly confusing. At least it’s not quite as bad in Mozilla as it is in Netscape’s distribution …
- Hit the “Search” button on the Personal Toolbar, then enter your search in the resulting search page.
… but it’s still pretty bad. After three years of development, the entire suite of search paraphernalia in Mozilla is slower and less intuitive to use than the Google bookmarklet I keep on my Personal Toolbar. It shouldn’t be that way.
The Search box is pretty much the same as this bookmarklet, but with guess-as-you-type as a bonus.
To a large extent, making the Search function usable depends on fixing Navigator’s toolbar structure (putting a single, unambiguous “Search” button on the main Toolbar) and fixing its menu structure (having only one “Search the Web…” item in the “Tools” menu). That alone would increase Search usability by at least 50 percent (one measure of that, incidentally, would be the revenue that Netscape earns from the feature). Converting the Search sidebar panel into a simpler HTML version, and simplifying the customization options, would produce even bigger gains.
This is basically what we did - the Search box could be said to be the "Search button" on the Toolbar, and there is a "Web Search" (one less word than "Search the Web") option on the Tools menu. The Search Sidebar is no more. Of course, you can always install extra toolbars like Google's to get more search methods if you miss them.
Mozilla is currently heavily lopsided towards expert users, and people who prefer using the keyboard to using the mouse: as mentioned above, it has not enough toolbar buttons, and conversely it has too many menus. Menus are the most difficult GUI control to use, so you need to keep them as simple and uncluttered as possible. Mozilla, unfortunately, does the opposite.
In the future, as browsers become more thoroughly integrated with the platforms on which they run (so that Bookmarks and Help become part of the platform rather than part of the application, for example), and as applications which run inside the browsers become more complex, browsers will probably become very simple and unobtrusive and end up with about four top-level menus. Mozilla’s menu bar, meanwhile, currently has ten menus. That’s ridiculous.
Bookmarks are not yet a platform-level feature. Help has actually migrated to the web. Browsers are arguably becoming simpler in their UI. Firefox has seven top-level menus - File, Edit, View, History, Bookmarks, Tools and Help.
Even in the menus which should remain, there are problems of complexity. The “File” menu buries “New Window” in a submenu, following that up with two “Open” items instead of one, and continuing with a structure which — like the “Window” menu — makes sense only for Macintosh users. And the “View” and “Tools” menus are burdened with poor logical order, redundant items, and an overdose of submenus.
New Window is no longer in a submenu. There are still two "Open" menu items, although Open Location just focusses the URL bar in the same way that Web Search focusses the Search box. View still has five submenus (Toolbars, Sidebar, Zoom, Page Style, Character Encoding), but Tools has none.
I think it would be a useful design exercise to try and abolish Firefox's "Tools" menu, since it's a junk drawer. Camino and Safari both do without one, with scant help from their respective "Window" menus (they both contain "Downloads", which could reasonably go in the "File" menu instead).
If you want users to switch from a competing program to your own, you need to do more than just provide a program which is better in every respect. You also need to make it very easy for users to migrate from their current program to your one, and to allow them to switch back to their previous program so that they will be more willing to try your one.
Microsoft understands this very well: Internet Explorer lets you import your bookmarks and cookies from Netscape, and provides a “Help for Netscape Users” item in its “Help” menu. Outlook Express will import your account settings, your messages, your address books, your mail filters, and even your signature file; it also provides a “Test Drive mode” so that you can try the new program without losing messages from your current mailer.
Firefox on Windows has a "Help for Internet Explorer Users" menu item.
Mozilla, on the other hand, is woefully incomplete in this regard. You can show your Internet Explorer favorites as a folder in your Mozilla bookmarks, but you can’t import or edit them. You can’t import messages from a Netscape Communicator 4.x profile after creating a Mozilla profile, nor can you import your address book without exporting it from 4.x first. (This leads to the alarming situation where it is easier to migrate from 4.x to Microsoft equivalents than it is to migrate from 4.x to Mozilla. Little wonder that Netscape 6.x’s market share is so low.) And the ability to import information from Mozilla’s main competitor, Outlook Express, is completely absent.
Firefox imports IE favourites (again, one of the first things Ben implemented). The Netscape 4.x migration issues are now largely irrelevant, but Thunderbird auto-imports Mozilla 1.x or Netscape 7.x mail data, as well as a whole class of other applications, including Outlook. You can also do this even after you've created your profile.
Shortcut menus (known as “contextual menus” on Mac OS) are a method of quick access to extremely frequent commands (such as “Back” or “Forward”), and commands which are specific to the selected or focused item (such as “Block Image” and “Show Only this Frame”). Mouse down on the item, drag the mouse a small distance to the item you want, mouse up, and you’re done.
Or at least, that’s the theory. And that’s how it works on Linux. But on Windows, Mozilla breaks with previous versions (and with every other kind of menu) in requiring two clicks, rather than a single drag, to select an item — doubling the amount of time taken to use the menu. And on Mac OS, the menu often remains open long after you’ve decided you don’t want it any more.
The Windows two-click problem is apparently still not fixed.
Once you do get the menu open when you want it, however, you might well wonder why you bothered. For most of last year, Mozilla’s shortcut menus were too long and too inconsistent for anyone to be able to use them quickly. Now the length problem has largely been fixed, but at the unnecessary expense of cross-menu consistency, and with the bizarre use of a submenu for frame-specific items. The net result is that the menus are much slower to use than they could be.
Context menus were mpt's nemesis for quite a while. They did eventually get cleaned up. The maximum number of entries was once 30; I can now only manage 15 (linked image in frame) without extensions. Frame stuff is still in a submenu, but given that it contains most things on the standard context menu repeated, I can see why this is still done. And frames are far less common than they were.
- Specification: Content area shortcut menus
Mozilla, like all other minority browsers, is in a precarious position on the Web. It is trying to provide a good user experience rendering files in a particular format (HTML), where the details of that format are largely (though indirectly) under the informal control of a company which has a near-monopoly on the browser market and every interest in seeing that dominance continue.
Like other browsers, Mozilla can appeal to the authority of the World Wide Web Consortium, and the recommendations produced by the Consortium on how browsers should behave. This approach may work for most people who wander in to the Mozilla newsgroups, and it may even work for some Web developers (though this is less likely as Mozilla distributions continue to attract nearly zero market share).
Our market share numbers have improved somewhat :-), and with them the situation for standards on the web.
But such an appeal to authority will cut no ice with users, most of whom have never even heard of the W3C, let alone care about its recommendations. If a site works in Internet Explorer, and even (in many cases) in Netscape 4.x, but not in their Mozilla-based browser, without any other information users will naturally assume that the problem is with Mozilla.
So, how to solve this problem? How to break the disconnect between the public interest of supporting Web standards, and the user interest of making pages work? Unless Mozilla distributors can ship a free evangelist with every copy of Mozilla, they cannot possibly get to every faulty page before the user does, to explain to users what is going on.
Well, actually, there is a browser which ships a free evangelist with every copy. And it’s a cute evangelist, too. The browser in question is called iCab, and the ability to list the errors in a Web page is one of the features which makes iCab users such fans of the browser.
We never did do this, although we still ship the Error Console and there are many extensions which show errors in the status bar (e.g. Firebug). iCab now uses WebKit, but still has the Smiley to warn of errors.
I was on crack with this suggestion. An error icon would not have made users less angry in the slightest; only rendering the Web page usefully would do that. As penance, for the past four years I've participated on the WhatWG mailing list working on HTML 5, and I fully support its more realistic approach to reconciling de jure and de facto Web standards.
Granted, this seems like a propeller-head feature. But there are already plans to show an icon in Navigator’s status bar to notify the user if a page contains script errors, or objects which Mozilla doesn’t have a plug-in for. It would be a natural and unobtrusive extension of this idea to show a broken page icon when the page contains markup or style errors which may cause bad rendering. At the very least, this would make users less angry with Mozilla when a page does not render properly. And at most, it would help recruit the user population in the evangelism effort to return the Web to open standards.
Mozilla/4.x’s Preferences dialog had two main problems:
- there were too many preference categories, making it difficult for people to find the option they wanted;
- the odd “a branch is also a leaf” structure of the category tree resulted in categorization problems, made it difficult to expand a category branch, and (in some cases I watched) led people to be unaware that collapsed category branches had any child categories at all.
Mozilla’s current Preferences dialog takes each of these flaws, and repeats it with a vengeance. There are even more preference categories (and constant proposals for new ones), and worse feedback than 4.x when expanding or collapsing a category branch. And the problem with category branches being categories themselves has reached an absurd level.
Ben completely redesigned the preferences dialog; it now uses a tab-based UI, and has far, far fewer options. However, the ghost of it continues to haunt the Account Settings dialog in Thunderbird, which uses this structure.
Honorable mention goes to the following usability problems, which are pretty bad but didn’t make the Top Ten.
11. Cryptography interface. [Editor's note: the following was in HTML comments in the original document.] The first exposure which a user is likely to get to Mozilla’s interface for secure connections is an alert when they log in to Hotmail or another Webmail service which uses SSL, warning them — with a danger icon — that they are entering an encrypted site. This is likely to convince a novice user that using Hotmail with Mozilla is dangerous and they should use another browser instead.
Secure HTTP, like domain name resolution, is one of those things that should Just Work — there should be little if any need to configure it. In other browsers, this is indeed the case: Internet Explorer requires a single preferences panel for it, Opera (that bastion of overconfigurability) needs only half a preferences panel, and iCab gets away with just two checkboxes. Mozilla, meanwhile, has four preferences panels, from which five secondary dialogs can be opened, and most of these dialogs have been in an unfinished state for months.
Even in the sections which are apparently finished, the text ranges from doubletalk (“Set Mozilla [sic] to show a warning and ask for permission before: … Sending form data from an unencrypted page to an unencrypted page”) to gobbledygook (“SSL3/TLS Ciphersuites”). Truly, this part of Mozilla’s human interface is cryptographic in every sense of the word.
Improved, but still work to do.
12. Toolbar icon design
Been through many changes.
14. Page load feedback
Not much has changed.
Hardly any improvement since Mozilla 1.0. The status bar text is just as spastic as it was in Netscape 1.0, flitting between the dozens of things the browser is doing when loading a page. The progress bar still jumps backwards and forwards, which progress bars just shouldn't do. And it's flabbergasting that there is still no browser competent at showing progress when uploading a file. That's one thing Web browsers should be able to do perfectly, since it's (almost always) local I/O and the browser knows the exact size of the file it's uploading. Web authors engage in all sorts of inconsistent hacks to work around this.
15. Error messages
Some are better.
16. Java and plug-in installation
It used to be that plug-ins had to be downloaded and installed manually. We now have a "Plugin Finder Service" - when an unknown content type is encountered, Firefox goes off and asks the service where to get the plugin, before offering to automatically download and install it for you. I think it still requires a restart, though.
17. Encoding selection UI
Just as bad as it's been since Mozilla 1.0. The "Customize List" dialog is cruft. And that a default installation of Firefox contains sub-sub-sub-menus is shameful.
18. Mail account setup
Still too complicated.
19. Message composition window design
There are two main problems, neither of which have improved since Mozilla 1.0.
a) Adding and removing recipients is gratuitously difficult, especially with the keyboard, and especially if some of them need to be CCed or BCCed. Displaying only one recipient per line is extremely wasteful, and the addressing area continues consuming space once you've finished addressing. Imagine if word processors worked that way when writing letters!
b) Attaching a file is also gratuitously difficult. That attachments are not displayed inline with the text makes it easy to forget that you haven't attached them yet. And once you remember to do it, dragging the file into the message area results not in the file being attached, but in a "file://..." URL being inserted into the message text. Yeah, I'm sure anyone has ever wanted that.
We now have inline spell-checking in form fields.
Copyright © 2008 Gerv.
Copyright © mpt.
From an email on 4th August 2008.
Original URL: http://www.gerv.net/usability/mpt-top-ten/