ChildFeed - GR2 - D1

Design 1: Adaptive Direct Manipulation UI

The General approach of this design is to provide an interface that adapts to different form factors (by adapting to different screen sizes), allowing the pages to be used and feel ‘native’ on workstations, laptops, and mobile devices. The design will also feature direct manipulation through mouse, touch, etc., in an effort to make different aspects of the UI, especially with regards to data entry and visualization, easier to use and understand.

General Design

Before we get to the storyboard, the general concept of this design needs to be explained. ChildFeed will have two separate (though possibly consistent) UIs that face two different user groups. The first is the UI facing the daycare worker, allowing said worker to share pictures and stories, and status reports of different children in the daycare. The second is the UI facing the parent or guardian, where the child’s status, stories, and pictures can be viewed through a feed.

Design Principles

The design aims to be learnable by being conversational. Most section headings and labels will be informal and conversational, making it clear to the user what is being asked for. For instance, the "drop off" screen that daycare workers use to show which children were dropped off or picked up to the daycare is headed with "Who's here?". Similarly, when a daycare worker wishes to share a story about a child, simple and conversational language is used: the heading is "Share a Story" (not 'status', 'item', 'feed update', etc.), and button labels are simple: "Who?" "What?", etc.

Affordances

Some affordances of the design are also not visible in these low-cost, low-fidelity design sketches. Some clickable items will prompt the mouse to change cursor, and some editable text will appear in soft rectangles and trigger a mouse cursor change on hover. I attempt to communciate other affordances, such as checkboxes, buttons, etc., however these can only portray their true function once implemented in a higher-fidelity prototype.

Daycare Worker's UI

The daycare worker’s UI framework is shown above. The different parts of the storyboard will go through the box labeled “content” in the illustration shown above. In the UI, we will be able to navigate through different parts of the web app through multiple levels.

As you can see, the app is scalable and the same “content” box is available to be viewed on screens of different sizes and fidelities. Depending on the size and fidelity of the screen, we can have one of the three interfaces shown above. Notice that, for the most part, the design of the “content” region is the same. Some minor adjustments, however, such as changing the number of objects tiled per row, etc., will be made from size to size to ensure that the design is usable on all form factors.

Child Selection

One of the main UI elements that will be used in this design is the Child Selection component. This is sometimes a page on its own (i.e. is displayed in the "content" portion of the above UI), buts sometimes appears as a modal or popup. This element allows different children to be selected for one purpose or another. The example used above shows how this component will be used to specify who is here and who isn't. I will be explaining how this ties to the storyboard later.

The tiling seen in the image above is also representative of how information will be displayed in this design, from the daycare worker's perspective.

Parent's UI

The parent’s UI is shown above. Here, we can see the main aspects of the interface. The feed takes the center stage in the parent UI and most aspects of the storyboard will revolve around the feed. Notifications appear at the top of the page in larger screens and the feed's density changes with screen size. The high-fidelity version shows the entire story in the feed, but with a small image thumbnail that can be enlarged by clicking on the image to view a bigger version. The medium-fidelity version shows a more concise feed with smaller thumbnails, that expand into the full story when tapped on, on the side of the screen. This includes a larger image and the complete text. The low-fidelity version shows a similarly-concise feed with small thumbnails, also expanding to the full story when tapped on, but on a different page.

Contrary to the daycare worker's perspective, the parent's view has more emphasis on feed entries, laid out in rows, as opposed to tiles of children. This is because the experience of the parent is focused entirely on the child he is caring for.

Notice that a parent can have more than one child that he or she can look at, and this is achievable by clicking on the name of the child or the "V" arrow next to it.

Storyboard:

Illustration	Step	Description
	Paul drops off Chuck; Dan signs Chuck in	The child selection page is an easy tiling of "entries" of different children that Dan has control over. Each entry contains a checkbox that toggles whether or not a given child is presence right now. The question, "Who's Here?" is informal, conversational, learnable, obvious, and understandable, and Dan understand what it means and chooses to select all the children that he sees at any point in time. To enhance the usability of ChildFeed, each time the "Who's Here" screen is loaded, the entries are sorted such that the kids who are "here" appear first, followed by kids that are not here. This makes it easier for Dan to see both kids who are here and not and check them on or off.
	Patricia checks the account; sees notification of Chuck being dropped off	Patricia checks the account on her tablet and sees the latest feed items. One of these news feed items is a "drop off" action that indicates that Chuck was safely received by Dan the Daycare Worker.
	Dan shares photo story of Chuck finger painting	The conversational layout is obvious here. The dialog attempts to flow naturally and extract the needed information from Dan through the questions it asks. Dan can indicate who is there by typing into the text box and benefiting from Autocomplete (in a manner similar to that of the "To:" field in GMail, Hotmail, etc.). However, Dan can also click on the "+" icon next to the textbox, where a Child Selection modal/page pops up and allows Dan to select the relevant children for the story. *Note that the "publish story" button should say "share story".
	Patricia checks the account; sees notification of Chuck's new story	Now being at her workplace, Patricia checks the account from her laptop, on a bigger screen. This allows her to see more information on the stories, and sidebar information with the latest report about Chuck from the previous day, and some of his eating habits history.
	Dan and his coworkers go through the children in his ChildFeed app, logging what they all ate and how much they ate	Dan achieves this by listing the meals provided in lunch. This is done by clicking on the "Add other meal..." (or "Add meal...") text box, which makes it an active item. Pictures can be added to each meal, also. After information on the meals provided is entered, Dan needs to tell ChildFeed how did everyone eat. Dan can choose not to answer the question by clicking on the checkbox next to a child's name, to deselect that child from the report operation. Dan answers questions for each child, by selecting what that child ate from a dropdown box (which Shift+Click can be used to select multiple meals), and a slider to indicate how much the kid had to eat. This slider is labeled by "Too little" "Just Right" and "Too much", but with the ability for the slider to go smoothly anywhere on that scale. The app also leaves a space for text comments. This is shown by the "Comments" label on the child tile, with a clipped part of a textarea underneath it. This has the affordance of a textarea and behaves like one when hovered over. Upon getting focus, the tile floats over the screen (while remaining in its own position) and expands to show the entire textarea, allowing the user to enter data there. Upon losing its focus, the interface returns to its previous state. One done, Dan will publish this information.
	Paul and Patrica notice that Chuck did not eat much today, and go back to check his eating history, and notice that he doesn’t eat very much whenever they serve macaroni and cheese	The history view shows a graph history of different trends that are selected from the right-hand-side bar. The trends that are selected are the same as those entered in the daily report or food report, and include any value or metric that is decided with a slider in this design. Hovering a certain trend line point will result in a floating message popping up that describes the relevant activity at that point in time. For example, hovering over a point on the food trend line will tell the parent any comments Dan had on that day, as well as what the child ate on that day. For this example, Paul and Patricia look at the low points in the food trend line and hover over all of them, noticing that Paul always eats less when macaroni and cheese is being served, and thus arrive at this conclusion.
	Dan puts all of the kids to sleep and sits down and logs information about each child’s mood, temperament, overall energy, etc.	Dan's daily report is a simple tile of user information with sliders and comment boxes as described for the lunch entry.
	Patricia checks ChildFeed for overall information on Chuck’s wellness and notices that he is not in a very good mood	Patricia views the daily report screen for today's date. She can see a wealth of sliders indicating Chuck's mood today, as well as stories that involve Chuck that took place today, and any additional comments given by Dan. Different trend lines also show in the sidebar (if viewed from desktop), with today's settings visible and thus easily comparable. The mobile UI to view the daily report is also shown in the bottom part of the image.
	Patrica picks Chuck up; Dan signs him off	Dan will deselect chuck to show that he has been picked up by his parents.

Analysis:

Learnability

Advantages: the design has some learnability thanks to the internal consistency of its design elements. Components like the child selection toggle, for instance, appear in multiple locations and feature similar, intuitive ideas, like toggles, check boxes, etc. The design also attempts to have affordances for familiar items, such as buttons, checkboxes, textboxes, and editable fields. The language of the dialogs is understandable and explains the purpose of each screen to the user.

Disadvantages: No clear workflow is required. The purpose of some links on the main page is not explained. For instance, once we get to the "Who's here" dialog, it is clear what Dan needs to do to finish the task. But how does Dan know that he needs to go to "Who's Here" to begin with? What compels Dan to go there at the beginning and end of the day? Similarly, what tells Dan that he should publish the food report at a certain hour of the day and the final report at another point?

Efficiency

Advantages: All tasks are either keyboard entry or pointing tasks, there are no steering tasks (a slider can be achieved by either pointing to the end location, or by a steering tasks with a wide mouse capture). Autocomplete when entering a child's name. Sorting and grouping of child entries during drop off and pick-up. All of these aspects of the design make it faster and easier for an experienced user to proceed with work. Bulk tasks for publishing information on children also enable this.

Disadvantages: Bulk tasks still require editing each individual user for either comments or changing the slider, this can be time consuming for a large amount of children for a worker.

Safety

Advantages: Undo can be provided for textbox and textarea entry, as well as the publishing of stories, etc. Similarly, most tasks can be recovered from easily, such as toggle tasks, where Dan can re-toggle an unchecked child who should be checked. From the parents' perspective, the lack of data entry means that there are very few places where errors can take place, and where recovery would be an issue. One area where mistakes can take place in both places is navigation, and as long as all navigation areas are exposed and the user can easily return to the page they intend to be on, the interface is safe.

Disadvantages: However, accidentally navigating to another page means that some data that is being worked on might be lost. For example, if the user is doing a bulk data entry, then that information is not processed until the user clicks on the "Publish" link at the end of the page. What happens if a user accidentally clicks on another link on the page before publishing? Is all of the data lost? In some modern browsers, form data is saved and can be retrieved by hitting the back button. However, we cannot count on that for all devices, and especially for non-standard form input such as sliders, or elements that are used by javascript. This is a general disadvantage of a web-based layout, but a disadvantage that can be mitigated through more careful design and iteration.

Child pages