...
We developed for Android 2.3 using the Google Maps APIs and Eclipse. We thought that this would allow us to take advantage of recent improvements to the Android OS, but still support a majority of users. The server is PHP with a SQL MySQL 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.
We made several simplifications that we deemed appropriate given the scale of our project. 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 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.
...
Designing a product is highly challenging and may be was one of 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.
| Panel |
|---|
Project Proposal, User Analysis, and Task DevelopmentWhat 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 many 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 early 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 focused 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 honestFrankly, we should 've have 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 have narrowed in scope our User analysis 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. |
| Panel |
|---|
Paper & Computer Prototyping and Heuristic EvaluationsWhat We Learned We did a great job of designing our paper prototype which made this step very useful and easy to conduct for us. We learned that it was very important to have short and concise tasks and really make high-level observations for each task & iteration we did. Because we did such a thorough job with our prototyping, we ended up being very happy with our computer prototyping results. Heuristic evaluations were very helpful and we incorporated many of the final suggestions into the next partdesign. With both the paper and computer prototypes, we really focused on the fidelity of breath, which was definitely the right decision. We concentrated on look and feel, wanting to really make sure that we were on the right track before investing any more resources. What We Would Have Done Differently If were to do this again, we would have probably added another round of paper prototyping before development. We didn't really value this step until we did it and saw how much knowledge and information we acquired from it without a lot of energy or high cost on our team's part. The computer prototyping part of the project took a large amount of work, and we definitely could have broken down the tasks more effectively between the four of us. Starting work earlier would have made the process less stressful. We were a little attached to our prototype, but since we were all attached to different parts, it was easy to continue to improve it and not stay too attached. However if we were to do it again, we will all keep in mind the importance of a dynamic, constantly improving and changing prototype. For example, we didn't realize how confusing the tabs we had in our original prototype were ("Map View" and "List View") and we didn't want to change it until multiple peopled pointed it out to us. |
...