Page History

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.

Evaluation

We conducted all of our user tests in a similar way to how we did our paper prototyping user tests. We gave each the same briefing and the same tasks that we used previously, and added an archives task. We chose not to use a demo because we felt like our tasks and interface were simple enough to not need them, and we were able to gain information about a user’s first impression.

Initially, our group planned to conduct user tests on three daycare workers in the TCC located in the Stata Center. Unfortunately, although the daycare gave us positive feedback about the idea, only one worker volunteered, and we have been unable to schedule something with him. However, were able to find two nannies and a babysitter.

Our first nanny was very helpful in her feedback . She is a 31-year old mom and current nanny of 3 year old girls. She described herself as pretty comfortable with computers, but not ‘techy’. She mentioned that she often tries and is sometimes unsuccessful to give the girl’s parents a better idea of what goes on in her household daycare. Although she is not a worker at a larger daycare, she is very typical of our target population. She gave us useful suggestions regarding both the usability and usefulness of our website. For example, she mentioned that the ‘energy’ of a child is hard to quantify. She said “energy and mood changes so much throughout the day for a young child that it might be useful to break up into time-frames, such as ‘pre nap’, ‘post nap’ and ‘post lunch’.”  She also mentioned that ‘potty’ could become more useful to a parent by noting how many times the child went, and whether or not he/she pooped or not. She currently jots down ‘stories’ about the girl she babysits for the parents in a notebook, and would like an easy way to do that. Our nanny wishes she was better at taking pictures and sharing them, and felt that having an tablet would make this task a lot easier. Overall, she really liked the site and found most things intuitive.

Our second nanny was also very helpful and close to our target user population. She is a 24-year old, who has been a nanny and has taught daycare aged children in school. She feels very comfortable with computers. Again, although she is not a current daycare worker and is not in our target user population, she has a very similar perspective into what a worker might want in such a website. She commented that as a care provider, at the end of the day when the parents ask what happened, it's hard to remember which child did what. She thought this website would be helpful to keep track and also serve as a way for parents to know without having to ask each day. She mentioned that this would be helpful in writing quarterly reviews for the children, which is common practice in her job caring for 3-year-olds. She really liked the filtering options available in the archives page, especially by child. She imagined this being helpful to see what each parent would see. She commented that the 'mood' slidebar indicator could be improved by turning it into a flag that signals a problem. This could be used to send a notification to the parent of a problem. Overall, she thought the website was very useful, and could be a selling point for a daycare that utilized it. 

Our third user was a 22-year old student with years of babysitting experience as a teenager. She identified herself with medium computer experience. She is probably the farthest from our target daycare worker population, and did not have as much to say about the usefulness of our website. However, she mentioned that she really liked the ‘share story’ idea, and could imagine how a parent would love to hear stories and see pictures. She had good comments about the usability of our site. Overall, she found Childfeed very intuitive and usable.

Some usability problems that our user tests highlighted:

Reflection

We learned a lot through out the process of designing and redesigning ChildFeed. One of the main lessons from class that we learned first-hand was the difficulty of finding an optimal balance between efficiency and learnability. One of the main problems we found during testing is that often when we tried to make a feature more efficient, we ended up sacrificing learnability and vice versa. For example, our original design for Check-in/Check-out was more efficient than our current one, but it was much harder to learn how to use. However, as we continued to test and evaluate our designs we steadily progressed towards better balances.

Another lesson from class that we learned over the course of the iterative design was the difficulty of predicting how users would interact with our product. There were many times where we would take for granted that a particular feature was simple and easy to use, but user testing revealed otherwise. For example, we thought that users would easily understand how to use our Report Lunch feature without any assistance, but a number of users needed to be shown how to use it.

We do not have many regrets when it comes to our decisions regarding design process. For the most part, we used concrete evidence and critical analysis when deciding the direction of our project. However, there are a few things we would do differently if given the chance to redo our design process. In particular, it would have been in our best interest if we fully decided which features we wanted to implement in our final project. We did not entirely decide how we wanted to make the daycare worker’s previous posts visible until late into implementation. Had we decided that we were going to implement it in an Archives page early on in the design process, we could have tested a design during paper prototyping and we would have had had more information to work with and more time to implement.

We do think that it would have been nice to fully design and implement the parents’ side of ChildFeed, but we do think that we ultimately made the right decision in not doing so. During the design process, we quickly realized that just implementing the daycare worker’s side of ChildFeed to the level of usability that we wanted was going to take the entirety of the amount of time we could afford to the spend on the project. Thus, we felt that if we fully designed and implemented the parents’ side of the interface, we would have ultimately sacrificed some usability on the side of the daycare worker.

One risk assessment that we made a mistake on, was the risk of not finding daycare workers that would be willing to test our product. We assumed that that daycare workers would willing to participate in our user testing because ChildFeed is directly related to their profession and requires minimal time to test. Thus, we waited until we were done implementing ChildFeed to email the daycare workers in the TCC in the Stata Center. Unfortunately, they did not show nearly as much enthusiasm as we expected. Had we known that there might be difficulty in getting volunteers for our user testing among daycare workers in the TCC, we would have started the process of finding test users among the daycare worker population earlier. However, we believe that we were still able to more-or-less accurately evaluate our project with a less representative user population. We believe that our choice of testing ChildFeed on users who had experience in childcare gave us a good sense of how well daycare workers would have been able to use our interface.