Jamie's Blog

Thinking about the problem domain, Trevor, Sebastian, and I decided to abstract away the complexity. The problem (as I understood it then) can be explained thusly:

Students need a way to follow a list of scheduled tasks throughout the day, to assist them in performing daily activities. These tasks can be broken into more detailed tasks with steps or choices. A choice, such as what to have for lunch, is non-linear. A choice helps a student develop his sense of independence. Each choice and task may have accompanying text and audio.

Day to day within a week, the schedule of tasks may be different. Weeks can also differ from each other.

Given these simple business requirements, we decided that a step, a task, and a choice were all the same in that they had a name, audio content, text content, and that they had a parent-child relationship with each other. We decided that all of these would be “tasks” and that there would be a “task type” field to differentiate between these. The “task” paradigm yields the following definitions:

• A task is a task with linear/sequential sub-tasks
• A step is a task with no sub-tasks
• A choice is a task with non-linear, non-sequential sub-tasks

We also decided, after further discussion to make certain other things tasks. We thought that days and weeks were similar enough to a task in the parent-child relationship. We decided that

• A day is a task with linear/sequential sub-tasks whose name is a weekday
• A week is a task with day sub-tasks (days as defined above)

This allowed us to have a single Task model, and a Task Parent model, which greatly simplified the API. Instead of making REST calls to create a step, create a week, or create a choice, there would be just one create call, with a task type defining the behavior of the task. This would also make copying tasks and task trees easier, since we would only have to work with one model when doing a deep copy of a task tree.

Although this made the API really quick to build, when I started writing the builder code, interacting with the API, I found the API to be a bit low level. For example, I would have to make two calls to bind a new task to a user. First, I would have to create the task via the API, and then create the user-task relationship via the API. As I was writing nested callbacks with the jQuery ajax functions, I questioned our decision to make the API so simple. Still, I think the API is a thing of beauty, and I am still proud of what we did that weekend.

As the MECA staff were describing the application, I didn’t have a clear sense of how beneficial our work would be. To illustrate how our application would help people, they showed us a video of a student going to a gym. In the first clip, the student has trouble following directions and signage about the use of gym equipment. In the second clip, the student is following auditory prompts and exercising at the gym with little trouble.  Another student was able to prepare a meal with the help of visual prompts from a PDA. It was illuminating to see the difference that prompts could in someone’s daily life and spurred us to work even harder.

We decided to split the application into 3 components:

• A REST API written using Rails
• A HTML/Ajax builder web application
• An iPhone user application

We had a team of about eight people, and we knew we had to separate tasks somehow. There were some individuals with iPhone experience (mostly novice stuff like simple view demos), and some with Ruby experience, and then there were two designers with CSS and some jQuery experience.

We figured Trevor, who has extensive Rails experience should lead the API effort, and that Brian, who has done the most, albeit little, iPhone development using MonoTouch should lead the student application effort, while the designers should focus on designing and implementing some of the builder code. (The interface for the user application had already been worked out by group consensus.)

I decided I could best help with the API, so I worked with Trevor on that. Something that I think amazed all of us was that once we had assigned ourselves to teams and broken the project up, we functioned seamlessly, all of us entering the zone in our respective areas. It’s the kind of synergy and flow you get when the majority of your team knows their shit. It was an incredible experience to be a part of that.

We had a good framework and sample response API for the student interface and builder to start building plumbing by the time we left on Friday. Meanwhile, the iPhone app team had gotten some samples working using Monotouch. The builder interface was looking really sharp. We were off to a good start when we decided to break for the night around midnight.

In the next post, I will describe some of the insights behind the API.