I am not claiming to be an expert in building good user interfaces, in fact I have been known to use terrible color combinations, overload forms with too many controls and confusing the user. But on the other hand I have been using computers for all of my adult life and I have seen quite a lot of really bad user interfaces, so I think I know a bit about what not to do.
Being a Delphi programmer by profession, even by passion, most of this applies to Delphi, but probably a lot of it applies to other tools. So, here we go:
Do not trap your users
One of the worst feelings for a computer user is that he has done something and cannot get back. Some programmers think it is a good idea to check the user input and force him to enter valid data. E.g. there is an entry field that only allows numerical input and if the user dares to enter something the program does not like, that field will turn red and will not let go of the input focus until the user has done what is required of him. Often this even means that he cannot press the Cancel button or close the window. Instead an error dialog is shown with a more or less generic message. Combine that with some annoying Pling sound and you will certainly entertain the whole office.
So, what do I suggest?
- Input validation, even coloring the background is a good thing, but use a color that won’t reduce readability, like a very light red. I for one prefer yellow.
- Do not force the input focus anywhere. If the user decides he wants to fill in other fields first, before going back to a field that was marked as invalid, that’s fine. He might have a reason for it. E.g. he might have just copied some text from another application to the clipboard in order to paste it into that input field.
- Of course, any button for submitting the input should be disabled until the input passes validation.
- Do not play error sounds. In today’s open plan offices but even in a smaller, shared office, this will absolutely annoy not just the user but also his colleagues.
- Do not pop up error dialogs. They unnecessarily disrupt the user’s focus on your dialog. Most people nowadays are keyboard averse and will in that case use the mouse to close that dialog which disrupts their work even further. Also, as we all know, users don’t read error messages, they just want that annoying dialog go away.
- If input validation fails, the user needs to know, where and why. Do not just disable the OK button, but give visual feedback what is wrong. Personally I prefer invalid input to get yellow background (As I said above: My color perception may be warped.). Also, there should be a text telling the user what kind of input is expected. That can be a text in the status bar or maybe even better near the input field that contains the offending input.
- Do not automatically clear input fields with wrong content (Yes, I have seen programs do that, but that bad habit is most common with online forms.). It’s always easier to correct the input than to type it again. Imagine some user pasting a 10 digit number from his spreadsheet into your program and getting the decimal separator wrong (Yes, my American readers: There is such a thing as decimal separator other than the point. Many European countries use the comma. And don’t even get me started about date formats!). He might then simply replace that one character with the correct one rather than typing the whole 11 characters again.
- Do not prevent pasting from the clipboard. Some people think it is a security risk to allow users to paste data from the clipboard into their program. In particular some programs do not allow pasting passwords. I might be wrong here, but I don’t see how not allowing paste from the clipboard improves security. If the system is compromised, the user is f***ed anyway. Of course copying from password input fields to the clipboard is a different matter.
- Another thing about password input fields is the display. In some environments, showing the password in clear text is definitely not a good idea as somebody might be “shoulder surfing”. On the other hand, the user needs some way to determine whether he might have mistyped his password and correct it. Passwords are commonly displayed as *** or similar characters. Personally I like an option to temporarily display the password in the clear, e.g. a button which shows it as long as it is being pressed. There is a slight security risk (apart from “shoulder surfing”) here: If the user leaves the computer with this input mask open, somebody else can also press that button and read the password.
- Be consistent! If you in one part of your program use yellow as the error color and display the input hint in the status bar, you should do that everywhere. If you develop internally used software for a company, somebody should decide how to do error handling and this should be enforced.
The above would not be complete without a link to my own input validation unit in dzlib.
That’s the end of part 1. I am sure I will continue that series at some time. Be prepared to hear me rant about tab order and resizable forms next.
Edit: Here is Part 2