[MUSIC] In this lecture what I want to do is provide some pointers to broader HCI principles, general HCI principles, that you would learn in great depth if you were taking a course in human computer interaction, HCI, in another venue or in a longer-form course, where you would be focusing just on human computer interaction. And I wanna talk about these outside of the realm of what Apple and iOS do. So these principles are not principles that are dictated or enformed by Apple documentation rather they're HCI principles that had been studied by practitioners and by researchers and form a body of knowledge which represent our best known practices for human computer interaction across the spectrum. Whether it be in a car or on a watch, on a billboard, a smart sign desktop or smartphone. So in that way in this lecture I'm kind of channeling my inner Donald Norman if you are familiar with any of his work. His groundbreaking and far-reaching work in human computer interaction. So for this lecture what I wanna do at a high-level is make you aware of many of the well studied principles for designing a user interface and just implore you to follow them as much as possible. And then, I want to look at a particular design, and kind of deconstruct it to look at whether or not it is doing some of those things. So, let's start with the first idea, which is familiarity. Familiarity means that you should, with great care only deviate from familiar controls and patterns. Which means that generally you should not deviate from familiar patterns. And the reason why is because the familiar patterns are things that people know already. They're things that people understand. They don't require learning and people can pick them up quickly and leverage them. When and if you do decide to deviate from familiar patterns because of course if you're going to innovate and the user interface you do need to try something new. You can't be doing familiar stuff all the time if you want to actually bring some new technology or new techniques to the world. If you do ,do it, you need to make sure that you do it with great care and that you test it with real people. And the problem is that a lot of times, people when they develop things for human computer work, they think they have a great idea. They're the developer, they have a particular need. They have this great idea for how they can do it. And they implement it in such a way that is very clear to them. But it turns out that if you take such an interface and you actually put it in front of other people, you might be surprised to find out that other people actually don't find it that clear or don't find the metaphor that good or don't find the implementation that great. And so it may be the case that your Innovative new interface is actually not that good. So the first principle I want to talk about is familiarity. This reminds us that we should work in patterns that are familiar to users, and know very clearly why, and when were deviating from known patterns and when we do that we study it before we inflict it on the rest of the world without their knowledge. The next principle that I want to talk about is visibility. Visibility speaks to the ability of a user to be able to know what's available to them to do next. Options should be visible so they know what actions can be taken and what they can do as the next step. Now Apple actually has been criticized a little bit, not a little bit, they've been criticized quite clearly for not making a lot of their options visible. So, if you're familiar with any of the list interfaces you know if you swipe to the side it will sometimes reveal like a delete button, or something like that. Well that option, that ability to delete something, is not visible at all before you one day discover that you can swipe to the side. So, this would be an example of bad visibility. When you have navigation options, you want to make sure that you show those navigation options but you should also make sure that your objects exhibit affordances by objects, I mean digital objects. I mean the things that you are representing on the screen. Whatever options you have available for functionality for navigation, for information manipulation. It should be clear from the way in which you are displaying it, that those options are available. So maybe, the edge, if you an turn the page, maybe the edge of your corner has been peeled down a little, to show that you can move left to right. Maybe if it's possible to scroll left and right, you may be familiar with the little dots on the bottom of a screen so that when you slide left or slide right, you see what page you're on. Those are examples of affordances that indicated to the user than you can move left or right or that you can turn the page. Other examples are that links should look tappable. And by that they should be called out in a special color. A draggable thing should look draggable. Maybe they have a little bit of a shadow on them. Maybe they have some texture on the place where you can drag them. And this becomes harder with the current design metaphors. The flat design where things don't have a lot of texture. They don't have a lot of shininess. They don't have a lot of shadow and all of those things, although they were baggage on a minimal design, they also were indications to the user that certain things could be done with these objects as if they were physical objects. So it's still possible to do these things and one way you can do them in flat design is to put little animations in. So rather than having a corner that's turned down all the time when you first show a screen maybe you fold down the corner and then fold it back to indicate that this page is turnable. It requires some clever ideas, but the idea is that basically you communicate to the user what things can be done so that they can use your app to its full capability. The third principle I want to talk about is discoverability. And this is very much like visibility and this supports learning for a user. If a user's going to be able to understand what's possible the different features should be discoverable. For example, icons that are otherwise mysterious should be labeled with text. All the actions that are possible should be shown in some way, perhaps through a menu. Menus are a great way to show available actions so that a user, when they're comfortable with the actions that they know, can explore additional things that are presented on the menu and they know that they're there because they can see them. You don't want to have to have your user memorize gestures that would be required in order to use your app. So swipes or taps or things are commonly used in Apple interface guidelines, but they sit at attention, because a lot of times people don't know that different swipes and gestures are things that provide features for the user. So don't make them memorize them. Put chevrons in indicating that you can slide or swipe or scroll and help the user out. The next important principle is the idea of errors and undoing. Now there's kind of a school of thought that has forgotten that humans make errors, humans always make errors. It's almost like the definition of what it means to be human and so your software design should always be designed with the expectation that a user is going to be confused, distracted, going to click on the wrong thing, and in order to successfully handle errors, one of the best principles that you can build into your design is to implement undo. The ability to undo a task so that a user never does something that is not able to be recovered from. This is a principle that's been identified as being central to a good human computer interface. Other ways in which you can help a user recover is to have a back button or the undo button, as we mentioned. And if there are actions that are not possible to undo, I mean there are some things that are permanent, then in those cases it's helpful to have confirmation dialogs. These are the things that sort of warn the users. It says what you're about to do is a destructive action. Are you sure that you wanna do that? And so you might have a pop-up box that has a button that says that that's okay, or that's not okay. Now these pop-up boxes, these confirmation boxes are obviously annoying and they can become very routine so that users don't even think about it sometimes. And so they cease to lose, they cease to be very functional in that case. And so what you wanna do is as much as possible, you wanna support the undo capability of your applications so that there are not destructive acts, if that's possible, and that the times in which you wanna show a confirmation dialog are very, very rare and few and far between. Consistency is a principle that reflects the fact that when you do something in your application in one way, when you present an action in one way in one portion of your application, another portion of your application to present it in the same way. A very straight forward thing that you can do that would be consistent, would be to make sure you're using the same fonts when users are in the same situations. So across your app, you probably want to have a link look the same in terms of color, font, weight, shadowing, whatever you're doing, so that as a user moves through different parts of your application, once they realize it's a link, they understand other places that it's also the link. If that color doesn't mean a link, whatever the color means, you want the color to mean the same thing everywhere. That text is editable. That it's something that's going to change in a moment. That it's something that was delivered by another person. However you use color you wanna make sure that it's consistent across your application. And of course we've already seen that we want your icons to be the same everywhere. So Apple supports this by having standard icons. If you use those icons, you wanna make sure that you're consistent. This consistency travels across all of the applications in the way the team in interface guidelines dictate. And that also speaks to making sure that your apps conform to standardized behavior. So the principal of consistency is not one that comes from the Apple human interface guidelines, it's one that the Apple human interface guidelines has leveraged. That Apple recognizes that consistency is such an important aspect of human-computer interaction, that they baked it into all the different SDKs and functionalities that they have designed for app developers to use. So it's not that Apple supports consistency, it's that consistency is such a good idea that Apple wants to support it. A broader principle than just something that Apple uses. Another broad application, another broad principle, is the idea of supporting expertise so everyone starts using an app and they have little experience with it but very quickly they can become highly skilled. And as you become more and more highly skilled in using an application, some of the support features, some of the ways in which an app might help you to learn how to do an action, or how to undertake some task or some functionality become burdensome because there are so many clicks or so many menus you have to open. So supporting expertise says that as a user becomes very familiar with an application, they should be able to discover, use, and learn different kinds of shortcuts. So, in a desktop environment, this might be a hotkey. In a smartphone environment, this might be a certain swipe or certain gesture that cuts through a lot of different menus for frequently used tasks. It might be access to advanced features that present themselves through an advanced menu pane or an advanced preferences pane, and some of those shortcuts may be the specialized gestures. And the basic idea here is that as people become more expert, they don't need as much hand holding. And you wanna help them speed up their tasks so that they become more efficient using your application. You wanna support that. A very important principle that you may not realize is built into almost everything now, all the user interfaces, but not always implemented well, is feedback. Feedback says that whenever you press a button, whenever you take an action, the computer should very quickly provide feedback indicating that it has received your input and is operating on it. Now ideally if you're doing a direct manipulation task, for example, maybe dragging a photo around a page, that photo should move with your finger, and the feedback should be the direct manipulation of a virtual object. It should just feel like you're moving something physical. Not everything can be handled like that, and so if you can't manipulate something, as a physical object would actually move within their app, then your user will be confused unless you provide feedback. And if you don't do it well and you don't do it quickly, your app is gonna feel sluggish or even worse, it's gonna feel broken. So what do I mean by this? Well, when you click on something, and some of this is built into iOS, you should very quickly change a loading indicator, a status, you should change the title of the button or the text on the button to reflect the fact that the application is doing work. Maybe you want to bring up a progress bar, showing that the application communicates to the user that yes, I've received your input and I'm trying to take advantage, I'm trying to respond to it. And here's how long it's taking me. And then the user can understand that progress is being made. That the device hasn't crashed. That this isn't a case of bad software. This is a case of a task that takes a lot of work. Other places where you see this is you'll see loading indicators indicating that maybe a network is being accessed. You'll see that sometimes on the status bar, next to where the carrier is listed, you can have a little loading indicator saying that the network is being accessed in iOS devices. And again, it could be also as easy as just the progress bar that's loading to tell you that something is being taken care of. There are a lot more principles that had been identified as things that make for good human-computer interfaces. Things like accessibility, which speaks to the ability of an application to be used by different kinds of people with different levels of physical ability whether it is motor control, vision or hearing, ways in which you can make your interface accessible to many kinds of people and many different places. Affordances, making sure that your virtual objects look like they are, can do the things that should be able to do. A tradeoff between flexibility and usability. Chunking which has to do with how much a user can remember at any given time and usually it's described as approximately seven or five, plus or minus two. It depends on the study a little bit what it is. Mental models speaks to the way in which users think about your information architecture. Proximity speaks to having common functionality close to each other, like in menus where things are grouped according to the sort of things they do. Mental models again, sorry. Framing, archetypes. Form follows function, hierarchy, Fitt's law, glanceability. All these things are examples of high-level HCI principles, that are worth studying from time to time when you come across them, in order to be able to be a better human-computer interface designer. Now let's take a look at something that I would call, A Bad Design. And this is something that's called a Hamburger Menu for lack of a better term. But what it refers to is this little menu up here. Which is common in responsive web design. You see it a lot in apps. Let me see if I can show to demonstrate how it works. There we go. You click on it and it exposes a menu down below it, for example that shows up right there, that's otherwise hidden. And so this is a hamburger menu example. And let me walk through why I would say this is a bad design. So for starters, what exactly is this a picture of? It is three lines. If anything it looks like something that has texture that you should be able to grab and move. Why would you expect, having never encountered this icon before, that clicking on it would actually reveal anything? If anything, to me, it looks like it's going to show fine print. Or, it almost looks like it's a branding element, like maybe it's a logo associated with your company. So, for starters, this icon doesn't communicate anything that's familiar. So, it has really bad familiarity for a user that has never encountered it before. Now the thing about a lot of these principles is that sure, if you've encountered something a lot of times and you've learned about it, and you've kind of come to expect something new. Okay, you can learn what these things mean. But this one in particular, it's difficult to see, it's difficult to remember what it does and because there's not a clear understanding of what's behind it, you actually don't know in a given app what is going to be there. So, its principally a navigation device. It enables you to go to different places in your application, and as a navigation device it does a bad job because as it sits there, it doesn't really explain where you are in the current information architecture. It doesn't place you in a linear sequence, or in a graph anywhere, it doesn't even explain where you can go by itself, because that icon stays the same. And it doesn't even explain really what you can do. It doesn't seem that you can necessarily press it. So because of that, I would say that this has bad functionality. The menu hides items. The menu items that are associated with it are invisible. And so what that means is that, all awesomeness that's associated with your app, all this great functionality that you've spent a lot of time designing and implementing, it's hidden and the user might actually never realize that your app can do all these things because they can't discover that these things are there. So this has a bad discover ability. And actually there have been a few studies, I haven't seen these rigorously peer reviewed. But I've seen some studies that have been done by web developers who are just interested in looking at their own designs and have made their results public. They say that things that are buried behind hamburger menus, get used maybe 30% of the time, as compared if they are presented in regular menus. And that's really bad if you've spent all this time developing a fully functional app and all the users get to see is the page without those options. In terms of efficiency, this menu also has pretty poor efficiency and here's why. Because in order to use it, although it does save screen real estate, in order to use it, you have to click it, you have to wait for the animation to happen that opens it up. Once it's open, you have to find the option that you're interested in, and once you find the option that you're interested in, you have to, by scanning it, you have to click to select it. You don't even really get the ability to kinda look ahead and find the option that you're searching for before you click on it because it's not even there. It's not visible. So in order to even see the option so that you can move your finger towards it, you have to click, wait and find this option. So it's really bad efficiency. Now, part of the reason why designers like it, though, is because it allows you to have lots and lots of options without taking a lot of screen real estate. This provides a lot of flexibility for the developer, but it suggests that maybe the developer didn't think a lot about what the important options were. How could it be structured? What is it the users use case is that should be most highly supported? It kind of encourages lazy user interface design, because the menu that it exposes can be very, very large. Doesn't require the developer to think very heavily about hierarchy, how to structure the different tasks, so that they make sense as you move through a menu. How to support discover ability, maybe in the primary view of the window. It just gives the developer a lot of space to not have to think about good design. So, overall, I would say that the hamburger menu is an example of a user interface that does not follow some of these common user interface patterns such as familiarity, visibility, discover ability. It doesn't really promote consistency because we've never seen it before. And it's slope. So, beyond just this hamburger menu, there are lots of user interface patterns that have been studied. That have been identified as being things that should be implemented as best known practices. And you should appeal to them in your design. Now again, these are not things that Apple invented, these are not things that Apple even necessarily supports in a lot of their interfaces. Sometimes Apple breaks these, much to the chagrin of human-computer interface, researchers and designers. But you should, as much as possible, in order to create a high quality, well understood, well used design, leverage familiarity, visibility, discover-ability, errors and undo capability, consistency, and you should support expertise, or the ability to get faster through shortcuts and rapid workflow patterns, and then feedback. Make sure that you've got good code that supports rapid response and quick feedback to the user that something has been clicked. That action is being taken. All these things together will help you make an app that follows the best known practices of human-computer interaction. So I look forward to seeing how you leverage these in your applications in the future. Thanks for your attention. [MUSIC]
