ChildFeed - GR6

Design

Home Page

For this page we tried to have big logos, that the user should associate with each activity (these logos are also used in the archives page). The archives page does not have its own button because it is not an action (in all the other pages the user is actually going to submit some information while the archives page is just for consulting). In the first iteration the logos were not buttons (just images), but in the heuristic evaluation some users mentioned that the logos did not afford clicking. In the second iteration we put the logos in buttons and we made them responsive.

Check In/Out

The design for this page was mostly decided after the paper prototypes. During user testing with the paper prototypes we realised that the symmetry of the check In and check Out actions created some confusion in for the users. In the Check In/Out page the daycare worker continuously builds a set of children that are at daycare in a specific day. At first the only way to check in/out a child was to drag the Id Card of the child from one side to the other. After the heuristic evaluation, we modified the page so that a child could be checked in with a double click on the Id Card, and we also modified some CSS so that the Id cards would better afford dragging. One thing that is different on this page from all the others is that as soon as the daycare worker finishes dragging an id card from one side to the other the action is recorded (the user does not have to press any ‘submit’ button). Due to this we display a toast message at the end of the dragging action that informs the user that the action was recorded. In addition as soon as the user checks in a child, the label with the last checked in date is updated to: “Just Now”. This label will display the last checked in date in a few different ways:

This page works very well on an iPad (or any other touching device) as a lot of actions on the iPad are “dragging” actions. Another important detail is that as the screen/window size gets smaller the id cards keep getting smaller and loosing some elements (picture, last checked in label) so that this page is still usable in small windows/screens (this is specially useful for devices such as tablets).

Share Story

Users found this page fairly straightforward to use because it is essentially equivalent to sending an email/message. One of the main design decisions we had to make for this page was how the user was going to select which children the story was about. We allow for two different ways:

Report Lunch

For this page we made the assumption that most times, all the children ate the same meal except for a few kids who might have some special dietary constraints (Eg. Allergy to cheese). Therefore, we wanted to make this page efficient, in the sense that it should be easy for the daycare worker to say that most children had the same meal, but we also wanted to accommodate for the cases when a few children had a different meal for some special reason.
We came up with this design after the paper prototypes. The changes that we made after the heuristic evaluations to this design were minor, but nonetheless important. One of the more relevant changes was adding animations to indicate that the options in the dropdown menus had changed in some way.
The drop-down menus glow every time a meal is added to the list of available meals, a meal is deleted from the list of available meals, the fill all button is pressed.

Report Daily Log

This page is fairly similar to the Report Lunch page. We decided to use sliders because we wanted the user to have a good amount of options (the sliders have 5 states), but we also wanted it to be efficient to report information about a good number of children at the same time. Sliders also have the advantage of being very glanceable. One thing that users found helpful were the labels that appear on top of the slider thumb.

Archives

The main purpose of this page was to allow the daycare worker to have a sense of what he has submitted about each children. Through the archives page the daycare worker can check if he has not submitted events abour a particular child in a long time. We use the same icons we use in the home page, which allows the daycare to quickly identify the type of events that he is looking at. Because there will be a fair number of events reported each day, we allow filtering by type and by children.

Implementation

Front-end

The front-end of ChildFeed was created with HTML5, CSS3, and jQuery. All presentational aspects of the website was implemented in HTML5 and CSS3, no JavaScript was used in displaying anything (though jQuery is used to generate common components and inserting them into the DOM). A number of CSS3 properties used were not supported by Firefox, such as box-sizing, which causes ChildFeed to render incorrectly on Firefox. This was not an issue for this project, since we were allowed to restrict ChildFeed to a single browser, Google Chrome, which we did, and which allowed us to use some of these advanced CSS3 features.

Along these lines, the UI of the website is fluid and responsive, meaning it responds to changes in screen size, allowing it to resize its components, and even reorganize all of its UI components and layout to fit the smaller screen size. ChildFeed works on large desktop and laptop screens, and scales down to medium laptop screens, then iPad screen sizes, and down to an iPhone screen size, looking presentable and highly usable at every intermediate step. The responsive layout is achieved only through HTML5 and CSS3, specifically using CSS3 @media queries which target different screen widths, combined with the <viewport> HTML tag which defines the width of the screen relative to the device’s screen width. No jQuery or JavaScript was used to aid the responsive part of the interface.

Meanwhile, JavaScript and jQuery was used for a number of reasons:

1. to write code that generates a Child’s ID card (for Check-In/Out), Lunch Log card (for Report Lunches), Log card (for Report Daily Log), and Archive entry (for Archives). This is done using Javascript closures to create an initializable class for each of these abstract objects, and implementing an “insert” function which uses jQuery to insert the proper HTML of these cards into the desired containers.
2. to implement the “Report Lunches” meal adding, removal, and setting which meals each child had
3. to implement different types of validation, such as disabling form buttons on submit, or not allowing submit until values are interested in some boxes, etc.
4. to communicate with the backend through asynchronous GET and POST requests, and receive responses.

Different jQuery components were also used to implement UI components:

1. jQuery UI draggables for Check-In/Out, along with a jQuery touch plugin to translate touch events to mouse events, allowing draggables to work on the iPad and other devices
2. jQuery UI sliders for daily log and lunch report screens, allowing tool tips to be used with the sliders
3. jQuery UI multi-select for archives, allowing the user to easily filter through archives by opting to view archives for subsets of the children, or events
4. jQuery UI modal dialog, used in the share story screen to allow users to refer to a list of children
5. jQuery tokenized input plugin, used in the share story screen to allow users to search for children  by typing part of their names and autocompleting, removing individual children, etc.

Back-end

The Templating System

A very simple templating system was built from scratch using PHP which uses a general page skeleton and inserts into it the proper components (javascript, title, content, and sidebar, if available) according to lookup which looks up the current page queried from a 2D array of possible pages and the files and values that need to be substituted.

The Database System

The website has a number of mySQL tables which we have access to from our PHP files, hosted on scripts.mit.edu. A “utilities” directory exists, with a number PHP files which can be called (through GET and POST requests) to do certain actions or return certain information.

Each file is a model, responsible for one of the mySQL tables. Each model receives and action attribute, and some extra attributes if needed and returns a jSON of the results, which the jQuery parses and presents to the user.