Jamie's Blog

Here’s a post that might help problems with Sammy routes, callbacks, and event handlers using jQuery, especially the “live” function.

I have an input form with submit buttons like:

<form>
<input type="submit" name="what" value="SomeCommand" />
<input type="submit" name="what" value="DifferentCommand" />
</form>

This didn’t play well with Sammy, as it doesn’t load the value of what into it’s params hash. So, I did a work around like:

  // hack to allow sammy to access the 'what' param
  $('form input[type=submit]').live('click', function(){
    var submit = $(this),
      form = submit.parents('form');
    form.find('input[name=what][type=hidden]').val(submit.val());
  });

I’m not sure why I originally chose to use “live.” It could’ve been that I was building DOM dynamically using jquery-tmpl. In Firefox and Chrome, this worked as expected. In IE, the Sammy route handler would fire before the click handler above! So, I changed the code to use the non-live version.

  $('form input[type=submit]').click(function(){ // changed
    ...
  });

I did a quick matrix to compare various mobile JS frameworks in late May. It is probably a little outdated, especially with the recent Sencha merger, and I did not know DashCode could create web applications at the time, but maybe it will help someone. Enjoy! http://bit.ly/d6Gsaj

The Builder

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.

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.

Dani led us into a different conference room from the main room that most of the other conference attendees stayed in the entire weekend. We met MECA members Gloria, Kaori, and Avi who teach autistic individuals how to function independently. They discussed some of their current work and successes, including the Preparing Adolescents for Adult Life (PAAL) program.

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 used jQuery for the UI. I am a recent convert to jQuery, having mostly used Prototype + Scriptaculous.

The word list is embedded into the page script as a javascript array. On document ready, html is generated, which writes the first and last word to the page, and creates blank input boxes for the intermediate words.

There is a keyup event bound on each input box, which will determine if the word is correct. If it is, a css class will be added which shows a green underline underneath the box. Otherwise, a red underline will be shown.

Finally, there are buttons on the page which are created dynamically and provides hints or reveal all of the answers.

Word Jumble Filled

For a recent Regular Expressions Tech Talk at Wharton, I wrote a Word Jumble game.  I will be describing the game and some of the key concepts used in making the game. Here’s the github repo.

Game Screenshot

The premise of the game is to transform one word into another by replacing a single letter in the starting word to form a new word and repeating until you match the last word.

So, let’s say we have the word baked, which we want to transform into the word water. We do this by changing one letter in the word baked and forming a new word, repeating the single-letter replacement until we have the word water.

• baked <- start
• bated
• batea
• bater
• water <- end

The rules are:

• You are only given a starting word and ending word
• Change only one letter to form a new word
• The new word must be a real word (in some dictionary)
• The same word cannot appear twice
• Each word must be the same length

Based on these rules, I sat down one evening and spit out an implementation of the game which has the following features:

• randomly generates a puzzle of 5-letter words
• generates a puzzle of max length n, where n is the number of words in the puzzle
• accepts an initial starting word
• accepts user guesses for the intermediate words