...
We decided to implement a web application using HTML, JavaScript, CSS, JQuery, with a PHP/MySQL backend and we use MIT's scripts server for hosting. User authentication is implemented with MIT certificates, which are also utilized to pull user information (name and email address) from. This may be confusing that users aren't required specifically to log in, but we expect that most users with certificates understand their purpose. There are two sql tables: one for user information and one for all of the trips. The site collects any information that the user is inputting and when the user does an action that requires table lookup/modification, the site passes the information via URL to the other page (home -> my_trips, my_trips -> home), which executes the relevant commandquery. The main usability problem with this implementation is that any action that requires a table lookup/modification requires a page reload, which as it stands resets any of the user's current partial input. Most of our fields and buttons are controlled via javascript, and we utilize the Google Maps API for our maps. We chose Google Maps for both its ease of use in implementation but also in hope that the users will be familiar with the interface and controls.
Our graph that shows nearby travelers on a day range larger greater than yours is only visible once the user has inputted a location and selected a start and end date. While this was implemented this way because otherwise the information could be misleading, the fact that the graph is at times not showing and then being displayed may cause potential usability problems. We also decided to implement the graph with dummy data to show off its functionality, as there would need to be a large amount of data entered into the system for the graph's output to be relevant.
...
- More users for each of our tests: Though the amount of usability testing that we conducted was sufficient enough to provide us with valuable feedback, we feel that testing both the paper prototype and initial design on a wider variety of users would have given us more insight into our target user population. Additional paper prototypes would have saved us a great deal of time and provided more user feedback during additional iterations.
- More rounds of testing: We also believe that we should have done more iterations of testing after coming up with new designs after GR4. We were too focused on creating a final product that was what we wanted instead of ensuring that from the beginning that we were focused on something that that our user population would want and could use.
- More stretch: We think we should have zeroed in on the fundamentals of our user interface earlier so that we could have spent more time adding stretch. Stretch was the challenging part of the UI that allowed us face difficult decisions and utilize user feedback.
- More detailed computer prototype: While we had a computer prototype that enabled testers to get some sense of our user interface/project, we would have had a much easier time creating a more cohesive and better UI for our final implementation if our computer prototype had been further implemented before being heuristically evaluated.
- Focus the idea: We spent too much time initially trying to make a site that did too many things (and much of them were repeat functionality of already existing web applications). We should have more immediately focused on the elements of an idea that proposes unique and challenging UI problems.