Hey, folks, welcome back to our series of videos on heuristic evaluation. And if you'll recall from the last video, right, we introduced the idea of heuristic evaluation. We talked about how to execute a heuristic evaluation at a very high-level and we talked a bit about the history of heuristic evaluation. In the next couple videos, we're going to be getting into the real meat of this whole heuristic evaluation process, which is going to involve digging into the heuristics themselves. Now, you'll recall that you can use any list of heuristics that you want in heuristic evaluation. But by and large, when people talk about heuristic evaluation these days, they are often referring to the procedure as well as a very well known list of ten heuristics developed by Nielsen. We touched on this a bit in the last video and these ten heuristics are one, flexibility and ease of use. Two, user control and freedom. Three, consistency and standards. We're going to go through all of these and then we'll dig into them in detail. Four, help users recognize, diagnose and recover from errors. Five, we want to match between the system and the real world. Six, we talked about error prevention a bit in the last video, that's a big one. Seven, visibility of system status. This is also a big one and a fun one to talk about. Eight, recognition rather than recall. Nine, aesthetic and minimalist design. And then ten, help and documentation. So in this video, we're going to focus on these top four and we'll do the remaining six in the next couple of videos. Okay, let's start off our exploration of these ten heuristics with flexibility and ease of use, and all of these heuristics are defined by Nielsen with a definition. As you can see in this little note on the slide, I often find the definition captures the main gist of what people often talk about with each heuristic, but it doesn't capture everything. You might find that there's a problem that this definition doesn't cover that really fits under, for instance, flexibility and ease of use, but isn't in the definition. That's totally okay. With all that said, let's dig into this definition here. Flexibility and ease of use. Accelerators, unseen by the novice user may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions. So, the key thing in this definition is this notion of accelerators and let's dig into this in more detail here. So, what are these accelerator things? Well, for example, let's consider a desired action, which I execute all the time, especially when putting together slides for in-person classes as well as, of course, the slides for this course. And that desired action is taking a screenshot of an active window and copying it to the clipboard, so that I can then copy it into my slides, excuse me, paste it into my slides. So the most basic way to go about this is as follows, right? I take a screenshot of the whole screen, I then open up that screenshot in my favorite photo editor. This is Preview on Mac and I carefully select the outline of the window that I'm interested in. I then go to the Edit menu and I select Copy. Wow, that's a lot of work. Now if you're just doing this once, right, it's not a frequent action, not a big deal, right? We can get over that. However, I do this on a weekly basis when I'm putting together lecture slides 20, 30, 40, 50 times. Also when I'm putting together slides for research presentations and that's going to get really annoying. And this is where accelerators can come to the rescue for expert users like myself, right? A user who's using, for instance, PowerPoint very often. In this case, the accelerator is a keyboard shortcut. So, I can press Apple+Shift+Ctrl+4, then space bar, then Enter and I get a window perfectly cropped that I can paste into PowerPoint or wherever and copy to my clipboard. This takes me a very small number of seconds whereas the unaccelerated path takes me many seconds. And if we analyze this using some of the other evaluation procedures that we're looking at in this course, in our specialization, you can also tell that, for instance, with DOMS, the unaccelerated path is going to have just this massive list of actions. Whereas the accelerated path has a very small number. In general, keyboard shortcuts make great accelerators. They're one of the common accelerators that we interact with on a day to day basis and that's because they meet very clearly two key parts of this definition, right? They're unseen by the novice user. You can't really discover keyboard shortcuts unless you look for them. There is some visibility, right? So if you look at the menus, for instance, by Copy it says, Apple+C or Ctrl+C on Windows. That kind of thing is important for a number of reasons which we'll get to in various aspects of this specialization, but it's not very, very visible, right? It's not something that's a big bar across the top of the screen. For instance, on the iPad these days, you hold down the Cmd key, and it'll show you the list of keyboard shortcuts that are available in your application. That is very not visible and definitely accords with this heuristic. And then of course, keyboard shortcuts also speed up interaction, right? We saw that with the keyboard shortcut for copying and pasting screenshots. I do want to point out though that accelerators are definitely not just keyboard shortcuts. They can really fit in to almost any process and almost any user interface design. This is a great example here, Amazon's 1-Click, right? So if I were to have clicked this button, I would have bought something and have it sent to my house. No need to enter address or a credit card number. Amazon already has it, right, these are accelerators. They're shortcuts. So why make me enter them over and over again for a frequent customer, if given that I'm a frequent customer of Amazon that very often just buys things and sends it directly to my house, right? This is kind of Amazon's equivalent of a keyboard shortcut, but it is an accelerator in a different form. Another good one here is this the favorites, the list of favorite folders that is both on Mac and Windows these days, right? You can customize them, you can drag them in. You can see we have our MOOC Madness folder down there at the bottom. I'm very frequently these days entering stuff in that folder to prepare for this MOOC. So, I have that over as an accelerator in my favorites list. Another great example are PowerPoint templates, right? So you'll notice that a lot of the fonts and the headers and opening slides are very similar across all of the slides for this entire MOOC. That's because we've used an accelerator in the form of a PowerPoint template and we're very grateful to the designers of PowerPoint that we don't have to manually customize every single slide so that they look the same, right? There's an accelerator available for us. So through this video and through the next couple of videos when we're going through our heuristics, I'm going to present positive examples, which I just did, right? Examples of user interfaces, meeting the heuristic, right? They'd get a zero in our heuristic evaluation scale, but I'm also going to, of course, present some negative examples and we'll do that here for flexibility and ease of use. I find that the negative examples are equally powerful in terms of their ability to communicate the idea behind each heuristic. And speaking of emoji here, right, on Mac, I think they do not meet this heuristic with regard to entering emoji text at least yet. I think we're in Mac OS 10.11. When we get to 10.12, which might be out by the time you get this video, I think I heard that they've improved this. But to enter an emoji on a Mac, you have to go to a menu, open a window, carefully select the emoji that you want, double-click on it, right? That is a lot to input a character. So, if I were doing a heuristic evaluation on Mac OS, I would actually say, you know what? This is a problem. It's emoji, it's not going to start World War III. But it is something that people type a lot, emoji art, things that people type a lot these days. So we have that frequency dimension of our heuristic evaluation severity scale, right? So I'm going to give this a two, right? So can we find a way to make it easier to provide accelerators for people entering emoji text? A great example comes from the course system, or the course management system that we use here at the University of Minnesota. Uploading lectures, which I naturally do after every single lecture, so the slides for the lecture, maybe my course notes, takes about five, ten clicks, three or four screens, these types of things. And it just simply drives me nuts because I do this so regularly, and there's no accelerator. So if I were the designer of this system, which is Moodle, in the next version, I'd definitely include accelerators. And if I were the heuristic evaluator of the current system, I would say, you know what? Professors are an important part of our user base. They very frequently upload lectures, and it takes a zillion steps, and there's no accelerator. This is a pretty serious issue. I'm going to give this a three. Okay, so that's it for flexibility and ease of use. Let's move on to our second heuristic, which is user control and freedom. And again, we have our definition from Nielsen here. So user control and freedom. Users often choose system functions by mistake, and will need a clearly marked emergency exit to leave the unwanted state without having to go through an extended dialogue. Support undo and redo. This last very, very small sentence really captures most of the user control and freedom heuristic. And people are generally pretty good at according to this heuristic, or systems are generally pretty good at according to this heuristic these days. There's all sorts of undo everywhere, right? So these days you can undo, copy and paste, excuse me, you can undo moves in Apple's Finder. Right, you can undo almost anything in most sophisticated applications. The web has its own version of undo, which is the back button, right, and redo, which is the forward button. I'd say, in general, the back and forward button are used when the data that you're manipulating haven't changed. So you're just looking at another web page. You're just viewing the data in a different way. That's when undo and redo becomes back and forth. Whereas when you're actually manipulating the data, that's when you typically have this explicit undo and redo that are in the edit menu, or have their according accelerators in the form of keyboard shortcuts. I will note there are some exceptions to this rule of this heuristic being followed very generally. And part of the reason that's the case is oftentimes when you're going through heuristic evaluation, you're finding problems. Sometimes even though they're very serious problems, you and your design team will say, you know what? This is basically impossible to fix. We're just going to have to live with it, right? And one example that I think is absolutely great in this respect is email. When I send an email, let's say I write to my boss here. Dear Boss, I don't like you very much. Also, I want a 200% raise now, right? And I sign it with my full name, so my boss knows exactly who I am. If I hit send on this, there's no way for me to undo that even though it's an incredibly important action, right? It's so important that I don't think this email address is actually alive. But when I wrote this email to take a screenshot, I very carefully hit the red button, and made sure not to save and not to send, right? Just because sending an email like this can be incredibly powerful. And as a result, I would actually say the lack of ability to undo emails in standard email interfaces is actually a four, very severe, because people can get themselves into very serious problems. I'm sure some of you who are watching this video have done this, maybe not so intentionally. But unfortunately the email protocol, it makes it very difficult to fix this problem. All right, so this is one of these things where it's a serious issue, but we haven't seen it fixed over the last 15, 20 years when email has been active because it's very difficult to fix. Now I will say there have been some efforts. One of my favorites is Google's supposed ability to unsend an email. What it basically does is it puts a delay on your email, right? It says, we're not going to send your email for 10 seconds or 20 seconds, just in case you want a chance to reconsider. Let's say I'm just very angry at my job, and I send that email. Then I think about my wife, and how I need to make sure I save enough money for my family. You know what? That was a bad idea. I'm just going to be calm and continue on in my job. If I had had this feature enabled in Gmail, I would be able to do so as long as I did that in 10, 20 seconds, these types of things. Another thing I think that's interesting is Snapchat might actually be a reaction to some of this, right? So in Snapchat you can send a message and it disappears. That's a form of undo, right? It's a reaction to the fact that email has this major failure in heuristic evaluation that has yet to be addressed. Okay, more generally, if you have a system that doesn't support undo and redo well, which is, although it's not common in commonly used applications, I should say it is somewhat common in sort of very specialized applications. And certainly applications developed by naive developers, developers who haven't taken courses like this one. You can end up in a situations where your users feel like they're in a Pottery Barn. Here in the United States, we have this notion of a Pottery Barn effect or Pottery Barn principle where if you break it, you buy it, right? You walk into this fancy Pottery Barn store. It's a chain of stores. You're looking at an expensive bowl, and you drop it. Well, the story goes, you have to buy it. If you don't support undo and redo, your users will feel like they're walking around a Pottery Barn, right? They'll think, I don't know if I can explore that feature, even though it's very important to me, because I can't undo it if I do this, right? And it ends up having this dramatic chilling effect on user experience. And so while this heuristic is more commonly followed these days, that's not to say that it's unimportant, right? If you're designing a system, you really have to be careful about this, and make sure that you're adhering to this heuristic. All right, let's move on to heuristic number three, which is about consistency and standards. Let's talk about Nielsen's definition here. So Nielsen writes, for this heuristic, users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions. This is a great example of how how heuristic evaluation connects in with a lot of the other topics we've been learning about in this specialization. We talked about consistency in the last course. This is basically a heuristic that wraps a lot of those notions. So for example, if someone hits undo here, the standard, the convention, is that it undos the last action, right? Not the last five actions, not the last ten actions, not the last half action, but the last action, right? If you violate that convention, that can be a serious problem and can create a lot of confusion, as we talked about in the last course. Same deal here, right? Right-clicking in almost every, actually, across both Windows and Mac and Ubuntu, and these types of things, right, right-clicking brings up a contextual menu. It brings up a list of operations that are valid for the thing that you right-clicked on. This is a convention that if you did something else It would create a great job confusion. So for instance, if you had right-clicking at the start drawing a line or to send an email somewhere. That is going to, that would receive a serious three or four heuristic evaluation. Because it eliminates all the benefits of convention standard, right. This heuristic is very, very commonly followed these days. It's relatively rare in frequently used applications to see dramatic violations of conventions. That said, again by a naive developer, or in specialized applications you do encounter this a decent amount. I was looking around in the applications that I frequently use and trying to find an example of a relatively serious one. In a short search, I couldn't find one. The one thing I did see was Firefox's, the new versions of Firefox have this hamburger menu which is unconventional in a desktop application, right. You frequently see them in web applications but it's it you were, in fact, I probably did have a little bit of confusion when I first saw that appear in Firefox just because I'm not expecting it in a desktop application. So I'm going to if I were a heuristic evaluator, I'd give this a one. Not a two because most of these functions are available in their standard places. And this is a standard in web applications, and of course, Firefox is a web browser. But that said, it is a desktop application at its core and that is unexpected. So I would mark this as one in heuristic evaluation. Okay, that's it for consistency and standards. A heuristic evaluation fail in this slide itself. I'm going to give that a two because that checkmark looks a lot different than the other two checkmarks. This little, silly little thing I put in here is just to remind me and emphasize to remind me to talk about and to emphasize that, when we're talking about consistency and standards. We're not just talking about interaction, we're also talking about appearance, right? There are a number reasons why that's important, which we covered in the last specialization. So I'm going to fix this problem. Mark that as a two, right? Bad slide there, Professor Hecht, you have a heuristic evaluation issue in your slides. Mark that as a two and let's fix that. All right, let's go ahead and finish up here for this video with our last heuristic which is number four, right. And that is help users recognize, diagnose and recover from errors. So this is the definition that Nielsen provides for this heuristic. Error messages should be expressed in plain language, no codes, should precisely indicate the problem, and should constructively suggest a solution. And if you dig into Nielsen's writing a bit more. He provides five properties of good error messages that are emergent from this heuristic. The first property is that error messages should be obvious. It should be very clear that an error occurred, right? The second property is that error messages should use human-readable language. This is sort of a direct response to this no codes notion but goes beyond that, right? The error message should use language that your users will understand without any effort. The third property here is that error messages should be precise. It shouldn't just say error, it should say specifically what happened. The error message should be constructive, this is an important one. It should offer potential solutions unless those solutions are very common sense solutions. And you have to be very careful about guessing that people's common sense, user's common sense includes some things that it might not. And then lastly, error messages should be polite, no matter how frustrated you are when you write an error message, you need to be polite to your users. So, let's walk through a couple of examples here. This is an error message that I personally generated today. I typed in a URL at the University of Minnesota's website that I knew didn't exist and this is the error message that I got. Now, let's go through this. Is this error explicit? Yeah, it's very clear that something happened and that something was an error, right? So, that's very clear, at least to me. Second, does it use a human-readable language? Yes and no, right? Not found, what exactly are you talking about? A very, very clear, human-readable language here would say, sorry, you know what, the webpage that you typed in, we don't have that webpage, sorry about that, right. You can see there is a little bit of that in the subtitle but I think you need a little more for me to say, you know what, this property is definitely true in this error message. Is the error message precise? Yeah. It says, sorry your URL was not found. Is it constructive? No, it isn't, right. It doesn't offer solutions for me, right. It doesn't say maybe do you want to Google Search, this UI MOOC thing plus UMN, do you want to go to the homepage, these types of things. This error message is not constructive. And lastly and I'd say it's reasonably polite. It doesn't say, hey, you idiot, you typed in the wrong URL, right? So I'm going to give this a one as a heuristic evaluator just because it does an okay job. But I would prefer that the error message be more constructive, definitely, and probably more human-readable as well. Okay, let's move on to another error message here. This is an error message that you get on Google Flights when you say you want to fly from one city to the same city. Your origin and destination are the same. So it's a little small here but you can see, you see it says here, sorry flights between the same city are not supported. So let's walk through our five properties here. Is this explicit? Yep, it's very clear to me that an error occurred. Does it use human-readable language? Sure, right, it could say error 707 variable dest cannot equal variable origin, right. Instead it expresses in very clear language what happened. Is it precise? Yep, it says exactly what the error is, right? Origin and the destination can't be the same. Is it constructive? Yes and no, I'm going to, I said yes just because I think this is common sense, you could make the argument that it could be more constructive. Saying like did you mean a different city, why don't you enter a different city, these types of things. Maybe well, you could argue that's a question mark or you could say, you know what, that's pretty common sense. I know sometimes, if I'm searching for a flight, I'll forget, what just not being paying attention. And this one, I always know what to do next. Maybe that's not true for all users. And is it polite, yeah, it's actually very polite. It says, sorry, right, even though you as the programmer might say, why is this stupid user saying that they want to fly from the same place. It will start at the same place and end at the same place, right? Instead, Google has a lot of smart people and they realized you know what, calling your users stupid isn't the best idea. Let's apologize, right? Okay, so in that case, since I put a checkmark here on all of these things, this is no problem, it's a zero. No, I would mark nothing on my heuristic evaluation. But you could make the argument. Maybe it could be a little more constructive and give it a one. All right, here's one of my favorite old screenshots of an error message from Excel. I think we all have encountered this error message at some point. And let's walk through our five properties here. Is it explicit? Yeah, it's pretty explicit that an error occurred. Is this human-readable? Definitely not, right? So even though I am a Computer Science PhD student, I don't quite a priori know exactly what they mean by sort reference, right? I'm going to have to figure out how their language matches my language and these types of things. Is it precise? Not really, right? So, which sort reference which cell should I look at, these types of things. Is it constructive? Definitely not. It doesn't tell me what I need to do. If you get this error message You have to say, you know what I'm going to have to figure out how I can fix this even though I'm given no suggestions, right. I have to explore on my own, and is it polite? I guess you could say maybe with he dog, but not valid, Neilson talks a lot about how sort of invalid or illegal these words really shouldn't appear in error messages. Especially things like, as you get more and more serious, illegal, that makes you feel like you did something bad, right. Imagine for instance in older users may get easily confused about that. So I would prefer this to say, sorry we had a problem figuring out what's going on with your sort reference. Just to fix the polite issue, obviously that error message that I just suggested wouldn't fix human-readable language, or precise, or constructive. Okay, in this case because there are so many problems with this and I think we've all encountered this before, it's relatively common. I would give this a 2. Okay and then here is the last one. The check engine light in probably in many of your cars. Let's walk through this error message with respect to Nielsen's Heuristics. Is it explicit? Maybe, maybe not, right. It's pretty small for a potential engine failure I would like something really big to show up, right? This personal safety is an issue here. So I would prefer this to be much bigger for me to give this a check mark. Human-readable language, eh. Yeah, you know that maybe looks like an engine and does say Check, but it could do a better job. So I'm going to say maybe, but probably not. Is this precise? Definitely not. There are about 150 different problems that can be going on. And really the only thing you know to do at this point is maybe bring to a mechanic who can then figure out what this actually means. This is in some ways the definition of imprecise. Is it constructive? Definitely not. Should at least say go to a mechanic. Maybe it should say, your oil, there's an issue with your oil, these types of things. Why don't you change your oil? This is definitely not constructive. And is it polite? I would actually say no, right? This is a worrying issue when you see the check engine light it's like yikes. It's at least a major inconvenience, maybe a personal safety risk. I'd prefer to say, something along the lines of, I'm sorry to inform you of this, but there's something wrong with the engine. I really highly recommend that you go to a mechanic as soon as possible, right? So, this could be made much more polite. And because of the seriousness of this issue, the potential impact, both commercially, I think, and well, maybe not commercially, at least for the user. I would actually give this a 3, right. We would want to see check engine lights be much more human readable, precise constructive, polite, and I would actually say explicit as well. In the future, and you're starting to see this happen, right. People are developing apps that plug into car computers. That can actually solve some of these issues. And one of the main appeals of these apps, is that it actually addresses this problem, that probably comes up in any heuristic evaluation that you would do of a dashboard panel, here. All right that's it for our four heuristics for this video. We'll continue on with Heuristics five, six, seven, eight, nine and ten. See you then.
