SJS's Journal: User Interface Policies

I just ran across an article on the evils of cut & paste, and I find my reactions mixed. I don't recall reading anything by Jef Raskin before, but he seems to be an articulate guy, and his argument stands by itself.

He starts off talking about UI faddishness, which I agree is a problem, and then discusses the problem with cut & paste. Namely, it's a bad idea, because while something's cut, you don't remember what it is, and you're likely to lose it.

To me, this borders on calling the user stupid, which seems a bit strong.

He then discusses the "often-proposed fix" of select-and-drag. He then discusses the problems with select-and-drag, and uses that to introduce an example of a "classic mode error".

Now, although I loathe select-and-drag, I haven't made this 'classic' error he refers to -- when re-selecting text, I first select some text, or click in the background, or do something to unselect the text. Handling the modes of "no selected text/have selected text" isn't really a problem for me. I have, however, accidently selected and then moved text (click-and-grab to move, except that the the click accidently strayed into an area where 'select' was an option), which is one of the reasons why I don't like select-and-drag.

Anyway.

He then goes on to describe his preferred solution -- the 'move'; that is, the selection doesn't go away until the new insertion point is specified. He goes on to point out that he's eliminated one command -- you use a move, instead of a cut AND a paste.

Well, sorta.

First, I don't buy the modes-are-always-bad line of thinking. Too many modes are, but no-modes/one-mode are almost just as bad -- there's a happy middle ground in there somewhere. But that's a different rant, for another day.

Second, then, is that it's not necessary that the buffer used in cut & paste be "invisible". For a long time, I used a tool called xcb (the X Cut Buffer) that allowed me to look at what I had cut. It also allowed me to keep several cuts on hand, so a new cut wouldn't necessarily cause the previous cut to be lost. The only problem with xcb was that it took up screen space, and there was a tradeoff in sizing the buffer display large enough to be useful, and small enough to stay out of the way.

But this leads us to consider some other possible solutions. The buffer doesn't have to be invisible. Multiple buffers can exist to be selected among, and/or a stack-approach could be used to keep all buffers around. After all, most of the time, you don't forget what you just cut.

Third, the 'move' command "solution" doesn't eliminate a command from your toolset, only from that one operation. You still need a command to cut-and-discard, and you still need a command to duplicate a chunk of text. When programming, we sometimes talk about the "minimal necessary set" and the "minimal usable set" of functions.

When you build an API, you want to keep in mind these sets. Otherwise, you clutter up your API with a bunch of convenience functions that do what you could do with only a little more work. The cluttered API is harder to learn and harder to use than a simpler API, especially for those who aren't experts in that API. Even those who are moderately familiar with the API will have to spend time looking through the options to find what the "best" way is.

When we edit text, we want a way to delete a chunk of text. Backspacing over a whole page could do the job (minimal necessary set) but being able to select-and-delete saves a lot of effort (minimal useful set). Likewise with copying text. We could just type it in again (minimal necessary set) but a paste saves us a lot of effort (minimal useful set).

So our "useful" set of commands for editing text provides a delete and a paste (select is implied). If we paste the most recent selection, we get our 'move' functionality for free, and our commands work on a very simple and consistent model.

If we add in our 'move' command, it looks like a more complicated version of what we can already do: select, paste, delete. If we choose to force our users to use the move command instead of the cut & paste sequence, we can say that the delete command discards the most recent selection entirely, and our user now needs to remember three commands instead of two.

Ah, that's only one more command! Where's the problem?

Not there, not really. But if every sequence of useful commands is replaced with its own command, we have done the user a disservice and made their life more complicated than it needs be.

That being said, I don't dislike the idea of a move command. I think it's a much better solution than select-and-drag, and I would use it in preference to select-and-drag (although I wouldn't avoid cut-and-paste as well, just select-and-drag). But a better solution yet would be to have a non-invisible buffer-stack, as that offers up new ways of working on certain problems, and doesn't presume that the user is an idiot.

IMNSHO, of course.