Hey folks, welcome back to our rundown of Nielsen's Ten Heuristics. As you recall in the last video, we went through our first four. In this video, we're going to do numbers 5, 6 and 7. So let's go ahead and jump right in with number 5 here. We want to match between our system and the real world. So as you recall, each of these heuristics has a definition that captures most of the meaning of the heuristic. And all these definitions come from Nielsen himself. And so, Nielsen describes this heuristic as, the system should speak the users' language. With words, phrases, and concepts familiar to the user, rather than using system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order. So I like to think of this here as having two parts. In the first part, we're thinking about speaking the user's language. And the second part, we're thinking about a more general version of the same idea. Which is making sure that information appears in a natural and logical order. So let's go through this, Part 1 and then Part 2, are speaking the user's language. This is a great example of a success, in terms of speaking the user's language. Those of you who are computer scientists, know that we refer to matrices, usually in a 0 indexed fashion. So the first cell here, the one that's highlighted, would be 00. This is from Excel, and Excel has learned to speak the user's language. It doesn't call this 00, it calls it A1. The 1 is because most human beings, other than computer scientist, count starting from 1 rather than 0. Again, speaking the user's language rather than the system's language. And the A is because people have a hard time remembering what a row is, what a column is, x, y, etc, etc. Quite frankly, I think sometimes, computer scientist do themselves. Does that 0 refer to the row or the column or so on and so forth? So Excel's done a really good job here and has indexed all of its cells in Excel, by A1, B1, C1, C2, etc. Rather than using a system terms as its probably implemented which starts from 00. Another good example of speaking the users language come from Airplane Mode, on most smartphone operating systems. What Airplane Mode does, is it turns off radios. But if you had a radio icon there and the text associated with it was, turn off radios. The vast majority of users would say, well, wait a second. I don't have a radio on this phone, do I have a radio? Can I tune in to FM and AM stations and so on and so forth. Instead, they're speaking the user's language. They're saying, the only time you'd really want to do this is on an airplane, so we're going to call this Airplane Mode. We're not going to use the term radio at all. That stays within the system development team, okay? When you're trying to speak the user's language, metaphors can be helpful but they also can be misleading. A great example comes from emptying the Trash or emptying the Recycling Bin. On Windows, this is from Mac OS, when you empty the Trash or empty the Recycling Bin using that metaphor. It tells the user, hey, the things are in the Trash, in the Recycling Bin, those things are gone forever. The garbage folks have come in and picked up the garbage. Never going to see this again, in most cases that's true. And it really has communicated, a pretty complicated idea, that deletion of a file on a disk, to a user in a way that's understandable. But it does have some risks, too. Those risks are associated with the fact that, in fact, in most cases, the file doesn't actually go away. Especially, when we're talking about older file systems and older disks. What happens is, the operating system says, hey, I can write over this spot, then next time I need some space. In the vast majority of cases, it's not a problem but if I were to take a computer that had a whole bunch of files that were important. Say, financial documents, personal documents, that were in the trash and the trash was deleted. And a user took that computer and gave it to their cousin or sold it on eBay. That's a concern, because the files actually can be recovered pretty easily. Even though, the user thought that by emptying the trash, those files are gone forever. So metaphors can be helpful but they also can be risky. Think carefully, when you use metaphors, okay? Let's go on to the second part of this heuristic. Which is making sure that information appears in a natural and logical order. And this is a great counter example, don't do this. This is a website from National Public Radio, which is our version in the United States of the BBC or the CBC. This is a map that shows the bikeability of each state in the United States. And it does not show information in a natural or logical order. A natural and logical order of this information would show more bikeable states as darker red or darker green or something. And less bikeable states as lighter red or light green. Instead, they've decided to vary the color or the hue. And you can pretty easily see the problems with this. Minnesota here, can you priorate tell, whether its very bikeable or not very bikeable? No, you have to go to the key and really study it. And you have to go to the key for every single color. Which wouldn't be the case, if they had varied the brightness rather than the hue or the color in this map. This is kind of a classic fail along the lines of making sure the information appears in a natural and logical order. Another, perhaps, even and more classic fail comes from light switches. Whenever you have a large group of lights. Very famously, or very traditionally, in terms of how this material is taught in a classroom, right? Very often, a classroom has eight different lights and they often appear in horizontal order. But the lights themselves are spread out all over the room. Right, so in this case, we have two in the front and two in the back. But the user's supposed to know that, okay, this two, this one goes here, this one goes here. This is not a natural and logical order. A natural and logical order would have two buttons here, right, and two buttons here. Two switches is here, two switches here. Right, this is a classic issue with light switches that, hopefully, in the future we'll be able to fix. Now, that we're entering the world of the smart home, I thought, this might be fun to show you that this problem has replicated even to this new smart home world. This is the app for the LIFX system, my wife and I invested in for a smart lights, to see what's going on with this whole smart home thing. And we, in general, love these lights, they're very bright, they're very fun. But they have the same problem as our classic light switches in their mobile interface. We have lights that are labeled but it doesn't say, where they are in the house, right? I wouldn't say, this is as serious as of a problem. As for instance, the light panels in classrooms because light panels in classrooms are used by all sorts of people. You don't do them very often so it's hard to learn. And they don't, typically, have text associated with them, like the LIFX App does. But to me, this is still a pretty serious violation of the natural and logical order component of this heuristic. So I'd give it a two rather than a three but that could be a judgement call. I did notice when I was putting together these slides, that people are thinking about fixes for this issue in the future. This is a fun light switch concept by two folks who have, essentially, set up an idea. Where the lights themselves are represented in the light switches, exactly, where they are in the room. Which would be a perfect light switch set up according to this heuristic. Okay, that's it for a match between system and the real world. Let's move on to error prevention. This is a big one, this is an important one. We've seen it a couple of times through examples but now we'll go through it in more detail. All right, let's do Nielsen's definition of error prevention, our sixth heuristic. Even better than good error messages is a careful design, which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they can commit to the action. So as I said before, we've seen a lot of examples of failures along the lines of this heuristic. So we saw that Google Maps allows people to route themselves through a war torn areas. Way back in course one, we saw an example of a chemotherapy system. That allowed users to give patients more radiation than any human could possibly need as part of their chemotherapy treatment. Which is a clear and very serious violation of this particular heuristic. Another very important one, although on the financial side, versus ultimately the most important, on the human life side, is this example. I don't know, if you folks have noticed, but very often airlines, yeah, once or twice a year. Airlines will have a situation where they, accidentally, issue a fare that is ridiculously low. So in this case, Delta accidentally issued a fair from Boston to Honolulu for $64, right? And then there's a news story about, will they honor the fair, won't they honor the fair, and so on and so forth. This is the type of thing, that in the pricing system, should be considered a failure of this heuristic. And its a four because its a million, millions and millions of dollars, the impact is quite large. Okay, so when you're thinking about this heuristic, I like to think of this quote from Laubheimer, who works with Neilsen. I'll show you a reference to Laubheimer's articles in a second. Laubheimer writes, that the designer is at fault for making it too easy for the user to commit the error. Or in other words, when you're thinking about this heuristic, your philosophy should be, there's no such thing as user error. When an employee of Delta entered that $64 fare, that is the designer of their pricing system's fault, right? We have to resist saying that users are stupid or did stupid things. We have to treat all user actions as potentially our fault. Same deal with Syria, the Syria routing example, and so on and so forth. Now, just as a quick refresher here, when we're talking about errors, we're talking about two types of errors in particular, right? These are the two types of errors users, typically, make in a system. The first is a slip, the user intends to perform one action but ends up doing something else. One version of this, that's quite common is the auto pilot error. So when you're doing something and there's a slight variation from what you usually do. You do what you usually do and a slip happens. The second type of error is a mistake. This is when your goals are inappropriate, so when the user wants to do something that really they shouldn't do. Now, regardless of whether you're dealing with slips or mistakes. There are a couple of solutions you can offer along with marking that there's an issue with this particular heuristic in a system. And also, by highlighting these solutions because, I think, it helps us understand the meaning of the heuristic, a little better as well. Okay, so when you notice an error prone situation, when you see a violation of this heuristic. One's potential solution is to double check with users, right? So when Delta Airlines' employees typing in a $64 fair, your system may have a some code in it that would pop up a message. And says, you know what, your fair is greater than two standard deviations below your competitors, right now. Are you really sure you want to do that? And in some cases, they might say, yes, if there's a sale, right? But in most cases, they'll say, no, that was a slip. I didn't mean to do that, right? So double checking with the users is a great way to solve problems associated with this particular heuristic. Another is providing helpful constraints, this is, particularly, good for slips. So for instance, in Google Flights, if you try to route yourself from Chicago to Chicago. For instance, you mix up the two boxes or you're watching TV or something along these lines. And Google will say no, no, no you can't do that. Rather than showing you that there are no flights from Chicago to Chicago, right? So this is a constraint, we won't allow this. And then, the user will realize, I didn't mean to do that. Chicago to Minneapolis, is what I actually meant. Another version of this constraint might be to say, hey user, we don't think we can route you to Jordan right now. Because you have to go through Syria or we can't give you the fastest route. Okay, so the final solution to problems associated with this heuristic, that we'll talk about, is using previews. This is, particularly, important when a user is about to engage in a costly operation. Particularly, discuss when the cost is associated with time. So for instance, it requires a reset or the computer has to process for 30 minutes, something along these lines. This a great example here, in IOS, you can choose two different sizes for your icons. The standard size and the larger size but it requires a restart, right? So what Apple has done smartly here is, it allows you to preview the size of the icons before you restart. So you don't have to go through a minute, two minute long operation, just to see, effectively, what your options are. This is a great example of a solution to a potential error-prevention violation, right? So if you're interested in learning more about preventing user errors. I really like these two articles from the Nielsen-Norman Group. You can see the URLs here, take a look at them if you're interested. Okay, so let's go and move on to our third and final heuristic of the video, and this is visibility of system status. So Nielsen defines this heuristic as follows, the system should always keep users informed about what is going on through appropriate feedback within reasonable time. So just from experience, I found that this heuristic breaks down into two corollaries. The first is that, for all operations greater than a few seconds, feedback about the progress of that operation, is absolutely essential. And the second is that modes are dangerous, they should be used minimally. And when they are used, they have to be very, very visible. So let's go through this one by one. Starting with feedback about operations greater than a few seconds. This one's really pretty simple and I made a little diagram to help us understand. So when we're making things, when things are very invisible. So this would be a series of violation of this heuristic, here. This is the situation that we've all found ourselves in at times when we're trying to click, right? The computer is doing something, we're trying to click but nothing's happening. We don't know exactly what the computer's doing. We don't know how far long it is in doing what it's doing. This is very not visible, according to the visibility of systems status heuristic, right? And it can be a problem ranging from one, two, three, or four on the heuristic evaluation scale. One way to sort of, a quick and dirty way to fix this, is to use the beachball or the Windows progress cursor, right? If you're developing an application for Mac OS or Windows, this happens actually, automatically, sometimes when the computer is doing something. So Apple and Microsoft have helped you and make your user interface accord to this particular heuristic. But the best thing to do, is to do a progress bar, right? This makes the system status very visible. It shows you, what is happening, in this case, there's a copy. It tells you what's going on and, in general, it'll tell you how far long it is, right? So it'll say, 62%, 73%, and so on and so forth. So this is the ideal case according to this heuristic. And this is a violation of this heuristic down here, right? The system status is completely invisible, system status is very visible. Okay, the second corollary of this particular heuristic is that modes are dangerous. They should be used minimally and when they are used, they should be very, very visible. So just to make sure that we're on the same page. A Mode is a setting in a user interface, such that the same input, will result in two or more different effects. Classic example of a mode is the Caps Lock key. Hit the Caps Lock key, I type an A, I got upper cases A. Hit it again, I type an a, I got a lower cases a. Classic mode, right? On, uppercase, same input, off, lowercase, right? So same input results in different things depending on whether the mode switch is on or off. Another good example is the bold button or the italics button or the underline button. That occurs in many, many different text editing applications including PowerPoint here. A fun example is the keyboard layout mode, that is in most operating systems, right? So I can switch my keyboard to Spanish where the same input will result in different output. Then if my keyboard layout is in the US keyboard layout. So in your interfaces, there are going to be times where you're going to think, you know what, I'll just implement a mode. If you can avoid it, you should. There are a number of ways to avoid it, we're not cover that in this course. But oftentimes, common sense will do the job, find a way to avoid the mode. Unfortunately, it's not always possible to avoid modes. For instance, consistency in standards, right? Our fourth heuristic, that requires us to have a Caps Lock key. That more or less requires us to do implement bold text in the same way. And I'd say, the same thing is true also of keyboard layouts. So we're kind of in a box, we want to make sure our easier interfaces are consistent and standard with norms, right? But at the same time, we want to avoid modes. In these cases, you go with the mode but you make sure they're really, really visible. And in all three examples here, we see that this is very much true, that designers have done a great job. Making sure that the status of the mode is very visible, for instance, the Caps Lock key. I'm sure it wasn't easy for Apple to implement a small little light on the Caps Lock key. But that tells us what's going on with this system. This tells me that the Caps Lock mode is on. I, as the user, can see that, it's visible. When I type a, I know that I'm going to get a capital A. Same deal here with the keyboard layouts, right? This little flag tells me I'm in the US keyboard layout mode. If I switch to Spanish, it's going to switch to a Spanish flag. I can see, the system status is visible, the mode status is visible. Same deal here with the bold button. I can see that it's depressed, I know what type of text is going to be entered when I start typing. I know the status of the mode. It's pretty rare to find these days, uncommonly used applications. Violations of this part of the heuristic, right? Situations where there are modes but the mode status is not visible. I did, however, find one good example from Google Maps. Here, you can see, I've routed myself from the University of Minnesota to Northwestern University. And it's saying that, it's going to take me nine hours. And having done this trip a couple of times, I know the actual amount of time is roughly six hours. And actually what's going on behind the scenes is that, I have set some modes. I've told the Google App on to avoid tolls and avoid highways. But when I close this little panel here, that's no longer visible, right? And in the iOS version of actually Google Maps, these settings would persist. So you would be routing yourself, maybe once you decided you want to avoid highways. You would routing yourself later and, what is going on. Why is it giving me these weird routes that take a lot longer? That's because the mode wasn't visible, right? So I would actually say, this is the actual route you can see here, with the correct versions of the mode from the user intent on. I'd actually say, that this is a pretty serious violation of the visibility of system status heuristic, a two or a three. It's going to result in a situation, actually, where users might look at that nine hour route. And say, you know what, I know this only takes six hours. I'm going to switch over to Apple Maps. I'm going to switch over to Big Maps because I know that system will give me the correct route. So this is a pretty serious heuristic evaluation issue. Okay, so that is it for visibility of system status. We'll continue in the next video with the final three heuristics.
