Dear Thunderbird: I know you can’t save my draft; please stop complaining about it

A modal dialog box is the software designer making a claim that the software cannot do anything else until the user makes a decision. Upon closer examination, this claim is almost never justified. It’s usually a case of developer arrogance: developers assuming that because they have to care about some edge case in the software control flow, the user should have to care about it too.

There’s a particularly egregious example in Thunderbird 7.0 which I’ve seen a lot of lately because I’ve been composing a lot of emails offline.

I’ll be on the train or something, happily offline, typing an email in Thunderbird for later sending, and suddenly I’m interrupted by this:

Email composition, interrupted. Train of thought, destroyed. Input window, blocked. I cannot continue until I’ve processed what the software is asking me and made a decision.

Alright, Thunderbird, what’s the problem? Oh, you couldn’t save my draft to my mail server? Gee, I wonder why. Maybe because I’m not connected to the internet. There’s no reason I would expect you to be able to save a draft right now.

The correct behavior would be for Thunderbird to keep checking, silently, for an internet connection, and to save the draft to the server as soon as a connection becomes available again. But there’s no button for that, so I click “Cancel”.

Argh! Another one! What is it this time?

…An error message telling me my draft could not be saved. Thunderbird, I just told you to stop trying to save my draft. Why are you using an error message to report that you’re doing as I told you? That’s not an error, that’s the expected result of the button I just clicked. Why are you telling me anything at all? Why are you putting another dialog box in my way instead of just letting me get back to my email?

Jef Raskin used to call these “Monolog boxes” — they’re like dialog boxes except there’s no dialogue because the software isn’t asking me for any information. It’s just complaining to me and then making me click a button to acknowledge that I heard its complaint.

So that’s a modal dialog box followed by a modal monolog box just to tell me something I already knew, which is that I’m offline so of course drafts can’t be saved. And this pointless ritual recurs every ten minutes or so when Thunderbird tries to save my draft. If I’m composing multiple emails at the same time, I have to dismiss these pointless dialogs for every composition window!

The way to fix this interface is quite simple. There’s no reason to interrupt the user to report on the status of saving the draft. Thunderbird should allow me to keep typing my email while it displays a discreet warning message — off in the corner of the window, perhaps — to the effect of “This draft has not been backed up.” Even that much is arguably unnecessary, because the right thing to do in this case is obvious: back up the draft to my hard drive, and then sync it to my email server when an internet connection becomes available again. This can be done without any user input at all.

When the right thing to do is obvious, software should just quietly do it. It shouldn’t interrupt me to ask my permission or complain about problems.

 

Emacs, you know I love you, but..

The Aquamacs “Save File?” dialog box has a ridiculous surplus of buttons.

Readers: How many buttons does this dialog box really need? (Answer below the fold.)

 

The Synonym Problem

THE HITCHHIKER’S GUIDE TO THE GALAXY
Infocom interactive fiction – a science fiction story
Copyright (c) 1984 by Infocom, Inc. All rights reserved.
Release 31 / Serial number 871119 / Interpreter 0 Version

You wake up. The room is spinning very gently round your head. Or at least it would be if you could see it which you can’t.

It is pitch black.

>flip lightswitch
I don’t know the word “lightswitch”.

>lights on
There was no verb in that sentence!

>turn on light
Good start to the day. Pity it’s going to be the worst one of your life. The light is now on.

Bedroom, in the bed
The bedroom is a mess.
It is a small bedroom with a faded carpet and old wallpaper. There is a washbasin, a chair with a tatty dressing gown slung over it, and a window with the curtains drawn. Near the exit leading south is a phone.
There is a flathead screwdriver here. (outside the bed)
There is a toothbrush here. (outside the bed)

>get out of bed
Very difficult, but you manage it. The room is still spinning. It dips and sways a little.

>take nightgown
I don’t know the word “nightgown”.

>put on dressing gown
You’re not holding your gown.

>take gown
Luckily, this is large enough for you to get hold of. You notice something in the pocket.

>put on dressing gown
You are now wearing your gown.

>reach in pocket
I don’t know the word “reach”.

>empty pocket
I don’t know the word “empty”.

>take stuff out of pocket
You used the word “stuff” in a way that I don’t understand.

>open pocket
Opening your gown reveals a buffered analgesic, pocket fluff, and a thing your aunt gave you which you don’t know what it is.

>take pills
I don’t know the word “pills”.

>take medicine
I don’t know the word “medicine”.

>take buffered analgesic

In Ubiquity 0.1.1

CmdUtils.CreateCommand({
  name: "get-stuff-from",
  takes: {url: noun_container},
  preview: function( pBlock, dirObj ) {
    pBlock.innerHTML = "Gets the stuff that is inside your " + dirObj.summary;
  }
});

From the Inform manual

An Inform verb usually has several English verb words attached, which are called synonyms of each other: for instance, the library is set up with

“take” = “carry” = “hold”

all referring to the same Inform verb.

Hitchhiker’s again

>take aspirin
You swallow the tablet. After a few seconds the room begins to calm down and behave in an orderly manner. Your terrible headache goes.

>get toothbrush
As you pick up the toothbrush a tree outside the window collapses. There is no causal relationship between these two events.

>hold screwdriver

Taken.

>carry robe
You are already wearing it.

In the latest Ubiquity source build, as of yesterday afternoon

CmdUtils.CreateCommand({
  name: "get-stuff-from",
  synonyms: ["take-stuff-from", "take-stuff-out-of", "empty", "reach-in"],
  takes: {url: noun_container},
  preview: function( pBlock, dirObj ) {
    pBlock.innerHTML = "Gets the stuff that is inside your " + dirObj.summary;
  }
});

 

Tabbing Through the Tabs

There’s been a lot of discussion at Mozilla lately about the keyboard shortcuts for switching tabs, and how to improve them:

1. Boriss talks about why the new behavior is being proposed for addition.
2. Atul talks about the trade-offs between the old behavior and the proposed new behavior.
3. Aza Raskin throws his hat into the ring with some analysis based on information density.
4. Boriss takes inspiration from application-switching shortcuts in the operating system in looking for ways to improve the new proposed behavior.

In this post I’ll add my two cents to the discussion.

First, if you’re using Firefox, and you have several tabs open, please try holding down the ctrl key and tapping tab a few times, just to see what happens. Go ahead, try it right now. Come back to this page and keep reading after you’re done.

If your Firefox is version 3.0 or older, what should have happened is that each time you tapped tab, Firefox switched to the next tab — meaning the tab to the right in the tab bar. Let’s call this the “old tab behavior”.

If you are using the brandest-newest cutting-edgiest version of Firefox, you would see a transparent overlay with up to three thumbnail images in it, of three of your tabs. Each time you tapped tab, it would change the hilighted thumbnail, but it wouldn’t change anything in your main Firefox window until you released ctrl. Another difference is that the tabs in this mode are ordered by freshness, i.e. by how recently you looked at them, which may be different from the left-to-right ordering of the tabs at the top of the Firefox window. Let’s call this the “proposed new tab behavior”. In case you haven’t seen the very latest Firefox yet, here’s what the proposed new tab behavior looks like:

 

Voice recognition and ambiguity

First, watch this video and laugh:

Writing a Perl program with text-to-speech

Cue discussion of how voice-activated interfaces are a terrible idea, that real computers will never work like computers on Star Trek, that Microsoft’s UI designers were consumed with hubris if they ever thought this would work, etc. etc.

Too pessimistic! Thing is, there’s actually a very simple solution to this problem. It doesn’t even rely on any exotic technologies. We could do it today.

Things that a human says within a computer’s hearing might be:

1. commands (“Do this”)
2. content (“Put this text into my document”)
3. noise (things not intended for the computer at all, such as conversations between humans)

The very same words can be any of these three categories, depending on the intent behind them. Human language is ambiguous! That’s why humans rely on so many non-verbal cues, like tone of voice and facial expression, to interpret what other humans are saying.

Computers can’t interpret like that. But they wouldn’t have to if we just had a microphone with a couple of buttons on it.

• Hold button 1 and talk: The software interprets your speech as commands.
• Hold button 2 and talk: The software interprets your speech as content.
• Hold neither button: The software ignores anything you say.

I’m gonna go out on a limb here and predict that we’ll see a decent voice-activated system within the next few years, that will rely on a non-verbal communication channel (such as a few buttons) to help resolve the ambiguity of speech.

There will still be plenty of applications where people would rather type than talk (think about all the reasons why people would use text messaging on cell phones instead calling up and talking to someone), but once the novelty wears off I think speech-based interfaces will soon be seen as one more useful tool among many.