Tim Berners-Lee
Date: 2016-12-15, last change: $Date: 2017/12/14 13:15:41 $
Status: personal view only. Editing status: first draft.

Up to Design Issues

User Interface: Random tips

User interface ideals can be very subjective. Here are my own biases. Much of it may be motherhood and apple pie. In a way, more than 25 years after the WWW project started, you'd think that these things would be be generally understood. And they are covered in many blogs and books. But here are some points which still now seem to need pointing out. They may not include your own pet peeves -- but here are some of mine. The order is a bit random.

All text must be copyable

If you put up information which your user can read then you should always make it copyable. (This is not just for web sites, it is also for native apps) You can't tell when a user won't want to share it with someone, look it up in a search engine, save it for later.

Especially error messages

People who do not understand a lot about your system may still be able to use a full detailed error message, but looking it up in a search engine, or asking a friend. Make this easy by allowing them to copy and paste it! You'd think this was obvious but it amazing how often it isn't done.

An exception to the copyable rule for text is, for security, a password field.

Input fields must be pasteable

These normally do come paste-able out of the widget library, so it takes actual effort to make a non-paste-able one, but it happens when developers try to be over-cute about capturing all the keystrokes, and for example preventing anything being typed apart from numbers in a numeric field. If you take suppress and replace the default line editing the browser does in each device, then you should have really important reason for it, not just cuteness.

Auto-complete libraries may be a common source of problems here. If the auto-complete librray you are thinking of using doesn't allow users to paste, it is a step backwards.' Just go back to the basic input widget.

Especially password fields must be pasteable

You should be encouraging your users to be using long unguessable passwords. This means they will be generating them or storing them with something app or some service but not in their heads. They will be copying them into the pastebuffer and pasting them into your app. If they then can't paste them in, and are forced to type them (perhaps on a phone keyboard with the echo of the characters replaced by dots) they may give up and switch to using a short and unsafe password out of frustration.

Password fields must be optionally visible

It seems that when I am entering a password on laptop I sometimes I have a checkbox available to make it visible, but often the option isn't there.

Meanwhile, on a phone, the ability to make the password field visible is more important. If you want to use a good password, I am not going to be able to type it in without mistakes -- unless you let me see it as I type it and pour over it to correct errors before I hit Enter.

Set up the focus where I will need it

When I load a form, for example a log-in page, I am typically going to be filling out the form starting at the first field. It is a bit lame of I have to click on the first field to get the focus there. You should set that up automatically. After that first field, I should of course be able to navigate around the form using tab.

Only, though, take the focus if you are doing it immediately as a result of my user action, so I am expecting it. Otherwise you will not only confuse me, you might also end up with secret thing I was typing somewhere else.

Never user modals

A modal dialog box is one which interrupts the flow of user interaction, blocking the ability to use any of the rest of the UI, until the user has finished the sub-task involved. They are almost always a bad idea, unless it really is crucial that the user attend to nothing else until the dialog box is answered. The problem is the at the user is working on things in parallel, and for all kinds of reasons will justifiably want to work on different things before they finish the sub-task. They might even need information

An example of doing it wrong might be, on a bank web site, popping up a blocking UI to transfer money from one account to another, when the amount o money transferred, or an account number, may be elsewhere in the site and end up being inaccessible. Another example might be of popping up a modal which the user doesn't understand, while blocking their ability to actually look up the help information about it.

Instead, just open up the dialog box in the real estate you have on screen, between other things, and when the user has finished, close it up again.

Up to Design Issues

Tim BL

Also,... never use a multi-page electronic digital road sign. It distracts users, who have to take their eyes off the road for 10-12 seconds... safer to send them a text?