To keep the teams working as separately as possible with the least interference, we decided that the PAAL Builder, the tool used to build student schedules and lessons, would be completely HTML and Javascript. That means that there would be no server-side code, no ERB or HAML template files, and no Rails special sauce. This allowed the designers to work without developer support, and allowed developers who did not know Ruby or Rails to work solely on Javascript code. The Builder would interact with the API via ajax calls with JSON responses. A simple format for the response envelope was designed:

{
version: 0.1,
error: '',

data: {
  task: {
    id: 1,
    name: 'Brush Teeth'
  }
}
}

This is an example response upon the creation of a task with the name “Brush Teeth.” On each request, the error property would be checked to make sure that it was blank. The version property would also allow changing the API in the future without breaking the application.

In the previous post I discussed the problems of having a simple API. One common scenario is to create a task and link it with a parent task. This would happen if you wanted to create a task like “Brush Teeth” and steps underneath it like “get toothpaste,” “get toothbrush”, “brush front teeth.” Here is the code necessary to do that (I am just posting the necessary jQuery calls rather than the wrapper functions I wound up writing):

// create the task via a POST
$.post(
  '/tasks',
  taskData,
  function(envelope, textStatus, request) {
    if ( envelope.error != '' ) {
      // error
    }
    else {
      // on success, tie the newly created task
      // to a parent task
      function callbackSuccess(newTask, envelope) {
        $.post(
          '/task_parents',
          {
            task_parent: {
              task_id: newTask.id,
              task_parent_id: some_parent_id
            }
          },
          function(innerEnvelope, textStatus, request) {
            if ( innerEnvelope.error != '' ) {
              // error
            }
            else {
              // success!
            }
          },
          'json'
        );
      }

      callbackSuccess(envelope.data.task, envelope);

    }
  },
  'json'
);

Wrapper functions make this simpler to understand, but the fact that it requires two posts troubled me. Still, I avoided adding a new method to the API to do this all in one step.

When we were working on the project, the designers and another developer worked mostly on basic UI. I then worked on “installing the plumbing” as I put it, making all the API calls and using the live data. A lot of this plumbing went into the product after Give Camp. One aspect of the project I found hard after Give Camp was figuring out how a feature or UI element would work. Often, I’d be hooking up the plumbing, but be unsure of whether they wanted a stand-up shower or a bathtub. Both would get the job done, but I wasn’t sure what they had in mind, and it wasn’t clear from the design.

Part of this was due to the fact that I didn’t have the most recent design. We switched versioning systems two times during the course of Give Camp, and repository locations 3-4 times. Part of this was due to lack of notes or obvious visual stimuli. In general, after Give Camp was over, it was hard to coordinate with each other.

There a number of programs that are used to make an individual’s life easier. One, used by an individual with speech impairment, is a Powerpoint presentation featuring images of common items. Clicking on an image plays a sound file that represents the image. In this way, the individual can communicate with others.

Another program is a sort of flash-card program. This program helps guide a student through daily tasks by breaking the tasks into granular steps. The program also provides a choice option that prompts the user to choose among a set number of options. Although the user program is fairly effective, the authoring application for these files is cumbersome to use. Two drawbacks of this program exist:

1. There is no monitoring component built in. Monitoring of students is done on paper.
2. There is no schedule component to the application, which would provide the students a task list of activities for the day

MECA wanted a program that not only was easy to use for students, but also a program easy to use for instructors to author lessons. Additionally, a program that incorporated a task-list and monitoring component would be especially helpful.

While the staff explained some of the requirements, we were joined by other team members: Brian, Erik, Sebastian, and then Joe. There was another person who came to help during the night but he didn’t come on subsequent days. Much of that first Friday evening was spent just gathering requirements and attempting to fully understand the problem.

When we finally thought we had enough to start, it was around eight or nine at night. In the interest of time, we decided we would not work on a monitoring component. We decided to break the remaining problem into three components:

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

The next post will discuss the reason for this split.

I have been known to fall into similar patterns in personal projects. They tend to get bloated in totally unnecessary places while key features remain unimplemented. I blame the curse of a modern attention-span!