Page History

...

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 Based on feedback from HW2, we incorporated a summary page at the end of creation create process to prevent user from recallingusers 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.

...

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:

Wiki MarkupLocaShare 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.

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.

Image Added

The user can begin Image Removed
 
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.

Wiki Markup*\[1\]* http://xilinus.com/jquery-addresspicker/demos/

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:

...

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.