Adobe Update: a study in understanding usage patterns

I just fired up Acrobat Reader -- I beg your pardon, Adobe Reader -- and it decided it was time to install some updates.  When I said that was okay, it told me it was going to have to shut down Acrobat in order to do so.

As a techie, I understand why Acrobat feels this way, but as a user, I feel Acrobat has completely misjudged the moment.

I bring up Acrobat when, and only when, I want to read a document.  Usually, as soon as Acrobat has launched, I start reading.  Given that it takes Acrobat a little while to download the updates, by the time the restart-or-cancel prompt appears, the chances are better than 95% that I am right now in the middle of reading that document.  If I have a choice between continuing to read or shutting down the application and having to find my way back again later, I'll stick with continuing to read, thanks.

A better approach would be for Acrobat to install the updates as it shuts down, or the next time it starts.  In the former case, I have clearly finished reading, and it can beaver away in the background without bothering me.  In the latter case, although I clearly want to read something right now, I'm only going to be a bit delayed getting started, rather than losing my context to a shutdown-restart cycle.  The only wrong time for Acrobat to require a restart is when I am in the middle of a document; and yet this is exactly the time it chooses by default.

Anti-interaction interaction design

Bret Victor: "Today, a Perl programmer needs just four letters to invoke decades of research into filesystems and physical media: 'open.' A finely-tuned mergesort is available with the word 'sort,' and even more finely-tuned hashing algorithms require just a pair of brackets. Until machine learning is as accessible and effortless as typing the word 'learn,' it will never become widespread."

Reminds me of Joel Spolsky's observation of the different levels of abstraction of Microsoft and Google.

Visualisation methods

Visual Literacy: A Periodic Table of Visualization Methods. The "periodic table" metaphor is a bit stretched, and some of the entries feel like visualisations of specific data rather than adaptable methods, but it's a cool way to... uh... visualise all these different techniques.

In praise of jargon

Kathy Sierra: "Dinner conversations around my house often are about one of those two things--programming or horses--and most non-horse, non-developer folks might wonder if we're just making s*** up. But if you took away our jargon, the conversations would not just be slower, they'd be dumber."

MailMarshal's potty mouth

Interesting design philosophy from the MailMarshal email filter at work.

The filter is configured to block incoming emails that contain naughty words. When this happens, MailMarshal sends the recipient a notification message saying that a message was blocked and explaining why. In the case of naughty words, the notification says something like, "Unacceptable language: shitting (score: 5)."

Think about this. The idea is to block offensive language. The implementation, however, blocks all the innocent language, and sends only the offensive content to the recipient.

Stupid design, or deliberate subversion?

Multi-touch interaction

Multi-touch interaction research (requires Flash). Some of the demos are no more than noodling, but the photo manipulation and map navigation demos open one's eyes to just how much the primitive vocabulary of the mouse/pen single-cursor interface is holding graphical user interfaces back.

Happy World Usability Day

Wow, the BBC noticed: "A company's 'brand' does not just mean their logo or icon, but the gut feeling a customer gets from their products. This gut feeling is communicated by many elements including what the company says about itself, its advertising and, of course, the ease of use of its products."

And, in the true Beeb tradition of doing their very best to find another side to every story, a sort-of dissenting opinion: "It's not that I don't think usability is a good idea - of course it is... My worry is that the world has so far to go in making technology usable that I fear that celebrating usability is premature and conceals just how much hassle we put up with on a daily basis."

And I trust the Wellington UPA will be out in force tomorrow, protesting outside Dymocks about the confusing layout of the fiction sections, presenting a petition at the Beehive about poor signage on the revolving doors and, obviously, putting the quislings at Gamesman to the sword. Right?

User interface patterns

I've not tried to work through the differences between Jenifer Tidwell's two UI patterns sites, Common Ground and UI Patterns and Techniques. Some of the newer site seems to be rewriting, expanding and illustrating the Common Ground patterns, other bits seem entirely new. From a first glance at the newer site, I marginally prefer Common Ground because of its more generalised, "patterny" language, but this is probably because I have been corrupted by evil techie developerspeak; I can certainly see how the simpler language and visual examples will make the patterns concrete for a non-academic, non-developer audience.

Anyway, Tidwell's work has now been picked up by O'Reilly and will be published in dead tree format in October. For my money, this will be a must-buy. A pattern catalogue really hits the sweet spot between HIG-level specifics like "Buttons will be 120 pixels wide" detail and wise but unhelpful generalities like "Think how a digital device will be held and carried." UI designers do deal with the same problems in application after application, site after site, and patterns are a superb technique for capturing these kinds of common problems along with their solutions. And even ignoring the cookbook aspect, a pattern catalogue gives us a common vocabulary for describing and debating UI solutions, much as developers now find Observer, Decorator and their ilk to be handy shorthands for explaining technical designs. "Hey, why not combine the four filter boxes and use a Forgiving Format instead?"

By the way, I particularly like the intro to the newer site. "There's nothing new here." In our industry, it takes a brave writer to make that her hook.

Firefox raspberry shocker

It seems that Firefox blows a nasty raspberry noise if you search for some text on a page and it doesn't find it. It's really quite intrusive and disconcerting, and I'm sure it never used to do this. Is it a 1.0.4 'improvement'? Is there a way to turn it off?

User experience and the development team

Matt Goddard, the man Don Norman turns to instead of Jakob Nielsen when he needs his Web site usability improving, expands on Alan Cooper's adage that "user interface is not just skin deep."

The problem with Matt's remarks is that he is dealing with API usability within the development team, and this is neither necessary nor sufficient to guarantee a good user experience for people outside the development team. API usability is a good thing, of course, and who could argue with guidelines like "Your objects should be named clearly" -- but the goals and concerns of the developers are different from those of the end users. It's very important to developers that your lookup table class is called Hashtable or Dictionary rather than GemmasCoolClass, but it makes no difference to the user experience whatsoever (except of course in terms of delayed delivery and slow maintenance).

Where Matt may have a point is in the idea of treating API usability as a training ground for real user experience. If developers can learn to plan their APIs around their usability to the rest of the team, that may train them to plan their user-affecting designs around their usability to real people. On the other hand, it may just train them to expose the usual implementation concepts with blindingly precise technical jargon instead of the usual fuzzy sugar coating. ("Well, maybe they shouldn't employ nurses who don't know what a red-black tree is!")

API design does have a part to play in the usability process, but it is as part of the top-down design of the system, for example the design of domain objects to support the desired user experience -- a design that can then feed down into the design of implementation objects and data stores. What Matt is writing about is the simple fundamental of keeping the development team productive and sane, a concern which is actually pretty much internal to the development team.

Heh. Actually, I recognise this whole symptom of starting to care about the development team's sanity and health rather than regarding them as a necessary but expendable labour force to be subjugated to your will no matter what the cost. Watch out, Matt. I think you may be going native.