Nielsen's first heuristic is visibility of system status. And what this means is, the system should always keep users informed about what is going on with the system through appropriate feedback within a reasonable amount of time. So, we first might ask, why is this important? Well, knowing what actions are available, so what the system can accept or what actions are possible at this particular time, bridges the Gulf of Execution as we've discussed previously. Knowing how the system responded to actions that the user has taken bridges the Gulf of Evaluation. And this also echoes Norman's principles of Feedback and Constraints that we discussed in previous lectures. This heuristic manifests in a few different ways in the design of systems, and I'm going to go through them each one by one. So the first way that this manifests is through feedback. And it's important to provide good feedback to actions that users take. And feedback happens at multiple levels throughout the system, and a well-designed system will provide feedback both at the level of very small actions that the user takes, as well as larger actions that support the users goals. Let's look at a live system to just look at examples of how feedback happens. So if we just were to browse around on Amazon for a moment, we can see many examples of how feedback is used. So for example, when I hover my mouse cursor over these different links right here towards the top. You can see that I get feedback that that link will be selected if I press, through that subtle underlining effect that shows up. And you can see many other places where if I hover I see feedback from the system telling me that it's recognized my action and what it's going to do. And of course, if I click on one of these links, I'm rewarded with feedback showing me that the system has accepted my input and taken the action that I desired. In some places, the feedback is even more explicit. So for example, in Gmail, if I mark conversations as read, I get a banner at the top of the screen showing me explicitly what the result of my action has been. In this case 12 conversations have been marked as read. And I'm given the opportunity to undo that action if I wish. Another place that the visibility of system status manifests in user interfaces is through showing the user what actions are available at the current time, and by extension, what actions are not available at the current time. So in PowerPoint, for example, when I have text selected in the design window, a certain set of options, such as selecting a font, and the size of the font, and bolding and adding italics and things like that are made available, but if I don't have anything selected, those options are not available. If I switch PowerPoint out of presentation mode and into design mode, we can see this example directly. So right now, the options for modifying text are grayed out because they're not available. And as soon as I go over and select some text, they're made available. This is an example of the system showing me what status it's in in terms of what actions it can accept and what I can do at any particular time. It's also important for the system to indicate its general availability to accept any kind of input. And we often see examples of this especially at the operating system level where the operating system will indicate that it's busy and it can't accept any input. It might be busy downloading some data or connecting to the network or otherwise engaged and unable to accept our input. And we typically see this through various kinds of changes to the cursor that indicate that it's not going to accept our input at this particular time. When something takes a particularly long time, it can be valuable to present the user with an indication of how far along the process has gotten, and allow them to assess how long it's likely to take. So here's an example from installing a Windows update, and here's an example from Chrome of showing how long it will take to finish downloading a large file that the user has downloaded. And there are some general rules of thumb that we can follow when deciding what kind of indicator we should provide when the system is going to take a long time to do something. So here we need to understand how users are likely to react to different kinds of delay. We know, for example, that anything that happens within 100 milliseconds or a tenth of a second in response to a user's action, is perceived by them as instantaneous. If it takes longer than that but less than a second, the delay is noticeable but is typically tolerable and users will be able to adapt to that delay. If it takes longer than a second but less than ten seconds, it starts to get pretty annoying, but most users are willing to wait so that they can continue their task right away. And if something is going to take longer than about ten seconds, its' better to let the user go and do something else. They are likely to lose focus on the task that they are accomplishing and they are likely to prefer to go and do something else like check email, go get a cup of coffee, or do something else while they wait for that process to finish. So we can turn this into a set of general guidelines for what kind of indicator we might use in different situations. So first of all, if it all possible, you always want to strive for a fast response time, which means less than 100 milliseconds. That's not always possible. If it's going to take up to a second, no indicator is needed. You don't really need to change the cursor. You don't need to indicate that the system is busy. By the time the user recognizes the delay, the delay will already be over. From one to ten seconds, you want to use a wait cursor. You want to change the cursor into the beach ball or the hour glass or whatever it is on your particular platform to indicate that the system is busy but it's planning to come back. And if somethings going to take more than 10 seconds, you want to complete that task in the background, and indicate to the user that it's going to take a while and they should go do something else. And provide them with progress indicators and estimates of how long it will take so that they can plan accordingly. So those are the ways that Nielsen's first heuristic, visibility of system status manifests in system design. Through feedback, through showing available actions and through showing the general availability of the system to users.
