Welcome back. In this lecture we're going to begin talking about the basic building blocks of user interactions. Building blocks that are there in basically every kind of application that you might be developing. Whether it's a desktop system, or a mobile app, or something for a wearable. All of these applications are really, at the conceptual level, consisting of the same pieces. And the simplest way to think about this is that all applications are basically machines for translating some kind of an input into some kind of an output. And your job as a designer is to really try to conceptualize what those inputs need to be for the system to be able to do the task that it's intended to do. And what kind of output the system needs to give to the users to enable users to to complete those tasks successfully. In this lecture we're going to be focusing on the input part of this process, while in the next lecture we'll be looking at the output and the state of the system that allows the system to translate the input into the output. So let's talk about data input. When we talk about input in computer science, really what we're talking about is the data that needs to be entered into the program to enable it to perform desired tasks. The job of the designer in the UX design is to try to understand both what kind of data need to be entered into the system, as well as how that data should be entered to both enable the user to effectively use the system and for the system to have all the data that it needs to perform its tasks. At the very broad level, it's worth distinguishing two types of data input, user entered input and passive input. User entered input is really the input of data that the user actively performs on the system. And the job of the designer is really to set up interfaces that the user can use to enter that information into the system. There are several types of user input, but really a simple way to conceptualize this type of input is that it consists of the various graphical user interaction elements. Things like buttons, icons, and menus and switches, that the user can access and manipulate in order to tell the system what the user is trying to do. As well as the data that the user is able to enter through things like text boxes, structured forms like date picker or checkboxes or sliders. As well as through different kinds of modalities of input that modern applications support, such as voice input or using the camera to take a picture. In all of these cases however, the input of the data is actively being done by the user as he or she is interacting with the interactive system. Passive input, on the other hand, is the data that the application takes in in the background by use of the various kinds of programming interfaces that are available both on the device itself and on the Internet as a whole. Some of the main kinds of the passive inputs are sensor readings, things like accessing the GPS to get the location or using the camera in a continuous way to take pictures. As well as various other kinds of embedded sensors that are becoming more common in modern phones and other wearable devices, things like accelerometers, gyroscopes, and so on. Modern applications also often access data from other applications. And prime examples of this are the applications that use the user's calendar or contact list to be able to support some of their functionality. As well as being able to access larger collections of information that users have on their systems, such as their photo library or the health data that is being stored in Apple Health or Android Fitness. Finally, many applications also connect to the Internet to get data from various web based sources, such as the APIs of web applications, such as FitBit or Yelp. As well as things like weather forecast or RSS feeds that are being published by various news sources. All of these kinds of data, applications are able to get in the background either at the time that the user is interacting with them or between user interactions in order to enable the system to have the right kind of information to be able to perform the functions that it's intended to perform. One of the major tasks that interaction designers have is to design those various inputs in a way that allows the system to effectively function. And the kind of design considerations that go into this are things like the following. What kind of granularity to the data is needed? When and how often is data going to be needed in the system? What state is the user going to be in when the data is needed? Is the user going to be sitting quietly at the desk in front of a computer when he or she has plenty of time to enter information? Is the user going to be driving? Are they going to be in a loud enviroment? The state of the user is going to be key for understanding what kind of input methods are going to be effective and usable for the users. And finally, what is the value of obtaining the information versus the burden that the user is being put to in order to get that information? Direction designers have to carefully think about all of these kinds of questions in order to effectively design input methods. I'll give you a flavor of what that looks like through a concrete example. So let's consider Heartsteps. This is a relatively simple application that my research team has developed that is intended to support individuals in trying to walk more throughout the day. And for our purposes, let's focus on three particular pieces of Heartsteps. Heartsteps again is a walking application. And it supports individuals in trying to walk more through three particular kinds of interaction components. It allows individuals to see graphs of their walking behavior so they can monitor how much they could be walking. A few times a day, Heartsteps send to users a notification that contains a suggestion for how they can be active in their current context. As well as asking them at the end of the day how they might be active on the following day so that users can make concrete plans for the physical activity on the following day. And let's take a look at what kind of input methods are needed to make an application like Heartsteps work. So the first thing that the Heartsteps needs to be able to do is track the user's steps. This is a walking application, and one of the things that both the user and the researcher wants to know is how much the user's going to be walking. So the primary data type that is feeling Heartsteps is the data about how much the user is walking. We enter this information into the system using a sensor, in this case a Jawbone activity tracker. And this sensor is worn on the wrist, and as long as the sensor is worn, it monitors user steps continuously and provides the system with a minute level information about the user's steps. So as long as the system is worn, Jawbone app is able to passively collect information about the user's steps, and do so on a continuous basis. For Heartsteps, steps is a high value type of data because the whole application is structured around walking behavior. And so we want to be able to get this information into the system. But on the burden side, most of the burden says this is basically collected information really has to do with things like usability of the job on bracelet. How often the user has to charge this bracelet so that it continues to work, the comfort of wearing it, how well it fits with other things that they're wearing, and so on. And remembering to wear the bracelet. So really the burden in this case for this input method is around usability, while the value of the information is high since it powers the whole application. Another type of information that Heartsteps needs to have is the information about the users location. Again, one of the things that Heartstpes does is it sends individuals messages that tell them how they might be able to be active in their current context. And for this the system needs to know the user's location. We get this location, again, through a passive sensor, in this case GPS. But the frequency at which this is done is very different than it is for steps. In our case, since the messages are sent to users only a handful of times each day, up to five times a day, we only need to know the user location at the time when we're actually planning on sending them a activity suggestion. So we only query the sensor at those times to get a location because we do not really need location at other times throughout the day. In terms of granularity, we really don't need a huge amount of granularity for the user's location. Since the location is used to tailor activity suggestions, we really need only the level of granularity that is necessary to do the tailoring effectively. In our case, we have suggestions that are relevant when the user is at home. We have suggestions that are relevant when the user is at work. And we have a broad range of activity suggestions that are just relevant in general when users are moving throughout their daily lives. So whenever we take a GPS location, we translate that on the fly to only one of these three categories, home, work, and other. And that is the only thing that the system actually stores. In terms of burden, the main issue that location raises has to do with privacy and battery life. And this is one of the considerations for why we decided to keep only a low level of granularity frequency of getting location from the users' phones. Users do not like to be tracked in real time, and by keeping the frequency of location testing low and by keeping the granularity of the information that we keep at the very broad level, such as common work, we can protect the user privacy while at the same time making sure that we don't drain their phone battery. So in this case the considerations of privacy and battery life burden were key to determining both the frequency and the granularity at which the location would be tracked. Finally, one of the things that Heartsteps does is also collect information about the user's plans for how they are going to be active on the following day. And this is user entered text, right, so these are the plans that the users themselves have to enter into the application. And we do that through one of two input methods. We can either have the users type in the text as a sentence into the system or select from a list of previously entered information. In both cases, the application gets a chunk of text that represents how the user's going to be active on the following day. But the actual user interaction of how this happens is very different. Creation of a new piece of text by typing versus just a simple selection from a list of things that the user has previously entered. This is done daily. The granularity of how detailed the plan is going to be is completely user defined. And on the burden side, really the biggest aspect of the burden is the cognitive effort involved in coming up with a new plan. As well as for older participants in our studies, the effort of typing on a small phone keyboard. But really if you look at this particular part of Heartsteps, one of the key questions that we had is which of these two input methods is actually more effective? So we supported both in the system, and then we were able to run studies that would try to determine which of these input methods actually matter most. So to summarize what we've just talked about, input methods and designing effective input methods are fundamental to the design of effective technologies. At the same time the format, the granularity, and frequency of input sets limits on what an application is able to do. And that's why these kinds of considerations have to be thought of very carefully as part of the design process. For instance, in the case of our activity plans, given that this is just free text, it is really difficult for an application to be able to do things like set automatic reminders based on the instructor data. So the same kind of considerations apply, for instance, when one is potentially tracking food using a camera. Taking a picture of food is a lot easier in terms of user input than looking up a food in a database. But those images are much harder to process in ways that provide users with graphs of how much they have be eating over time. So exactly how the input of the data is done in an application fundamentally alters what that application is able to do. At the same time, the user experience of the system as a whole is greatly affected by the input design. If the user is having to input data into the system frequently and that input is laborious, there is a risk that the user will end up being frustrated and annoyed. As well as, in case that a lot of passive data is being collected, that the user might have serious privacy concerns about the application. At the same time, if the input is made to be delightful, if it's designed in a way that makes the process of inputting data enjoyable. Input could actually lead to a larger engagement with the application. This cuts both ways. Effectively design input can be both a boon to the engagement with the application, as well as if the input is not designed well it can lead to frustration and potentially system abandonment. Finally, although we did not discuss that in detail so far, the mismatch between the user state and input modality can be highly problematic. So if a application is something that the user is using a lot while they're on the go, while they're walking or potentially in a moving vehicle, requiring the user to type a lot, for example, might not be effective way to enter data into the system because that is difficult to do while the person is moving. So considering issues like the user state, as well as the format, granularity, and frequency of input, is really fundamental for developing both input methods that are going to work for the users and effective systems as a whole. In the next lecture we will then start looking at how the data that is entered through such input methods is translated into the user feedback in the form of the output. Thanks for watching, and see you next time.
