CSCI E-168

The Evolving Project for Assignments 4, 5, and 6

Revision history:

• 28-Oct-2007 The following changes were applied to the schema: A foreign key to users from invitations marking the ownership of the invitation was removed; instead, go to the playdate for the invitation, and check the organizer of the playdate. The foreign keys to users from invitations and playdates to users were also changed to reflect their semantics.
• 22-Oct-2007 Tweaks to schema
• 21-Oct-2007 Original

The evolving project is called Childcare Co-op.

This project will be the basis for Assignments 4, 5, and 6 (the final project).

Assignment 4 is about ActiveRecord (database), and Assignment 5 is about Action Controller and Action View (application flow and display). Before I discuss the nature of the evolving project, a word or two about each of the assignments.

I’ll start with Assignment 6 — the final project.

For assignment 6, there are going to be two options:

1. You will extend Assignment 5, adding 2 or 3 new features leveraging other aspects of the Rails system. For instance, you might add REST, or generate XML feeds, or manage e-mail. We will provide a list of possible new features.

2. You can propose a project of your own. It will need to have a data model and browser interface that is at least as complicated as what you develop for Assignments 4 and 5, as well as 2 or 3 new features, as in Option 1. For option 2, you will need to write a project proposal, and get it accepted by your grader. I haven’t decided on a due date for the final project proposal, but right after Thanksgiving is pretty likely: So that would be around Nov. 25.

Option 1 has more guardrails, and is probably more suitable for people who want to go deeper into Rails details. Option 2 is probably best for students who have an existing project they want to create with or adapt to Rails. NOTE: You may not adapt an existing Rails project. E.g., if you already have your own Rails site, you may not build on it to satisfy Option 2. It must be new work.

Assignment 4 is about creating the data model for the project using ActiveRecord. This assignment will have many automated tests.

Assignment 5 is about creating the controllers and views for the project. Some parts of this assignment will have automated tests. Also note that we may very well throw out the specific data model from Assignment 4 — that is, we will likely hand out a modified data model for Assignment 5. It will be very much like Assignment 4, but it will become more or less complicated depending on how Assignment 4 goes. Assignment 5 will also be looser in the sense that there will be some opportunities for development that isn’t as constrained by testing.

Ongoing project for Assignments 4, 5, and 6 (Final Project): Childcare Co-op

The Childcare Co-op is a web-based product that helps parents organize playdates for their children.

Scenario

Many families organize “play dates” for their kids. Parents and kids get together for a couple of hours, say, on a Saturday afternoon at a park or playground. Other locations for play dates are someone’s home, the zoo, etc. The kids get to play, and the parents get to talk. Typically one parent will organize the play date. That parent, or another parent, may be responsible for bringing a snack for the kids. The responsibility for “hosting” the play dates may rotate amongst the parents.

The Problem

It turns out that this kind of activity is hard for parents to organize. There are a number of reasons for this. First off, parents are incredibly busy, so remembering that there is a Saturday obligation is sometimes hard. Second, the scheduling for kids is oftentimes not managed by the same software parents use at work. It’s a different calendar, and can be very poorly managed (could be on paper, on stickies on the fridge, or on fading ink on the back of one’s hand…). Parents also require notifications of upcoming play dates, via e-mail and text message.

It is worth noting as well that existing products are not very well suited for this kind of social organization. For example, generic calendars don’t provide for the kind of security we imagine (that is, privacy amongst the parents). Blogs are too public as well. Facebook is an interesting possibility, but it’s also not very private, and the target Facebook audience is still primarily college students, despite the growth in the over-25 demographic. Having said that, Childcare Co-op will eventually provide means to publish information to calendars (such as Google Calendar), and it will expose and consume feeds. In other words, the product will leverage the existing protocols of Web 2.0 to make it a platform for organizing multi-family information.

Market Opportunity

Because of the pain of keeping play dates organized, we believe that parents would pay for this service. When a parent signs up, he or she will pay $20/year to participate in as many playdates as he or she wants. When a playdate is created, parents are invited by e-mail. If the invited parent is not registered, they will have to pay the $20/year themselves. As an option, the initial host may pay for invitation credits, so that the signup cost would be waived for selected invitees. By this means, we believe that Childcare Co-op will have viral adoption. The size of this market is vast: There were 36 million households in the United States in 2006 with children under 18 (http://www.census.gov/population/www/socdemo/hh-fam/cps2006.html - table AVG3). Capturing even a 10th of a percent of this market would be 36,000 households; at $20/family, that would be revenue of about $720,000/year. We believe that the primary market will be households with annual incomes of $75,000 or higher. These are typically families with two wage-earners who are time-strapped and might find the service useful. To start, Childcare Co-op plans to focus on the greater Boston market. In Suffolk County, there are 26,417 households with incomes of $75,000 or greater (http://www.dwellings.com/dw/pages/boston.html). Guessing that at least half at that income level have at least one child, that would be about 15,000 households with children. In Boston, we hope to capture 1% of that market (150 families) by the end of a year. That would result in revenue of about $3,000 per annum which is a good start. (We will also serve Google AdSense ads, though that probably won’t make us any money for quite awhile). The subscriptions would obviously pay for all hosting costs, which would be less than $200 for the year. The rest of the money would be used for targeted marketing, chiefly Google AdWords) for the second year.

Customer Story

Lisa Smith and Rick Jones are married and have two children, Boris (age 10) and Sara (age 4). It happens that Boris’s last name is Jones and Sara’s last name is Smith. They call their family the “Smith-Jones” family. Lisa and Rick have a part-time babysitter named Cassie Rogers, whose schedule is somewhat unpredictable. Most every Tuesday there is a playdate at 10 AM for Sara at Lincoln Park. (Note that sometimes the playdate is delayed until 10:30 AM because another family sometimes has a late breakfast. In most cases, Lisa takes Sara, but sometimes Cassie takes over. The playdate lasts two hours and includes lunch. There are four other families who usually attend the playdate, with 6 kids among those families. At each playdate, one family is responsible for bringing a snack suitable for all of the kids.

Lisa is de facto the leader of the playdate, and she’s been having a lot of trouble lately keeping everyone up-to-date on the schedule. Some people like to be notified about the starting time and the snack obligations by e-mail, while others want text messages. And some people need a week’s notice, while others just need to be updated the night before.

Lisa also takes Boris to soccer practice most Wednesdays right after school; that’s at 3:00 PM. She has missed at least one practice because the coach didn’t tell her about the date. It happens that the coach’s 4-year old son is also in Sara’s playgroup for the Tuesday playdate.

Clearly, Lisa needs help.

Using the Product

NOTE: What is described here is a bit in advance of what will be released for Version 1.0.

Lisa has recently heard about Childcare Co-op and how it makes it easy to organize these kinds of events.

She goes to the web site, and first registers herself, providing her e-mail address, phone number, first and last names, address, and other materials required to charge with her credit card. Lisa is given the option to pay $20 in advance for others (i.e., she can buy “credit” in the system.

Then, as time permits, she enters information for each of her children (Boris and Sara) and for the other two parents / guardians / caregivers for her family (Rick and Cassie) [remember: caregivers are out-of-scope for 1.0.]

Next she defines a Playdate “Tuesday Lincoln Park Playdate” for 10 AM every Tuesday.

Now she invites other parents to participate by entering their e-mails and an optional message. She can also check the invitation so that the recipient is paid for by any credits she might have in the system (credits are only drawn down when a recipient actually registers and is confirmed by the inviter). The e-mail invitations are sent out. Each notification contains a link that, when clicked, returns the user to the site. If the e-mail is in the system (i.e., the parent is already registered) the parent is allowed to add his or her kid(s) to the playdate. If the e-mail is NOT in the system, the recipient is invited to register (and pay, if Lisa didn’t pre-pay them), or log in. Then the user is given a means to join kid(s) to the particular event. If Lisa had already had a playdate joined by other kids, then during the invite process she would have been given an opportunity to check off any “already known” kids. The parents of those kids would be sent the invitations.

Once an event is set up, and invitations are sent out, Registered invitees can review the event and see who’s coming. The parents of participating kids can control their notifications of upcoming playdates.

Now Lisa has a consistent reminder for Sara’s regular Saturday playdate. Because Boris’s coach joined Childcare Co-op because of his son’s participation in the Saturday group, he has started using it to manage soccer practice. Recently, the coach changed the practice start time, and Lisa received a text message the night before with the updated time. So for once she isn’t surprised when the practice time changed.

Some Initial Use Cases

1. A Parent can sign up for the service. During the alpha, the product is free and registrants don’t need to supply credit card info, etc.
2. A Parent can define multiple Children.
3. A Parent can define a Playdate.
4. A Parent can invite others (by e-mail) to participate in a Playdate.
5. A Parent can review Invitations.
6. A Parent can accept an Invitation.
7. A Parent can associate a Child with a particular Playdate.
8. A Parent can review upcoming Playdates.

Technology

The product is designed and built with Ruby on Rails. Because the requirements for the product will change frequently owing to intense assessment of customer needs and wants, we require a platform that is amenable to rapid iteration. The CTO/co-founder who is responsible for the technology has experience with JavaEE, .NET, and Ruby on Rails, and in her own development practice she has found that Ruby on Rails is especially appropriate for a product like this one because of the framework’s shallow learning curve and quick demonstration of results. The product in its present form also does not require heavy enterprise integration or internationalization (two weak spots for Rails, though engineering believes that by the time the product goes international, these problems will be solved by the Rails community).

Furthermore, the CTO is aware of a new course n Rails offered by Harvard Extension. The new course promises to increase dramatically the number of local developers who are proficient in Rails — so she is not too worried about a lack of developers should the product take off and the technical team need to be expanded.

The CTO plans to have a working product with the basic features completed in a couple of months, and a full preview release (working beta) in three months. One thing that will probably be out of scope for the working beta is payment processing and some other security features regarding invitations. There is also a key feature involving the delegation of responsibility to non-subscribers. That will have to come later.

Getting Started

To begin development, we’ll focus on the data model that will support the product. Here are some of the entities (things) the product must manage:

User: Someone who can log in. Very generally, this is a parent. We may actually change the name to Parent at some point. Users can invite other users to join their children to Playdates. NOTE: For the initial version, “Subscriber” is a synonym for “User” in all requirements. In a later version of the product, there will be two types of Users, Subscribers and Caregivers.

Caregiver: [Caregiver is out of scope for initial version — do not implement.] a person to whom a User may delegate responsibility for her children. Caregivers can also log in; i.e., all Caregivers are also Users. A Caregiver might be an aunt, uncle, babysitter, nanny, or close friend. A Subscriber may have 0 or more Caregivers. A Caregiver may be a Caregiver for many Subscribers. A Subscriber may also note that a Caregiver has custody of her Children.

Note: Thus a Caregiver can do many of the things a Subscriber can do, with one very important exception: A Caregiver cannot invite others to a Playdate.

Note: A Subscriber’s Caregiver may be responsible for any of the Subscriber’s Children at a Playdate. We do not model the idea that one Caregiver might be responsible for, say, only one of the Children, while another Caregiver is responsible for the Subscriber’s other kids. The point of designating a Caregiver as having custody (like a Subscriber) is to support different levels of information privacy and authority between Subscriber and Caregivers. For example, only a Subscriber or a Caregiver with custody can change a Child’s allergy settings.

Finally: It is possible for a Caregiver to be such for more than one Subscriber. Indeed, a User might be Subscriber herself, but a Caregiver for another Subscriber. [In other words, there has to be a join table.]

Child: We interpret “child” very loosely: a Child is a person who is managed by a Subscriber. A Subscriber may have 0 or more Children. (Remember, in the initial release, by Subscriber we just mean: User.)

Location: A place for a Playdate. A Location may be marked as “public” so that Subscribers [out of scope: and Caregivers] can comment on it, and so that it can be used by others during Playdate scheduling.

Playdate: something that happens at a Location on a certain date, starting at a certain time. There is also an optional end time. The Location may be null (i.e., unassigned at the time the Playdate is created: Essentially, that would mean that the Playdate Location is TBA). Subscribers create Playdates, and invite other Subscribers [out of scope: and Caregivers] to participate. In the web application, but not in the data model, a Subscriber will also be shown the names of children whose own subscribers have previously accepted playdate invitations — the invitation to a Child in the web app effectively goes to the Child’s Subscriber.

Here is a diagram of these entities and their relationships (click for larger view) (about the schema diagram: The relationship lines in all cases show one-to-many relationships. The “crows-feet” icon designates the “many” side of the relationship. In other words, in the diagram, a user may have many children. For some discussion, see http://en.wikipedia.org/wiki/Entity-relationship_model#Crow.27s_Feet):

Based on these entities and relationships, we should be able to answer the following questions:

Who are the children of a subscriber?

What are a subscriber’s created playdates (i.e., managed by the subscriber)?

Which users are invited to a playdate?

What children are assigned to a playdate?

Where will that playdate be located?

And so forth.