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. It was endorsed by Dave Hyatt as summing up what’s wrong “pretty nicely”. 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.
Really good summary Gerv, and I think it is good that you have highlighted what has been done to fix each problem, and areas where there is still room for improvement. The Account Settings dialog in Thunderbird is particularly over-complex; while it’s not the easiest thing to design the fact that it hasn’t changed in 7 years is worrying.
Great overview. Thanks Gerv and mpt!
Some semi-random comments:
Gerv, on Linux with GTK2 window open time is measured in multiple seconds over here. It’s bad enough that I stopped using Gecko-based products on Linux once I could no longer run GTK1-based builds.
So I’m not sure where your comments about window open time come from…
Thanks, that was a very interesting read! Firefox sure has come a long way, but there are obviously still things that can be improved.
I blogged one area for improvement yesterday:
http://davidnaylor.org/blog/2008/08/four-ways-to-improve-form-filling-in.html
bz: well, the Firefox tinderbox has it at between 0.15 and 0.5 seconds on all platforms. But I’ve updated the page to note your concerns.
Character encoding. My gosh, yes. I have posted thousands of user support messages, and I still have absolutely no idea how most of that menu works. The only thing I know how to do is take a wild guess. Even the small part of it that I do understand is quirky.
I used to get really frustrated because most of the time I couldn’t get even serious bugs fixed. But then I remember that even messes like this often don’t get fixed.
Now that I think about it, there are some other weird features.
1. Two different views of history are presented in two separate menu items. The more useful view is rather hidden on the second menu level. In spite of the logic of putting it there, lots of people will never find it.
2. The Tools menu is mostly about turning nuts and bolts. There’s not much in there that is needed for ordinary browsing. Then why not put Page Source in the Tools menu next to Page Info? And why is it grouped with Full Screen?
I agree with Raf on plugins. It may not work in all cases, but seriously, how is the Plugin Finder Service “no improvement” over
1) realize you are missing some sort of plugin for viewing a page
2) search around until you find something promising
3) download an executable
4) run the executable
5) restart your browser
? For many common plugins like Flash it “just works” and you’re up and running in seconds.
The rest of your post was very interesting, and a fun trip down memory lane :)
VanillaMozilla: Page Source has been in that position since very, very early on in browser history. Moving it now would mean people would lose it.
Jon: As far as I know, we’ve always had a Plugin Finder Service. It might find more plugins now than it did then, I don’t know. Or are there some UI improvements I don’t know about because I haven’t installed a plugin in the last six years?
As I recall, back in the day, there were a lot of people that disagreed with mpt’s thoughts… although I was never on that same bandwagon and couldn’t understand why. At that time, I was first getting interested in software and I used to love reading mpt’s ideas on good UI. He’s actually the catalyst that sparked my love of thoughtful and good UI design, for that I’m forever indebted to him. Glad to see he’s still around and providing thoughts on moz! I’m glad there is still interest in good interface design for moz, thanks gerv and keep up the good work all!
Now I remember why I sometimes can’t stand “average users”. Makes me glad I use Mozilla 1.9.x instead of FF.
Re: open window time, just eyeballing it, I get under 2 seconds from button press to fully rendered start page (http://www.seamonkey-project.org/start/), and it just doesn’t feel slow.
B: At the time Mozilla was slowly dying, and what attention it did get was often negative, so I think a lot of people would get automatically defensive over any criticism, however well reasoned. The situation is the opposite today – Firefox has a decent market share and gets generally positive press. I think the greater cooperation between browser vendors has also helped to reduce the defensive atmosphere.
“VanillaMozilla: Page Source has been in that position since very, very early on in browser history. Moving it now would mean people would lose it.”
Good point, I suppose, but do you think people who are technically-minded enough to need the page source are not smart enough to find it grouped under Tools with Page Info?
I must say say that I really don’t like the “we’ve always done it that way” argument. I hear it a lot, but it doesn’t keep the interface from getting changed anyway with each new version. I guess it’s a useful point of consideration, but nevertheless it probably discourages suggestions.
I have one gripe with with Gervase’s response to point #7: the search box is not the same as the bookmarklet. There is one major usability difference. The bookmarklet allows using the noun-verb order; i.e., select something on a page to search, and then activate the verb (the bookmarklet). The search box does not allow doing that. In order to search for something you have selected, you have to select, copy, paste, possibly switch search engines, and only then hit the search button. I should be able to select something anywhere, choose the search engine, and immediately be taken to my desired search results, as quickly as is hitting the bookmarklet. Firefox makes this slightly less painful by adding a search entry to the context menu, which, as mpt points out, still carries a Hick’s Law penalty due to the extra choice. If the search box followed the correct noun-verb paradigm, these annoyances and slow-downs would go away. (Better yet, revert the search box into a single button/drop-down, and you can have both noun-verb and remove the need to choose between the location bar and search bar!)
On a somewhat related note, it’s a shame OpenSearch is so limited. Because of it, I have to have an extra bookmarklet always visible for “search this site”.
I am fairly confident that the Plugin Finder Service was not always part of Mozilla, at least not in its current state. After some Googleing, I found this press release, which announces the PFS as a new feature:
http://www.mozilla.org/press/mozilla-2004-09-14-02.html
Maybe some aspect of this feature existed in ancient times. I vaguely remember Netscape Communicator detecting a missing plugin and taking me to some netscape.com page listing likely candidates. But they still required you download the plugin and manually install it outside of the browser. The current incarnation where this is all largely automated was definitely a new feature of Firefox.
The text encodings menu is really a thorny problem, because when you need it, you absolutely need it, all of it (in all of its ugliness). With Camino (and Safari does similar), we list a small subset of common encodings that form a single, too-long menu and, ironically, are the encodings I rarely have to fuss with. This means that there’s no way to fix pages that are sent as x-user-defined but really are ARMSCII-8 (apparently that’s a common mis-declared encoding on Armenian financial and governmental sites), or are UTF-16 but are mis-declared as UTF-8 or Latin-1, or are ISO-8859-8 but are mis-declared as UTF-16, and so forth.
Until every web page in the world is served with the correct content-encoding header, or until the universal character detector is performant, works correctly 100% of the time, and handles 100% of the available encodings, an ugly text encodings menu remains necessary. Unfortunately, you can’t make a reasonable choice as to what encodings a user will need, so you have to make all of them available. It’s probably possible to make the Firefox menu suck a bit less by moving the regional sub-sub-submenus up one level, but it’s still ugly.
On the other hand, luckily that menu is somewhat like the form manager for many users :P
Jon: You are right; before, we just redirected the user to the URL given in the page and they had to download and install it manually. The Wikipedia NPAPI article explains it in the Security section. I’ve updated my analysis to be more positive. :-)
Not if you have middle-click-paste. You can select it, middle-click the search box and hit enter. I’ve certainly never found searching to be a slow operation in Firefox. But I confess I’ve never wanted to select something and search for it.
VanillaMozilla: I hear you; the problem is that if a toolbar button moves, you can look to find it, whereas if a menu moves, you have to scan all the rest (or you assume the feature’s gone).
We currently have the Preferences menu in different places on each platform (the App/Window menu or whatever it’s called on Mac, the Edit menu on Linux and the Tools menu (I think) on Windows) because of platform convention and historical precedent.
With respect to item #7, importing, Firefox and Thunderbird still have a major problem: They don’t import from themselves.
This becomes a problem any time you are migrating from one machine to another. I aways end up having to go in and manually move files around.
It’s worth pointing out for the hundredth time that autocomplete deletion hasn’t required shift+delete for four years now. Delete has worked on its own (as it does in other browsers) since Firefox 1.5.
Also, I heart mpt. Without mpt it’s not impossible to imagine a world without Firefox.
– Chris
B, to add to what Ian Thomas said, back then I was also often unhelpfully caustic in my comments. This understandably made people less keen on supporting the ideas I put forward. I’ll always regret that, though I learned a lot from it.
Smokey, have you tried Epiphany? It includes a slightly tweaked version of the encoding-switching design I proposed for Mozilla. Your most-recently-set encodings are in a single short submenu. Other encodings are accessed from an instant-apply window, so you can experiment to see which is the correct encoding without having to dive repeatedly into sub-sub-sub-menus or even sub-sub-menus.
i cant understand the whole problems in mozila firefox.