The Case of the Missing Tab

One of the things we noticed when we first started doing some rigorous usability studies with Word is the way people used the tab key. It’s a holdover from typewriter days: you want to indent a line of text, so you hit the tab key a few times. It’s one of those learned behaviors that, over time, have become rather difficult to unlearn. One could probably start a whole field of cognitive science built around this issue of mapping old behaviors from one technology to a newer, yet similar, technology—that is if academia hasn’t already started one.

This kind of thing presents a problem to those of us who develop the newer technology. How do you help users take advantage of the new paradigm that the new technology presents without asking users to give up their learned behaviors? The case of the tab key is classic. Not only does a Word Processor offer fine control over tab stops, but it also provides an alternate way to achieve the result one used to use the tab key for: paragraph indents.

One might ask whether this is a problem at all. After all, we could simply let users use the tab key when the really want an indent, and let them climb the learning curve about tab stops and indents in a modern word processor. And, to a certain extent, it wouldn’t have been quite so much of a problem had we been building a word-processor from scratch. The problem stemmed, in part, because Word already had some behaviors with respect to indents and tab stops. For users who hadn’t climbed that learning curve, using the tab key to create indents often produced results they didn’t really want.

I’m not going to enumerate specific scenarios, primarily because I wasn’t intimately involved in studying them. I’m likely to leave out key aspects if I try to discuss them. If one of the folks involved happens to read this, perhaps they can add more insights into these specific problems.

So, we had a problem, and it had a deceptively simple solution. This is exactly the kind of problem Word’s Auto Formatter was designed to solve. The fancy name for Word’s Auto Formatter is a “rule-based inference engine,” which really means that it’s like pattern matching on steroids. It takes into consideration the current state of the document, and interprets various keystroke input sequences in terms of a set of rules. It’s designed to work very fast, so that users don’t notice any effect on typing performance.

Using the Auto Formatter to solve this problem turned out to be not as simple as it first seemed. Obviously, there are times when the user really wants a tab stop, not an indent. How do we know? Well, we tried several different ideas, and figured out that there were three basic cases that we needed to think about. These involve having an insertion point a) at the beginning of an empty paragraph, at the beginning of a non-empty paragraph, at the left-hand edge of a line that’s somewhere in the middle of a paragraph.

Note that this discussion does not pertain to headings and outline levels in Outline View. There is an entire set of behaviors associated with the tab key in Outline View that do not involve the Auto Formatter at all. For a discussion of tab-key behaviors in Outline View, go here.

The empty paragraph case turns out to be the hardest. In that case, trying to infer intent ends up being so complicated that you can’t write a rule set that captures the possibilities. So, we left that one alone. When you press the tab key in an empty paragraph, Word will always insert a tab character.

When the insertion point is at the beginning of a line somewhere in the middle of the paragraph, users almost always want the paragraph to be indented, so that’s what Word does. This can present a problem, but there’s a workaround (more on this later).

If you’ve already typed up a paragraph, and put the insertion point back at the beginning of that paragraph, then there are really two possibilities. If you’ve set a tab stop, even if it’s on one of the default tab stop locations, Word will insert a tab character. If you haven’t set a tab stop, then Word will apply an indent to the first line of the paragraph mark.

To summarize these rules, if the insertion point is:

1.      In an empty paragraph--always inserts a tab character;

2.      In the middle of a non-empty paragraph--always indents the whole paragraph; and

3.      In the first line of a paragraph:

3.1.  If there are no tab stops set, then indents the first line of the paragraph; or

3.2.  If there is a tab stop set, then inserts a tab character.

The most common case where Word is likely to be wrong is case #3, so the auto-recovery feature in Word 2003/2004 allows you to convert the auto-formatted indent back to a tab.

We hadn’t known it at the time, but it turns out there’s an interesting case involving rule #2. Suppose you have a paragraph, but have inserted manual line breaks. If you put the insertion point at the beginning of one of those lines, Word still thinks that you’re in the middle of a paragraph, though, typographically, it looks like the line is its own paragraph. Hitting the tab key at that point won’t insert a tab character. It will indent the whole paragraph.

In this case, there is a workaround. In fact, the workaround will work under any circumstances where Word interprets the tab key as an indent. When you press Ctrl-Tab, then word always inserts a tab character.

Lastly, you can turn all of this off via Preferences/Edit and unchecking Tabs and backspace set left indent.

 

Rick

Currently playing in iTunes: Flamenco Sketches (Alternate Take) by Miles Davis