User Interface Design

A bit of psychology

• A feeling of helplessness comes from not being able to control your environment
• We perceive this based on small successes and small failures each day
• Examples:
  • If your roommate's alarm clock wakes you up at 6 am, the food is bad for breakfast in the cafeteria, and you attend a boring lecture, you will feel frustrated and annoyed
  • If you get up on time, eat a satisfying breakfast, and ace a test, you will feel happy and fulfilled
• These phenomena are extremely important when dealing with computers
• Examples
  • If you want to check your email and the network is acting up, you will be annoyed
  • If you write a bunch of code but you don't understand the errors from the compiler, you will be frustrated
  • When your code has some simple compile errors that are easy to fix, and it then has only one bug that is easy to fix, you will feel happy
• Users of computers get annoyed when the computer does not "do the right thing"
• Examples:
  • Someone who has always dealt with files using the graphical folders is forced to wrestle with the command line on Unix
  • You click on a file and it doesn't bring up an appropriate program to open it with
  • Someone who is used to Windows uses a Mac

Major premise (rule #1):

• A user interface is well-designed when the program behaves exactly how the user thought it would.

Mental models

• User model: User's expectations of what the program will do
• Program model: What the program actually does
• A good user interface: user model == program model
• If the user and program models conflict, there will be problems
  • It is easier to change the program model than the user model
  • Users do not read manuals, and they ignore help menus

Discovering user models

• Ask users
  • Interviews
  • Prototypes
  • Five to six seems like a good number in general
• Simplicity
  • User models are rarely complex
  • If a user has to guess how it works, the guess will be simple

Consistency

• User models tend to be shaped by their environments
• Their environments include Microsoft products
• Hence, if there is an equivalent Microsoft (or other popular) product, do the same things the same way
• Emulate popular programs as closely as possible
  • Don't be creative!

Users have better things to do

• They do not want to use any extra brainpower to figure out your program, even if they have the brainpower available
• They don't read the manual
  • In general, they have more urgent tasks, so even if they can find the manual they will consider it a waste of time to read it
• In fact, they do not read _anything_
  • Any substantial text in a dialog box will be ignored
  • The probability of text being read is inversely proportional to its length
• Users do not want to make decisions about things they don't care about
• These are not always facts, but design as if they were

Assume that users can't control the mouse very well

• Make stuff big
• Use courier or other monospaced fonts for text
  • Makes cutting/pasting easier
  • Consider the letter "i"

Don't ask users to remember anything the computer can remember

• File dialog boxes are a good example of addressing this well

Bottom line: Testing and iterative development

• Have users run your program
• Observations to make:
  • What is hard?
  • What is common?
• Get their feedback on ease of use
• Also find out their goals for the software, so you can figure out what to support