It was still light when I started queuing out the back of the Forbidden Planet. About 100 people stood between me and Neil Gaiman.

Many of the fans brought various Gaiman artifacts to be signed. The guy in front of me had a faded looking 2000AD from the 70s amongst other things. I was just clutching my freshly store bought copy of Fragile Things.

It was dark when I reached the door. He looked as tired as I felt. Maybe it was because he knew there were only a dozen more people to do. Maybe he is just naturally a nice guy. He seemed to always say a few things to everyone, even taking photos if requested. He managed to keep smiling and made the wait worthwhile.

After two and half hours in the queue:

Dan Webb: Unobtrusive Javascript

I said a quick hi to my colleagues as I dashed from the congress hall to Dan Webb's talk. I was surprised at the small venue they had given him, but quickly grabbed a seat. Good thing too, as I discovered that people were turned away from the talk.

After this incident, Skillsmatter were quick to attempt to rectify the problem by determining numbers before assigning rooms. Dan kindly gave a repeat performance the following day in the congress hall, for all those who missed it.

Back in Fashion

From the ashes of the browser wars and DHTML came CSS, XHTML, and Web Standards. Javascript had a bad name. However, along came AJAX and Web 2.0, and made Javascript trendy again.

Unobtrusive DOM scripting

CSS and XHTML separate out content and style. Separating out Javascript is the next logical step.

It is not merely about putting Javascript in a different file. It requires a change in mindset. Javascript should be used to enhance an already working application. Javascript should not be required to use the application.

Rails

Rails helpers such as link_to_remote create Javascript which works, but is not good. link_to_remote generates a link which will not work without Javascript: it does not degrade gracefully. Collections also produce ugly HTML, which inevitably lead to fatter pages.

UJS Plugin

The Unobtrusive Javascript Plugin hopes to rectify this situation.

You can just select parts of the page to apply behaviours to. apply_behaviour (CSS selector, event)

Will create the appropriate Javascript file which will act upon the CSS selector. There will be no Javascript mixed in with your HTML.

Links should never have side effects. If they must do something besides be a link, then they should be buttons. You can always apply any behaviour you want to your button, after you have confirmed it works.

respond_to

Assuming that you have a button_to on your view which will add something to your basket, you will have an action in the controller to deal with it. Make sure that works first.

Now you can make it fancier by adding a behaviour. However, you don't want to have to rewrite the action just because you are using Javascript to do some additional things.

Enter respond_to: this new feature in Rails controllers will allow an action to respond differently depending on what was requested.

respond_to do |type|
  type.html { redirect_to products_url}
  type.js # does default which is to render action.rjs
end

Case Study

Dan kindly provided us with an example of UJS in action. (It's an online sneaker store, in case the Web 2.0 name didn't give it away).

• Sneakr Case Study

Path to Enlightenment

1. Write a working app using semantic HTML
2. Style with CSS
3. Apply JS to hijack the page elements to enhance the UI
4. Learn Javascript and DOM scripting

Conclusion

I enjoyed Dan's talk, because he made it look easy and especially because it made so much sense. The generated pages looked amazingly clean; like seeing a styled page for the first time after years of table hell. Thanks Dan and Luke!

Kathy Sierra: Creating Passionate Users

I have been enjoying Kathy's blog for the past month or so. So, I was eager to hear her keynote.

She spoke about what she knows, and what I believe she is passionate about: Creating Passionate Users

Passionate Users

She explained that for any application you build, or tool as she refered to it, you need to create passionate users. They are the ones who will evangelize your product, help other users, and generally improve your product more than you could on your own.

Suck Threshold

Users will start out sucking, then they will become competent, before they become passionate. In order to move users past the suck threshold:

1. Have a clear goal. Something the user can aspire to being able to do.
2. Have a clear path. A series of steps that will allow the user to get there.
3. Easy first step.

Flow

You may have experienced this when coding, or doing anything else you are passionate about. You enter the Zone. The Flow. Time flies by without you realising it. You believe you are always one compile away from finishing.

The longer users can stay in the Flow, the more passionate they become. Enchant the user, and keep them in the flow state where they are happiest.

Make it hard to do the wrong things.
Make it easy to do the right things.

User Experience Spiral

Knowledge and skill, balanced correctly with challenge will engage the user. The challenge is what the user can do with the application, not the application itself.

Motivating Benefit -> Interaction -> Payoff (which is the next benefit)

You get the challenge, and promise of some reward, so you go on to learn something new. Once you have learned something new, your next challenge is dangled in front of you which uses what you learned. This is something which I felt when reading the Head First series of books.

Interesting point:

• Boys found it motivating just getting to the next level.
• Girls asked what they would get for getting to the next level.

Community

Forums, conferences, user groups, study groups, blogs with comments. This is where people can go to seek help. It is key that there are no dumb questions and no dumb answers. Having key figures in the community also help lead and motivate others.

Conclusion

I thoroughly enjoyed Kathy's talk. She tied together various disciplines which are not normally considered together, to come out with insightful ideas.

Tom Ward

I would eat a monkey.

The next morning

I should qualify that: I wouldn't go out of my way to eat a monkey.

DHH

I owe Matz a lot. I would do a lot for that man.

First Impressions

The first Rails conference in London, attracted about 400 people. Given the number of people you'd think that name tags would be used. Unfortunately, the name tags were printed with the names being the smallest and most unreadable text at the bottom of the tag.

Some people had lanyards, others clipped these useless plastic rectangles somewhere on their person, some had acquired bits of string. Not what I expected from a £500 a head conference.

DHH Keynote

The conference kicked off with DHH talking about Rails 1.2. He intends for this to be the last major 1.x release before 2.0

Main changes include:

• dependency system
• auto reloading, support in models, and controllers, of modules
• routing
• removal of deprecated features: in development this will generate warnings, and simply not work in production

SimplyRestful intends to use HTTP to indicate what to do. What appears to be have been taken up by many others was the respond_to

respond_to do |format| format.html # render :action => 'index.rhtml' format.xml { render :xml => @posts.to_xml}
format.js # render :action => 'index.rjs' end

One question I had was what is to stop me messing with other people's model using SimplyRestful. Jim Weirich asked a similar question at the end of the day. Apparently there would be authentication.

SimplyHelpful is another plugin, this time aimed at views. Basically it allows you to write your views more like you might expect: dealing with models.

DHH then showed a picture of a flower, and the talk ended. His keynote continued in the evening. Perhaps it was good that this happened, as he was very caustic.

The Rant

The second half of his talk was basically a rant. He was not happy about the reaction of a vocal few when there was a security issue raised, and the mailing list was moved without warning.

He felt that he owes the average Joe very little. They downloaded the software and then demand that it works. He showed and read out the license which ships with Rails. His conclusion: I don't owe you shit.

He then proceeded to clarify that he aimed that statement at people who have not contributed anything to the community. They have no currency with him.

I am not sure he understands that the problem was not the security problem, or the mailing list move. The problem was the way it was communicated to the community. Why were people expecting a more open explanation of the security problem, and notification of a mailing list move? Using DHH's words - it's convention.

It is convention to explain what security hole you have just patched. It is convention to warn the mailing list before you move it. That is why people reacted the way they did. They were treated without respect, and it is now clear why: DHH is leading by example.

He noted Kathy Sierra's talk mentioned "be nice" as the key to her forums working so well. I wonder if he ignored the rest of her talk.

More about the first day of the conference tomorrow, as it is now midnight.