I just finished watching The Billion Dollar Code, a German language miniseries on Netflix. It’s no Halt and Catch Fire, but it combines ’90s nostalgia, early web tech, and an opportunity for me to exercise my German comprehension.
It’s based on a true story, but with amalgamated characters. The plot, which centres around the preparation for a court case, inevitably invites comparison to The Social Network, although this time the viewpoint is from that of the underdogs trying to take on the incumbent. The incumbent is Google. The underdogs are ART+COM, artist-hackers who created the technology later used by Google Earth.
Early on, one of the characters says something about creating a one-to-one model of the whole world. That phrase struck me as familiar…
I remember being at the inaugural Future Of Web Apps conference in London back in 2006. Discussing the talks with friends afterwards, we all got a kick out of the speaker from Google, who happened to be German. His content and delivery was like a wonderfully Stranglovesque mad scientist. I’m sure I remember him saying something like “vee made a vun-to-vun model of the vurld.”
His name was Steffen Meschkat. I liveblogged the talk at the time. Turns out he was indeed on the team at ART+COM when they created Terravision, the technology later appropriated by Google (he ended up working at Google, which doesn’t make for as exciting a story as the TV show).
His 2006 talk was all about Ajax, something he was very familiar with, being on the Google Maps team. The Internet Archive even has a copy of the original audio!
These days, no one talks about Ajax. But that’s not because the technology went away. Quite the opposite. The technology became so ubiquituous that it no longer even needs a label.
A web developer today might ask “what’s Ajax?” in the same way that a fish might ask “what’s water?”
I wrote a little something recently about using ARIA attributes as selectors in CSS. For me, one of the advantages is that because ARIA attributes are generally added via JavaScript, the corresponding CSS rules won’t kick in if something goes wrong with the JavaScript:
Generally, ARIA attributes—like aria-hidden—are added by JavaScript at runtime (rather than being hard-coded in the HTML).
But there’s one instance where I actually put the ARIA attribute directly in the HTML that gets sent from the server: aria-live.
If you’re not familiar with it, aria-live is extremely useful if you’ve got any dynamic updates on your page—via Ajax, for example. Let’s say you’ve got a bit of your site where filtered results will show up. Slap an aria-live attribute on there with a value of “polite”:
<div aria-live="polite">
...dynamic content gets inserted here
</div>
You could instead provide a value of “assertive”, but you almost certainly don’t want to do that—it can be quite rude.
Anyway, on the face it, this looks like exactly the kind of ARIA attribute that should be added with JavaScript. After all, if there’s no JavaScript, there’ll be no dynamic updates.
Assistive technology will initially scan the document for instances of the aria-live attribute and keep track of elements that include it. This means that, if we want to notify users of a change within an element, we need to include the attribute in the original markup.
I think it holds up pretty well. There’s one interaction pattern in particular that I think has stood the test of time. In the talk, I introduce this pattern as something you can see in action on Huffduffer:
I was thinking about how to tell the user that something’s happened without distracting them from their task, and I thought beyond the web. I thought about places that provide feedback mechanisms on screens, and I thought of video games.
So we all know Super Mario, right? And if you think about when you’re collecting coins in Super Mario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.
The feedback you get in Super Mario is about the number of points you’ve just gained. When you collect an item that gives you more points, the number of points you’ve gained appears where the item was …and then drifts upwards as it disappears. It’s unobtrusive enough that it won’t distract you from the gameplay you’re concentrating on but it gives you the reassurance that, yes, you have just gained points.
I think this a neat little feedback mechanism that we can borrow for subtle Ajax interactions on the web. These are actions that don’t change much of the content. The user needs to be able to potentially do lots of these actions on a single page without waiting for feedback every time.
On Huffduffer, for example, you might be looking at a listing of people that you can choose to follow or unfollow. The mechanism for doing that is a button per person. You might potentially be clicking lots of those buttons in quick succession. You want to know that each action has taken effect but you don’t want to be interrupted from your following/unfollowing spree.
You get some feedback in any case: the button changes. Maybe the text updates from “follow” to “unfollow” accompanied by a change in colour (this is what you’ll see on Twitter). The Super Mario style feedback is in addition to that, rather than instead of.
I’ve made a Codepen so you can see a reduced test case of the Super Mario feedback in action.
It’s a function that takes two arguments: the element that the feedback originates from (pass in a DOM node reference for this), and the contents of the feedback (this can be a string of text or it can be HTML …or SVG). When you call the function with those two arguments, this is what happens:
The JavaScript generates a span element and puts the feedback contents inside it.
Then it positions that element right over the element that the feedback originates from.
Then there’s a CSS transform. The feedback gets a translateY applied so it drifts upward. At the same time it gets its opacity reduced from 1 to 0 so it’s fading away.
Finally there’s a transitionend event that fires when the animation is over. Once that event fires, the generated span is destroyed.
When I first used this pattern on Huffduffer, I’m pretty sure I was using jQuery. A few years later I rewrote it in vanilla JavaScript. That was four years ago so I wonder if the code could be improved. Have a go if you fancy it.
Still, even if the code could benefit from an update, I’m pleased that the underlying pattern still holds true. I used it recently on The Session and it’s working a treat for a new Ajax interaction there (bookmarking or unbookbarking an item).
If you end up using this unobtrusive feedback pattern anyway, please let me know—I’d love to see more examples of it in the wild.
As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
Well, fast forward to the past few weeks, when I was contacted by one of the screen-reader users on The Session. There was, once again, a problem with the Ajax pagination, specifically with VoiceOver on iOS. The first page of results were read out just fine, but subsequent pages were not only never announced, the content was completely unavailable. The first page of results would’ve been included in the initial HTML, but the subsequent pages of results are injected with JavaScript (if JavaScript is available—otherwise it’s regular full-page refreshes all the way).
This pagination pattern shows up all over the site: lists of what’s new, search results, and more. I turned on VoiceOver and I was able to reproduce the problem straight away.
I started pulling apart my JavaScript looking for the problem. Was it something to do with how I was handling focus? I just couldn’t figure it out. And other parts of the site that used Ajax didn’t seem to be having the same problem. I was mystified.
Finally, I tracked down the problem, and it wasn’t in the JavaScript at all.
Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate rel="prev" and rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:
Those links control the area of the page with the search results.
That area of the page has an ID of “results”.
I should add aria-controls="results" to those links.
That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.
Just as the solution last time was to remove the aria-atomic attribute on the updated area, the solution this time was to remove the aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.
These forms have been enhanced with some Ajax to add some motion design: instead of refreshing the whole page, the next form is grabbed from the server while the previous one swooshes off the screen.
That wrapper also adds some ARIA attributes. The region of the page that will be updated gets an aria-live value of polite. Then, whenever new content is being injected, the same region gets an aria-busy value of true. Once the update is done, the aria-busy value gets changed back to false.
That all seems to work fine, but I was also giving the same region of the page an aria-atomic value of true. My thinking was that, because the whole region was going to be updated with new content from the server, it was safe to treat it as one self-contained unit. But it looks like this is what was causing the problem, especially when I was also adding and removing class values on the region in order to trigger animations. VoiceOver seemed to be getting a bit confused and overly verbose.
I’ve removed the aria-atomic attribute now. True to its name, I’m guessing it’s better suited to small areas of a document rather than big chunks. (If anyone has a good primer on when to use and when to avoid aria-atomic, I’m all ears).
I was glad I was able to find a fix—hopefully one that doesn’t negatively impact the experience in other screen readers. As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
For me, all of this really highlights the beauty of the web, when everyone is able to contribute to a community like The Session, regardless of what kind of software they may be using. In the tunes section, that’s really helped by the use of ABC notation, as I wrote five years ago:
One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.
That’s when it struck me that ABC notation is effectively alt text for sheet music!
Then, for those of use who can read sheet music, the text of the ABC notation is automatically turned into an SVG image using the brilliant abcjs. It’s like an enhancement that’s applied, I dunno, what’s the word …progressively.
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.
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 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:
Listen for any clicks on the page,
If a “previous” or “next” button is clicked, then:
Display a loading indicator,
Request the new data from the server, and
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:
Listen for any clicks on the page,
If a “previous” or “next” button is clicked, then:
Start a timer, and
Request the new data from the server.
If the timer reaches an upper limit, show a loading indicator.
When the server sends a response, cancel the timer and
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:
I click on a button,
I briefly see a loading indicator,
I see the new data.
Now your experience is:
I click on a button,
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?
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.
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.
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.
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>
But if you leave those out, then it’s an indeterminate progess bar:
<progress>loading...</progress>
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.
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.
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.
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.
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:
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.
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 DRY 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.
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 lazy loading.
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.
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…
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 loose coupling.
This is no accident. The web stack is rooted in Postel’s law. 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/
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.
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.
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.
This game-inspired feedback mechanism feels surprisingly familiar to me. Sign up or log in to Huffduffer to try it for yourself.
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.
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:
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.
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.
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.
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!
