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.
Paper prototyping:
Heuristic evaluation:
User testing:
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.
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.
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.)
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.
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.
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.
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
New CheckIn
Viewing/Editing CheckIns
User 2: Parent
Add child screen:
New / Edit CheckIn:
Viewing/Editing CheckIns:
User 3: Child
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!