Add a new section GR6 User Testing to your group's wiki page, with the following subsections:
- DesignDescribe the final design of your interface. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
- ImplementationDescribe the internals of your implementation, but keep the discussion on a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
- EvaluationDescribe how you conducted your user test. Describe how you found your users and how representative they are of your target user population (but don't identify your users by name). 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. List the usability problems you found, and discuss how you might solve them.
- ReflectionDiscuss 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.
Design
Implementation
We developed for Android 2.3 using the Google Maps APIs and Eclipse. The server is PHP with a SQL database. Requests are sent from the app, and the servers responds with XML, which is parsed by the app. We tested our app on the Nexus One, Galaxy Nexus, and several other models of Android phones. The test phones included operating system 2.3, but also version 4.0, Ice Cream Sandwich.
Our app has a local front end, but the tour data is stored on our server. We made some simplifications to our system to make it fit into the scope of this class. For this reason, the landmark data is stored locally, and users cannot add new landmarks with their own pictures. Also, we simplified the database for tours by not allowing the user to chose a picture for a tour they create. These don't take away very much from the functionality of the app, at least in terms of what we think our users want/need to do.
Users can add their own tours to the database, and in the future when they search those landmarks they will find their tour. This is not local to this user, so all users see all tours created. There is currently no way for a user to delete a tour, but this doesn't hurt functionality that much.
Evaluation
When we were initially formulating the idea for our app, we consulted with several of our friends to determine whether they thought our idea was any good. Several of them expressed that they would use the app themselves; therefore we followed-up with these users in order to perform our user study. We believe them to be good representative users since they are people that would be likely to search for, download, and use our application. However, they are all MIT students and there are likely other biases due to the fact that we knew them and they were not selected randomly. We decided that this was an acceptable trade-off for the ease of finding users, since we did believe them to be within our target population.
All of the users for the user study had not used our app previously. One of them was an Android user, so we provided him the application and instructed him to install it. The other two were not Android users, so we provided them with our Nexus One test device to use. We instructed all users to open the application. We then read them our briefing, unchanged from our paper prototype: "Torch is a mobile application designed to help users find and follow walking tours of notable landmarks and attractions. Users can also create and submit their own tours." We then sequentially gave them three tasks, also unchanged from our paper user study. We focused on these tasks throughout our entire design process, so it made sense to keep them the same.
- Find a tour of MIT's campus.
- Follow a tour around MIT's campus.
- Make a tour of MIT's dorms that includes Baker, East Campus, and Burton-Conner.
For the most part, reactions from our users were positive. Users were able to complete our tasks with very little assistance, which is strikingly different from our paper prototype user study.
Usability problems are summarized below, along with possible solutions:
Reflection
Designing a product is highly challenging and may be the most difficult task our group has ever faced together. We all had unique visions for our final product and merging those visions together with the other constraints of real life, such as time, was difficult and taught us all some valuable lessons.
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.
Project Proposal, User Analysis, and Task Development
What We Learned
While creating the project proposal, we learned that it was a lot easier to get our creative juices flowing once we knew what we wanted to develop. Through the entire proposal process, we realized how important it was to conduct the interviews, especially in the case of Torch. We learned the importance of digging deeper and really focusing on the aspects of route-planning application. Once we had designed the tasks and narrowed our focus, it was really easy to begin creating designs. Together we brainstormed all the different ways that we could have such an application, and each of us focused on a different way to do the three main screens. This process allowed us to have four different designs for each main screen, giving us a lot of options. Our end design ended up being an amalgam of different parts that we all created, and it really allowed us to have the best possible design going into the paper prototyping.
What We Would Have Done Differently
When we were trying to decide on a product, we at first were focusing on what was already out there rather than what was something that we wanted to use. We eventually learned, but if we had started from that mindset of creating something of use rather than improving something that was already in existence, we could've saved ourselves some time and thus, would have had more energy to devote to analysis and proposal of Torch. When we first started, we didn't really have a specific problem and we had some lofty goals. To be honest, we should've narrowed down our focus directly to the specific needs of self-guided tours rather than what does the user "find interesting" angle. We should've narrowed in scope our User analysis so in the future it would've been easier to develop specific tasks and needs. Our interviews were more surface level than they should have been, and while designing our product, we had to delve more deeply, a task we could have avoided if we had done more comprehensive interviews originally.
Designs
What We Learned
What We Would Have Done Differently
Paper & Computer Prototyping
What We Learned
What We Would Have Done Differently
Heuristic Evaluations
What We Learned
What We Would Have Done Differently
User Testing
What We Learned
What We Would Have Done Differently