James's Weblog

(That’s the pessimist’s view; the optimist’s perspective is sometimes you sometimes can get way more bang for your buck.)

A funny thing can happen when a product priced at several thousand dollars suddenly becomes free: usability polish can become really important. It’s a bit unintuitive; you’d probably expect expensive products would get more attention toward fixing usability problems. After all, there’s money on the line, right? Surely users would be more critical.

Well, yes and no.

• A thousand-dollar-product has a significantly smaller audience than a free product. Consequently, there are simply far fewer eyes looking at the product that would notice (and more importantly, care about) a font or widget that doesn’t look or feel right. There are far fewer people randomly bashing on their keyboards and falling into some crazy corner case.
• If the audience is small enough, the road to consultingware is a tempting path: only fix problems when a customer complains. Why spend lots of effort trying to guess ahead of time what issues people might have? Being lazy and fixing issues on demand doesn’t have the penalty of wasted effort.
• The audience consists of a different demographic. People spending thousands of dollars on a software product are more likely to know what they’re buying and to know what they’re doing, and consequently they probably will need less hand-holding from the user interface. (This doesn’t apply when the purchasers aren’t the same people as the users, although in those cases a product is more likely to be unusable for other reasons: the people spending the money simply don’t have enough information to know when they’re being sold a usability lemon.)

The other important detail is that there’s money on the line for free products too. When a free product is meant to be vehicle for brand promotion, you’d better put on a good face for the public and make its UI look good.

When I left Sony, one of the little things that pleased me was that I no longer had to deal with Microsoft Outlook and a finicky Microsoft Exchange server.

Well, it turns out VMware also uses Outlook and Exchange, and I am reminded how much I hate them.

• Inflexible rules. The rules don’t allow boolean expressions, and what constructs they do allow are crippled. Want to match email that contains both “foo” and “bar” in the subject line? Forget it.

• Rules aren’t filters. Outlook’s rules don’t act as filters. In a sane system, each rule is applied in order to each received email message; if a message can be matched to multiple rules, the first rule gets precedence. Not so in Outlook. Outlook displays an error message informing the user of the rule conflict, and then silently disables the conflicting rule. A single message triggering a rule conflict warrants turning off the rule completely? How helpful.

  I’ve been told that I’m supposed to add a “Stop processing more rules” command to each of my Outlook rules to avoid this stupidity, but apparently Outlook 2000 has a bug where “Stop processing more rules” really means “stop processing rules for email, period.”

• User-friendly search gone awry. Microsoft tried to make Outlook’s Find function user-friendly by making it task-centered, but they made it too task-centered. They focused only on some common tasks and made the less common (but not rare!) tasks hard. The Find dialog box offers the ability to search for email from specific time periods, such as this week, last week, the past 7 days, this month, last month. Some of the “user-friendly” options require a bit of cognitive thought (does “this week” start on Monday or Sunday? does “last month” mean the past 30 days or since the first day of the previous month?), and if you want to search any other time periods (the past two weeks, the past two months, the month of March, from the last week of January through the first week of February, …), forget it, you have to use Outlook’s bewildering Advanced Find dialog. To specify a date range, you must use the freeform text field that provides no clues how the input should look. (Outlook actually is surprisingly intelligent about parsing the input into this field, but it’s still intimidating and error-prone. How can you really tell that Outlook parsed the input correctly?)

• Network and fault intolerant. Outlook is so poorly designed that if the Exchange server goes down (which seems to happen fairly frequently), its entire UI is unusable. You can’t even access mail stored on your local disk. Outlook eventually will figure out that the Exchange server isn’t responding—if you’re willing to wait 10 minutes. Even better, when the Exchange server comes online again, as far as I can tell, you can’t tell Outlook to reconnect; you must quit Outlook and restart it.

• No source for you! Outlook inexplicably makes it really hard to view the message headers to Internet email.

These are all issues I’ve had with Outlook 2000. In Microsoft’s defense, maybe they’ve fixed some or all of them in later versions. On the other hand, it’s sad that they were issues in the first place, because Microsoft’s free, light-weight (and independently-developed) email client—Outlook Express—has had friendlier search and filtering capabilities for years before!

A lot of audio players like to combine Play and Pause buttons. If a song is playing, pressing the Play button again pauses the track; if a song is paused, pressing the Play button resumes playing. It makes sense and reduces the number of buttons, right?

Winamp does not take this approach, and I commend its developers for it.

On the surface, combining these two buttons seems like a great idea. However, let’s suppose you want to replay the current track. Maybe you’re not paying attention and suddenly realize that the song you’re listening to is a favorite that you haven’t heard in a while, or maybe you’re just in the mood to listen to a particular song over and over.

In Winamp’s separate button design, if a song is playing, pressing the Play button again re-plays the current track. In the combined button design, pressing the Previous Track button typically returns to the track’s beginning. Seems like a sound design so far.

Now let’s suppose you want to skip to the previous track. In the separate button design, the Previous Track button always selects the previous track. In the combined button design, however, the Previous Track button only sometimes selects the previous track, since it’s also used to restart the current track. Typically the button skips to the previous track only if it’s already at the beginning to another track—the “beginning” defined as some arbitrary number of seconds.

Thus, overloading the Play button with pausing functions means we need to overload the Previous Track button too. Furthermore, overloading the Previous Track button requires introducing either time-dependent behavior or button modality. That’s a significant increase in interface complexity to save a single button. (The Previous Track and Next Track buttons typically have another behavior too; they seek within tracks when the buttons are held down.)

Increasing interface complexity increases error rates. My car stereo uses the combined button approach, and it makes it difficult for me to navigate backwards through CD tracks when I want to find a particular track. I need to listen for a few seconds to determine which track is which, and depending on how long I wait to listen, I sometimes need to press the Previous Track button once and sometimes twice. This is even more problematic when I’m driving and not looking at the track number.

Makers of software-based audio players have nothing to lose by providing separate buttons; virtual buttons have no monetary cost. Makers of car stereos should provide separate buttons because it’s a little safer.

(Although I prefer separate buttons, if space is at a premium, a respectable compromise might be to combine the Pause and Stop buttons instead. If pressed briefly, pause; if held down, stop. If the Stop button has been done away with too, then perhaps holding down the Play button can replay the current track.)

The history pane in Internet Explorer 5 and 6 tries to be intelligent and user-friendly, but in practice it seems almost completely useless.

Consider this scenario: You surf the web and follow a lot of random links. The next day, you try to find a specific page again.

I do not believe this is an uncommon task. How can you accomplish this in IE? IE’s history has a “View » By Date” option, where it separates history items by day or by week. Unfortunately, within each day, items are sorted alphabetically by site. This is counter-productive; if users remembered the address of the site, why would they need to look for it in the history pane?

(IE also has a “View » By Order Visited Today” option, where it lists each page you’ve visited during the past day in chronological order. Unfortunately, when Microsoft says “today”, they really mean today, not the past 24 hours. IE is not friendly to late-night web surfers; once the clock on your PC rolls past midnight, say goodbye to history items from 11:59 PM; you now have to remember the site address if you want to find them again. Oh, and if it just turned Monday, your history items from Sunday are now lost amidst all other items from “Last Week”.)

The only alternatives are to try to retrace the original steps or to try to find it with a search engine, both tedious chores.

Why should a seemingly simple task be so incredibly hard?

Netscape/Mozilla have done it right for ages. They allow you to view all history items in a single, flat list. Superficially, it might not appear to be as organized as IE’s hierarchical history pane, but it’s infinitely more useful, and it’s simpler too.

Unfortunately, years of using IE have weaned me away from using browsers’ valuable history features. Ugh.

There’s a lot of confusion out there about rechargeable battery technology.

Is the memory effect real? Do modern rechargeable batteries suffer from it? Should you discharge batteries completely before recharging? Should you charge batteries whenever they’re not in use? Does overcharging damage the battery? What are the differences between NiCd, NiMH, lithium-ion, and lithium-polymer batteries?

In this case, confusion leads to disinformation. Some people often say to discharge lithium-ion batteries completely to avoid the “memory effect”, even though most of the sources I’ve seen say that completely discharging a lithium-ion battery is bad.

Forget it. Batteries should be more intelligent. Sure, there currently are “smart batteries” out there that report things such as chemistry type, number of charge cycles, voltage levels, and temperature, but do users care about these things? Do users know what they mean? The batteries (or the devices that use them) should be smarter and tell users what matters:

• Estimate time left on the current charge. Making accurate estimates is difficult, because many devices do not consume power at a constant rate. Manufacturers want to avoid complaints from users who say, “your device said I had 1 hour and 15 minutes of battery life left, but I really had only 50 minutes!” Instead, device manufacturers often don’t say anything at all.

  Truly smart batteries or devices could generate statistical data and usage patterns. Even with variable power consumption, they ought to be able to use such data to compute reasonably accurate estimates. When in doubt, they should be conservative with their estimates.

  If nothing else (and to rip off an idea from Mac OS), if you can’t be accurate, be less precise. For example, a better estimate might be “About 1 hour” or “About 30-60 minutes”.

• When to recharge. Smart batteries or devices can know their chemistry type and could tell the user the appropriate charging behavior to follow. Messages such as, “You should recharge your device now to maximize the lifetime of the battery” could be used to supplement existing low battery warnings. Overcharging should never be a problem; smart devices already detect when the battery capacity is reached and stop automatically.

Last night’s BayCHI meeting had a talk by Scott Weiss, author of Handheld Usability. He mentioned, among other things, a couple of additional points about PDAs versus physical calculators:

• Instant gratification. Calculators turn on and are ready to do their thing immediately. With a PDA, you usually need to tap some sequence of physical and virtual buttons just to start the calculator program.
• Batteries not included. Many four-function calculators and some scientific ones don’t need batteries at all, instead relying on solar cells.

On the other hand, he noted that PDAs can be better for specialized programs for common tasks. For example, a program can display the sales tax or 15% tip automatically for a given value.

Coincidentally, the 2004 PalmSource Developer Conference is going on this week. During one of the presentations yesterday, a speaker from palmOne suggested that students use PDAs instead of physical calculators. Ugh. That brings me to my next point:

I don’t see a lot of benefit to having computers in the classroom, especially in schools full of upper-class children who probably have computers at home already.

I think the one big win is if every student has a laptop or PDA with network access, students can provide real-time, anonymous feedback to the instructor. Peer pressure discourages students from asking questions, even good ones.

I’m sure there must be a good low-tech alternative, but I can’t think of one. A locked drop-box isn’t real-time, making it difficult for students to correct the instructor. It also isn’t very anonymous; students submitting questions might be seen by others, and it’s not that difficult to distinguish students’ handwritings.

(I wish that I had thought of setting up an anonymous feedback form while I was a teaching assistant. I don’t think I got my due share of “James is a stupid-head” remarks.)

As much as I like PalmSource (the company that makes Palm OS), its registration forms always bug me.

There are always questions that are required but don’t apply to me, such as job title, company name, number of employees, what distribution systems I use, what type of market I’m targeting, and so on. Admittedly, the majority of registrants shouldn’t have any trouble answering these questions. On the other hand, a significant number of Palm OS developers are hobbyists who don’t represent their employers, and these days a lot of people are unemployed.

If your marketing department demands that you require demographic information in your registration forms, remind them that disinformation is worse than no information. If nothing else, provide “not applicable” or “I don’t know” options.

For anyone curious about what’s so special about my dream keyboard that I mentioned last December:

• Buckling-spring construction. It’s equivalent to an old IBM Model-M keyboard. Unlike the flimsy, cheap membrane keyboards most people use, buckling-spring keyboards are solid, are built like tanks, and last forever. True, they are much noisier, but my typing already sounds like a jackhammer, so it shouldn’t be much worse.
• Integrated TrackPoint. Some people hate these things, arguing that a normal mouse is better. While I won’t argue with that, a TrackPoint and a mouse aren’t mutually exclusive. Modern operating systems support multiple pointing devices; why not use both? If you need to do a lot of mousing and only a bit of keyboarding, use the mouse. If you need to do a lot of keyboarding but only a bit of mousing, you can use the TrackPoint without taking your hands off of the keyboard. It’s the best of both worlds. It rocks for coding, and I think all keyboards should have this.
• Windows keys. Some people hate these things too, arguing that they’re nearly useless. If they bother you that much, there are versions without them. Me, I think they’re useful. Use an application such as WinKey to assign keyboard shortcuts to Windows-key combinations. For example, I set Win+p to open the command prompt, Win+i set to start my web browser, and Win+v to open my volume controls.

I’ve seen numerous people suggest purchasing a PDA over a physical graphing calculator. After all, a PDA can do everything a calculator can do (there are graphing calculator emulators that run on PDAs!), and it can do so much more. A PDA must be better, right?

I’ve spent the past three years in the PDA industry. I also own a physical graphing calculator. There are no doubts in my mind that a PDA is adequate for occasional use, such as for calculating sales tax or tips, but a physical calculator is superior for any extensive calculations, such as for math, science, or engineering work.

A physical calculator wins handily in the following key areas:

• Physical buttons with good tactile feedback. You want to be able to use the calculator to a reasonable degree without looking at it. You want to be able to feel for the button you want, and you want to be confident that the calculator registered the button press. Why do people prefer bulky physical keyboards to those flat, touchpad-like ones?
• Ease of use. People avoid touching PDAs directly for fear of getting fingerprints on the screen, and pulling out the stylus to tap on virtual buttons is clumsy. If you’re writing results out on paper, switching between a pen and stylus can be tedious.
• Battery life. My physical calculator lasts for years on a single set of batteries. PDAs need to be recharged frequently.
• Durability. PDAs are fragile. Physical calculators are rugged. A physical calculator can be thrown into a knapsack and jostled around without worry. Even if something breaks, a calculator is much cheaper to replace.
• Dependability. I trust the results from calculators of established manufacturers such as Texas Instruments and Hewlett Packard. Their calculators are thoroughly tested and have been used by engineers for ages. PDA software packages are made by less mature vendors who don’t have the same track record.

Plus, if you’re in high school, you really don’t have a choice, because PDAs aren’t allowed on standardized tests.

I know these things save lives and all, but I really hate the ones we have in our home.

When their batteries get sufficiently drained, they emit a short, annoying, loud chirp once a minute. It seems to me that whoever thought this up never lived in a home with a smoke detector in every room. It takes around 10-15 minutes to track down which smoke detector is complaining, because:

• We have a lot of smoke detectors.
• The chirp is too short to get a good fix on the location immediately.
• Funny acoustics can play tricks.
• I have to wait a full minute to refine each guess.

Ten to fifteen minutes isn’t a long time, but it’s longer than it ought to be. Listening to the shrill, piercing chirp doesn’t make the time spent any more enjoyable. (And why do these chirps always seem to start in the middle of the night while you’re sleeping?) The chirps seem to go on forever; just how low on power can the batteries possibly be? At my old apartment complex in Berkeley, I listened to one go on for weeks.

What I don’t understand is that the smoke detectors are wired to get power from the house. The batteries are supposed to be used only as a backup. How are they getting depleted so quickly?

Of course, a good high-tech solution would be to connect all the smoke detectors to a network and to have a central monitoring system.

Better low-tech solutions:

• Use a rechargeable battery; signal a warning only when the battery can no longer retain a sufficient charge.
• Use visual cues instead of (or in addition to) the chirps for battery warnings. For example, a smoke detector could turn off its power LED when battery power is low (and thereby save electricity too); it could release a short, brightly colored ribbon and let it hang; or it slide open a hatch that reveals some brightly-colored material underneath.
• Use less annoying chirps and chirp more frequently. It’s silly to design a smoke detector that can signal a low-battery warning for several weeks. Even two chirps in quick succession would be a huge improvement.
• Get a dog.