[SOUND]. Usability life's at the heart of usable security. It's a way that we can measure and understand, how easy it is for people to use a system. In this lecture, we'll learn the elements of Usability and the different ways we can measure those. When we're Measuring Usability, there are five main factors we consider, Speed, Efficiency, Learnability, Memorability and User Preference. It's possible to have good Usability on some of these factors, but not all of them. Occasionally, there's a trade-off, but what we want to do is be able to look at all five, and make the system as usable among as many of these features as possible. Speed, is a way of measuring how quickly a user can accomplish the task. We generally measure this by timing how long it takes them to complete it, and we ignore mistakes in this. So we assume the users are acting in an optimal way, and not making a lot of mistakes. Here we'll conduct a test to see if it's faster to login to an iPhone, using the thumb print recognition system or a four digit code to authenticate. Ready, go. So we can see it took one second to login using the thumb print identifier, but 4.8 seconds to login with the four digit code. Thus, the thumb print wins. Efficiency, measures how many mistakes are made in accomplishing the task. So, someone might be able to accomplish a task very quickly, but also make a lot of mistakes along the way. Sometimes there's a trade-off between Speed and Efficiency. For example, if we think about typing, someone may type at a normal rate of 60 words per minute. But we could increase that, and have them type at a rate of 120 words per minute. Their would certainly increase, but they would be likely to make more mistakes along the way, so the efficiency would decrease. If we want to measure the efficiency of something like the iPhone log in system, we would count errors on the thumbprint recognition system, as times when the thumb is put down but it's not properly recognized. This will show a try again message at the bottom of the screen. Similarly, for the four digit code entry, we would look at how many times the user enters the wrong code or makes a typo while entering the code. Learnability, is a feature that tells us how easy it is for a user to learn to use the system. This let's us know how well someone can come into the system for the first time, and get up and running with it. Ideally, they would need very little instruction. And, be able to find the features they need quite quickly. On the iPhone, when the user turns the screen on, if they don't do anything for a couple of seconds, the slide to unlock message appears at the bottom. If the user slides their thumb over that, they get the keypad entry. This makes the Learnability quite straight forward for learning, to do the four digit code entry. However, there's nothing to tell the user to put their thumb on the pad to enter the system that way. So, the Learnability for the thumbprint system, without instruction, is lower. Memorability, extends Learnability. Once a user has learned how to use the system, Memorability tells us how easy it is for them to remember how to use it. So if they've stopped using the system for awhile, and they come back, is it likely that they quickly remember how to use it. Or do they need to practice and relearn some of the features. We'll take a bit of a diversion here from our iPhone authentication example, to look at something else, a font system. This is a little preview of how these measures of Usability, can play into the design of the system. We're going to do a whole separate lecture on design, but this is a little hint of how the things are connected. In this case, we have a font system. We want users to be able to come in. Pick some different fonts, and see what they look like. This helps them learn the name of the fonts, and what they look like. They can try it a few times, and then they'll get a good sense, but, if the font eventually gets changed to something strange, and the user comes back. Or they remember that they want to use a different font, you shouldn't force them to remember the name of the fonts they learned. If you can aid them by both showing. What those fonts are, and not just forcing them to remember by name. It becomes a much easier task, for users to remember how to use the system. And the final usability feature is User Preference which is what the users like most. Ideally, users will prefer a system that's faster, easier to learn, and that allows them to make fewer mistakes. That's not always the case. Sometimes we could build a system that has good Speed, Efficiency, Learn-ability and Memorability, but the users prefer it less than a system that has worst usability on all the other measures. This has actually happened. There's an example from an older paper, from The University of Maryland, where users were shown two map systems. The first one, shown here, has an overview window in the corner. In this case showing a map of the state of Washington, with a little context window that shows what's zoomed in, in the main part of the screen. This is one of the interfaces users we're given, and the other interface would start with the full state zoomed out like this and users could actively zoom in much like you can do with Google maps now. Users were given a set of tasks, to do with these maps. Their Speed and Efficiency were measures, and the users were also given a questionnaire to fill out at the end to indicate their preferences. The zooming map scored better on Speed and better on Efficiency, but in terms of user preference they preferred the overview with the small context window. There's no good guideline about which feature to choose in this case. There's simply a trade off. The users preferred the overview, even though they were slower and they made more mistakes. It's really up to the system designer to figure out in cases like this, if we want to pick one system over the other? Or if there might be a way of combining the features to give users an option, or the ability to have some of the preferred features with some of the benefits of the other system. The next question then is, how do we measure these? Sometimes that's straight forward, the speed we measure it by timing how long it takes someone to complete a task. For Efficiency, we count the number of errors that a person makes, and we may rate those errors in terms of their severity. A simple typo may be a less severe error, then something a user does that causes the whole program to shut down, losing their work and forcing them to start over. But, what about Learnability, Memorability, and User Preference? Those don't have a measure that's a straight forward, as timing the user completing task or counting the number of errors. For Learnability, we often look at how long it takes a user to learn to use the system. So, we have a chart here where we would measure how long it takes a user to log in. And we have a series of log in attempts across the bottom. The first log in may take them ten seconds, the second may take more like five seconds, a third two and a half seconds and so on, until by the end the amount of time it takes them is leveling off. This chart gives us a sense, of how long it takes people to learn. And a sense of the learning curve. We could have a system that looks like this, but we could also have a system, where for many log in attempts it takes a long time, until finally something clicks and the users are able to quickly complete the task. To Measure Memorability we can start off the same way and then wait a long time, have the user come back and use the system, and see how long it takes them to log in then. It could take a really long time, in which case we have bad Memorability, or they could log in as quickly as the last time they used the system. Which means the system has good Memorability. It's likely that we may have a value, somewhere in between where, after a long break, the users may need a little more time to re, familiarize themselves with the system. But, hopefully they're not returning to a level of, ability with the system, as poor as when they were first learning how to use it. And then finally, we want to measure User Preference. This is something that we do either with, questionnaires and surveys. There are many standard questionnaires and surveys for measuring user preference, on a variety of systems. And so those are things that you can give to users, they rate things on a scale. Usually from one to five, or one to seven and then you can actually compute between two systems. Which ones the users prefer more. And conducting interviews where you actually sit down, talk to users as they're using the system and have them explain what things they like and what they don't, can give you much deeper insight into users preferences. And, how usable the system feels to them?
