GR6 - User Testing

Design

Final Design (TODO: Label each screenshot)

1. Login Screen	2. Tutorial Screen	3. Home page showing the position of logged-in user on map with blue dot	4. Home page showing position of friend on map with green dot	5. Friends' list
6. Search page to add friend	7. Profile page of a person currently not added as friend	8. Event initiation page	9. Participants selection page (this is wrong snapshot -- this is view participants list -- add snapshot with check boxex on right) TODO	!device-2012-05-15-161243.png	border=1,height=300!10. 10. Location Selector
11. Confirmation message on selecting a locatoin		13. Notification page: A bubble appears on Notification button when new notifications are received unread notifications are highlighted in beige background	14. View Proposed Change page.	15. Event when viewed on map shows the RSVP responses from all invitees in form of color and textured line connecting them from the venue. a small legend on top of screen explains what different colors and textures stand for.

Design Decisions (TODO: Fill in all remaining designs and their descriptions)

Title	Screenshot	Alternatives	Description & Justification
1. Title Screen		Our first implementation of the title screen actually centered the form fields.	We opted to shift the form fields to be slightly higher (40% way down the screen), because we realized that otherwise, the soft-keyboard would actually occlude the Log In button. (Pilot Testing)
2. Tutorial Screen		N/A	One of the biggest issues raised from our heuristic evaluators was that the application's minimalistic design and gave users a slight learnability problem when confronted with the application for the first time. The evaluators suggested for some kind of tutorial or instructions to walk first-time users through the the main features of the user interface. We thus implemented a by-passable tutorial screen which walks users through the various icons and what they meant on the home screen, as well as explanation of the icons on the map view. (Heuristic Evaluation) Based on our user tests, many of them showed approval and were welcoming of the tutorial screen. (User Testing)
3. Bubble showing the details of the person have a close button on top right corner		tapping on a dot denoting a persons position opens a bubble showing the details about that person. previously this bubble was dismissed by a second tap on the dot. our new design have a small "x" at top right to close the bubble.	people found it hard to figure out how to close the details bubble, because of the missing affordance, even though this feature is externally consistent with google map applications. to alleviate this problem we made the close button visible.
4. Profile Page		previously all the profile details were enclosed in a bounded text box. in our new design we removed the boundaries.	people confused these boxes as editable text box.
5. Map view of event	TODO : snapshot with all three kinds of responses	previously the RSVP was indicated only by difference in color (red, green and gray) of the connecting lines. now it is indicated by both colors and texture. and a legend is displayed on upper right corner to help users learn the meaning.	choosing only color as indicator proved to be ineffective because it was hard for color blind people to distinguish these colors.
6. Notification Page		originally all the notifications were displayed in similar manner, irrespective of whether they are click-able or not. now the notification which may require user to perform an action or have further details to show have a tine arrow on right, giving the affordance to show more.	users faced difficulty in understanding why tapping some notifications redirects them to another page while on some nothing happens. to let user distinguish these different kind of notifications visually we placed an arrow for the notifications which are click-able.

Implementation

Client Application (Front-End)

Discover.Me was developed as a native Android application using the Android SDK. Eclipse was used as a development environment, and we made use of the emulator and 3 different Android devices for testing. Java was used as the programming language, and all the views were programmed from scratch. We made use of default Android components (EditText, TextViews, TimePicker, Button, ImageButton, etc.) in order to maintain consistency with the Android platforms design guidelines. Image assets were hand-created using GIMP and PhotoShop, and some of the icons were gathered from freely available icon packs. We made use of the Android Google APIs in order to render the map view, as well as for getting geographical and location based information. Each view seen in the application (called an Activity) is created using a mixture of declarative and programming approaches (as seen in the figure above). Locally persistent information is stored on the device's storage, and directory or database intensive information were stored on a local SQLite database on the device. The device also caches information sent from the server in order to speed up queries. For example, the directory is loaded from the server, and then locally cached on the device in order to make searches much faster, and this was crucial to enable our suggested/autocomplete search functionality in our application to work efficiently.

Server Service (Back-End)

In order to ensure data stays persistent, we made use of a PHP server as a back-end service to store the user's information which is sent from the device. We implemented an asynchronous thread on the client which frequently sends information, such as the user's location, to the server which would then proceed to push the information to all other devices. This was used in order to enable multiple users to keep track of one another's location. Our notifications service also used the same system in order to send notifications about an action one user performs to another (i.e. Alice creates an Event and invites Bob. The event information is pushed from Alice's Device to the Server. The Server stores the information and generates a notification to Bob. Bob's device will pull the updated notifications and visually displays it to Bob.). Several PHP scripts were written in order to perform actions such as Creating an Event, Proposing a Change to an Event, Sending a Friend Request, Deleting a Friend, etc. Data-related storage were stored as .txt files on the server, and were prefixed with the user's MIT ID. For example, the list of Charlie's friends would be charlie_friends.txt.

Evaluation

Conducting the User Test

TODO: Describe how you conducted your user test.

User Population

TODO: Describe how you found your users and how representative they are of your target user population (but don't identify your users by name).

Task Briefing

TODO: Describe how the users were briefed and what tasks they performed; if you did a demo for them as part of your briefing, justify that decision.

Usability Problems

TODO: List the usability problems you found, and discuss how you might solve them.

Overview of Usability Issues Observed

Finding a Friend in your Friend List	Adding an Individual into your Friend List	Creating and Inviting Friends to an Event	Responding to an Invitation by Proposing a Change In Time	General Comments

Detailed Observations

User	Finding a friend in your Friend List	Adding an individual into your Friend List	Creating and Inviting Friends to an Event	Responding to an Invitation by Proposing a Change in Time	User's General Comments
1
2
3

Reflection

TODO: Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

Child pages

GR6 User Testing