Design

Navigation:

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 tex 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.Design Implementation

Implementation

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.

...