You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

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)







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)

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.

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.

  • No labels