DESIGN

Here is a screen shot of the Marauder's Map main page.

Marauder's Map is a way for users to see where their friends are and what they are up to.

It stands out from other location oriented websites because it sports several features to help with organizing, displaying, and interacting with friends.

The rounded markers on the map represent different friends that are online, while the gold star represents the current user.

These markers are placed dynamically by geotracking the user's IP address.

The colors of the marker correlates with the mood that each friend has set.

A mood must be chosen at login, but it can be changed at the top of the main page.

There are three moods: "Adventurous", "Relaxed", and "Studious."

Friends can be organized into different groups. These groups are displayed as tabs in a sidebar on the right of the screen. 

The tabs control the visibility of markers on the map: if an online friend is not in a group when its tab is clicked, their marker becomes transparent.

This can be seen below:

The tab that is currently selected is the "All Friends" group. It has Mason, Tamika, and Xiaoji in it.

Tamika is offline so she is not on the map. Mason is adventurous, which is represented as a red icon by his name in the sidebar and a red marker on the map. Xiaoji is relaxed, so her colors are blue.
When the "Study Buddies" group is selected, Mason's marker becomes transparent, because he is not a member of that group.

Groups are managed by the two bottom tabs. The "+" tab opens an add group dialog, and the "-" tab opens a delete group dialog.

The "-" tab was added later in the design process. Because these two tabs manage the other tabs, they are separate from the main tabs.

The add group dialog has a field where the user can type the name of a new group.

The delete group dialog displays all of the created groups in a drop down menu. The user can select any group and remove it.

When a tab is selected and a group is displayed, the friends in this group are displayed.

Each friend is described by their name, photo, status, and status message. 

The other icons by each friend are the "Chat With" and "Hide From" icons.

The Chat With icon opens an instant messaging session with the corresponding friend,

while the Hide From icon makes the main user invisible to that friend (the main user shows up as offline to that friend).

These buttons were initially hidden from view in the "V" button, but have since been draw out to increase visibility and efficiency.

The only button that remains hidden in the "V" button is the "Delete This Friend" button. 

This design choice was made to prevent users from accidentally deleting friends.

The hiding from icon has the added feature of displaying the hiding state between the main user and the friend:

When the eye is open, the main user is not hiding from that friend. If the eye is closed however, then the main user is.

The Hiding From state is also displayed in the bottom bar under the hiding from section.It is shown here as well so that the main user can constantly see who he or she

is hiding from-- even if a different tab is selected.

In the initial stages of the design, the bottom bar was a droppable area that images of friends needed to be dropped into.

This was not intuitive to users in user testing. Now, the bottom bar just holds the names of a user after the corresponding

Hiding From button has been clicked.

 
The "All Friends" tab is a tab that cannot be deleted. It is different from the other tabs. It shows all of the friends a user has.

Friend requests are located at the bottom of the tab.

At the bottom of the user-created tabs, is the hyperlink "Manage Friends."

This link opens a dialog with all of the main user's friends. The friends that are already in the group appear with checkmarks by their photos.

The user can check or uncheck boxes in this dialog to add or remove friends to the group.

This was a major design improvement from initial designs. Where in the past a confusing drag and drop method was depended on,

this method is simple, clear, and to the point.

IMPLEMENTATION

All major functionalities are organized within one page. For implementation and collaboration convenience, we divided the page into several modules. The modules were first developed separately, and then integrated into one layout. The main frame resizes the modules to fit into the size of the browser window.

Each module has its distinct behavior, but actions taken in any of them may have a global influence, as discussed below.

One crucial point of the implementation is to make sure the information displayed in all modules are synced. For example, by clicking on a 'hide from' button in the sidebar friend list, the following views are expected to change: the hidden/shown status icon on the sidebar; the hidden/shown status icon in the map popup window; the tags in the 'hiding from' bottombar. To solve this we use a MVC pattern:

The HTML file contains the layout information and the templates of all dynamic objects (FriendEntry, Tag, …).

There are two types of functions in the scripts: the 'loader' functions retrieve records from the backend and refreshes all visible elements accordingly. For example, the refreshTabs() function takes an array of friends information, make a tab for each group, generate a grind entry object for each friend using the template, attach listeners to its buttons then append it to its tab.

Very few listener functions, upon receiving user actions, activate another object in the view, for example, clicking on a user's name on the sidebar causes the info window in the map to pop up. Other listeners do not alter the views directly. They request the backend to update the database, then dispatch an 'reload' event. They handle user requests such as adding/deleting friends, hiding/unhiding from user, managing groups, updating mood and status message, etc.

This design makes sure that all modules are as independent as possible. However, there is the downside of it: the views are not refreshed until the backend data is updated. When there is a significant delay in getting server response, the user cannot see the effect of his action in time, and gets confused if he has missed the target. This was observed during the demoday in class. This fails the 'feedback' principle in usability.

If we are to improve the implementation, I would cache a copy of the user info/friendship data locally. The listeners should modify this local data and use it to refresh the views. The local data will be synced with the server in the background.

EVALUATION

Method

We conducted our testing using the same briefing and tasks from GR3 Paper Prototyping. Throughout GR4 and GR5 the intended purpose of our application and it's features did not change, so we decided that the same briefing and tasks would still be suitable and sufficient to test our finished implementation. 

During pilot and user testing our users were given the briefing and then began completing the tasks one by one, which were dictated to them. There was no demo given since our testing involved tasks that highlighted every main feature of the application. Therefore, any sort of demo would have caused us to bias user performance on some of our tasks. We opted to have more thorough testing with all of the nine original user tasks, rather than give a demo and have to omit some of the tasks from the testing process.

In addition to the briefing, during our actual user testing, users were given instructions to think out loud, to not worry about how quickly they completed the tasks, and to feel free to give up and ask for the solution to a task if they got frustrated. 

In both situations our users were completely representative our our target audience, as they were all current MIT students.

Pilot Testing Results

Pilot testing was conducted on four 6.813 / 6.831 students on Demo Day. All four users had no trouble completing each of the 9 tasks but provided feedback that brought to light the issues detailed below. More important however, our pilot testing assured us that our testing method was clear and concise enough to be used for our final user testing.

1. Cosmetic (graphic design): Two users pointed out that the add/delete group button looks too similar to the Google maps navigation buttons. 

 Buttons for adding and deleting a group attached along the sidebar

This issue did not affect their ability to figure out what the buttons were for, so it was deemed cosmetic. To alleviate this issue, we could have affordances for those buttons other than a ' + '  and ' - '. For example, the button for adding a group could read ' + Group ' instead of just ' + '. 

2. Minor (visibility): One user initially thought the status text field was for searching. 

Room for a "Status" label on the left

3. Major (learnability): All three users had issues discovering how to create a group.

Two of the users took significantly longer to complete the task "Create a group called Study Buddies" than any other task, and one user opted to be told how to do it. All three users commented that they thought the ' + ' and ' - ' signs meant that the buttons were meant for zoom functionality on the map. One user also commented that it did not help that the buttons were separated from the group tabs, as opposed to just being right below the last tab.

This issue was acknowledged in pilot testing and originally deemed a cosmetic graphic design issue. However, the fact that our test users had significantly more trouble with the task, plus one user having to ask how to complete the task, we now consider this issue a major learnability issue. The solution to this issue remains the same as previously described in our pilot testing results.

User Testing Results

User testing was conducted on three students who have never taken either course and have never been educated in user interface design through any other sources. These students were recruited simply by asking friends if they would like to participate in our user testing and letting them know what the time commitment would be and what would be expected of them before they agreed. The results of our user testing proved to be much more interesting than our pilot testing. Some of the issues our users had were unexpected, and it was surprising that each had the same exact intuitions. Our user testing brought to light the following issues.

1. Minor (learnability): When logging in, none of our three users clicked on the mood icons to login.

Our users all simply typed in the given username and password and hit enter. Our application allows this and will default the user's mood to "Adventurous" if they do not pick one. Upon being told how the login was intended to work, one user replied that she would have never thought that those icons had a purpose other than decoration. When mousing over the icons, the mouse changes from an arrow to a hand, indicating that these icons ca be clicked on and have a purpose, however this is only beneficial if the user never even thinks to mouseover the icons.

It is possible here to see the mood icons as decoration, as opposed to functioning buttons

A possible solution could be to leave things as is, because if the user does not select a mood upon login, they can change their mood afterwards in the status bar. Another option would be to disable the fact that clicking "Enter" will log a user in, and instead require that a mood icon be clicked on. In this case, if the user does hit "Enter" to try and login, the mood icons could be highlighted to show the user they must choose one to login. 

2. Minor (learnability): When tasked with hiding from a friend, all three users initially clicked in the hiding from area, two of them specifically attempting to click within the placeholder.

When asked why that was their first intuition, two users stated that the placeholder made it look as if they could type in a name. However, when clicking in the "Hiding from" area in the bottom bar, all three users went to click on the "Hide from user" eye next to the designated friend, successfully completing the task without too much hassle. 

The dashed placeholder has the potential to be confused with a text area

Initially the purpose of the dashed placeholder was to be a target for dragging and dropping a friend's profile picture into a dashed square that read "Drag Photo" in order or hide from or chat with a friend. Now that we are no longer using drag and drop for this purpose, the placeholder does not hold as much significance and can be removed so that users do not confuse it with a text area.

3. Major (learnability): All three users had issues discovering how to create a group.

Two of the users took significantly longer to complete the task "Create a group called Study Buddies" than any other task, and one user opted to be told how to do it. All three users commented that they thought the ' + ' and ' - ' signs meant that the buttons were meant for zoom functionality on the map. One user also commented that it did not help that the buttons were separated from the group tabs, as opposed to just being right below the last tab. This issue was acknowledged in pilot testing and originally deemed a cosmetic graphic design issue. However, the fact that our test users had significantly more trouble with the task, plus one user having to ask how to complete the task, we now consider this issue a major learnability issue. The solution to this issue remains the same as previously described in our pilot testing results.

REFLECTION

In this project it became apparent that simplicity was the best method. In the beginning, the group tried to jump into fancy drag and drop methods, but these effects ended up making the design more confusing. It was only after countless hours of frustration that the group admitted that drag and drop was not necessary or even useful for the project. In the future, it would be good to keep the importance of design decisions during implementation. Questions such as “how necessary is this feature to the core tasks of the design” and “how does this design decision add to or complicate the user interface?” should be asked.

Simplicity also played a part in designing the project’s main features. The group had to strip the project down to its core features to figure out what to prototype and focus on. Since the project had a simple scope, this part of the process was easier to do well. When designing interfaces in the future, it will be important to remember that it is better to do a simple project very well, than a complicated project poorly.