Tags: ajax

24

sparkline

A little progress

I’ve got a fairly simple posting interface for my notes. A small textarea, an optional file upload, some checkboxes for syndicating to Twitter and Flickr, and a submit button.

Notes posting interface

It works fine although sometimes the experience of uploading a file isn’t great, especially if I’m on a slow connection out and about. I’ve been meaning to add some kind of Ajax-y progress type thingy for the file upload, but never quite got around to it. To be honest, I thought it would be a pain.

But then, in his excellent State Of The Gap hit parade of web technologies, Remy included a simple file upload demo. Turns out that all the goodies that have been added to XMLHttpRequest have made this kind of thing pretty easy (and I’m guessing it’ll be easier still once we have fetch).

I’ve made a little script that adds a progress bar to any forms that are POSTing data.

Feel free to use it, adapt it, and improve it. It isn’t using any ES6iness so there are some obvious candidates for improvement there.

It’s working a treat on my little posting interface. Now I can stare at a slowly-growing progress bar when I’m out and about on a slow connection.

A question of timing

I’ve been updating my collection of design principles lately, adding in some more examples from Android and Windows. Coincidentally, Vasilis unveiled a neat little page that grabs one list of principles at random —just keep refreshing to see more.

I also added this list of seven principles of rich web applications to the collection, although they feel a bit more like engineering principles than design principles per se. That said, they’re really, really good. Every single one is rooted in performance and the user’s experience, not developer convenience.

Don’t get me wrong: developer convenience is very, very important. Nobody wants to feel like they’re doing unnecessary work. But I feel very strongly that the needs of the end user should trump the needs of the developer in almost all instances (you may feel differently and that’s absolutely fine; we’ll agree to differ).

That push and pull between developer convenience and user experience is, I think, most evident in the first principle: server-rendered pages are not optional. Now before you jump to conclusions, the author is not saying that you should never do client-side rendering, but instead points out the very important performance benefits of having the server render the initial page. After that—if the user’s browser cuts the mustard—you can use client-side rendering exclusively.

The issue with that hybrid approach—as I’ve discussed before—is that it’s hard. Isomorphic JavaScript (terrible name) can theoretically help here, but I haven’t seen too many examples of it in action. I suspect that’s because this approach doesn’t yet offer enough developer convenience.

Anyway, I found myself nodding along enthusiastically with that first of seven design principles. Then I got to the second one: act immediately on user input. That sounds eminently sensible, and it’s backed up with sound reasoning. But it finishes with:

Techniques like PJAX or TurboLinks unfortunately largely miss out on the opportunities described in this section.

Ah. See, I’m a big fan of PJAX. It’s essentially the same thing as the Hijax technique I talked about many years ago in Bulletproof Ajax, but with the new addition of HTML5’s History API. It’s a quick’n’dirty way of giving the illusion of a fat client: all the work is actually being done in the server, which sends back chunks of HTML that update the interface. But it’s true that, because of that round-trip to the server, there’s a bit of a delay and so you often end up briefly displaying a loading indicator.

I contend that spinners or “loading indicators” should become a rarity

I agree …but I also like using PJAX/Hijax. Now how do I reconcile what’s best for the user experience with what’s best for my own developer convenience?

I’ve come up with a compromise, and you can see it in action on The Session. There are multiple examples of PJAX in action on that site, like pretty much any page that returns paginated results: new tune settings, the latest events, and so on. The steps for initiating an Ajax request used to be:

  1. Listen for any clicks on the page,
  2. If a “previous” or “next” button is clicked, then:
  3. Display a loading indicator,
  4. Request the new data from the server, and
  5. Update the page with the new data.

In one sense, I am acting immediately to user input, because I always display the loading indicator straight away. But because the loading indicator always appears, no matter how fast or slow the server responds, it sometimes only appears very briefly—just for a flash. In that situation, I wonder if it’s serving any purpose. It might even be doing the opposite to its intended purpose—it draws attention to the fact that there’s a round-trip to the server.

“What if”, I asked myself, “I only showed the loading indicator if the server is taking too long to send a response back?”

The updated flow now looks like this:

  1. Listen for any clicks on the page,
  2. If a “previous” or “next” button is clicked, then:
  3. Start a timer, and
  4. Request the new data from the server.
  5. If the timer reaches an upper limit, show a loading indicator.
  6. When the server sends a response, cancel the timer and
  7. Update the page with the new data.

Even though there are more steps, there’s actually less happening from the user’s perspective. Where previously you would experience this:

  1. I click on a button,
  2. I briefly see a loading indicator,
  3. I see the new data.

Now your experience is:

  1. I click on a button,
  2. I see the new data.

…unless the server or the network is taking too long, in which case the loading indicator appears as an interim step.

The question is: how long is too long? How long do I wait before showing the loading indicator?

The Nielsen Norman group offers this bit of research:

0.1 second is about the limit for having the user feel that the system is reacting instantaneously, meaning that no special feedback is necessary except to display the result.

So I should set my timer to 100 milliseconds. In practice, I found that I can set it to as high as 200 to 250 milliseconds and keep it feeling very close to instantaneous. Anything over that, though, and it’s probably best to display a loading indicator: otherwise the interface starts to feel a little sluggish, and slightly uncanny. (“Did that click do any—? Oh, it did.”)

You can test the response time by looking at some of the simpler pagination examples on The Session: new recordings or new discussions, for example. To see examples of when the server takes a bit longer to send a response, you can try paginating through search results. These take longer because, frankly, I’m not very good at optimising some of those search queries.

There you have it: an interface that—under optimal conditions—reacts to user input instantaneously, but falls back to displaying a loading indicator when conditions are less than ideal. The result is something that feels like a client-side web thang, even though the actual complexity is on the server.

Now to see what else I can learn from the rest of those design principles.

Async, Ajax, and animation

I hadn’t been to one of Brighton’s Async JavaScript meetups for quite a while, but I made it along last week. Now that it’s taking place at 68 Middle Street, it’s a lot easier to get to …seeing as the Clearleft office is right upstairs.

James Da Costa gave a terrific presentation on something called Pjax. In related news, it turns out that the way I’ve been doing Ajax all along is apparently called Pjax.

Back when I wrote Bulletproof Ajax, I talked about using Hijax. The basic idea is:

  1. First, build an old-fashioned website that uses hyperlinks and forms to pass information to the server. The server returns whole new pages with each request.
  2. Now, use JavaScript to intercept those links and form submissions and pass the information via XMLHttpRequest instead. You can then select which parts of the page need to be updated instead of updating the whole page.

So basically your JavaScript is acting like a dumb waiter shuttling requests for page fragments back and forth between the browser and the server. But all the clever stuff is happening on the server, not the browser. To the end user, there’s no difference between that and a site that’s putting all the complexity in the browser.

In fact, the only time you’d really notice a difference is when something goes wrong: in the Hijax model, everything just falls back to full-page requests but keeps on working. That’s the big difference between this approach and the current vogue for “single page apps” that do everything in the browser—when something goes wrong there, the user gets bupkis.

Pjax introduces an extra piece of the puzzle—which didn’t exist when I wrote Bulletproof Ajax—and that’s pushState, part of HTML5’s History API, to keep the browser’s URL updated. Hence, pushState + Ajax = Pjax.

As you can imagine, I was nodding in vigourous agreement with everything James was demoing. It was refreshing to find that not everyone is going down the Ember/Angular route of relying entirely on JavaScript for core functionality. I was beginning to think that nobody cared about progressive enhancement any more, or that maybe I was missing something fundamental, but it turns out I’m not crazy after all: James’s demo showed how to write front-end code responsibly.

What was fascinating though, was hearing why people were choosing to develop using Pjax. It isn’t necessarily that they care about progressive enhancement, robustness, and universal access. Rather, it’s often driven by the desire to stay within the server-side development environment that they’re comfortable with. See, for example, DHH’s explanation of why 37 Signals is using this approach:

So you get all the advantages of speed and snappiness without the degraded development experience of doing everything on the client.

It sounds like they’re doing the right thing for the wrong reasons (a wrong reason being “JavaScript is icky!”).

A lot of James’s talk was focused on the user experience of the interfaces built with Hijax/Pjax/whatever. He had some terrific examples of how animation can make an enormous difference. That inspired me to do a little bit of tweaking to the Ajaxified/Hijaxified/Pjaxified portions of The Session.

Whenever you use Hijax to intercept a link, it’s now up to you to provide some sort of immediate feedback to the user that something is happening—normally the browser would take care of this (remember Netscape’s spinning lighthouse?)—but when you hijack that click, you’re basically saying “I’ll take care of this.” So you could, for example, display a spinning icon.

One little trick I’ve used is to insert an empty progress element.

Normally the progress element takes max and value attributes to show how far along something has progressed:

<progress max="100" value="75">75%</progress>

75%

But if you leave those out, then it’s an indeterminate progess bar:

<progress>loading...</progress>

loading…

The rendering of the progress bar will vary from browser to browser, and that’s just fine. Older browsers that don’t understand the progress will display whatever’s between the opening and closing tags.

Voila! You’ve got a nice lightweight animation to show that an Ajax request is underway.

Tracking

Ajax was a really big deal six, seven, eight years ago. My second book was all about Ajax. I spoke about Ajax at conferences and gave workshops all about using Ajax and progressive enhancement.

During those workshops, I would often point out that Ajax had the potential to be abused terribly. Until the advent of Ajax, it was very clear to a user when data was being submitted to a server: you’d have to click a link or submit a form. As soon as you introduce asynchronous communication, it’s possible for the server to get information from the client even without a full-page refresh.

Imagine, for example, that you’re typing a message into a textarea. You might begin by typing, “Why, you stuck up, half-witted, scruffy-looking nerf…” before calming down and thinking better of it. Before Ajax, there was no way that what you had typed could ever reach the server. But now, it’s entirely possible to send data via Ajax with every key press.

It was just a thought experiment. I wasn’t actually that worried that anyone would ever do something quite so creepy.

Then I came across this article by Jennifer Golbeck in Slate all about Facebook tracking what’s entered—but then erased—within its status update form:

Unfortunately, the code that powers Facebook still knows what you typed—even if you decide not to publish it. It turns out that the things you explicitly choose not to share aren’t entirely private.

Initially I thought there must have been some mistake. I erronously called out Jen Golbeck when I found the PDF of a paper called The Post that Wasn’t: Exploring Self-Censorship on Facebook. The methodology behind the sample group used for that paper was much more old-fashioned than using Ajax:

First, participants took part in a weeklong diary study during which they used SMS messaging to report all instances of unshared content on Facebook (i.e., content intentionally self-censored). Participants also filled out nightly surveys to further describe unshared content and any shared content they decided to post on Facebook. Next, qualified participants took part in in-lab interviews.

But the Slate article was referencing a different paper that does indeed use Ajax to track instances of deleted text:

This research was conducted at Facebook by Facebook researchers. We collected self-censorship data from a random sample of approximately 5 million English-speaking Facebook users who lived in the U.S. or U.K. over the course of 17 days (July 6-22, 2012).

So what I initially thought was a case of alarmism—conflating something as simple as simple as a client-side character count with actual server-side monitoring—turned out to be a pretty accurate reading of the situation. I originally intended to write a scoffing post about Slate’s linkbaiting alarmism (and call it “The shocking truth behind the latest Facebook revelation”), but it turns out that my scoffing was misplaced.

That said, the article has been updated to reflect that the Ajax requests are only sending information about deleted characters—not the actual content. Still, as we learned very clearly from the NSA revelations, there’s not much practical difference between logging data and logging metadata.

The nerds among us may start firing up our developer tools to keep track of unexpected Ajax requests to the server. But what about everyone else?

This isn’t the first time that the power of JavaScript has been abused. Every browser now ships with an option to block pop-up windows. That’s because the ability to spawn new windows was so horribly misused. Maybe we’re going to see similar preference options to avoid firing Ajax requests on keypress.

It would be depressingly reductionist to conclude that any technology that can be abused will be abused. But as long as there are web developers out there who are willing to spawn pop-up windows or force persistent cookies or use Ajax to track deleted content, the depressingly reductionist conclusion looks like self-fulfilling prophecy.

Progress

I remember when Ajax started gaining traction on the web and in the minds of developers. One of the factors that web developers suddenly had to think about was giving feedback to the user when a request was made to the server.

Normally this is something that the browser takes care of (with its rotating letter “e” or its sweeping lighthouse fresnel lens or whatever method your chosen browser uses). But once you decide to use Ajax to make a request to the server, you’re effectively saying “Hey browser, it’s okay; I got this.”

And so web developers everywhere began to recreate loading indicators that were so popular on Flash sites. Some of them are very clever, created entirely in CSS.

This is a pattern that has been codified into HTML itself. We now have a progress element. This can be used to display fine-grained progress if you give it value and max attributes, or you can simply use it without any attributes to indicate that something is happening …perfect for those Ajax requests.

<progress></progress>

What I like about this element is that you can put fallback content in between the opening and closing tags. So let’s say you’re currently using an animated .gif to show that some content is being requested via Ajax:

<img src="spinner.gif" alt="Loading...">

Now you can wrap that within a progress element:

<progress><img src="spinner.gif" alt="Loading..."></progress>

Modern browsers show the native progress indicator. Older browsers show the animated .gif.

Of course, right now your ability to style that native progress indicator is limited (the shadow DOM may change that) but, as I pointed out in my book, that may not be a bad thing:

Remember, the web isn’t about control. If a visitor to your site is familiar with using a browser’s native form doodad, you won’t be doing them any favors if you override the browser functionality with your own widget, even if you think your widget looks better.

Clean conditional loading

It’s December. That means it’s time for the geek advent calendars to get revved up again:

For every day until Christmas Eve, you can find a tasty geek treat on each of those sites.

Today’s offering on 24 Ways is a little something I wrote called Conditional Loading for Responsive Designs. It expands on the technique I’m using on Huffduffer to conditionally load inessential content into a sidebar with Ajax where the layout is wide enough to accommodate it:

if (document.documentElement.clientWidth > 640) {
// Use Ajax to retrieve content here.
}

In that example, the Ajax only kicks in if the viewport is wider than 640 pixels. Assuming I’ve got a media query that also kicks in at 640 pixels, everything is hunky-dory.

But …it doesn’t feel very to have that 640 pixel number repeated in two places: once in the CSS and again in the JavaScript. It feels particularly icky if I’m using ems for my media query breakpoints (as I often do) while using pixels in JavaScript.

At my recent responsive enhancement workshop in Düsseldorf, Andreas Nebiker pointed out an elegant solution: instead of testing the width of the viewport in JavaScript, why not check for a style change that would have been executed within a media query instead?

So, say for example I’ve got some CSS like this:

@media all and (min-width: 640px) {
    [role="complementary"] {
        width: 30%;
        float: right;
    }
}

Then in my JavaScript I could test to see if that element has the wide-screen layout or not:

var sidebar = document.querySelector('[role="complementary"]'),
floating = window.getComputedStyle(sidebar,null).getPropertyValue('float');
if (floating == 'right') {
// Use Ajax to retrieve content here.
}

Or something like that. The breakpoint is only ever specified once so I ever change it from 640 pixels to something else (like 40 ems) then I only have to make that change in one place. Feel free to grab the example and play around with it.

By the way, you’ll notice that in the original 24 Ways article and also in this updated example, I’m only testing the layout on page load, not on page resize. It would be fairly easy to add in an onResize test as well, but I’m increasingly coming to the conclusion that—apart from the legitimate case of orientation change on tablets—the only people resizing their browser windows after the page loads are web designers testing responsive designs. Still, it would be nice to get some more data to test that hypothesis.

Lazy loading on Huffduffer

If you look at my profile page on Huffduffer, this is what you’ll see:

  • my details,
  • what I’ve huffduffed,
  • links to subscribe to my podcast and
  • my tag cloud.

That’s the core information for that page, preceded by a header with site navigation and followed by a footer with some additional links.

Because I’ve provided a URL with my details, there’s some extra information displayed in the sidebar:

It’s a similar situation if you look at a piece of audio I’ve huffduffed. The core information is:

  • all the details about the audio (title, description, tags),
  • who else has huffduffed this,
  • possibly-related items and
  • links to share and embed the audio.

In addition, because I’ve used a machine tagbook:author=cory doctorow—the sidebar contains:

  • related articles from The Guardian,
  • sales information from The New York Times,
  • books on Amazon.

In both cases, this supporting information isn’t essential; it’s just nice to have.

There’s a potential performance problem though. Because this extra information is coming from third-party services—and despite the fact that I’m doing some caching—it could delay the display of the whole page. So I took some time on the weekend to adjust the architecture a little bit. Now the extra information is requested with Ajax once the core information has already loaded. This is .

Now I’ve introduced a dependency on JavaScript, which is far from ideal, but because this is just “nice to have” information, I think it’s okay if it isn’t seen by a subset of visitors.

In fact, because this extra lazy-loaded stuff takes up valuable screen real estate, I think it might be acceptable to only serve it up to visitors who have the screen real estate to accommodate it:

if ($(document).width() > 640) {
// do lazy loading here
}

So if you load my profile on a small screen, you won’t see my latest tweets or my Last.fm recommendations. Likewise if you look at something I’ve huffduffed that’s tagged with music:artist=radiohead you won’t see information from Last.fm, pictures from Flickr or albums on Amazon unless you load the page with a wide enough viewport.

Now it could be that the real issue here isn’t viewport size, but connection speed …in which case I’m making the classic error of conflating small screen size with limited bandwidth. A script like Boomerang, which attempts to measure a user’s connection speed, could be very handy in this situation.

Lazy loading is the new fold

I was chatting with James about the implications that lazy loading could have for earlier phases of the design process: wireframing, page description diagrams, and so on.

Traditionally, you’ve got only two choices when judging what content to include: either something is on the page or it isn’t. You can use hierarchy, position and contrast to emphasise or de-emphasise the content but fundamentally, it’s a binary choice. But with conditional lazy-loading there’s a third option: include some content if the user’s circumstances warrant it.

Once again, Luke’s Mobile First approach is a useful thought experiment. It can help prioritise which elements are core content and which could be lazy-loaded:

Mobile devices require software development teams to focus on only the most important data and actions in an application. There simply isn’t room in a 320 by 480 pixel screen for extraneous, unnecessary elements. You have to prioritize.

So when a team designs mobile first, the end result is an experience focused on the key tasks users want to accomplish without the extraneous detours and general interface debris that litter today’s desktop-accessed Web sites. That’s good user experience and good for business.

Sometimes there are political reasons for wanting the “extraneous detours and general interface debris.” Lazy loading for large-screen users could be the least worst option in that situation. Semantically speaking, the kind of content that might be marked up in an aside element might be a good candidate for lazy loading …if the viewport is large enough.

I have a feeling that we’re going to be seeing a lot more of lazy loading as the responsive web design revolution rolls on. Used judiciously, it could provide plenty of performance benefits. But if it’s taken too far, lazy-loading could be disastrous, resulting in sites that rely on JavaScript to load their core content—I’m looking at you, Twitter.

Going Postel

I wrote a little while back about my feelings on hash-bang URLs:

I feel so disappointed and sad when I see previously-robust URLs swapped out for the fragile #! fragment identifiers. I find it hard to articulate my sadness…

Fortunately, Mike Davies is more articulate than I. He’s written a detailed account of breaking the web with hash-bangs.

It would appear that hash-bang usage is on the rise, despite the fact that it was never intended as a long-term solution. Instead, the pattern (or anti-pattern) was intended as a last resort for crawling Ajax-obfuscated content:

So the #! URL syntax was especially geared for sites that got the fundamental web development best practices horribly wrong, and gave them a lifeline to getting their content seen by Googlebot.

Mike goes into detail on the Gawker outage that was a direct result of its “sites” being little more than single pages that require JavaScript to access anything.

I’m always surprised when I come across as site that deliberately chooses to make its content harder to access.

Though it may not seem like it at times, we’re actually in a pretty great position when it comes to front-end development on the web. As long as we use progressive enhancement, the front-end stack of HTML, CSS, and JavaScript is remarkably resilient. Remove JavaScript and some behavioural enhancements will no longer function, but everything will still be addressable and accessible. Remove CSS and your lovely visual design will evaporate, but your content will still be addressable and accessible. There aren’t many other platforms that can offer such a robust level of .

This is no accident. The web stack is rooted in . If you serve an HTML document to a browser, and that document contains some tags or attributes that the browser doesn’t understand, the browser will simply ignore them and render the document as best it can. If you supply a style sheet that contains a selector or rule that the browser doesn’t recognise, it will simply pass it over and continue rendering.

In fact, the most brittle part of the stack is JavaScript. While it’s far looser and more forgiving than many other programming languages, it’s still a programming language and that means that a simple typo could potentially cause an entire script to fail in a browser.

That’s why I’m so surprised that any front-end engineer would knowingly choose to swap out a solid declarative foundation like HTML for a more brittle scripting language. Or, as Simon put it:

Gizmodo launches redesign, is no longer a website (try visiting with JS disabled): http://gizmodo.com/

Read Mike’s article, re-read this article on URL design and listen to what John Resig has to say in this interview .

Collective action

When I added collectives to Huffduffer, I wanted to keep the new feature fairly discrete. I knew I would have to add an add/remove device to profiles but I also wanted that device to be unobtrusive. That’s why I settled on using a small +/- button.

The action of adding someone to, or removing someone from a collective was a clear candidate for Hijax. Once I had the adding and removing working without JavaScript, I went back and sprinkled in some Ajax pixie-dust to do the adding and removing asynchronously without refreshing the whole page.

That was the easy part. The challenge lies in providing some meaningful and reassuring feedback to the user that the action has been carried out. There are quite a few familiar devices for doing this; the yellow fade technique is probably the most common. Personally, I like the Humanized Messages as devised by Aza Raskin and ported to jQuery by Michael Heilemann.

I knew that, depending on the page, the user could be carrying out multiple additions or removals. Whatever feedback mechanism I provided, it shouldn’t get in the way of the user carrying out another addition or removal. That’s when I thought of a feedback mechanism from a different discipline: video games.

Super Mario Bros. Frustration Speed Run in 3:07

Quite a few arcade games provide a discrete but clear feedback mechanism when points are scored. When the player successfully “catches” a prize, not only does the overall score in the corner of the screen update, but the amount scored appears in situ, floating briefly upwards. It doesn’t get in the way of immediately grabbing another prize but it does provide a nice tangible bit of feedback (the player usually gets some audio feedback too, which would be nice to do on the web if it weren’t to likely to get very annoying very quickly).

It wasn’t too tricky to imitate this behaviour with jQuery.

Collective action

This game-inspired feedback mechanism feels surprisingly familiar to me. Sign up or log in to Huffduffer to try it for yourself.

Thatmedia Ajax

The @media Ajax conference has wrapped up in London and a most excellent gathering it was. Kudos to Patrick and his orange-clad helpers for putting together a schedule filled with excellent presentations. I’ve written up individual summaries of day one and day two on the DOM Scripting blog.

The closing “hot topics” panel went pretty well. I could really get used to this moderation business. Instead of agonising over slides for days and weeks in advance of the conference, my preparation consisted of chatting with my fellow attendees in the pub to find out what questions they wanted answered. Seeing as beer-lubricated discourse is my favourite activity at any geek gathering, I didn’t have to modify my existing behaviour.

I did feel somewhat out of my depth on stage with the likes of Brendan Eich and Douglas Crockford. I hope I didn’t make too much of an idiot of myself.

All the presentations were recorded and a podcast will be available soon. As usual, I’ll transcribe the panel I moderated and post it with the other articles.

Kung Shui

Podcast coverage of South by Southwest Interactive 2007 continues to emerge, drop by drop. The audio recording of my joint presentation with Derek emerged last month. As usual, I’ve had the talk transcribed so you can read it, search it and link to it: Ajax Kung Fu Meets Accessibility Feng Shui.

Don’t forget: the RSS feed from the “articles” section of this site doubles up as a podcast.

There’s still no sign of the talk I did with Andy, How to Bluff Your Way in Web 2.0, but as soon as it’s available, I’ll get that transcribed too.

Hybrid Design and the Beauty of Standards

My speaking commitments at the Web 2.0 Expo have been fulfilled.

The panel I gatecrashed on Monday morning—The New Hybrid Designer—was a lot of fun. Richard deftly moderated the discussion and Chris, Kelly and I were only too eager to share our thoughts. Unfortunately Emily wasn’t able to make it. It may have been slightly confusing for people showing up to the panel which had Emily’s name listed but not mine; I can imagine that some of the audience were looking at me and thinking, “wow, Emily has really let herself go.”

I mentioned a few resources for developers looking to expand their design vocabulary to take in typography and grids:

Tuesday was the big day for me. I gave a solo presentation called The Beauty in Standards and Accessibility. My original intention was to give a crash course in web standards and accessibility but I realised that the real challenge would be to discuss the beauty part.

I reached back through history to find references and quotations to bolster my ramblings:

One of the tangents on which I veered off was Joseph Whitworth’s work with Charles Babbage. If you’re interested in following this up I highly recommend reading a book by Doron Swade called The Difference Engine: Charles Babbage and the Quest to Build the First Computer—originally released under the title The Cogwheel Brain in the UK

I really enjoyed giving this presentation and from the reaction of the people in the room, a lot of people enjoyed listening to it too. I was just happy that they indulged me in my esoteric wanderings.

On the morning of the presentation I schlepped a box full of copies of Bulletproof Ajax from my hotel to the conference centre so that I could give them away as prizes during Q and A. My talk was in the afternoon so I left the box in the speakers’ lounge for safe keeping. Once my talk was done and I had time for some questions, I said “I have some book… oh.” They were still in the speakers’ lounge.

Thus began our merry trek through the halls of the conference centre. I continued fielding questions from the enthusiastic crowd of followers eager to get their hands on a copy of my book. I couldn’t have asked for a nicer audience. I was only too happy to reward them with tokens of my appreciation in dead-tree form.

My lovely audience We got books!

Speaking at South by Southwest

This was my third year attending South by Southwest and also my third year speaking.

It seems to have become a tradition that I do a “bluffing” presentation every year. I did How to Bluff Your Way in CSS two years ago with Andy. Last year I did How to Bluff Your Way in DOM Scripting with Aaron. This year, Andy was once again my partner in crime and the topic was How to Bluff Your Way in Web 2.0.

It was a blast. I had so much fun and Andy was on top form. I half expected him to finish with “Thank you, we’ll be here all week, try the veal, don’t forget to tip your waiter.”

As soon as the podcast is available, I’ll have it transcribed. In the meantime, Robert Sandie was kind enough to take a video the whole thing. It’s posted on Viddler which looks like quite a neat video service: you can comment, tag or link to any second of a video. Here, for instance, Robert links to the moment when I got serious and called for the abolition of Web 2.0 as a catch-all term. I can assure you this moment of gravity is the exception. Most of the presentation was a complete piss-take.

My second presentation was a more serious affair, though there were occasional moments of mirth. Myself and Derek revisited and condensed our presentation from Web Directions North, Ajax Kung Fu meets Accessibility Feng Shui. This went really well. I gave a quick encapsulation of the idea of Hijax and Derk gave a snappy run-through of accessibility tips and tricks. We wanted to make sure we had enough time for questions and I’m glad we did; the questions were excellent and prompted some great discussion.

Again, once the audio recording is available, I’ll be sure to get it transcribed.

That was supposed to be the sum of my speaking engagements but Tantek had other ideas. He arranged for me to rush the stage during his panel, The Growth and Evolution of Microformats. The panel was excellent with snappy demos of the Operator plug-in and Glenn’s backnetwork app. I tried to do a demo of John McKerrell’s bluetooth version of the Tails extension using a volunteer from the audience but that didn’t work out too well and I had to fall back on just using a localhost example. Still, it was good to be on-hand to answer some of the great questions from the audience.

And yes, once the audio is available, I’ll get it transcribed. Seeing a pattern here? Hint, hint, other speakers.

As panels go, the microformats one was pretty great, in my opinion. Some of the other panels seem to have been less impressive according to the scuttlebutt around the blogvine.

Khoi isn’t keen on the panel format. It’s true enough that they probably don’t entail as much preparation as full-blown presentations but then my expectations are different going into a panel than going into a presentation. So, for something like Brian’s talk on the Mobile Web, I was expecting some good no-nonsense practical advice and that’s exactly what I got. Whereas for something like the Design Workflows panel, I was expecting a nice fireside chat amongst top-notch designers and that’s exactly what I got. That’s not to say the panel wasn’t prepared. Just take one look at the website of the panel which is a thing of beauty.

The panelists interviewed some designers in preparation for the discussion and you can read the answers given by the twenty interviewees. Everyone gave good sensible answers… except for me.

Anyway, whether or not you like panels as a format, there’s always plenty of choice at South by Southwest. If you don’t like panels, you don’t have to attend them. There’s nearly always a straightforward presentation on at the same time. So there isn’t much point complaining that the organisers haven’t got the format right. They’re offering every format under the sun—the trick is making it to the panels or presentations that you’ll probably like.

In any case, as everyone knows, South by Southwest isn’t really about the panels and presentations. John Gruber wasn’t keen on all the panels but he does acknowledge that the real appeal of the conference lies elsewhere:

At most conferences, the deal is that the content is great and the socializing is good. At SXSWi, the content is good, but the socializing is great.

Print matters

The Future of Web Apps conference finished with a day of workshops. I did a half day of beginning Ajax and had a lot of fun doing it.

I stuck around afterwards to sit in on Stefan Magdalinski’s workshop. Each workshop lasted just three hours—three and a half hours really, but there was coffee break in the middle. While I was frantically trying to cram my material into what seemed like a short space of time, Stefan was worried about having enough material to fill the alloted time. He needn’t have worried. He had plenty of stories from the trenches of They Work For You, Up My Street and the latest venture, Moo.com.

It was particularly enlightening to hear about the challenges of producing a physical product. It’s pretty clear from the success of great sites like Moo, JPEG Magazine and Threadless that there’s something special about holding a created object in your hands.

I had the pleasure of holding my own printed object in my hands when I got home from the day of workshops. New Riders—having inadvertently sent the original package to Dori’s house—sent an express delivery of two shiny copies of my brand new book, Bulletproof Ajax.

Bulletproof Ajax

Can you tell that I’m quite pleased with it?

Bringing it all back home

Given how much I travelled last year, you’d be forgiven for thinking that I’m leading some sort of transient lifestyle. But Brighton is where I spend most of my time and quite often it’s as eventful here as anywhere else on the globe.

There’s the renowned Brighton music scene, for example. I’ll be contributing to its vibrant ecosystem next month. Salter Cane will be playing a concert at The Joogleberry Playhouse on February 25th, which is, incidentally, my birthday. If you’re in town, come along and celebrate. You can add your name on Upcoming or Last FM.

On March 2nd, I’ll be giving an Ajax workshop. I’ve given workshops before in London, Manchester and Sydney. This time I’ll be doing it on home territory. Not only will it be in Brighton, it will be in the Clearleft office building, right in the middle of the trendy North Laine. If you’re interested in coming along (and helping me celebrate the release of Bulletproof Ajax), sign up before February 12 to get the early bird discount—£100 off the full price!

Announcing Bulletproof Ajax

When I wrote DOM Scripting, I can’t say it was the most pleasant experience. I found the act of writing to be quite laborious. As anyone who has written a book will tell you, it’s a hell of a lot of work.

But then when the book was finished and I finally held it in my hands, I experienced a great feeling of satisfaction. Once the reviews started coming in — mostly more than favourable — I felt even better. Before too long, I had almost forgotten the pain that had gone into writing the thing in the first place.

It was while I was in this vulnerable state of the newly-chuffed author at last year’s South By SouthWest that I was wined and dined by a charming representative from New Riders. Before I knew it, I found myself agreeing to write another book, one about Ajax this time.

Once the contract was signed, I was back behind my laptop staring at a blank Word document. That’s when I started remembering the pain of writing the first book. Bugger.

Fast forward to today. I’m done. The book is called Bulletproof Ajax and it will be released in one month’s time.

As yet, I don’t have a physical copy in my hands but already I’ve got that warm glow of achievement. I’m really, really pleased with how the book has turned out.

Now, here’s the thing: I think that people will either love this book or hate it. I didn’t write a typical programming book. Instead, the book has a strong sense of narrative and a distinctive tone of voice. I’m hoping that this will appeal to a lot of people but I expect it’s equally likely that it will put other people off.

I wouldn’t have written this book if I didn’t feel there was a need for it. On the face of it, another book on Ajax doesn’t seem to be filling a niche. After all, there’s no shortage of Ajax books out there. But most of those Ajax books are written for programmers. Generally they’re aimed at server-side programmers well-versed in a “proper” programming language like Java, and who must now come to grips with JavaScript.

Bulletproof Ajax is different. It’s aimed at front-end developers and designers: the kind of people who are already well-versed in web standards; CSS, (X)HTML, and maybe a dab of JavaScript. But it’s certainly not aimed at hardcore programmers.

Just to be clear: this book is not a cookbook of code. Yes, there is code in there to illustrate the concepts but it’s the concepts that are really important. The code is meant simply as a starting point. I go into far more detail on the design challenges and philosophical implications of Ajax. That’s why I think people will either love this book or hate it.

Personally, I love it… but then I may be a little bit biased—like a parent talking about how special their child is.

I’ve created a website to go with the book. It’s got the introduction, the table of contents and the code samples. Rather than start up yet another blog, I’m going to continue talking about Ajax and JavaScript on the DOM Scripting blog and then pull in the latest entries on the front page of the Bulletproof Ajax site.

Oh, by the way, about the title… I have Dan’s blessing. I just thought it was such a great adjective to apply to my approach to Ajax that it fit like a glove. So minus points for originality but plus points for accuracy.

Bulletproof Ajax is available to pre-order from Amazon. Some of the details listed on the Amazon page have been plucked from thin air and will get updated soon: the book is closer to 200 pages than 300.

If the release date listed on Amazon is correct, then the book will be available just in time for Valentine’s day so you can go ahead and get a book on Ajax for that someone special in your life. XMLHttpRequest is a geek’s best friend.

Ajax On The Beach

I just got off the stage at Flash On The Beach. To be honest, I didn’t think anyone would turn up: Microsoft were demoing their newest product in the big auditorium. On the plus side, I had a much smaller room to fill which made it nice and intimate.

The talk went well. The crowd were receptive and responsive, despite the oppressive stuffiness in the room. I was really, really glad that I had time for questions after I was done talking. I ended up talking for an hour (longer than I anticipated), but that still left fifteen minutes for a question and answer session.

I was talking to some people afterwards about some specific Ajax issues (cross-domain stuff, mostly) and I’ve posted some relevant links over on the DOM Scripting site.

Now that my talk is done, I can relax and enjoy Hillman Curtis.

Pictorial Ajaxitagging

I talked a while back about how I was attempting to add some extra context to my posts by pulling in corresponding tag results from Del.icio.us and Technorati, and then displaying them together through the magic of Ajax.

It struck me that there was another tag space that I had completely forgotten about: Flickr. Now at the end of any post that’s been tagged, you’ll find links entreating you to pull in any of my Flickr pics that have been likewise tagged.

This is all possible thanks to a single method of Flickr’s API. I’m reusing the same method to search for other pictures too…

A had a little epiphany in the pub the other night, chatting after the WSG meetup. I was talking about geotagging and I mentioned that it probably won’t be too long before just about every file will be geotagged in the same way that just about every file already has a time stamp. Then I realised, “hey, all my blog posts have time stamps and so do all my Flickr pics!”

So I added an extra link. You can search for any pictures of mine that were taken on the same day as a journal entry. I like the extra context that provides.

While I was testing this new functionality, I couldn’t figure out why some pictures weren’t being pulled in. Looking at the post from the Opera event written on Tuesday, I expected to be able to view the pictures I took on the same night. They weren’t showing up and I couldn’t understand why not. I assumed I was doing something wrong in the code. As it turned out, the problem was with my camera. I never reset the date and time when I came back from Australia, so all the pictures I’ve taken in the last couple of weeks have been off by a few hours.

Keep your camera’s clock updated, kids. It’s valuable metadata.

Hmmm… I guess I should take a picture today to illustrate the new functionality. In the meantime, check out this older post from BarCamp to see the Ajaxitagging in action.

London calling

It’s seems like I’m going up and down to London like a yo-yo this week.

On Monday, I gave a day of Ajax training at Framfab LBI. They’re a smart bunch. Normally, I have to sell developers on the concepts of progressive enhancement and unobtrusive JavaScript but these guys were already walking the walk. I felt kind of bad: for at least the first half of the day, I must have been preaching to the converted. Nonetheless, they were all very gracious and said they got a lot out of the day anyway. Too kind.

Yesterday evening was the Opera event which, despite the technical hitches, ended up being an enjoyable night out. Once the sales pitches and PowerPoint were out of the way, everyone was able to relax and enjoy the free booze, the mysterious canapés, and of course, the company.

After my talk and my hasty blog post, I spent the remainder of the evening explaining to people that no, I don’t have any connection to Opera, and wishing I had introduced myself before I started spouting my little after-dinner speech.

I had the chance to hang out with some of the gang from Last.fm, which was a lot of fun. It turns out that Hannah is a fellow believer in fighting the good fight for liquid layouts.

Today is the one day I won’t be getting on a train to the big smoke. Band practice takes precedence. Tomorrow, though, I’ll be returning to the bosom of mother London.

The second ever Web Standards Group meetup in London is taking place at the New Cavendish Street campus of Westminster University. The theme of the evening is microformats. Norm!, Drew and I will be covering the past, present and future of the single coolest thing happening on the Web right now. Why not join us for an evening of entertainment and education? The event is free. You can find more details on the Upcoming page. Try to get there for around half past six. Afterwards, we’ll decamp to the Bricklayer’s Arms for drinks ‘till late.

Be there or be square.

One talk down, one to go

I’m having a good time in Sydney. As illustrated in my Flickr photostream, I’ve been visiting all the usual tourist locations: the Opera House, filming locations from The Matrix, that kind of thing.

The Web Directions South conference is now motoring along and thus far, everything is going swimmingly. The pre-conference workshops have been going on for the past couple of days. I did a workshop on DOM Scripting and Ajax, which was good fun. The audience were a savvy bunch and they had some great questions and suggestions. The whole thing is online over at the DOM Scripting site.

Today the conference proper kicked off with the inimitable Kelly Goto, who gave a terrific and inspiring keynote. Then I had to follow her.

I wasn’t sure if I had prepared enough material. When I was practising my presentation back in my room, I was done in twenty minutes. As it turned out, I had plenty to say. In fact, there was only time for one single question from the audience at the end, which is a bit of a shame.

Overall though, it went well. There were no technical hitches (phew!) and some people came up to me afterwards and said they really enjoyed it.

You can take a look at the slides but they won’t make much sense without the context of the presentation. Fortunately, the whole thing has been recorded. I’ll be sure to get the audio transcribed and post it in the articles section of this site.

Now that I’ve got the first presentation out of the way, I can start fretting over the next one. Today I was talking about Ajax in a very broad hands-off kind of way. Tomorrow I’ll be delving into the actual code for building Ajax apps. As usual, I’ll be riding my Hijax hobbyhorse. I’m going to condense a lot of stuff down from my workshop so I’m hoping that the people who were at the workshop will go to the presentation by Thomas Vander Wal which is on at the same time as mine.