uccser/cs-field-guide

# Users and tasks

A very important consideration when designing or evaluating an interface is who the {glossary-link term="user"}users{glossary-link end} are likely to be.
For example, the typical age of a user can be significant: very young children may have difficulty reading some words and prefer images and animations, while someone in a commercial setting who uses an interface frequently will want it to be very fast to use, perhaps using keyboard shortcuts only.

Think about the kinds of considerations you would have to make for the following user groups.

- Senior citizens
- Gamers
- Casual users
- Foreign visitors

{panel type="spoiler"}

# Some possible answers: Don't open until you've thought about it!

- Senior citizens: use large print, have few features to learn, don't rely so much on memory, allow for poor eyesight and less agile physically (e.g. large buttons help), don't assume previous experience with computers
- Gamers: use previous experience with typical game interfaces, expecting challenges, possibly running on a high-end machine
- Casual users: interface needs to be very easy to learn, perhaps based on widely used systems, needs clear guidance
- Foreign visitors: use simple language and meaningful images/icons

{panel end}

The interface is the only part of a program that the user sees (that's the definition of an interface!), so if the interface doesn't work for them, then the program doesn't work.

Another important thing to do when designing and evaluating an interface is to think about what {glossary-link term="task"}tasks{glossary-link end} it is being used for.
Advertisements for digital devices often hide the complexity of a task, and simply point out the features available for doing the task.
For example, suppose a smartphone is advertised as having a high resolution camera.
The real task that someone might want to do is to take a photo of something they've just spotted, and send it to a friend.
If you look at what happens in reality, the smartphone might be in their pocket or bag, and if they see something cool going past, they need to:

1. Get it out.
2. Unlock it.
3. Open the camera app.
4. Adjust the lighting and other settings.
5. Press a button (is it easy to find when you're holding the camera up?).
6. Select the photo.
7. Choose a sharing option.
8. Select a friend to share it with (does the system help with that?).
9. Send it (what happens if you're out of reception range?).
10. Put the phone away.

If any one of these steps is slow or hard to remember, the whole experience can be frustrating, and it's possible the photo opportunity will be missed, or for some other reason the friend won't receive the photo.

It's important to think through all the parts of a task when discussing an interface, as it's the small steps in a task that make all the difference between using the interface in a real situation, compared with a demonstration of some features of the device.

{panel type="challenge"}

# Thinking about the context of tasks

It's very important to think about the whole context when describing a task.
As an exercise, can you provide an example of a real task, including context, for a real person for each of the following:

- Set an alarm clock
- Show a slide (e.g. PowerPoint) presentation

Discuss your answers with a classmate or a friend.
This should help you to evaluate your own answer, and consider other possible examples.

{panel end}

{panel type="teacher-note"}

# Possible answers for above challenge

The educational goal for students is to see the big gulf between the naive design view of "set an alarm clock" as being a sufficient task description versus a specific scenario that gives the task much more meaning.
It can take some effort for students to break down a task into its critical steps; if they have done the task before they have probably become adept at it and have forgotten any initial challenges, and if they haven't done the task, they may assume that it's easy.
Some of the ideas that you could prompt for are:

- Set an alarm clock: the task is often done late at night, and if a mistake is made the user may miss an important appointment or flight in the morning, so it's already challenging.
  Depending on the clock (it might be on a smartphone, or a physical clock), the user needs to set the alarm time (including getting the am/pm part right), switch on the sound for the alarm (perhaps making sure that the device isn't muted), and make sure it has sufficient power to last until the morning.
  All this is being done while tired, and a mistake could be costly!
- Show a slide (e.g. PowerPoint) presentation: this task is often done in front of an audience, and there may be limited time e.g. if the room isn't available until a few minutes before the presentation.
  The computer may need to be connected to a projector (a whole interface challenge in itself), the software put into presentation mode with the right image ready to start, the user needs to be able to move to the next slide, and recover from pressing a wrong key.
  To add to the challenges, a projector usually takes a while to warm up, and it can be hard to tell what's happening during that time.

{panel end}

{panel type="curiosity"}

# Dumb users or dumb interfaces?

Computer systems often make people feel dumb – in fact, there are lots of "dummies" books available, such as "iPad for dummies" or "The Complete Idiot's Guide to Microsoft Windows 10".
These books sell millions of copies, yet chances are the people who buy them are actually quite intelligent – it's just that the interfaces can make people so frustrated that they feel like a dummy.
The truth is that if an interface makes lots of people feel like an idiot, chances are the real problem is with the interface and not the user.
In the past there has been a culture where the balance of power was with the programmers who designed a system, and they could afford to blame the users for any problems.
However, now users have a large choice of systems, and there are competitors ready to offer a better interface, so if a programmer continually blames your users for problems, chances are it's the programmer who is the complete idiot!
If you hear people using derogatory terms such as luser, [PEBKAC](http://ars.userfriendly.org/cartoons/?id=19980506), or ID-10T error (Idiot error),
they may be humorous, but they usually show a disregard for the importance of getting an interface right, and are a sign that the system is badly designed.

{panel end}

{panel type="project"}

# Sending an email from multiple devices

For this project, try sending an email from both a computer and a mobile phone.
Take note of all the steps required from when you start using the device until the email is sent.

You will probably notice quite a few differences between the two interfaces.

Keep your notes for later, as you can further analyse them once you have read through more of this chapter.

{panel end}

{panel type="project"}

# Designing stovetops and door handles

{image file-path="img/chapters/poor-door-design-cartoon.jpg" alt="User conflict opening a door." position="right"}

For this project, you will design the top of a cooking stove, or the handles on a door.
This isn't a computer system, but will help demonstrate some of the issues that come up.
The main task is to sketch three different configurations for the stovetop which includes the arrangement of the 4 elements and the 4 control knobs.

The task is [described in detail in CS Unplugged human interface design activity](http://csunplugged.org/human-interface-design).

{panel end}