Month: April 2005

If you notice that your laptop fan sounds really loud, or even worse, if the laptop is baking hot and the fans aren’t running at all, try blowing in the exhaust vent and see what comes out on the fan side. Your laptop could have a giant hairball:

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.)

Synergy, for linux, mac, and windows. Lets you connect two computers together virtually, so that you can fling the mouse off one machine and end up at another machine. This is totally badass, and there’s no discernable delay, even with wireless ethernet.

The present is browsing, the future is search. Anyone who was browsing the web in 1996 or so might remember that yahoo started out as a great hierarchical web index. It was the best way to find sites on the net because its editors found the best sites for each category. Then came google, and we never looked back. Good search is better than the best browsing.

This metaphor is being extended to the desktop with Beagle, Apple’s Searchlight (which I can’t find a decent link for!), Google Desktop, and MSN Toolbar.

If any of these products can be as good for the desktop as google is for the web, it’s going to rule the world. I think GNOME should embrace “ubiquitous search” with the removal of all browsing as the eventual goal.

If I want to open a file, I’ll search for it. If an application wants me to find a file, it’ll open up a beagle window, not a file selector. When I save a file, I don’t put it in some directory I’ll never remember, I just give it a title (not a filename) and maybe a short description (for better keywording) and let the OS put it somewhere. The search program will find it when I need it.

Ubiquitous search means no more file browsers, no more file-selectors, no more filenames to remember. Obviously we will still need real filenames and folders underneath the hood, since some tasks (hacking code) really require them, but the common user with 20 gigs of mp3s, 100 gigs of movies, weeks of web history, a gig of email, and 100 megs of word documents doesn’t really need to know where those things are — they just need to find them quickly.

Once we make the transition, the search app will replace nautilus on the desktop. At the top will be the searchbar, and then the whole desktop will display the results of the search, perhaps with different columns for each result-type.

Right now GNOME developers seem most concerned with the “physical object” paradigm of the desktop, afraid that non-technical users will panic when applications disappear when you click the X rather than doing some mac-style genie minimizing. One might be afraid that users will be apprehensive about using a computer whose “desktop” is not a constant set of icons but instead an ever-changing search result.

I think more important than clinging to the physical “desktop” paradigm is developing an environment where even if something disappears, you can get it back easily. Right now “disappearing” is synonymous with “losing work,” and that’s what needs to be changed. Tomboy has a “no-save” philosophy. Evolution has crash-recovery builtin. You can get a crash-recovery plugin for Firefox. If the consequences of a crash can be reduced to zero then we can nurture a user that doesn’t care when something disappears.

As hard drives fill up with movies, music, pictures, and other little bits of stuff, it’s going to get harder and harder to sort through it manually. Most people have given up on sorting music and let itunes or rhythmbox do the work for them, but the problem is going to occur again and again for each filetype. I’ve been known to google for a video I already have on my hard drive because it’s inconvenient to find. In other words, I’m relying on emphemeral links and expensive internet connections for long-term storage because searching is so much easier than browsing. The OS that tackles the browsing problem best is going to win hoards of new users who want a desktop that doesn’t drown them in menial organizational tasks. It could be GNOME.

Today is the official “Reading the internet is pointless because everything’s an April Fool’s joke” day. Slashdot demonstrates this trait with particular overzealousness.