Just recently I finished reading a book titled “The humane interface” by Jef Raskin. I have this book in paper and it was a nice read. For someone that has been programming for a few years it was refreshing… in my time I had to design good looking, functional and understandable interfaces. I thought about writing an in-depth article about my experiences, tips and tricks with some guidelines, but the book proved to summarize pretty much everything I wanted to write. Therefore I will quote some key points, add my thoughts about it, write about how I feel interfaces could be designed. Though keep in mind I’m not professional designer here, and programmers shouldn’t do interface design :P
I’ll start with the definition of an Interface. Quote from the book:
I usually shorten human-machine interface or human-computer interface to user interface or simply interface. Many people assume that the term user interface refers specifically to today’s graphical user interfaces (GUIs), complete with windows and mouse-driven menus.
That’s correct, you probably heard of website API backends that allow developers to communicate with that service, well that is also called an interface, however not graphical. Interfaces allow people, be it a user or a developer, to communicate with a service. Standalone system program or a website…
Graphical user interface (GUI) refers to an interface which is visual and gives out information and accepts input, while an interface is basically the same, but not visual, often defined in a protocol. Take twitter, facebook or other API backend as an example. Sometimes that stuff can be complicated :P
I’ll be talking mainly about GUI’s here.
Technology is like a love-hate relation. You can’t live without it, but it’s hard to live with it.
It is probably safe to say, that a simple and understandable interface is as important as functional code behind it. It’s what the user sees and if it will look ugly, the user won’t be happy and if they won’t be happy, then the whole work could be thrown out because no one will use it.
Users do not care about what is inside the box, as long as the box does what they need done.
So
Once the product’s task is known, design the interface first; then implement to the interface design.
This is how I like go about it, not the other way around. It’s much easier to shape the code and do changes to an interface after you created it in the first place. I know this from experience, and besides, that’s the most fun part of whole project :D
The main key to a functional and fast GUI is to NOT keep the user waiting if not needed, annoy him with unnecessary alert or information boxes, make him do repetitive work… The way I see it, as an example, if a program needs to tell something to the user that is of informative type, it could be placed somewhere at the bottom, a status bar is perfect for that. If some task need to be done by the program, and if it is known that it isn’t typically gonna take very long to complete and if it’s a crucial part of whole system, then the user doesn’t really care or need to see that some stuff is going on. All he wants is the result.
Human organism is a perfect example of just that, quotes from the book:
An unconscious process, such as the one that monitors your bladder pressure, can be a stimulus, whereupon the need to relieve yourself becomes conscious.
A user must remain in control as much as possible.
That first quote can be rephrased as “Organism monitors the bladder status and invokes a sense to relieve when needed”.
So, hiding messages or putting them aside is most of the time a good thing to do, however sometimes a user could be so into doing something that he might click button on instinct without really reading the message. This issue was discussed in the book thoroughly.
A good point made in the book:
The more you are absorbed in the task at hand, the less you notice your surroundings.
A simple program would only require a simple GUI, bigger is not always better and a lot of features tends to push the crash rate higher :P
I can tell from experience that users will always, no matter how well designed and tested your GUI is, find ways to break it and be displeased about it. So less features, less user input will maximize user experience and lower the risk for your program to crash if a user enters something wrong.
How a feature will be used depends on the people that will be using your product, their background and the context that feature will be used in.
It must be clear and obvious to the user what operations are available and what is enabled. Interaction should be done with every smallest unit of input. GUI must not lock-up and provide interaction with char-by-char basis.
Take a list search for example. If all you do is show a list of matches, update the list with every char a user inputs. Making the user press Enter in this case would be a design error.
If doing large searches, like on a website, don’t lock everything up with some progress indicator… let the user navigate elsewhere if he feels it is taking too long.
Use icons only where research has shown to be advantageous. Icons can sometimes be hard to decipher and understand.
That is so true. Most of the time I just hover my mouse over and read the tooltip to understand what is it for. I have noticed that labels are much better for understanding, but icons are more pretty, takes up less space and they are very good only when they are really obvious for what they are for. In android development an icon along with a label is most of the time much much better than only an icon. Of course, if an icon shows a dial pad or a phone, it becomes obvious that this button is for calling someone. However in a menu it’s better to use a combination of both, an icon and a label.
As a developer, I find it really hard to pick proper icons :P
The last thing I’d like to mention are messages to the user. Quote from the book:
Whenever you’re writing an error message – stop and redesign your interface, so that the error message does no arise.
And I fully agree with that. Error and information messages must pop-up only when absolutely necessary. Developers have very handy error catching mechanisms, called the Try-Catch block. They allow to steer the ship when shit goes really wrong and you should use them to stop annoying the user with popups and other knickknacks.
Also on the same note, the book says that, every time a user must interact with the computer, the user expects a productive outcome. This not only speeds up work, but also increases productivity.
Some messages might also be misleading, lack of information and so on. You have to be very careful when writing error messages, to make sure the stupid users understands it. Or better yet just do it for him… that might not always work though, as Windows7 proved with their “please wait while we solve your problems” bullshit that never solves anything :P
So to sum it up, these were my thoughts on the subject, and I urge you to read “The humane interface” if you haven’t done so already, it’s really great and gives some great insight on human psychology.