The Pavlov’s Beep post got me thinking a bit about how user expectations can set a product up for failure out of the gate… and that made me think of the late, lamented (by some), lambasted (by many) Newton.
Ignoring the obvious hype surrounding the rollout—something the product could never live up to—one of the things that was coolest about the Newton was also the thing that caused the most frustration: handwriting recognition.
Handwriting and speech recognition are two areas that have seen a lot of advancement in the past years—for example, the recognizer that comes with Windows XP Tablet PC Edition 2005 Elite Pro Extreme (or whatever that product is called) is exceptional, and from all reports is improving in its next iteration. And, according to those who use these things routinely, like David Pogue, the latest Naturally Speaking (ex-Dragon, now ScanSoft) is similarly surprisingly accurate.
All that said, though, they’re doomed to teeny market segments, because no matter how accurate, when they make mistakes they frustrate their users.
Why? Because we’ve asked the computer to play by our rules, rather than asking us to play by its.
When a device imposes an unnatural input method on its user, any mistakes you make are your own. Consider Graffiti, as used on Palm OS: it specifically requires you to make certain “letter shapes” if you want them to be recognized. It doesn’t try to recognize your handwriting. If a letter comes out wrong, you might be frustrated, but you know it’s “your fault”—you didn’t make the shape right.
But, with the Newton, it was supposed to recognize your handwriting. Not an alphabet of its own design. And, when it doesn’t, the first thing that runs through your head is: this thing sucks! Even if it got 90% right, which is pretty remarkable considering many people can’t read their own handwriting!
Speech is hard, too—especially if used in an “unrestricted vocabulary” scenario. Not only do you have to “speak” all punctuation (try it sometime), but correction is an incredible pain. And speech is such a natural part of most people’s daily interaction that it’s near impossible to rise to an acceptable level of performance.
Newton, near the end of its life, tried to get around this problem by taking a bit of a Graffiti approach: it encouraged people to print, and there’s a lot less letter variation in printed characters. Suddenly, with the new Rosetta printed character recognizer (still in use in Mac OSX today), people started saying the Newton did a good job recognizing handwriting when—in actuality—it just shifted the burden onto the user some more by restricting input.
Similarly, speech is becoming more common in situation where the vocabulary is highly restricted and expectations are low: package tracking #s; pick 1-2-3 menus; interacting with “speed trade” stock systems. Correction is pretty easy and, given the relatively robotic nature of the interaction, expectations are low. (You’ll note that as the systems got better, they started using more animated, natural voices at the other end—raising expectations they knew, from testing, they could meet.)
So—if you’re designing a UI, remember that the way you “frame” the interaction often sets user expectations.
Leaving aside speech and handwriting, free form input can be really, really cool—see Simson Garfinkle’s SBook and Microsoft Outlook’s date/address fields for examples.
But if you put up a free-form field , you better make damn sure that it accepts all sorts of wacky variations. If date-based, expect things like “tomorrow”, “next wednesday”, etc—every one you miss, given the free-form nature of the field presented, is the fault of the program, from the user’s perspective. Similarly, what about international addresses? And how do you tell the user you’ve made the inevitable mistake?
A lot of words to say something obvious, I know. But it’s a mistake I make all the time… e.g. “Safety Clone”…
In the first Bang & Olufsen multi-line cordless phone system—the 6000 series—the designers and developers clearly had a problem. Basically, when you picked up the phone, it took a while to actually “connect”, something on the order of .5 seconds or so. Long enough for the user to get out a “Hello? Hello?” and to feel pretty stupid about talking to empty air.
I wasn’t there, and don’t know, but I’m certain that when this went to testing, users screamed bloody murder. Phones are devices with very set behavior, and when things don’t work properly, it’s instantly noticeable.
I can imagine the engineers’ reaction when this came back to them: but there’s just no way to make it go any faster, given the hardware we’re using! It just can’t!
Back in the 80s, when my company UnderWare was doing BRIEF (a programmer’s editor of some renown back then, and my first commercial endeavor), we were in a similar situation. We had a certain percentage of people who were complaining that writing files was just too slow.
Mike and I went over the file writing code over and over, and—without resorting to going direct to the hardware, something we just weren’t going to do—there was just no way to speed it up any more. This stuff was working as fast as the system would let it work.
So, we thought about it. And thought about it. And, finally, came up with a solution.
Since we couldn’t speed it up, we did the next best thing. We cheated.
BRIEF had a “status line”—a quaint bit of information at the bottom of the window that was all the rage back in the Olden Days—and, before cheating, it would put up “Writing file...” and then, when completed, it would say “File written.”
So, I changed it to write out the percentage it was through the process. Which, if you think about it, actually made the whole thing slower.
And we never had another complaint about write speed.
And what did B&O do? They added a “beep” when it was time to talk. Just a little thing, but after the first time, users started waiting for it (and, no doubt, blaming themselves for not waiting, rather than blaming the phone for being slow to beep).
Bingo. Problem solved.
Sometimes the solution to a problem isn’t really a fix. Sometimes, it’s whatever works.
So, conventional wisdom about Bang & Olufsen is, as far as I can tell, overpriced, bad sounding junk for the “Jet Set”. ("Jet Set” being a particularly old fashioned way of saying “stupid, snobby idiot”, given the context.)
I think that it’s easy to try to slot Bang & Olufsen gear in with the ultra-high-end audio equipment because their prices do tend to be significantly higher than typical CE—your Sony/Denon/Harmon Kardon/Pioneer/Panasonic lines. There’s no question that it’s expensive stuff.
What brought this to mind recently were a pair of recent trips to Costco and BestBuy. I was looking around at trends in CE design, and it was truly depressing.
Take phones. Every major company has a multi-handset wireless phone “system” on the market at this point. And every one of the ones I saw in these stores, without exception, was a button-happy nightmare in plastic. Each was trying to “out-feature” the other, with a million conferencing modes, color screens, GHz differences, and more elaborate “space-age” styling ("space-age" being a particularly old fashioned way of saying “horribly silver-and-chrome-tastic”, given the context).
Oh, and every one cost about $100. And—no doubt—would last a few months, just like their predecessors did.
What’s funny is that there’s a really, really good example of terrific telephone design (both UI and industrial) out there—and it comes from Bang & Olufsen.
Back in the late 90s, Bang & Olufsen released their Beocom 6000 series of cordless phones. These phones were quite minimalist & modern in the B&O style, and centered around a simple UI based on a circular “scroll wheel” with a button in the center.
The 6000 allowed up to 6 handsets to be used, and had a phone book that allowed 250 names to be added: the names added automatically synchronized between the handsets, as did caller ID and the redial lists.
Menus were simple: scroll through the stripped-down menu system with the wheel, click the center button to accept (or move to a sublevel). Name entry was easy, because the letters could be selected quickly with the wheel—and lookups went just as fast.
Even the battery management was fantastic: the handsets lasted forever, and the charging system did not kill the battery in a week. Or a year. Or two years.
Bang & Olufsen recently updated the phones with the Beocom 1, which: adds two-line capability; refines the existing concept with a better display and menu system; improves sound and call handling; allows more handsets; and offers even better battery life. What it does not do is make it more complicated.
It works incredibly well. Stripped down, stylish, not overly-featured. Expensive, but worth every penny. You can learn a lot about how to design really good consumer-product UI from this phone system.
Take a look at the page above, and then look here. Seem familiar?
B&O was there first, thinking different… and smart companies learn from the best.
We’re asked, every so often, why we don’t offer a time-limited full version of SuperDuper!.
It’s pretty simple, really.
If you’re going to time-limit a program, you have three choices:
“Cookie" the user’s system in some hidden way so you know when the program was first run, and can therefore calculate when you’re supposed to expire.
Automatically identify the system and phone home, asking some server when the copy should expire, and not allowing execution without internet access
Force the user to provide personal information, including an email address, so that you can give them a key that expires (and the key, which need not be hidden, can contain the “cookie")
The first, in my opinion, is right out. I hate it when programs hide things on my system, and while I understand why they do it (see above), it’s just the wrong thing to do, especially for a backup program. A backup program that writes hidden stuff to the source volume? I don’t think so.
The second is nasty for obvious reasons.
The third, while doable, forces users to announce themselves to me when they just want to evaluate the software. We’re very conscious of privacy here, and a lot of people are understandably touchy about this kind of thing. The last thing we wanted to do was to alienate them right out of the gate, and force them to register just to take a look.
So, given those not-so-good choices, we decided to:
Provide useful, free functionality in the unregistered version of SuperDuper!, including technical support and full documentation
Never “expire” or take away the free functionality we’ve provided, even in future versions
Offer an evaluation key, on request, for users who want to examine its full capability (all we ask is that you drop us a note and tell us what you thought)
So, now you know! I think this has proven to be a good compromise, and while it doesn’t satisfy everyone… what does?
Here at Shirt Pocket World Headquarters, we’re often asked about our upgrade policy, and—specifically—exactly how much v2.0 is going to cost if you already own v1.x.
Here’s the deal: SuperDuper! v2.0 will be a free upgrade for registered users of v1.x.
That said, not every major upgrade of SuperDuper! will be free. But, we promise one thing: we’ll always be fair. We truly respect and appreciate you—our users—and work like crazy to do right by you. But, we can’t do that without—well, to put it bluntly—money.
So, why is v2.0 a free upgrade?
It’s free because I wanted to reward registered users, both for their patience waiting for the new release, and for supporting us over the past year or so. You took a chance on a new product, and we’re incredibly gratified by and grateful for the response to SuperDuper!
To each and every person who registered, posted comments about SuperDuper!, and recommended us to their friends, family and colleagues: thank you! I’m sure you’re going to love the new version when it’s released. Stay tuned.
I remember back when Ketzl was a pretty young puppy, we always used to wonder if she had a bark at all. She never felt the need to let out a full “Woof!”, and pretty considerately used what we termed “mini-woofs” to get our attention (which involved blowing out her cheeks a bit and vocalizing just enough for us to hear—almost like a whisper, if dogs could do that).
It took an annoying lab, constantly trying to mount her one day, for us to hear the full power of her real bark. And, when it came—wow. Deep, resonant… loud.
And now, it’s gone—replaced with a strange, strangled-sounding two-tone “woo-woof!”
I suppose I should have expected it, given that Degenerative Myelopathy moves forward and affects muscles along the way, but somehow I didn’t think it’d take her voice, too.
SuperDuper! 1.5.5 was awarded 4.5 mice—with the only failing being a lack of scheduling. (Those of you here likely know that scheduling will be featured in v2.0: I’m discussing various bits of v2.0 here in my blog, and there are some screen shots in here, too.)
I think the best way to sum up my feelings at the end of the usability test would have been “despairing”. A lot of work went into what we did, and yet—somehow—it all went totally wrong. But why?
We’d thought that users knew/understood that “Saved Settings” were present, were documents, and as such—since the way scheduling worked was based on that model, and many had used them previously to manually schedule SuperDuper!—were an everyday part of SuperDuper! usage.
But once I had stepped back and thought a little more—and regained my user perspective—that clearly wasn’t the case. The only reason users even got near documents, for the most part, was to do a one-time scheduling setup. And most users didn’t even bother with that.
Users basically run SuperDuper! in immediate “mode”. That is, they start it—SD! conveniently restores their settings—and they click “Start Copying”. That’s it. Smart Update is fast enough that the backup takes but a few minutes. Then, quit. No need to save settings: SD!’s doing it for them, in the background.
Given that, it was clear that “mixing” the immediate usage model and the scheduled usage model was flawed: they’re two entirely different ways of dealing with the program. Combining them—no matter how well it might follow the internal model of what was going on—didn’t follow the external/users’s mental model. So, they couldn’t get their head around it without work, even when they could find the buried functionality: absolutely terrible usability.
So, I reviewed how I’d arrived at this point, and suddenly the answer was right in front of me! All I needed to do was roll back to the original design! Before we started working through the implementation, I’d solved the whole problem:
The scheduling functionality was right up front, in the main UI
The scheduled/immediate parts of the program were distinct from one another
The whole concept of “Saved Settings” was hidden from the user during the scheduling process, and they didn’t need to worry about it at all
So, I wrote the whole sad saga up, and sheepishly presented it to Bruce. He wasn’t happy about it, as we’d have to throw away a lot of work but—fortunately—I pointed out that the vast majority it could be re-used: after all, while the effect on usability should be significant, there were no “new” elements, just existing items that moved around.
Some judicious rewording of the buttons—from “Start Copying” to “Copy Now”—and “Copy Later” fit in the main window. Thus (some tweaks left to go, but this is the current build):
(In what you’re looking at, the red entry has failed to run: clicking Show Log will give the reason why.)
Of course, there are many parts here you can’t see: the way the “Scheduled Copies” window comes up and moves forward when it’s time to schedule, emphasizing the second type of use; the sheet that actually gives you the way to select the repeating timeframe; the new log window that makes it easier to contact support; schedule editing. But you get the general idea: it’s quite simple.
The second test commenced with the same four users, and it went great. Every one completed their task with no confusion, save for one point: most didn’t unlock the application, so the schedules never ran. Once we took care of that: bingo.
