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:

• Different group of users have different mindsets in using an application. How to make the app intuitive to all users is hard. Therefore, how to make the app easy to learn and easy to understand becomes important since it is nearly impossible to make an app cater to all the people.
•  It is hard to hide system implementation from design. Programmers are used to “programming language” and sometimes this makes the app not speak user’s “human language.” For example, we used to have “latitude, longitude” to express user’s current location.
• The tradeoff between implementation and design. Good designs might sometimes entail hard implementations. In this course, we don’t have many chances to do prototyping on implementations, therefore, even though we had some really nice design features in paper-prototying, we were unable to carry it out due to implementation limitation. This also makes us deviate from our previous design and produces immature features.