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 an 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

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 ' + '.

html: Security restricted macro is not allowed. An edit restriction is required that matches the macro authorization list.

html: Security restricted macro is not allowed. An edit restriction is required that matches the macro authorization list. 2. Minor (visibility): One user initially thought the status text field was for searching.

The status text field says "your status message" when it's blank, but once a status message is submitted, there are no other hints what that text field is for. To alleviate this issue, there is enough room on the left-hand side of the status bar to include the label "Status: "

Room for a "Status" label on the left

html: Security restricted macro is not allowed. An edit restriction is required that matches the macro authorization list.

3. Major(visibility): Managing friends and hiding / un-hiding from a friend is delayed with no feedback.

The response time for these features are too long, and to fix this issue we would have to modify our backend. Local variables would get modified when information is submitted to the server, so that the user can see the result of their actions right away as opposed to having to wait for a response from the server before changed are made visible.

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.

html: Security restricted macro is not allowed. An edit restriction is required that matches the macro authorization list.

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.

html: Security restricted macro is not allowed. An edit restriction is required that matches the macro authorization list.

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

GroupsGroups

Child pages

Marauder's Map - GR6 User Testing

DESIGN

IMPLEMENTATION

EVALUATION

Method

Pilot Testing Results

User Testing Results

REFLECTION