Design

The main content of Pack Planner is the interactive calendar which users see upon login.  During the initial paper prototype designing, we experimented with many different calendar representations ranging from a strict metaphor of a calendar, to a representation so simplified it was simply a list of events.  Ultimately something in the middle was chosen.  The focus of the calendar is put around the week, as we found that is what users mostly focus on. On load, the current day is expanded to show a list of tiles, each tile representing an activity planned for the current day.  During GR1, interviewees said that they most often look at their calendar to quickly remind themselves what needs to be done on the current day, so we made our interface cater to this quick current day view.  Users can navigate easily within the week by clicking the vertical tile for a given day, or use the previous/next day buttons at the top. Furthermore, the mini cal on the left hand side of the screen allows a user to more efficiently navigate to a day that may be further in the future, or simply help the user by alleviating the need to recall the structure of the given month.

Within the current day, Tiles are listed to show all the events of a day.  This is where the simplicity of the interface shines.  Instead of trying to show complicated timelines, a simple ordered list is used to display the tiles.  Furthermore, each tile is color coded to give the user the best information scent as to the plans of each family member.  The tiles are specifically designed to help parents arrange the driving to and from their children's events.  In the middle of the tile are three buttons, a 'driving to' button and a 'driving from' button with a button in the middle with a car symbol on it.  The 'driving to' and 'driving from' buttons are used to quickly assign drivers, or give the user a chance to reach out and ask a contact to drive.  These 'driving to' and 'driving from' buttons are turquoise, the main color of the interface, when a driver is assigned.  However when a driver is not assigned, these buttons are red to draw the users attention.  Because of the simplicity of tiles, it is difficult to give the user a good idea of when two events overlap.  However, the user should most often care if events overlap, only when driving must be coordinated.  So by utilizing the harsh red on the 'driving to' and 'driving from' buttons, the same goal can be achieved as the user's attention is attracted to events which do not have an assigned driver.

Modals are used across this interface to minimize the number of screens, thus simplifying the user's mental model.  The biggest challenge with the modals, particularly the event creation and editing modals, was creating efficient inputs for all fields.  For simple fields like title and location, typing into the text box is all the user needs.  But inputs which must be structured, such as time or date, are more difficult to implement safely and efficiently.  Ultimately, a date time picker was utilized for these fields, however some issues were encountered by using these input methods.  To improve overall interface, this is the first place improvements should be made as it is most confusing and possibly harmful.  Lastly, when assigning drivers in the modals, type ahead was utilized to make the process more efficient.  The reach out modal was designed to quickly and efficiently reach out and ask friends to drive for an event.  The reach out modal can be accessed by clicking the middle car button on a tile, or by clicking "reach out" within the drop-downs of the 'driving to' and 'driving from' buttons.  This modal is a list of the user's contacts, each contact is clickable which checks a box next to the user's name to indicate they have been selected.  After a user selects as many users as he or she wants, the user clicks "send driving request" and all those checked will receive a message asking for availability to drive for the desired event.  The simplicity of this modal increases the chance of a user finding a friend to help drive as it enables the user to ask more friends by lowering the barrier to request help.

Lastly, the contacts page utilizes a simple design to give the user the basic functionality needed to intact with others within Pack Planner.  The contacts page acts as a user's physical contact book would.  There is one entry per family, and when the entry is clicked, information is displayed on the right pane to show the family details including the parents' names, the children's names, and other useful information like email address and street address.  From the contacts page, a user can send a message to a contact, perhaps just to communicate about an upcoming event, or to plan a carpool.  Furthermore, a "find friends" button is present to search for the user's other friends which may have recently signed up for pack planner.

Implementaion

We used the Django Web Framework to implement PackPlanner. For the main pages, we simply have links that query the Postgres database for the appropriate information for the current user. We use this information and the Django template tag system to create JavaScript objects that mirror entries in the database. Then, we build the UI from these javascript objects, encoding onclick functions that use object IDs to determine which objects are involved in the user's actions.

Our design focuses on using modals to keep the user from continually changing pages. For this to happen, we had to use AJAX to make a lot of our requests. When a user action requires a database change without a page refresh, we use AJAX to send a request to the server, often to a different URL containing the action name and the object ids. The AJAX requests return JSON objects that indicate the success or failure of a particular database transaction. If the transaction is a success, the response may also contain information used to update the JavaScript objects for correct completion of further user actions. If the transaction is a failure, the JSON response contains some information about what kind of failure to help with safety (although we would like to increase the user safety currently available in our system).

We used Twitter Bootstrap to help lessen the amount of work we would need to do to make the interface visually appealing. However, this decision did come with some tradeoffs. First, we used many Twitter Bootstrap widgets to be consistent, even though some of them did not quite fit into the needs of our system, particularly the use of JavaScript objects and the scaling of the event calendar and minical. We were forced to make some "hacky" solutions that we would have preferred not to do. If we had more time to work on this project, we would look into using other UI toolkits that integrate better with Django and our system as a whole.

Evaluation

Briefing

PackPlanner is an interface designed to allow parents to easily create, update, and share events for their families. PackPlanner helps keep parents organized by providing a single space to manage their calendar and who is driving their children to and from various events.

You, Mary Smith, are a mother of three children, Andy (12), Barry (10), and Christine (7) with your husband Nick. Christine comes home from school with an invitation from her friend Daisy to a birthday party this Saturday at 2pm.

First, add this event to your calendar without specifying who will drive (Task 1).

After adding the event, view the calendar to plan how to get Christine to the party (Task 2).

After viewing this event, you see that Andy has a soccer game at 2pm for which you are planning to drive. Additionally, Barry has drama rehearsal at 2pm for which Nick is planning to drive. Unfortunately, the soccer field, drama workshop, and birthday party are far away from one another, and you and Nick will not be able to drive all three children to their events. So, use the website to reach out to other parents or relatives to help getting all three children to their separate events (Task 3).

Results

Users

Our target population are parents who have multiple children. In particular, we are aiming towards parents with most of their children too young to drive themselves to the events they are a part of and depend on other drivers to take them to and from these events. These parents need an effective way to manage their children schedules within their own daily lives.

• User 1: Father of Five
  User 1 was actually one of our parents, in fact, an interviewee for GR1. With one child capable of driving and with his/her own car, the other four are still too young to drive themselves. Even though his wife is very involved with the families events and obligations, he is the main in charge of managing all the schedules in the family and making sure everything is organized properly.
• User 2: Single Mother of Three
  User 2 is a parent of one of our close friends. She has one child that is involved in many extra-curricular activities and sports. As a working mother, she depends on reaching out to other parents and/or neighbors to help carpool her child to the events he/she so actively participates in.
• User 3: Newly wed Couple with Two Children
  User 3 is actually a joint user of two parents that have two children. They are two relatives of a group member. Since our interface will optimally be used by both parents, perhaps simultaneously, we felt they would be a suitable user to test our application. Their children are quite young and require their parents to plan, organize, and execute their activities.

Usability Problems & Observations

Briefing each user with the specifics above, we asked them to complete the tasks as thoroughly as they can. They were provided the username and password of Mary Smith to access her account and execute the tasks listed above. In order to conduct these tests with live feedback, we used google hangout and screen-sharing to see what they were doing. This allowed us to see exactly what they were doing on the screen as they completed the tasks. Also, we were able to immediately communicate with one another if necessary. Below is a collection of the main problems and observations users had with the interface.

User 1

• (Recognition, Learnability) Slightly confused with wording on "Add event to calendar for:"
• (Usability, Readability) Wrong type of input for time, was not familiar with default format.
• (Efficiency, User control) Preferred Typeahead vs. Dropdown to select drivers for driving to/from sections with even tile.
• (Consistency, Learnability) Confusion between the differences of "reach outs" used, modal from dropdown vs. middle car button.
• (Feedback, Aesthetics) No confirmation of having a selected contact, perhaps fixed by highlighting.
• (Feedback) Indication of reaching out status, not known who has been asked or has responded.
• (Aesthetics, User Control & Freedom) Not being able to toy with different calendar views, zooming in/out with month/weekly view.
• (Feedback) No notification of event creation to immediately see conflict.

User 2

• (Efficiency & Usability) Using text field to enter time/date not working well due to formatting issues.
• (Consistency & standards) The 24-hour mode of the text fields for time is inconsistent with the 12-hour mode for popups.
• (Help & Documentation, Feedback) When selecting driving button within event tile, not known if requests successfully sent.
• (Feedback) List of people already requested is not shown/visible.
• (Aesthetic, Recognition) Colors "clash" among children for event tiles.
• (Recognition, Learnability) Didn't know could add multiple people for "Add event to calendar for:"

User 3

• (Efficiency, User Control, Affordances) Multiple ways to navigate calendar (vertical tabs, buttons, minical)
• (Consistency, Visible Navigation ) Minical not available on all monitor sizes.
• (Learnability) Confusion with names corresponding to calendar filters
• (Usability, Error Handling, User Freedom) Input for time on some modals are disabled if selected from minical or not correct if manually typed in wrong format.
• (Feedback) Need confirmation button when selecting time
• (Consistency & Standards) Listing of children alphabetically
• (Learnability) Confusion about a multi-children event
• (Visible Navigation, ) Sudden flipping of tabs when advancing to next day on last day of week seems extreme
• (Safety) Can't change driver back to unassigned once selected
• (Recognition, Usability) Not intuitive car button within event tile is reach out
• (Standards) Not used to from/to customary format (Prefers there and back)
• (Feedback) Wants highlights contacts once selected and doesn't prefer checkboxes
• (Safety, Defaults) Close button on modals look disabled
• (Feedback) Confirmation on sending a message
• (Internal Consistency) Inputs on modals do not have same justification (left/center/right)

Discussion

Pros

All users liked the calendar representation of the application. The use of colors to represent children specific events and the status of assigned drivers gave immediate feedback and satisfaction. Users saw the uses of the application very beneficial, especially for reaching out to other parents/neighbors/relatives to carpool and schedule events. Navigation within the calendar view seemed easy and simple. The use of multiple affordances added to the ease of navigation. Layout was clean and a tabbed toolbar made finding sections more intuitive.

Potential solutions and Moving forward

Most of the problems resulted from the non-accustomed layout of representing a calendar in the application. Users were more familiar with large calendars with days represented as blocks rather than vertical tabs in a weekly view. Perhaps an option to view a normal calendar may be more helpful. Users also expressed their thoughts and aesthetics and functionality. Images of cars did not make it seem intuitive they represented reaching out to other potential drivers. When selecting drivers or contacts, there was no highlighting so not exactly sure if selected. Also, color scheme of filters for children within and event seemed arbitrary. Potential solutions would be to add help and documentation to the application to help guide users. Also, it may be helpful to add the option of customizing the skin of the calendar and/or colors to filters to make it fit user appeal. There were also some latency, error handling issues. This could be due to the default settings on the backend/frontend used. There were noticeable issues with input for events and time. Refreshing a page can be jarring as it shifts to the current day. A solution may be to go back to some "hacky" solutions to the code and make it more clean.

Reflection

We learned a variety of things about the design process in this project:

• The need for user testing became salient. There were various quirks about our system that were immediately apparent to our test users, but which weren't quite as obvious to us, and we wouldn't have been able to catch this without user testing. Since we are all familiar with the mental model of our design, it's easy to overlook things that may be difficult to understand to outsiders.
• There is a lot of value in sketching out and designing the object models and relationships before beginning implementation. Some of the relationships between objects in our system aren't always that obvious and have some quirks. A lot of time and grief could have been avoided if we had sketched out in full detail all of the different models, their properties, and their relationships to each other, before beginning implementation. To provide some examples: Each person has a user account. Each user account has an associated family member profile, which belongs to a family. Event details belong to a family (so all members in the same family see the same calendar) but there can be multiple event details (including drivers and such) associated with each event (to permit sharing). None of this is necessarily particularly convoluted, but it would've made development much simpler for all parties had we hashed out these models and relationships beforehand.
• As is often the case with most projects, one starts off very ambitiously, and when it comes time to implement and meet deadlines, it becomes really obvious really fast that one won't be able to implement the feature set one desires and needs to scale down. It would have been good, from the start, to begin with a much simpler product with less features (yet still satisfying the core necessities) and scaled up from there if time permits. Having a few too many features left to our engineering efforts becoming spread too thin, with many features not being as polished as they could be. This may also be a consequence of simply the problem we chose to tackle, which would necessarily have required a diverse set of features. Thus, there may have been some value in being more critical at the early stages of which problem we wanted to tackle, and pick one that intuitively might not require a solution with a large amount of functionality.
• In terms of choosing which technologies we work with, though this shouldn't be central to the project, it has a large effect on the amount of time required to complete various tasks. General unfamiliarity with the various technologies used (Django/Postgres/HTML/CSS/etc...) meant that completing relatively simple tasks would take a fair bit of time since one would need to constantly consult the documentation. Not really something we could have done much about, since we picked technologies we were most familiar with, but it couldn't have hurt for our members to have had more experience in them to begin with.