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. Image Removed

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 Removed

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).

...

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.

...

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.

...

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.

...