re: http://mpt.net.nz/archive/2005/04/11/ubuntu
Matthew Thomas lists some interface problems with Ubuntu, by which he really means GNOME in this case. I love good UI, and goodness knows we can always use more sanity and rationality in user interfaces, but some things UI people say make me so mad. Now, a lot of his points are valid and being worked on, some are valid and unfortunately aren’t being worked on, and some aren’t even true on my own computer and seem Ubuntu-specific (most seem theme-related). But some of his points are things I’ve read before on other sites, and can generally be summarized as “it doesn’t work like the Mac so it must be wrong.” This is a dangerous direction for UI design to go.
Every window that has menus puts them in a separate menu bar inside the window. This (a) wastes screen real estate, (b) is confusing (even experts occasionally click the wrong menu bar by accident), (c) does not work for narrow windows (as demonstrated by the Gimp), (d) works badly for windows near the bottom or right of the screen (for which menus unexpectedly open upward or leftward), and (e) works even worse if those menus have submenus.
Worst of all, because under Fitt’s Law their vastly smaller target size outweighs their somewhat closer proximity, (f) menu bars inside each window are several hundred percent slower to use than a menu bar at the top of the screen.
I hate the Macintosh menubar. Fitt’s law is great and everything, and this type of thinking sounds correct in the abstract, but in practical terms this concept doesn’t work. Why?
- Menus are not the most important part of an interface, and don’t deserve special treatment.
Most of my interaction with my programs are through the main document area and toolbar icons. I don’t want to waste that Fittsy-valuable space at the top of the screen on menus I rarely use. In my work as an IT Guy, I observe a lot of other, less technical people using computers, and I notice that they, too, spend proportionally small amounts of time navigating menus. Most time is spent typing or clicking on items in the main document area. So it doesn’t make sense that we should devote such important space to menus.
- Since menus require multiple navigation events, they are always going to be slow, no matter how Fittsy they are.
To use a menu you have to hit a top-level menu and then navigate down again to a menu item. Some menu items require even more navigation events if you have to navigate trees of options. Therefore it doesn’t matter if you’ve got a huge target area on your menu bar because people still have to hit a secondary target to get the option they want. Therefore menus are always going to be slow, which is why developers invented toolbars and keyboard shortcuts.
- Selecting incorrect menubars is a problem on the Mac, not GNOME or Windows
His point about confused experts is actually a problem with his own model, not with the one he’s criticising. I quite often find myself hitting the File menu on the Mac and discovering I’ve got the wrong program. There’s usually 3-5 seconds of confusion as I don’t see the item I was looking for before I figure out I have the wrong application. When the menu bar is graphically tied to the application as it is in GNOME, there’s no confusion at all about which application the menus belong to.
- Too-wide menus?
Gimp does not have this problem, because the main window has three menu items, which don’t run off the side. Image windows have many items, and they don’t run off the side either. So I think he’s talking about an abstract problem that I’ve never come across.
- As for the last point, applications rarely end up at the bottom right of the screen, but if they do, then yes it gets weird. This is not as big a problem as the “what program’s File menu is this” issue.
Moving on:
By default, many — but not all — push buttons and menu items have an icon as well as text. As well as making the interface more cluttered, this slows people down by misleading them into thinking that they can decipher a transient control’s icon faster than they can read its text, which is rarely if ever true.
When you have icons with text it increases the target area for the mouse, which by Fitt’s Law is a good thing. I’m not sure what “people” Matt is talking about that are mislead in the way he describes.
Many controls change their appearance when the mouse pointer is over them, which is misleading because they’re not changing their state, and distracting if the pointer is just passing over the control on the way to something else. It can also be extremely confusing. For example, the window switcher, file dialogs, and Evolution’s “window buttons” all use a recessed button to show the current selection. But when you click a button, it looks like it hasn’t worked, because the pointer is still over the button so it still appears raised.
Actually the “mouse-over highlight” technique is widespread on the internet and elsewhere because the highlight indicates “this is an item that can be clicked.” This is quite a nice visual queue. The “pushed button” mouseover behavior should be fixed, but it’s not indicative of a systemic problem with mouseovers.
Items can’t be renamed by clicking on their names and typing.
This is the most annoying behavior ever, and results in a lot of files on Macintosh desktops with no filename or weird random characters because someone clicked in the wrong place, started hitting some keys, noticed that the filename was changing, and then madly hit everything in sight to try to get it back the way it was. Just today I had to help someone repair a Volume label that had become “”.
A USB device must be “unmounted” before it is disonnected from the computer, to prevent loss of information. However, the only way to access this function is by a shortcut menu, which few people will ever see.
What would be better, dragging it to the trash? When I first started using Macintoshes I would hesitate for long periods of time before dragging disks to the trash, since the “trash” means “delete” in every other circumstance. I don’t want to delete all my data! Also, changing the icon to an eject button is a start, but I still don’t like it. The right-click menu isn’t perfect either, admittedly.
These “problems” he points out — no ubiquitous menubar, icons and text, mouseovers, click-to-rename, and unmounting procedure are all examples of linux being different from the Mac, not worse. In all of these cases I think the behavior is an improvement on the Macintosh, but Matt isn’t used to these conventions so he thinks they are problems to be fixed.
Another example of a feature that UI designers tend to love that I hate hate hate in practice is Click-to-Focus. The only thing click-to-focus encourages is for people to doubleclick on everything. As I watch users perform tasks at work, they often click on a text field, start typing, and then get confused when nothing is happening. So they click again, and the second time it works. Still confused, they move on and learn to doubleclick everything.
I’m afraid that as Linux and GNOME get more popular, more self-proclaimed UI “elites” like Matt will come in and Macintoshify the whole shebang without hesitation. The day GNOME adopts a Mac-like ubiquitous menubar is the day I start running GoneME. Matt himself points out in his previous rant that the Macintosh is not the most perfect UI, so he should know how to take a step back and evaluate new behaviors a little more impartially.
While Matt is pointing out flaws in Ubuntu, he misses an easy targets that would be at the top of my own list of beefs. That is edge-resistance and expand-to-fill. If windows are considered solid objects, then they should behave like solid objects. Window edges should bump into eachother, and I should be able to tell a window to expand until it hits surrounding windows or screen edges. Luckily there’s a patch for edge resistance, and I wrote a patch for expand-to-fill. These are features not found on the Mac except in hacky places implemented totally differently in each case (iChat, Final Cut Pro, Avid XPress Pro all have some form, Final Cut being the best). Edge resistance is a very powerful usability concept, but Matt doesn’t notice its absence because the Mac doesn’t have it.
And that’s the fundamental problem with UI designers. They claim to be impartial, that they’re just following Fitt’s Law, that they hate the mac too!, but really they are comparing everything to the Macintosh interface without any genuine patience for alternatives. If GNOME is going to have the best user interface in the world then we need to look beyond implementing everything the same as the mac. Is The One Menubar really the best solution? Isn’t edge-resistance and mouseover highlighting actually a good thing? Attempting to play dumb and calling some feature “misleading” or “confusing” without any real data to back it up isn’t going to lead to a better interface, it just results in making an interface work like the one the designer has in mind — usually the Mac. We need to do more real research and less projecting if we’re going to get it right.
(Aside: Furthermore his tone is snooty at times. It’s possible to explain why the term “Shut Down” is preferable to “shutdown” in ways other than a sarcastic mention of it being a “misspelling.” Also, if he didn’t like the brown, he could have changed the theme. He didn’t hesitate to look for ways to turn off Caps Lock, but he couldn’t spend a little time to find Preferences / Theme? I find a lot of UI people adopt this same condescending tone “apparently for no reason” as Matt might say. Yes yes it’s fun to play ignoramous and describe certain features as if you have no previous knowledge of computers, but it can be done without adopting a tone of scorn.)
