...
- 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.
- 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.
- In step 2, we provide auto-complete of choosing a location, we also mark the chosen location to give user immediate feedback.
- 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.
- 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."
- Based on feedback from GR4HW2, we incorporated a summary page at the end of create process to prevent users from having to recall what they just created.
...
- 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.
- 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 being 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.
Wiki Markup
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:
| Panel |
|---|
Thank you for participating in this user study. LocaShare is an application that allows you to share your location data in ways that are different from existing services like Foursquare and Latitude. * place and time-based sharing: you can elect to share your location only when you arrive in certain places, or only during certain times of day or times of the week, without the need to “check-in” Setup: Imagine your name is Katrina, and there are three other users in the system – Scott, Tiffany and Sharon. |
...
Task | User Interview and Observations | Learnability | Efficiency | Safety | Potential Solutions |
|---|---|---|---|---|---|
View friends | * All users succeeded to get this information without any difficulty. Most of them were also able to use the drop-down menu, aggregate information, and the current location. | * One of the users were confused with | * Most of them didn't find the "My LocaShares with LocaShares with sb." button. They went back to the home screen by clicking on the back button multiple times. We should make the button more prominent to enhance efficiency. | N/A | * We can solve the learnability problem by arranging the LocaShares in the drop-down |
Create a LocaShare | * one user commented that having a New Share button on the | * No create button on My Shares pageLocaShares page. Application does not match user's mental model. | * typing in place names is very slow. Not clear how to fix this. | * Back buttons and confirmation provide effective safety. | * add example sentence to indication * add example sentence to indication location, city, state as valid inputs. |
Edit a LocaShare | One user thought that inconsistency (sequential v non-sequential) with Create process was confusing, another user really liked it. | * It doesn’t make sense that you edit a share created for multiple people by entering through an edit menu associated with a single person. | * Inefficient to figure out * Inefficient to figure out what’s being shared with one person -- in order to see times of day and week, the shares must be opened one-by-one. | * There is no confirmation dialog for editing. | * Alternative interface might edit shares starting by location instead of by person. |
LocaShare overview | All the users looked at the home screen for a long time to | * Photo on home page does not | * Users mentioned that a lot | * This task did not involve | * Provide better information scent (with the profile photo on the home page). |
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.