User interface

Chapter 16

User interface of a software product is the “face” of it. Many “user errors” are caused by the fact that user interfaces do not consider the capabilities of real users and their working environment. A poorly designed interface means that users will probably be unable to access some of the system features, will make mistakes and will fell that the system hinders rather than helps them in achieving whatever they are using system for.

While designing user interface, some physical and mental capabilities of the people who will use the software should be taken into account. Some of them are:

  1. People have a limited short-term memory.
  2. We all make mistakes, especially when we have to handle too much information or are under stress. Too much system warnings, alarms etc. can annoy stressed people thus increase the chances that they will make more operational mistakes.
  3. We have a diverse range of physical capabilities. Some people see and hear better than other, some people are color-blind, etc.
  4. We have different interaction preferences. Some people like to work with pictures, others with text.

These human factors are the basic for the design principles.

The principle of user familiarity suggests that users should not be forced to adapt to an interface because it is convenient to implement.

The principle of user interface consistency means that system commands and menus should have the same format, parameters should be passed to all commands in the same way, and command punctuation should be the similar. However, full consistency is neither possible nor desirable.

The principle of minimal surprise is appropriate because people get very irritated when a system behaves in an unexpected way.

The principle of recoverability is important because users inevitably make mistakes when using a system. The interface design can minimise these mistakes, but mistakes can never be completely eliminated. Consequently, system should include some tools allowing users recover from their mistakes. These can be of three kinds:

  • Confirmation of destructive actions. To avoid accidental destructions or to explain consequences for user.
  • The provision of an undo facility. Undo restores the system to a state before the action occurred. Multiple levels of undo are useful because users don’t always recognise that a mistake has been made. (Why mspaint (not talking about paint.net or mspaint from Windows 7) has only three levels of undo, or do they think that people who use mspaint are only pros and don’t do too much mistakes??!)
  • Checkpointing. It involves saving the state of a system at periodic intervals and allowing the system to restart from the last checkpoint. Similar to simple backup system for data.

A related principle is the principle of user assistance. Interfaces should have built-in user assistance or help facilities.

The overall user interface design process in general concerned with two main questions: how should the user interact with the system and how should information from the system be presented to the user? User can interact with computer system in a number of ways, most common of them are:

  1. Direct manipulation. The user interacts directly with objects on the screen. It usually involves a pointing device, e.g. a mouse or a finger on a touch screen (like on your white 16 gig iPhone).
  2. Menu selection. The user selects a command from a list of possibilities (a menu).
  3. Form fill-in. The user fills in the fields of a form. Some fields may have associated menus, and the form may have action to be initiated.
  4. Command language. User enters a special command and associated parameters to instruct the system what to do (bash!)
  5. Natural language. The user issues a command in natural language. This is usually a front-end to a command language. (I also think that this includes voice commands)

Про айфон выше это я так пошутил, у профессора был такой.

Presentation of information by a computer system depends on user of the system. Also, the issue of colour in presentation is important. The most important key guidelines for the effective use of colour are:

  1. Limit the number of colours employed and be conservative how these are used.
  2. Use colour change to show a change in system status.
  3. Use colour coding to support the task users are trying to perform.
  4. Use colour coding in a thoughtful and consistent way.
  5. Be careful about color pairings.

The user interface design process includes sub-processes concerned with user analysis, interface prototyping and interface evaluation. The aim of user analysis is to sensitise designers to the ways in which users actually work. Different techniques (task analysis, interviewing, observation) are used during user analysis. User interface prototype development should be a staged process with early prototypes based on paper versions of the interface that, after initial evaluation and feedback, are used as a basis for automated prototypes. The goals of user interface evaluation are to obtain feedback on how a UI design can be improved to assess whether an interface meets its usability requirements.

My thoughts

As I was reading this chapter, I was thinking about how serious and professional Apple’s user interface designers are. Every point of the stuff discussed in this chapter was a serious for them. Like the principle of user consistency: in Mac OS user can always be sure, that the program he never used before will have a menu line at the top of the screen. ALWAYS!

Actually, the iPhone is one of the few products where I don’t even want to customize user interface, because it feels like someone did think. In general, I think of user interface as a very important and really interesting field in software engineering. Right now I’m working on GUI for our project, so this chapter was pretty useful for me.

 
software_engineering/user_interface.txt · Последние изменения: 2009/09/17 03:37 От freetonik
 
За исключением случаев, когда указано иное, содержимое этой вики предоставляется на условиях следующей лицензии:CC Attribution-Noncommercial-Share Alike 3.0 Unported
Recent changes RSS feed Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki