...
The idea of the design was to mobile focused because of the touring and moving aspect of the application. Most of the interface was reduced to just tapping and sliding, which were very easy operations to do with just one's finger or thumb. The only times where the user would have to use more would be when typing in the Search or Feedback sections.
Home Page
The home page and the checkin page represent two design structures that we use throughout the interface with the aid of jquery.mobile. The home page shows a very familiar list of options with big buttons to press. During paper prototyping every user was able to dive right into the application because getting to other pages was very intuitive.
Question Queue
The question queue was the focus of our application in the interaction between tourists and tour guides. In our computer prototyping design, each asked question was labeled with a time-since stamp, however most users were confused by this. i.e. "How many students go here? 10min" means the question was submitted 10 minutes ago, but it was confused with "will be asked in 10 minutes" and "The question was answered 10 minutes ago." For our final design, we removed this. Having the new questions drop to the bottom of the queue was enough to show the user how the system worked.
Stories/Profile Pages
The story page is very similar to the home page in that it is essentially a list of items. In paper prototyping, users frequently weren't sure if you could click on the stories to go somewhere else, but this issue was solved in computer prototyping. In earlier designs we also had an excerpt from the story instead of the whole story, but in computer prototyping, most users didn't seem to mind it too much as they were still able to skim stories quickly.
The profile page is very simple, with only the student's photo and various facts about themselves. Users varied between wanting the profile information already expanded or if they wanted it expanded when clicked.
Events Page
Like the stories page, the events page is essentially just a scrollable list. However the events page allows for changing the date and does not allow you to click on the events. The idea of only having a "Previous Day" and a "Next Day" buttons came by in paper prototyping because most tourists would only be in town for a few days and could thus find only relevant information. The URL was descriptive though and used the ISO standard of YYYY-MM-DD, so more advanced users that wanted to jump to specific dates could just type them quickly and simply into the URL.
General Stats/FAQ
The design for this page showed the differences between Paper Prototyping and Computer Prototyping. During paper prototyping, very few users understood how to move the graphs around and would end up either stuck or would try to click on the small grey circles below the graphs. However, during computer prototyping everybody understood how to slide the graphs from left to right without any direction at all. This shows us how you have to take paper prototyping results with a grain of salt and should retest design decisions on the computer if you have doubts abut their learnability.
Feedback
The feedback page was very simple. We used sliders for all three inputs because of their easy entry on mobile devices. Users asked for discrete sliders though, because they found it would be easier to decide on a rating if they were given a discrete range instead of a continuous range.
Map
The Map page ended up being very simple, with just a map zoomed in on one's current location. Originally there were going to be additions to the map design, but they proved too ambitious for the scope of this project. This page became useful just because of the accessible map even though it was empty otherwise.
Implementation
Back-End
The back end of the web site was built using Node.js and Express. The decision to use Node was mostly for self-improvement purposes, as no one in our group had used node before and wanted to learn something new. In addition, Socket.io was used to build the event driven portion of the app, mainly the Question Queue. The database used was Postgresql, interfacing via the 'pg' module.
...
- Check in to a tour and Ask a question to the tour guide.
- Find a fact that interests you about MIT.
- Find a dance related event happening either today or tomorrow.
- Find where you are on the map.
- Find a story that interests you and schedule a meetup with a student who wrote a story.
- Leave feedback for your tour guide.
User 1 Problems
- The user enjoyed the color scheme and found it aesthetically pleasing
- The user found difficulty understanding what types of questions could be asked to the queue.
- The user had no way of removing from the queue.
- The user did not understand what was on the General Stats page until clicking on it.
- The user pressed back on the events page expecting it to bring them back to home, but it brought them to the day they were previously on (unexpected).
- The user did not like all of the text on the stories page.
- The user would have liked a place to add events to a calendar.
- "Previous" and "Next" were slightly confusing. Would have preferred "Previous Day" and "Next Day"
- The user pressed on the story expecting to see it again in an "expanded" view, not the profile page.
- The profile schedule meetup button does not give feedback after pressing submit.
- Stars were missing from page when user visited.
User 2 Problems
- The user liked the font for ConnecTour.
- The user didn't like that they had to refresh the page to see their question added to the queue.
- The user would have liked to see something more in terms of ordering, such as time or numbering.
- The user didn't know that the General Stats page was going to be general stats/FAQs about MIT specifically.
- The user had trouble reading the graphs in the General Stats page.
- The user initially thought events were clickable on the Events page
- The user would have liked to see his own GPS location on the map.
- The user found the Stories page overwhelming with the amount of text.
- The user would have liked to see suggestions of what they could search, or filters they could use to look up stories (didn't know what kinds of stories were available)
- The user didn't like that Schedule Meetup was a popup. He would have liked to see it as a separate page.
User 3 Problems
- His tour guide wasn't listed under MIT which was confusing. We used canned information bc we didn't know who would run the tours.
- Wasn't sure if the Map page was supposed to do more than it did.
- Wanted to focus on the school and looking around, so he would only use the app in uninteresting or quiet places.
- Didn't know what the Star rating on the feedback page was for.
- Didn't know where his feedback was going to go (to the tour guide or to their boss.) and seemed concerned.
- Would prefer if the feedback page had discrete sliders. Continuous ranges were hard to choose from
Reflection
The main thing we would do differently in the class would be to try and focus on a more specific problem for our project. We think it would have been fruitful to work on just the Question Queue and use that as our application, rather than trying to satisfy every need of our target user group. We think the final product would have been a lot more polished, and we would have had more time to work on usability issues, which is the focus of the class. We may have even had time to focus on catering our UI to another one of our other user groups: the tour guides. We also made the decision to use node.js for this project. However, since none of our members had prior experience with node, we spent a lot of time trying to learn node on the fly while coding our application. Since every member on our team did know Rails, if we had coded our application in Rails we could have spent less time on the back end of the application and we wouldn't have had to compromise on our UI and everything we wanted to accomplish with it.
...