Design

Overview

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.

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.

From the child page, a user can send a CheckIn (which includes the child’s location information and any other questions that the parent requested) or request a ride (which will send a message including the reason and the child’s location).

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.

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.

Implementation

Overview

The web app is backed by the standard HTML/CSS/Javascript/jQuery with a Ruby on Rails backend. The app is hosted on a Linux server running Thin, a lightweight ruby web server. CheckIn Events record information about when the parent wants the child to check in and other questions about the child’s whereabouts. CheckIn Responses are tied to Events and hold the information asked for in the Events. Events can be repeating or non-repeating, and therefore an Event can have more than one Response tied to it. Location is pulled from the browser using HTML5 geolocation. Javascript controls the activity of the buttons, testing whether or not a child can check in based on the child’s upcoming Events, and only allowing the child to do so if the Event is within a certain timeframe. A ruby mailer was set up to email the child within 15 minutes of his or her CheckIn, and the mailer was controlled through a script run by Crontab every 15 minutes.

Problems

Using frameworks is a good idea for web development today, but not necessary for the projects in this class. We had trouble integrating the frontend with the backend because the backend was written in Rails, and the frontend was written for the prototype without a templating language. It probably would have been better to have done the entire thing in PHP, something everyone on the team was somewhat familiar with, rather than pick something like Rails that was only known to one of the team members.

Suggestions for future classes

One of the issues that we had was setting up the server to run checkin.mit.edu. While some people in our class have experience with servers, most do not, and it is easy to sink too much time into server setup, which is not useful for learning the concepts presented in this class. It would be relatively simple to set up a 6.813 server that ran each team’s web app on some port, so you wouldn’t even have to set up different hostnames (although that is easy to do through IS&T). The server could host git repositories with a push hook to pull the content to the actual directory on the server where the content was stored, and the users wouldn’t even have to interact with the server at all. The server could have support for PHP, Rails, and other frameworks preinstalled, eliminating other installation issues that we faced as a team. The single server could also help promote students to check out others’ sites, since they would only have to change the URL to some other team’s port to see it.

Scripts, Heroku, and XVM were some of the server options that we considered, but they all had various issues that prevented us from using them (the scripts Rails installer is currently broken; a Rails bug prevented us from using Postgres, which is what Heroku uses; and there were various installation issues with XVM). A dedicated server for the class (I’m sure IS&T would be happy to help) would fix this problem. (If you want to talk more about this idea, please contact us.)

Evaluation

User Selection

Our project serves two different types of users: parents and children. We decided to test two parents and a student not in the class on the appropriate interfaces. We decided to split it that way because during earlier testing (GR3 and GR4), we used people who were more representative of the child classes. The parents that we selected both have multiple children and have experienced situations where having this application would have been helpful to keep track of their children. We chose a freshman from our dorm as the student.

Briefing

Since the main ideas of our project changed little, we used a briefing that is very similar to the one that we used for the paper prototyping task. We are including it here also.

Parents often want to know where their kids are, and kids don’t want to have their parents worry, but kids can’t always answer the phone to verbally communicate to their parents where they are (sometimes, they don’t want to). This often creates tension between the kids and the parents. Our website aims to solve this problem by having the parents’ peace of mind be only a click away. There are two different interfaces: one for the parent, and one for the child. You will be testing the parent interface.

Remember, we are testing the interface, not you! Anything that you are unable to do is our interface failing, and has no reflection on your abilities whatsoever.

Tasks

Parent Tasks
You are a parent.
Task 0: Please sign up for a new account at checkin.mit.edu:3000. Use a dummy email address, please.
Task 0.5: Please add two children to your account named Bart and Lisa; use dummy email addresses, please.
Task 1: You expect Lisa to be home now, but she isn’t here. Please ask Lisa to check in now and ask her why she is not home.
Task 2: You want to know where Lisa was when she last checked in. Please view the details of Lisa’s latest CheckIn and tell us where she was last.
Task 3: You know Bart is out at a party. Please ask him to check in later today at 10pm and ask him which friends he is with, so you’ll know he’s ok before you go to bed.
Task 4: Lisa just joined a soccer team, and so she’ll be getting in late many days because of practice. Please schedule a CheckIn every Tuesday at 6pm for Lisa.
Task 5: You decided that you actually want Lisa to check in instead at 7pm on Tuesdays. Please edit the CheckIn.
Task 6: Please tell us if there are CheckIns scheduled for tomorrow, and if so, when they are.

Child Tasks
You are a child, and your name is Bart.
Task 1: You are using your phone when suddenly you get an email from the app. Your goal is to let your parents know that you are ok by replying to their CheckIn request.
Task 2: When is your next CheckIn?
Task 3: You realize that your next CheckIn is soon, so you decide to CheckIn now so you do not need to worry about it later.
Task 4: The party you are at starts to get crazy, and you would like to leave. Please request a ride.

Results

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

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

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

Viewing/Editing 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

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.

Reflection

Our group disagrees on how much time we should have spent on the prototype. One member thinks that we should have spent more time. Another thinks that the amount of time we spent was fine but that we should have thought more about how we were going to connect it with the backend before starting so we would not have to redo good work. The third member of our team thinks that a less involved computer prototype might have been better, for example, created using prototyping tools (especially the drag-and-drop kind) or more completely canned. Having put time and effort into the prototype made us reluctant to make big changes to it or to start from scratch. We did not receive user feedback that would have required such big changes, but starting from scratch would have helped integration with the back-end and also might have allowed us to use mobile interface tools like Twitter Bootstrap.

I was glad that we were able to do so many different types of user testing. It was interesting to see how our design changed from stage to stage. I also was surprised by how often feedback from different users overlapped. In particular I noticed this when summarizing the results from the heuristic evaluation in order to figure out how to prioritize our time. However, we also found similarities between our users’ feedback during our paper prototyping evaluation. At that stage, our users were consistently bothered by our button names and the way that our schedule looked.

It was also interesting to see flaws appear that  would have otherwise gone unnoticed. For example, in our final user tests our user noticed that whichever child she was editing, when navigating to the main screen it always defaulted to the first child’s tab. Without doing user testing with specific tasks, problems such as this would go unnoticed.

It would be easy and beneficial to keep performing this kind of iterative user testing. It would certainly be worthwhile to incorporate the feedback we received during this task, and at that point new flaws might either appear or become more noticeable. I imagine that it might be challenging to know when your product is close enough to being done and when it is appropriate to stop user testing.

I think it would have been fun to do a Wizard-of-Oz prototype, so we could have explored more with features. It also would have been helpful to have more time for the final project, so we could implement those last extra features in order to make it a smooth user experience.

The feedback meetings that we had after almost every task were helpful in keeping us on track and making sure that we could change things that needed to be changed. Thanks, Katrina!