...
In implementing this project, our goals included a front-end and back-end. However, as written in the Reflection section, the back-end goals were difficult to meet with our group of only 2 people. With that said, our implementation focused on the front-end User Interface. We implemented the User Interface with HTML, CSS, Google API, Javascript, Jquery, JqueryUI, and a number of other small libraries like JqueryCorner. The Front-End functionality was implemented in Javascript using the OOP features of the language.
The choice of these libraries were because they provided good features for a UI. For example, in some of our online research, we found that boxes with rounded corners are much more visually pleasing then straight corners.
In formatting the pages of the site, we used CSS to construct the layout. We reused a lot of the css from page to page to keep pages consistent - such as the Dashboard Page and the Plannit Page. Another CSS feature we utilized was the opaqueness. This was another feature we found that had a “visible appeal.”
In terms of the “dynamic” aspect of the site, we utilized the JavaScript Libraries such as Modal Boxes, accordions, buttons, etc. from JQuery and JQueryUI. For example, we store a user’s trips in the Dashboard using an accordion and we allow messaging using Modal Boxes.
The API implemented was from Google Maps. This provided a visual representation of the trip that was planned as well as directions for users for each leg.
The back-end functionality was actually implemented in Javascript in the front-end. There was not enough time or labor to implement an minimal and functional backend. However, our back end design consisted of PHP and MySQL. We would store a user’s trips in the database and pull them when the user logged in to populate their dashboard and messaging. Additionally, when messages were sent, they would be stored in the database associated with the user that the message was addressed too. However, the form error handling, sometimes done in the back end was always intended to be implemented in the front end.
One final shortcoming in our original goal was the implementation of the Facebook API. There was not enough time for the two of us to include it in the way we wanted to with everything else that had to be done. This was not a priority but nonetheless would have been great to use.
The UI is built to include the Facebook API, however. For example, in the “Host Options” panel, where there are a number of hosts in each city, each of those spaces are divs that allow for a picture and name of a Facebook Friend of the user in that location. Currently, they are only ‘canned’ hosts which are distributed randomly between locations.
In terms of the implementation hindering the UI, there was nothing that was explictly hinderedwas explicitly hindered. The UI is what was focused on mostly in the entire implementation because the backend was never implemented. However, because the front-end was all implemented in JavaScript, HTML, and CSS, we lost the opportunity to use other graphic techniques to better the UI such as using Photoshop, etc.
Evaluation
The target user population for RoadTrippit is both male and female students age 18-22. To find users for user testing we simply asked fellow MIT students as they are exactly the type of user RoadTrippit is intended for. We found users that expressed interest in travelling while in school and were open to using a service to help them plan and organize their road trip.
...
Severity: minor
Solution: Use a different word like ‘End’ or ‘Finish’
Reflection
This project allowed us to learn about many important aspects of the design process. The most important thing we learned throughout this process was the importance of constant user feedback. After each iteration we were very pleased with our design. However, only after user testing did we realize how many problems the design actually had.
After each round of user testing, our design made huge leaps forward in terms of usability. For this project we only did user testing after the paper prototype, the computer prototype and the final iteration for a total of three times. In retrospect we should have done more user testing than was required for the course.
We found that the paper prototyping was the most useful. The amount of time and resources required to create a paper prototype was very minimal and the amount of useful feedback was great. Our design would probably have benefited from many more rounds of user testing on paper prototypes. We were unable to do so because of the amount of time we had and the pace we had to keep in order to finish the project by the end of the semester.
We also learned not only the importance of testing users to find usability problems but also listening to users in order to find the best way to fix the problems. In most cases, the solutions to usability problems that arose during user testing were suggested by the user that was having that particular problem. Even though we had an idea of what features we wanted to have implemented, actual users proved to be extremely important in determining how the features should be implemented.
As important as we found listening to users to be, we also learned to make sure that a usability problem was consistent among different users. There were times when one specific user had trouble with the interface and we considered making changes to alleviate that problem but discovered that this user was unique and that making a change might negatively effect the usability for almost all other users. In other words, we learned to update our design based on common user problems rather than trying to address every single issue that every single user had.
An issue that we had during this project was implementing all the features that we had planned during the initial design phase especially given that we had only two group members. If we were to do this project again we would make an effort to do a better job of determining the features that would be realistic to implement in less than one semester with only two people.
We spent much of the early design phase crafting and testing interfaces for features for which we didn’t spend enough time thinking through whether it was reasonable to actually implement in the short time we had. We then had to spend most of implementation time during the end of the project on the back end and were forced to focus much less on improving the actual interface and user experience of the site.
In the end we had to scrap the back end as well as many key features that we had set out to implement and our user interface suffered because of this. If were to do this project again we would focus on implementing simple features very well rather than trying to implement very complicated and interesting features.