...
Meanwhile, JavaScript and jQuery was used for a number of reasons:
- 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.
- to implement the “Report Lunches” meal adding, removal, and setting which meals each child had
- 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.
- to communicate with the backend through asynchronous GET and POST requests, and receive responses.
Different jQuery components were also used to implement UI components:
- 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
- jQuery UI sliders for daily log and lunch report screens, allowing tool tips to be used with the sliders
- 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
- jQuery UI modal dialog, used in the share story screen to allow users to refer to a list of children
- 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
...
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:
Issue | Page | Type | Severity | Possible Solution |
|---|---|---|---|---|
The lunch sidebar was overlooked when trying to report a lunch. | Report Lunch | Learnability | Minor | We could add tool tips that remind the user to add a meal if they try changing the meal first. We are not too concerned about this, because once the user learns about the sidebar, it becomes obvious to learn how to use. |
The labels "Checked In" and "Checked Out" were confusing to some people. They were mistaken for actions instead of states. | Check In/Out | Learnability | Minor | We could rewrite the labels to be "In" and "Out" to get rid of the connotation with action. |
It wasn't entirely clear that the "Who?" input was tokenized rather than just a normal text field. When the users typed too fast, they can miss the search results causing their entry to not be inputted. | Share a Story | Learnability | Minor | Again, this would cease to be a problem as soon as the user is shown this fact. However, a tooltip could pop up to aid users if the user is unable to successfully add a child. Also, we could make the search results pop up faster. |
Fields like Energy, Potty, and Mood are hard to quantify. | Daily Log | Affordance | Minor | We could make the options for Potty, include a quantified number of times. We could provide extra information on how to quantify Energy and Mood in a tooltip or a help menu. This information could include particular criteria to make quantification easier. |
The "+" in the lunch sidebar was misleading and gives the affordance of a link or dropdown menu. | Report Lunch | Affordability | Cosmetic | Remove it. Possibly have a dropdown menu of previously used lunches. |
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.