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. Based on feedback from HW2, we incorporated a summary page at the end of create process to prevent users from having to recall what they just created.

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. We used real data from mobile experiments performed by a research group at CSAIL in our system. This helped us build realistic and meaningful scenarios for the user studies.

A schematic diagram of the workflow is shown below.

The user can begin 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:

Users:

We performed three user tests on users that we recruited from our personal networks of friends and family. We determined the suitability of the users by questioning them about their usage of mobile applications and of location-sharing applications. We found one very basic user, one medium-expert user, and one highly-expert user.
    Our basic user had never used any location-sharing apps and did not have a working knowledge of the capabilities of such mobile applications. This make the user representative of the category. Our medium-savvy user had had a mental model of how those apps worked but did not personally use them. This is slighly less savvy than our original definition, but close enough to be useful. Our expert user had used Google Latitude and Facebook checkin, but only sometimes. This is not quite as engaged as our original conception, but once again close enough to be useful.

Tests:

We performed our tests by briefing users with a written briefing, and then asking them to perform four tasks. There was one user, one facilitator and two passive observers in each case. The first task was to view information about a friend, and then determine what information about him/herself was visible to that same friend. The second task was to create a new LocaShare with parameters specified by the facilitator. The third task was to modify a LocaShare according to parameters specified by the facilitator. The fourth and final task was to obtain information from the Overview mode concerning what friends could see the user in a particular location.

Briefing:

Feedback:

General Issues:

* All three users did not (initially) find the home and back buttons in the header of the page. These should be made more visible.

* One user did not understand what the map on the home page meant. Need to make it externally consistent with other apps that use maps (e.g., by displaying a "blue dot" to indicate the user's current location).

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.