SitterPlan - GR2

Scenario

Lia is the mother of a 4-year-old boy named Charles, and she is hoping to find a babysitter so that she can go on a date with her husband sometime this weekend. She already has a list of preferred babysitters, two of which she would be perfectly happy leaving Charles with. The third babysitter is perfectly capable, but not preferable because she is less active and engaging with Charles. 

Lia starts by contacting her first babysitter, Ben. She tries to reach him on the phone, but he's in classes most of the day and so the phone goes to voicemail. Instead of leaving a voicemail and waiting for him to call back, she sends him an email. She asks if he is free on Friday night, since that is the night she was hoping to be able to have her date.

Ben receives the email, but has already scheduled a babysitting job for Friday night. Now Lia has to decide if she should contact the next babysitter, who might also end up being busy on Friday night, or continue trying to schedule with Ben. Lia sends an email to Ben asking about Saturday, and at the same time sends an email to her second choice babysitter, Hannah. The next morning, Hannah writes back saying that she is free on Friday night, and after negotiating the time in a few more emails, they agree for Hannah to watch Charles on Friday.

Design Sketches

Liz Simon

Design 1: A week by week calendar where you can click and drag to create events. Overlapping events might be shown in a few different ways: (1) decreasing the width to fit them side by side and cutting off the information. (2) Decreasing the width and color-coding with a key on the side or (3) Combining them into one item with all possibile babysitters/families listed.

Design 2: A small screen interface. Only one day can be viewed at a time.

Design 3: A full month calendar view. A large span of dates can be seen at once, but not all information will be visible without clicking. In the babysitter view, there would be a green dot on each day that the babysitter is marked as free. Similarly, the parent view would have a dot on each day they posted a job.

Jayson Lynch

Design 1: Analogue Billboard

• A billboard placed in a central community area (church, school, local store).
• We have three sections: Parent Info, Calender, Babysitter Resume
• Parent Info: includes names and contact info, some babysitting specifications (possibly age or other constraints), and optionally pushpins of different colors
• Babysitter Resume: Contains experience/background, contact info, optionally price, typical availability, endorsement category (parents can sign to endorse them)
• Calender: Parents can add pushpins to show the range of times a babysitter is needed and babysitters can added extra availability or availability.

Use: This can be used in a few ways. Parents can go with a date in mind, pick an available babysitter and contact them. They can also post their need on the board
in which case a babysitter can contact them with their preferred day/time out of those listed. The endorsement section adds some verification and those parents
can be contacted for more information.

Problems: This relies on revealing personal information publicly. This may also be a safety concern. This is probably only feasible in a small, trusted community like a church. This also requires going to it's physical location to update. Even though we have more scheduling information, we still don't optimize people's schedules or preferences. We also do not solve the last minute cancellation problem.

Design 2: Profiles and Matching
Every person has an account which keeps track of scheduling priorities. When submitted, it will perform a best matching given the information available
.
Priorities:

•   Time availability
•   Price (might do something like take an average of prices in some range)
•   Preference on parent/babysitter

 
Use: All users fill out availability and preference information. They choose other users they want to work with to link to. The software makes suggested schedules based on information available. People can confirm personally and then put thing

Design 3: Paintable Calender
Editable calender whose events can be shared between people. This allows babysitters to post times they are available and parents to post times they need babysitters.
Input can be paintable with options on the side. This would include preference rating and whether they are editing a weekly schedule. For parents it includes the length of time of the job.
Need to distinguish between times that are 'or' (I need a babysitter for 2 hours on any of these evenings) and different jobs. Also should be able to view different calenders at once. A symbol, like a clock, that dictates the time needed can suffice for that.
Groups of people for preferred or not.

Use: Parents can post needed times and babysitters can post available times. They can then each look for overlap in their schedules and coordinate from there. Parents may have a group of preferred babysitters and share events with them first, to try to schedule someone they would rather have. Easy to select times, and being able to post needing some block within a given time should make some scheduling problems easier. This also allows for coordination of joint babysitting.

Problems: Must be updated frequently to be useful. This isn't an optimal solution to the scheduling problem and still has no way to leverage certain private information. This does facilitate joint-babysitting scheduling. This also allows better coordination of flexible schedules. 

Casey McNamara

Design 1: Timelines and invitations
Parents can view all (or a subset of) their babysitter contacts' schedules as compact timelines one above the other, helping them find an ideal time to schedule a sitter. They invite babysitters one at a time; sitters can accept or reject invitations. For this system to work, sitters must have told the interface their schedules in advance.

Design 2: Small-screen with invitations
Under size constraints it makes more sense to have parents propose a time and the app check to see which babysitters are free, rather than trying to display everyone's schedules and let the parents optimize. The parents are presented with a choice of babysitters free during their proposed time (and can go back and choose a different time if they dislike this list) and can invite one of them; sitters can accept or reject invitations. Again, sitters must have told the interface their schedules in advance.

Design 3: Calendar with postings
Having met with the group, I think Liz's Design 1 is strictly better than this one. In any case, it's a Google Calendar-style interface where parents can see (any subset of) their babysitters contacts' schedules on the calendar, create an event for a time they wish to find a babysitter, and post that event to whatever subset of their babysitter contacts they wish; babysitters see postings that have been shared with them and can claim jobs they are interested in. With this interface, it's okay if the sitters' real schedules differ from those known to the system, as long as parents share postings liberally.

Storyboards

Design 1: This design will have three main sections organized by tabs: Home, Profile and Jobs. The Home tab will show notifications that the user receives. The profile tab will store useful information about both types of users, and also allow babysitters to store their availability. The Jobs tab will allow parents to create new jobs and allow babysitters to manage the jobs they have been invited to. The major feature of this design is a calendar interface that allows users to quickly display their scheduling preferences by painting over times which work for them.

Storyboard

When a parent wants to find a babysitter for a particular job, they will go to the jobs tab and click create new.

They will use an interface similar to a calendar to select which times would be best for this job, and which times would work if need be. The user will click and drag over all the appropriate times to paint them with whichever color is selected  - green meaning the time is good, and yellow meaning it's OK. If they accidentally color a time they didn't intend to, they can click it to erase the coloring. They will also enter a title for the job and the length of time for the job. Separately, babysitters fill out a similar interface to indicate their availability, which can be found under their profile tab.

The parents then receive a list of babysitters that are available at any of their specified times, and a separate list of babysitters that indicated they could be free if necessary. They can then invite some or all of these babysitters to apply for the job.

The babysitters receive a notification that they can apply for a job, and can apply by clicking "see details".

Babysitters can also view all jobs they've been invited to under their jobs tab. They can decline a job by clicking on the small X to the left of it.

When a babysitter clicks on a job, they select the start time that is preferable to them and then applies.

The parent will then receive notifications of which babysitters respond and can choose whichever they prefer. They can also leave useful information for their babysitters on their profile, so babysitters can easily look this up while on the job.

Design 2: Timeline
Parents create events which they need babysitters for and babysitters specify availability. These are done with sliding bar timelines broken up by day. The sliding bar makes it very easy to specify blocks of time one is needed. Since these are thin, we can stack many of them above each other, and then checking whether someones schedule matches is just a matter of looking down to see if those blocks overlap. This makes checking for compatible times very easy. We also allow sorting by availability or preference, to make it easy to find a match or pick your preferred babysitters. Unfortunately it limits the amount that can be displayed, which is why we have a toggle for which day is displayed. The toggle buttons are partially filled/colored to show roughly how many matches occur on that day. 

Use: Two parents decide they want to take an evening off to see a movie. They decide on their preferred times on Saturday and make an event on Saturday in SitterPlanner. They decide to sort their babysitters by preference, and quickly notice that their two favorites are not available until later in the evening. They could go with one of the other babysitters they trust, but this time, they decided to go to a later showing so their favorite babysitter can watch their daughter.

Problems: Tends to favor babysitters posting schedules and parents planning immediately, thus not helping babysitters coordinate jobs to maximize the number of people they can babysit for, although if parents post events and are willing to wait, it can facilitate this type of planning as well as joint-babysitting. Although it makes schedules in a single day very easy to compare, checking multiple day availability is harder and requires the user to remember what was best on past days.

Design 3: Calendar
In order to find a babysitter for her children while she goes on a date with her husband, Lia opens up SitterPlan and looks at the weekly calendar of babysitters' availability. She checks off the boxes to show her top two sitters' calendars - Jennifer and Wanda.

Lia decides to go on her date on Friday, from 7 to 11. Jennifer's not free during that block, but Wanda is. She clicks the part of the calendar representing Friday at 7, which pulls up a (movable, closable) popup to create an event. Lia chooses to share the event with all her babysitter contacts - if Wanda ends up having something come up, it would be better if the others have had time to think about whether they can be free - and clicks POST.

Wanda sees the job posting the next time she opens SitterPlan to check up on her part-time babysitting business. (Probably she's configured SitterPlan to send her emails when someone posts a job. Like Facebook, but less annoying.) She sees on the calendar that Lia has posted a job on Friday, when she's free. Another family has also posted a job on Friday, but Wanda prefers babysitting for Lia.

Wanda clicks on Lia's job to pull up a popup that lets her apply for it. She enters the amount of money she'd like to get paid for the job and clicks APPLY.

Lia gets an email with that information. She can reply to Wanda immediately to set up details, or wait a few days to see if anyone else replies before choosing someone.

Analysis

Design 1: This design is very efficient because painting over all times which work can be done very quickly. It might be a bit confusing to learn without text explaining what to do for at least the first time. It is somewhat safe since there is an easy method for undo-ing mistakes, but mistakes will be very common because any time a user accidentally drags across a time with the mouse down it will get colored.

Design 2: This design allows efficient input and very easy schedule comparison on single days. Since timelines are thin, we can stack many of them on top of each other and visually looking for overlap is relatively easy. We can also prioritize the list based on availability, favorite babysitter, or other criteria. This does not handle multi-day scheduling well. Creating multiple blocks of time may not be the most intuitive in this interface. We also believe this design will tend to drive babysitters putting up their schedules and parents using it to find a match. This achieves the parents goal very well, but does not allow babysitters to coordinate with multiple parents over flexible schedules.

Design 3: This design is fairly efficient, although clicking the calendar and then entering the precise times of the job is one more step than ideal. My storyboard didn't go into the babysitters' schedule-entry process; for added efficiency, that can be Design-1-style painting, since the parents have no need to know specifically what things the babysitters are doing, just that they are busy; and sitters' schedules can by-default carry over from week to week. Learnability is good due to the external consistency with Google Calendar (there are some deviations, like collapsing multiple babysitters being free into a single rectangle rather than side-by-side rectangles, but the overall interface is fairly similar). Advanced features like making events that are flexible as to what times they're at are less easy to learn and in some cases (like multi-day scheduling) not clearly supported. As with Design 2, this design will tend to drive babysitters putting up their schedules and parents creating an event with a particular babysitter in mind.