Every computing system has a boundary where it meets the world, and this section works inward across that boundary in four steps. First come the physical devices that carry data in and results out. Above them sits the interface, the style of interaction a program offers, whether typed commands or windows and menus. Within a graphical interface there are smaller choices about individual controls, and over all of these lie the qualities that make a design usable and accessible. The section ends with the method for finding out whether a design actually has those qualities, which is to watch people use it.

Devices that carry data in and out#

The most basic way to describe a computer is by what flows through it: data comes in, is processed, and results go out. An input device sends data into the system. Keyboards and microphones do this, and so do sensors, which measure something about the physical world, such as a rooftop anemometer measuring wind speed for a school weather station or a probe measuring soil moisture in a greenhouse. An output device presents results or acts on them. Monitors, speakers, and printers present results to people, while actuators act on the world directly: a pump, a valve that waters the greenhouse when the soil is dry, or a motor. That last case is a useful corrective to a common assumption, because a system with no screen and no sound still has output if a valve opens in response to its processing.

The test for which category a device belongs to is the direction the data moves relative to the system, not whether a person learns something from it. A lobby display that shows the latest wind speed gives people information, but it is output, because the data is leaving the system. A processor that averages readings handles data without being its source, and memory that passes values to the processor isn't an output device either. Some devices work in both directions. A touch screen senses touches, which is input, and displays results, which is output. A processor and software interpret each tap and generate each image, but they do their own work, and the screen still plays both roles. A smart doorbell shows how devices sort out in practice: its camera, button, and motion detector all send data in, and only the speaker that sounds the chime inside the house is output.

Output also needn't be visual. Speech output and braille serve blind users, and a refreshable braille display presents results by touch. This matters when choosing equipment, because a magnifying monitor still depends on sight, and a keyboard with tactile markings or a scanner helps someone send data in without giving them any way to read what comes back.

Command-line and graphical interfaces#

Devices determine how data physically moves, and the interface determines how a person tells the system what to do. Two broad styles dominate, and they make opposite trade-offs between efficiency and discoverability.

A command-line application runs through a terminal, a text window where the user types commands and the program replies in text, with input coming through the keyboard alone.¹² Losing a mouse therefore has little effect on this kind of work. The command line is efficient: one command can act on thousands of files, as when converting all 400 images in a folder at once. It is also easy to script, which means placing commands in a file that runs with no person present, so that repetitive work happens unattended. Because a terminal session sends only typed commands and text replies, it uses far less bandwidth than a remote graphical desktop, which has to keep sending a continuously redrawn screen. This is one reason the command line suits administering remote servers. Its weakness is that commands are hard for new users to discover. The prompt gives no visible indication of which commands exist, so they have to be known or looked up, and experienced users are fast largely because they already know them. Typing a command doesn't bypass anything, either: the system's permissions apply to commands as they do to clicks.

A graphical user interface (GUI) makes the opposite trade. It uses windows, icons, menus, and a pointer, so options are visible on the screen. Users can recognize an option instead of recalling its exact name, which reduces what they must remember and helps people who are new to a program, such as a staff member trying unfamiliar printer options for the first time. The cost appears with repetition. A graphical application makes each action easy to find but leaves the repetition to the user, so a task repeated 500 times becomes slow when done by hand, and repetitive tasks are harder to automate than they are with commands.

Hot keys partly bridge the two styles. They are single keys or combinations of keys that jump straight to a function, so that a clerk entering data can keep both hands on the keyboard without repeated trips to the mouse or trackpad. Pressing the combination for Undo, for instance, avoids both the trip to the trackpad and the search through a menu. Hot keys work best when they follow common conventions, such as Ctrl+S for Save. Users carry their habits from one application to another, so a program that assigns a familiar combination to a different action invites people to trigger the wrong one.

Choosing controls within an interface#

Within a graphical interface, a designer makes many smaller decisions about how each choice is presented, and form controls are the clearest example, because each control encodes a rule about how many answers are allowed. Radio buttons allow exactly one selection, since choosing one clears the others, which suits mutually exclusive options such as a single shipping speed. Checkboxes allow any number of selections among options that aren't mutually exclusive, such as the workshops someone wants to attend or every language they speak. Presenting those languages as radio buttons would wrongly force people to report only one. A single checkbox can also express a yes-or-no choice through its checked and unchecked states, so a pair of yes and no radio buttons isn't needed. A drop-down menu saves space when options are many: fifty radio buttons for fifty states would fill the screen, while a drop-down list stays compact and, unlike a free text field, still restricts answers to valid choices. Instructions on the screen don't substitute for the right control, because a note saying "choose one" doesn't stop anyone from checking several boxes.

Usable, accessible, and responsive design#

Choosing the right control is one part of a broader question, whether people can use the interface well. Usability has several recurring principles. A usable interface is consistent, so that placing commands in the same location on every page lets users transfer what they learn from one page to the next. It gives clear feedback, telling users what the system has just done. A progress indicator that appears from the moment an upload begins, for example, shows that the system is working, so users have no reason to click again. It prevents errors where it can, which means making serious mistakes harder to make: separating a Delete button from Save, or asking for confirmation before anything is deleted, acts before the damage, while a message afterward doesn't. When errors do happen, a helpful error message explains how to recover. A message stating the required date format, with the user's other entries left in place, gives direction and limits the cost of the mistake, while a louder alert or a larger red warning gives none.

Accessibility extends the same concern to people with disabilities, and 0001.e covers it in depth. For an interface, a few practices do most of the work. Controls should be labeled elements that receive focus through the Tab key, so that the interface doesn't rely on a mouse alone, since some users can't operate a pointing device. Semantic structure matters too: a real <button> element comes with keyboard behavior and with meaning that assistive technology can announce, while a <div> styled to look like a button has neither, and visual changes can't supply them. Text needs sufficient contrast with its background for people with low vision. Information shouldn't depend on color alone, since color conveys nothing to a screen reader user and may be indistinguishable to someone with color vision deficiency.

Phones add physical constraints of their own. A fingertip is less precise than a pointer, so touch interfaces need adequately large touch targets with adequate space between them. Phone screens are also narrow, so layouts should adapt to the width of the screen, rearranging or scaling content instead of forcing a fixed width. A layout that does this is called responsive, and it lets one site serve phones, tablets, and desktops. Hover doesn't exist on most touch screens, so information hidden behind resting a pointer on an element is unreachable there. The reliable way to find these problems is to complete common tasks on real phones and in phone-sized windows, which exposes problems that reading code or checking file sizes can't reveal.

Watching people use it#

That last point generalizes. Designers know their own interface too well to see where others will struggle, so the qualities above have to be checked with people. Usability testing observes representative users performing real tasks, to find where a design causes confusion or errors. A university testing its registration portal should watch a few first-year students trying to register, not ask staff who already know the system, and someone who has never seen a design, such as a substitute teacher, can show where newcomers struggle. Even a few users reveal many problems: a finding such as "four of five parents could not tell where to enter a child's allergies" is exactly what a test is for. Observers shouldn't guide participants, because help hides how users would have behaved without anyone there. Finally, what users say and what they do often differ. People may like designs they can't use well, so when stated preferences and task failures disagree, the failures deserve priority. Watching people at the boundary of the system raises the question of what lies behind it, and the next section turns to the hardware and software inside the device.

• input device: hardware that sends data into a system, such as a keyboard, microphone, or sensor
• output device: hardware that presents results or acts on them, such as a monitor, speaker, printer, or actuator
• sensor: an input device that measures a physical quantity
• actuator: an output device that acts on the physical world, such as a pump or valve
• command-line interface: an interface in which a user types commands into a terminal and reads text replies
• script: a file of commands that runs without a person present
• graphical user interface (GUI): an interface built from windows, icons, menus, and a pointer
• hot key: a key or key combination that gives immediate access to a function
• radio buttons: a control allowing exactly one selection
• checkboxes: controls allowing any number of selections among options that aren't mutually exclusive
• drop-down menu: a compact list of choices, useful when options are many
• feedback: an interface's indication of what the system has just done
• touch target: the area of a touch screen that responds to a tap on a control
• responsive design: layout that adapts to different screen sizes
• usability testing: observing representative users performing real tasks to find confusion or errors

Practice: practice questions for 0003.a

1. MWC1, Terminal Adventure: working from a command line. ↩

2. MWC1, Pipes: programs as transformations of data, and combining commands. ↩