Design

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.

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).

Evaluation here

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 us, but which weren't quite as obvious to our test users, 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.
• 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.