User Testing

Design:

LocaShare is an app that allows users to share their location data automatically, according to rules about who to share with, at what locations, and at what times. It also allows users to view such information that their friends are sharing with them.

In the final design, the user begins on a home screen which contains four interactive elements. First, there is an interactive google map that displays the locations of friends who are sharing with you. Clicking on one of the friends displays an infobox with the name of the friend, and links to the Friend’s Share page with that friend. Second, the current user’s profile photo is displayed in the lower left of the screen (we’ll call her Katrina). It is a link to the user’s profile page. Finally, there are two buttons -- the first leads to the Friends page, and the second is used to initiate the creation of a new LocaShare.

The Friends page page displays two lists in succession -- the first is the list of friends who are sharing with Katrina, and next is the list of friends Katrina is sharing with. Clicking on a friend in the first list links to the Friend’s Share page with that friend. Clicking on a friend in the second list leads to the My Share page with that friend.

The Friend’s Share page contains several interactive elements. At the top right is a link to the My Share page with the same friend. Proceeding down the page, there is a drop-down menu from which one share can be selected. Selecting the share modifies the History sentence to reflect how many times the user has been to the specified location recently. Finally, at the bottom of the screen is a map that shows the user’s current or last-known location.

The My Share pages with a friend is analogous to the Friend’s Share page, except that the information shown is about the current user Katrina instead of about the friend. There is a link to the Friend’s Share page at the upper right, and there is a drop-down list of shares. There is also a map showing Katrina’s current or last-known location. In contrast to the Friend’s Share page, the My Share page also contains Edit and Delete buttons for the currently selected share.

Design decisions for viewing friends:

1. Make the home screen more intriguing and informative by implementing an interactive map, and marking the locations of friends nearby.
2. The map and button failed to fit in the screen in GR4, so we decided to use a Google Maps API (addresspicker) to resolve this problem.
3. Make the profile picture in the homepage button-like to give users the affordance of clicking.
4. In friend lists, in addition to providing the name of friends, we provide their profile pictures to make it more efficient for user to find a certain friend. Also, the ">" arrow gives user the affordance of looking for more information.
5. In friend's page, in response to user1's (in GR3-phase 2) inquiry for knowing all the locashares I am sharing with a certain friend, we use a drop-down menu to list all the locashares.
6. In GR3, users expressed that "View me as sb." this sentence is confusing, so we modified the sentence and make it as a prominent button next to friend's profile picture.

Creating a new LocaShare is a four-step sequential process. Buttons at the bottom of the screen allow the user to navigate forwards or backwards in this process. The first page has a cancel button in lieu of a back button, and the final page has a submit button in lieu of a next button. On the first page, multiple friends can be selected to share with. On the second page, a location can be selected, with the assistance of auto-completion. On the third page, time parameters are selected -- times of day, time of week, and starting/end dates. A datepicker assists users when selecting dates. Finally, the fourth page allows the users to select whether to share history, and if so over what time period it will be aggregated. A confirmation screen shows a summary, and allows the user to go back if anything isn’t right.

Design decisions for creating a new LocaShare:

1. Make creating a locashare as a step by step process. Even though this sacrifices user's freedom to jump between steps, this tremendously enhances the learnability of creation especially for less-savvy users. Also, all the steps in creation have a default value which boosts the efficiency of creating a LocaShare.
2. In step 1, users are allowed to select multiple friends at one time. It also provides useful feedback in the form of a checkbox to make it so that you know which of your current fiends you are sharing with. If user selects no friends, the app doesn't allow user to proceed. 
3. In step 2, we provide auto-complete of choosing a location, we also mark the chosen location to give user immediate feedback.
4. In GR4, users criticized that the start date box in step 3 looks like a textbox. We resolved this problem with a datepicker which pops up whenever user clicks on the empty space. The datepicker also provides simple constraints such as the end date shouldn't be earlier than the start date.
5. In step 4, we adopted the idea of user1 (in GR3-phase 2) which allows user to select the scale of aggregation by using a slide bar. An example sentence was also included to assist user understands the sharing of "aggregated information."
6. System provides a summary page at the end of creation to prevent user from recalling.

When editing a LocaShare, there are four tabs that can be navigated independently. They allow you to modify, respectively, the friends, location, time, or history properties of the share. These tabs are analogous to corresponding pages in the create process.

Design decisions for editing a LocaShare:

1. Editing allows user to edit the same class of parameters as create. However, instead of being as a step-by-step process, we arrange the parameters as tabs. By doing so, we increase users freedom and efficiently reduce the button clicks if user only wants to edit "history". 
2. While editing, we automatically save users modification. 

Katrina’s profile page has several interactive elements. At the upper right, It links to her overview page. Next, it allows her to turn on or off sharing of her current location. When she turns it off, it overrides the settings of any individual LocaShares for the current location. When the toggle is on, there is a list below it of friends who can see Katrina in her current location. 

The Overview page has tabs for State, City, and Location-level shares. At the selected level, a list is shown of locations shared -- each element of the list shows the number of people who can see Katrina at that location, and clicking the link goes to an Overview Location page, which shows which people those are.

On the Overview Location pages, it shows who can see Katrina at the Stata Center. Each friend shown links to their My Shares page.

Design decisions for LocaShare overview: 

1. In GR3, users complained that the notion of LocaShare is not clear, thus, in the last design, we tried to match users mental model by incorporating a list of LocaShares and classify them into different levels. 
2. The Overview page has tabs for three levels of sharing, this gives user more freedom to browse only the share they are interested in.

Implementation:

LocaShare is a web-based mobile application that can be used across a wide-range of mobile browsers. The server-side code is written in PHP, while the client-side code is written in Javascript/AJAX/jQuery mobile. We used Google Maps API and a jQuery plugin called addresspicker [1] to incorporate maps in the application. The application uses a Model-View-Controller (MVC) framework that was taught in the 6.831 course. Finally, we used a MySQL database to store data.

A schematic of the workflow is shown below.

 
The user can being using the application by visiting the following URL <server location>/index.php?home. When the user enters that URL in the browser, index.php is called from the webserver directory. Index.php provides the parameter ‘home’ to router.php, which in turn tells index.php to call the controller for home.php. The controller's job is to load all necessary data from the database and render it to the user in HTML and JavaScript. In order to accomplish these tasks, the controller for home.php first interacts with the corresponding model for home.php to fetch the data. The model for home.php uses a database helper class called mysqlimproved.php to get the data from the database. Once the model for home.php receives the data, it passes the data along to the controller for home.php. The controller for home.php then interacts with a view class called view.php that contains helper functions to render the data on the screen. Using view.php, the controller for home.php creates an instance of the desired view (home.php) and passes the data along to this view. This view for home.php renders the data using HTML and JavaScript to the user.

A similar procedure is followed when a user submits data to LocaShare using a form. The only difference is that the controller for the appropriate form (say) abc.php obtains the data from the URL (since HTTP GET method is used) before calling the corresponding model and view pages for abc.php.

* Note: The model, view and controller for each page have the same name (e.g., home.php in our discussion) in the corresponding folders, in order to be consistent about which functionality is being handled.

[1]

Evaluation:

Finding Users:

We found our users by primarily contacting our relatives and friends. However, we did not know many very-savvy users of location-sharing services. Thus, we asked our TA (Katrina) for advice. She suggested a few potential users (this practice is called Snowball Sampling), out of which we contacted one but did not hear back from that person. We informally contacted another person but that person declined from participating in the study. We then found a user who is very-savvy with mobile technologies and knew a lot about how location-sharing apps worked (through that person’s research). However, that user did not personally use those apps. Thus, we ended up doing a relative re-ordering of our users and considered this user to be our medium-savvy user and promoted our other user (who we initially considered to be medium-savvy) to the status of a very-savvy user.

Though we had to do a relative re-ordering of our study participants, these users are representative of the user population categorization from GR1. User #2 never used any location-sharing apps previously and did not have a working knowledge of the capabilities of such mobile applications. Thus, that user is still a non-savvy user per the corresponding definition in GR1. We had to relax some of the constraints (usage of location-sharing apps) for the medium-savvy user because our User #3 had a mental model of how those apps worked but did not personally use them. User #1 can still be considered a very-savvy user because that user frequently used Google Latitude with family members and had previously used Facebook check-in (albeit rather infrequently).

Briefing:

Feedback:

Reflection:

We learned a great deal from the iterative design process we carried out for this project -- both about the difficulty of predicting what a user will think when using an interface, and about the difficulty of determining the essential features of an interface in order to achieve a minimal, highly usable design.

By testing our interface on different groups of users, we learned about different kinds of problems. In some cases we found that our usability problems were universal -- these were the things that were easiest to improve in subsequent iterations. In other cases, users representing different groups would like or dislike, understand or misunderstand exactly the same interface. This highlights the fact that it is very difficult to make an interface that is highly usable for many different user populations. In order to do as well as possible, it is important to mitigate worst-case misunderstandings of the interface. When the goal is to support a wide variety of users, the best solution often involves sacrificing efficiency for learnability.

Turning now to the lessons learned about our own perspectives on the design process, it was rather profound to observe how these changed as we made design decisions. In particular, we tended to want to have many features, and our design decisions tended to be about which features to cut. Features that we thought of as absolutely necessary at the beginning were often cut, but we rarely missed them. Each such change required only a small mental reorientation concerning the capabilities of the system, and moved us closer to a minimal, highly usable design.

It took us a long time to realize what was essential about our system. One debate we had, for instance, was about the importance distinguishing the mobile phone contact list from the contact list within our system. Because of implementation constraints, we ultimately presented the user with a fixed list of contacts. Although in a deployed product it would be absolutely essential to maintain such a distinction, for the purposes of this project as a study of one user interface, this turned out to be a useful simplification in one part of a relatively complex system. If we had it to do over again, we would have focused our discussions and attention much earlier in the game on the essential user interface principles that we were hoping to test. The tendency was to think about building a fully-featured, fully-functional real-world system, but many of the features we were thinking about were just not worth the time within the scope of the project. This lesson also applies more generally -- in the scope of any project with limited time and limited resources it is important not to divert resources to non-essential features. Just as was the case for this project as a class project, when considering a project which really is for deployment, there are levels of support and interfaces which seem important or at least highly tempting, and it is critical to prioritize and cut out everything non-essential. This is both in order to finish the project on time, and to achieve usability through minimalism.