The user environment comprises the traditional five senses, as determined by the computer. The computer programmer is responsible for how the user will interact with the computer. The following image displays how the user interaction cycle works:
The preceding image shows how the user provides input to a computer through a particular hardware device. The computer hardware converts the input information to software commands that are processed by the operating system, and the appropriate application.
Once the data has been processed, the process returns to the user: the application (or a different one, if appropriate) generates a return signal that is processed by the OS. The return signal is converted into the correct output signal, such as video or audio, and that signal is sent to the appropriate hardware device, where the output signal is finally received and interpreted by the user. Then the user responds to that signal and provides a new input signal, and the whole process starts anew.
The user's environment has to be accounted for, to make an appropriate interface for the situation. Enough information has to be provided without overwhelming the user with information overload, as well as "noise": information that is irrelevant to the task at hand. The following are a couple of examples of how designing a user interface with no regard to the user's environment can affect the situation:
- Three Mile Island: In 1979, the reactor at the Three Mile Island power plant had a stuck relief valve. However, the control panel's indicator light only indicated if the open/close signal was sent to the valve, not the true position. So, the relief valve was stuck open; but the control panel was indicating that it was closed. Hence, the reactor coolant leaked out to the point that the reactor overheated, which then released radioactive gas into the air outside the power plant.
- USS Vincennes: In 1988, the US Navy cruiser USS Vincennes shot down a civilian airliner after mistaking it for an enemy plane approaching on an attack run. The problem was that the radar operator's console on the ship had three large screens that showed the airspace around the ship, but none of them showed a plane's speed, range, or altitude. That information could only be shown by clicking on it with a cursor, and that information was provided by a separate, smaller screen.In addition, there were two separate cursors to highlight the desired target. One would track an item on the big screens, but a separate one had to be used to get the plane's flight information. A crucial fault, though, was that none of the provided information indicated how quickly a plane was gaining or losing altitude.Thus, the operator had the desired target highlighted on the big screen with the first cursor, but the second information cursor was on a different military jet. Thus, the information displayed on the smaller screen was of an actual military jet, while the desired target was a civilian plane.
While the preceding two examples aren't directly related to a normal GUI, they do show that the environment in which the user will be expected to use an interface plays a large factor in how it should be designed. Normally, people will interact with GUIs in a stress-free environment but, for a programmer or designer, the worst-case scenario should be expected.
When it comes to the GUI for our fuel farm scenario, it is advised to make it simple to use and understand. The worst-case situation is that the user needs to deal with a fuel spill and, thus, stop flow quickly to prevent a possible explosion.