Some fundamental usability issues

Matthew Paul Thomas mpt at
Wed May 14 10:51:45 UTC 2008

Hash: SHA1

chombee wrote on 08/05/08 02:24:
> But there is so much fundamentally wrong usability cruft going on here.
> This sort of incident should not be possible.

Others have discussed the backup and restore issue, so I'll address the
lower-level points:

> * The user should never have to press Save. There should not be any save
> buttons anywhere on the computer. Saving is something the computer can
> do automatically all the time, the user never needs to know. Save
> buttons were introduced back when saving a file to disk required the
> computer to freeze for several seconds. They are no longer needed, and
> haven't been for some time! The GTK text editor Scribes is one program
> that handles all your saving for you. Any others?

Tomboy. Rhythmbox, and most other music organizers. F-Spot, and most
other photo organizers. Microsoft OneNote.

> * This whole business of highlighting some text then pressing a button,
> whether it's paste or just a normal key, and having the highlighted text
> replaced, should be thrown out. This seems to be how it works in every
> text editor, but I think it's rarely what the user wants to do, and in
> the rare cases where you do want to do that you can stand one extra key
> press: highlight, delete, then paste or type in the replacement. **The
> user's content is sacred** and it should never be deleted unless the
> user explicitly selects it and presses delete.

Previously on this issue:

Jef Raskin, who designed the typing-replaces-selection action, later
concluded that it was a mistake

    In today's world we just select the old text and type away.
    This method was not a good idea, in fact it can be disastrous.
    It is easy to select text, forget it is selected (and the
    selection might be off-screen), and then start typing. With the
    nearly universally-available SELECT ALL command, it is easy to
    lose whole documents this way. Nearly all users I've
    interviewed have inadvertently lost text due to this design
    error. While it requires [an] additional keystroke, the design
    should have been (designers take note);

    To replace text: select old text, tap DELETE, type new text.

There would be a couple of problems with changing this now. One is that
a non-trivial fraction (my wild guess would be 20 percent) of current
computer users are used to the typing-replaces-selection behavior. (The
rest don't realize it exists, except when they trigger it by accident.)
And because it is such a low-level behavior, relearning it would be
quite irritating.

The other is that dialogs often contain text fields with default values.
You can tab to a field, all its text is selected automatically, and if
you want a different value you can just start typing. If
typing-replaces-selection was dropped, some of these default values
might no longer be appropriate, because the cost of deleting the value
would have become greater than the benefit of providing it.

One smaller step would be to leave typing replacing selection, but to
make Ctrl+A the keyboard equivalent for Select Paragraph, rather than
Select All. Then it would still do what people wanted most of the time,
but the dataloss from typing Ctrl+A instead of Shift+A would usually be
much less severe.

> * The whole paradigm of embedding semi-functional text editors in web
> browsers. I mean semi-functional when compared to the system's
> stand-alone text editor application. For how many years have people been
> typing out emails into web browsers, pressing Send, getting a server
> error, and losing their work? There must be a better way. The web
> browser should just integrate with the system's text editor so that text
> is not lost when the browser or some Internet server messes up.

The "It's All Text" Firefox extension does this.
<> But adding the
complexity of a new window, with a completely different interface,
*just* for avoiding dataloss is a high price to pay. (To be fair, that's
not the only reason people use It's All Text -- it also lets them use
Emacs/Vi keyboard commands.) And you still need to remember to save

I think it would be better for browsers to behave the way good mail
clients do: while you're typing a message, they regularly and silently
save the message into the Drafts folder, so you can retrieve it later
even if an accident happens. Ideally browsers would save *the entire
page*, including text, selections in other form controls, scroll
position, and everything else, so you could get it back easily if you
closed it by mistake.

- --
Matthew Paul Thomas
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla -


More information about the Ubuntu-devel-discuss mailing list