...

• #Table of Contents
• #Design
  • #Overview#Design Overview
  • #Design Decisions
• #Implementation
  • #Overview#Implementation Overview
  • #Problems
• #Evaluation
  • #Users
  • #Briefing
  • #Scenario and Tasks
  • #Usability Problems
• #Reflection

Design

Overview

Website

Our web app consists of an interface with 6 tabs: Carpool Search, Next Date, Swap Dates, My Full Schedule, My Carpools, and Pending Groups.

...

Selecting one of the carpools leads to a screen with 3 options: Enable Ride Tracking, Get Contacts, and Get Map and Directions. To enable ride tracking, the user should press the Enable Ride Tracking button.

Design Decisions

Prototyping

• Users were concerned with safety, something that we had egregiously failed to address in the carpool search portion of our paper prototype. While originally users could search for any carpool and look up potential carpooling partners' addresses without even logging in, the current version of our site requires the user to input an ID code (that they should have received from the activity instructor) in order to search for their activity. In addition, users cannot view other users until they have logged in.
• Our original interface for swapping dates, which was merged with the My Carpools tab, was very confusing for users because it lacked explanation and was not intuitive. To fix this, we decided to move the swapping interface under its own separate tab because 1) we predicted that it would be a commonly used feature, and 2) if it had its own tab, we would have more space to briefly provide instructions.
• The original form for sending swap requests did not include the names of the other users with whom the user would be swapping because we did not think that information would be relevant. However, most test users indicated that they were interested in knowing who they would be swapping with, so we decided to change our form to include this.
• The original form for accepting swap requests was inefficient because it involved multiple steps, which were somewhat redundant with each other. We decided to condense the form into a single step.
• For the web app overall, we noticed that the ordering of the tabs from left to right was important; users stopped scanning once they thought they had found what they wanted, failing to realize that we had included shortcut tabs further to the right. We decided to reorder the tabs so that shortcut tabs, such as Next Date and Swap Dates, would be located further to the left and thus appear more immediately obvious to the user.
• In the paper prototype of our mobile app, the option to enable ride tracking was confusing for users. The original wording on the button was "Track Ride," which didn't make sense because users couldn't understand why they would want to track their own ride. To fix this, we changed the wording to "Enable Ride Tracking."

...

• For the Next Dates tab, one of our evaluators suggested that we remove the Confirm Date button and change the Swap Times button to a link that said, "Can't make this time? Try swapping." We agreed with this suggestion because we predicted that a lot of parents would forget to confirm, which would only lead to confusion; we agreed that changing the button for Swap Times was a good idea for the sake of external consistency with other web apps.
• One of our evaluators pointed out the safety concern of not being able to see outgoing swap requests. They also complained that the interface was not as intuitive as it could be. We decided to redesign the Swap Dates tab to closely resemble Gmail's interface, so it would be more intuitive for users by taking advantage of external consistency. Users can now keep track of outgoing requests by viewing My Sent Requests.
• Both evaluators pointed out efficiency problems with not being able to easily access the user's full schedule. We decided to add a separate tab for this, My Full Schedule, so that the user would be able to find their calendar easily.
• For the mobile app, one of our evaluators suggested that we add more functionality to the mobile app so that it would more closely resemble the web app. We realized that they had not understood that the intended purpose of the web app was merely to allow users to enable ride tracking. We changed the title of the mobile app to "Ride Tracking App" in order to make this more obvious.
• In studio, a classmate pointed out that the home screen for our mobile app looked identical to the screens for the carpools; the only difference was the text on the buttons. We decided to invert the background colors for the carpool screens in order to establish a contrast.

User Testing

Implementation

Overview

Both our web app and mobile app were implemented with HTML, CSS, JavaScript, and jQuery on the front end; we also used Twitter Bootstrap to make our design look more clean and professional. For the back end of the web app, we used Python because the majority of the team had substantial experience programming in Python; we chose to use the Django web framework because it is widely considered to be the most popular web framework for Python, and we thought it would be a useful learning experience. We opted not to implement a back end for our mobile app because we knew we would not need it in our tasks for user testing. We deployed our app with an MIT scripts account because it would be easier to set up and would also be free of charge.

We used Django to create our SQL database, which we used to keep track of information for users and carpools, amongst other relevant data. We then used the Django template language in our HTML file in order to display the data we pulled from the database for each user. The calendar was implemented with FullCalendar, a jQuery plugin by Adam Shaw. For displaying the maps and directions for each carpool, we used the Google Maps API.

Problems

Our form submissions don’t work. We had realized that we would need to use AJAX to prevent page refreshes upon form submission. We had made significant progress towards implementing this; however, we discovered that pursuing the AJAX route would require us to rewrite all of our Django template code to HTTP Requests. As the deadline was quickly approaching, we did not have time to do this. Instead, we opted to make our front end function as though user’s actions had succeeded despite the changes not showing in the back end. This temporary, hacky solution could potentially cause confusion in user testing should the test user decide to logout and then log back in because their actions were not saved in the back end.

Evaluation

Users

User A

• -How we found him/her-
• -How representative he/she is-

...

• -How we found him/her-
• -How representative he/she is-

Briefing

Thank you for volunteering to test our prototype for 6.813/6.831 User Interface Design.  Our website is a tool designed for parents of school-aged children to coordinate carpooling for school and after-school activities. Our goal is to create an easy-to-use interface that makes it easy to set up carpools, helps users keep track of commitments, allows for scheduling flexibility, and ensures the safety of the children.

Scenario and Tasks

We have created three roles in which you will play the parts of various parents participating in a carpool.

...

• Task 5: Use the mobile app to allow the other parents to track your drive.

Usability Problems

-Problem Statement-

...