Page History

...

Our design consists of two main pages: one for the child, and one for the parent. In the screenshot below, the main screens for the parent and child interfaces are shown, respectively. In this case, Marge is the parent and Bart is the child. Image Added

From the parent page, a user can create new children accounts, schedule CheckIns, view recent CheckIns, and edit CheckIns. CheckIns are requests for information from the child, which by default ask for the location, plus any other questions that the parent specifies from the child. If there are any ‘Ride Requests’ from the child, those requests will appear at the top of the parent page, where the parent can then mark them as read or delete them.

...

Below, on the left is the screen to edit a CheckIn for the parent. The screen to create a new CheckIn is very similar, except that the only field that is filled in is a checked box for location. On the right is displayed what the child sees for that same CheckIn. The box for location is checked by default, and if the child allows it, then the coordinates of his location are submitted as well. If the parent had checked more boxes, then the child would have more questions to answer, in addition to just location. Image Added

Design decisions incorporated from evaluations

Paper prototyping:#

1. Wording on the buttons is very important, and still something that we have some working to do on. We changed ‘Edit CheckIns’ to ‘Edit CheckIn Schedule’, and ‘Send CheckIn’ to ‘Send CheckIn Now’ (the functions of the buttons did not change; only the wording). We changed the wording to ‘CheckIn!’ on the submit button for child CheckIns, as ‘Submit’ is just not as fun. 
2. As pointed out by one of our testers, parents might want to see the CheckIns that the children missed, so we have missed CheckIns appear the color red with ‘(missed)’ next to them in the main display.
3. We moved everything for a new CheckIn onto one page to eliminate the confusion for navigating two different screens for more options.
4. History on front only shows upcoming CheckIns for both parent and child, and recent CheckIns for today and yesterday for parent, as a tester pointed out this would be better (users don’t need as much history as we’re giving them; however, we might want to allow history searches in the future, in case a parent wants to track down when their child checked in on some day in particular).

Heuristic evaluation:#

1. A tester suggested that a child should be able to both send a CheckIn from the main button, but also click on the specific CheckIn from the listing and submit a CheckIn that way, which we incorporated into our final design.
2. Another usability problem that was pointed out to us was that the child does not know how much before or after the CheckIn time they are able to CheckIn. We solve this by having an envelope appear next to CheckIn’s which can be replied to at the moment. This also works towards solving the problem of having a child not know which CheckIn they are replying to.

User testing:#

1. It would be better to make the buttons farther apart, as user testing showed that it is possible to click the wrong button on a phone because they’re too close together.
2. The eyeball on the ‘Recent CheckIns’ listing for parents should be made simpler, since one of the testers could not see that it was an eyeball because of the detail, most likely.
3. Examples in the signup page (for either child or parent) would be very helpful; both parent testers had trouble with this section because they weren’t completely sure what was supposed to go in each text box (the examples could be in the text box and disappear when they click again).
4. A pop-up display of what the child sees would be ideal so the parent sees what they are sending exactly.
5. Messages other than questions would be good, since a tester thought that the ‘Other’ question would send them a message, rather than ask them a separate question.

...

Collect the usability problems found by your user tests into a list. Assign each problem a severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for the problems.

User 1: Parent
Problems:
Add child screen# screen

1. Button naming (help and documentation, minor): user was unsure what the difference was between ‘Display Name’ and ‘Username. Might be better if the ‘Display Name’ description included an example (‘John Doe’) and the user name did as well (‘john123’).
2. Email description (help and documentation, minor): user entered her own email instead of the child’s email. This could be cleared up with a description and/or an example on the side (‘Your child’s email address’, e.g., ‘child@example.com’). We didn’t have our users sign up (we just had them be Marge), so this might be why she thought this should be where she would enter her email address, since she didn’t do it before. (User tasks were changed to reflect this.)

New CheckIn# CheckIn

1. ‘Other’ text box (cosmetic): text box might be a little small.

Viewing/Editing CheckIns# CheckIns

1. Time format (visibility of system status, major): the time display doesn’t show up properly on Chrome (works fine on Firefox), and the user only had Chrome on their system, so she couldn’t tell what time a CheckIn was at. The user was also in a different time zone, which caused some other timing issues that could be corrected.
2. ‘Edit schedule’ button (consistency and standards, minor): user thought that she had to click this button; did not see the edit button (the little pencil) until later to edit a single scheduled CheckIn.
3. Eyeball on recent CheckIns (consistency and standards, minor): user had poor vision and could not tell that the eyeball icon was an eyeball right away. A less detailed eyeball could fix this problem.
4. Repeat button functionality (consistency and standards, minor): user wanted to put in a start date for a repeat event, but it defaults to the current day. Not graying out the date (which we did to show the user that the CheckIn would not occur on just one day) would prevent this, but might cause other problems.
5. Today/tomorrow display (good): user liked this feature.

User 2: Parent
Add child screen:#

1. Signup Screen (minor, help and documentation): User took a while deciding on a username and password. It might be useful to have some kind of description when you mouse over it, or something that assures you that there is a way to retrieve your username or password.
2. Email field in Signup Screen (good, safety): The user entered something that was clearly not an email address in the email field. This was caught.

New / Edit CheckIn:#

1. Now button (minor, visibility): User was not clear what the now button did, since she thought that the time after later applied to both buttons. Also, the date field is initially blank. It would be helpful to have the date and time initialized to the current date and time, for new CheckIns, or to gray them out more intensely.
2. Which child confusion (major, visibility of system state): User initially went to create a new CheckIn for the wrong child. She was able to correct this the first time because the child’s name is displayed on the page. However, in some later steps, she was creating CheckIns for the wrong child.
3. “Other” button (minor, learnability): User was unclear about what to do with the “other” option. She was typing messages to the children, instead of asking different questions. She also was unclear about how the children receive the questions. It might be worth it for us to include a place for parents to include a message to their children (it might not be a bad idea for children to be able to include a message to their parents as well).

Viewing/Editing CheckIns:#

1. Inconsistent state (minor, efficiency): After creating a new CheckIn or editing a CheckIn, when you return to the main page, you return to the tab that appears first, regardless of which child you were working on.
2. Button naming (cosmetic): User suggested using different names for Upcoming and Recent Check-ins, because requests are not the same as responses.

User 3: Child# Child

1. Feedback (visibility of system status, minor): the user said that she would have preferred feedback after sending a CheckIn to make sure that it was sent successfully.
2. Button size (user control and freedom, minor): user accidentally hit the wrong button on the main screen because they were too close together on the phone. This could be easily fixed with some padding on each button div.
3. Feedback (visibility of system status, minor): when user clicked on the wrong button, she did not realize that she had and sent a different CheckIn than she intended.

...