Thursday, May 2nd, 2019
Tuesday, March 5th, 2019
Hui-Jing talks through her process of building a to-do app on Glitch using a progressive enhancement mindset:
Monday, February 25th, 2019
Accessibility on The Session
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.
You can see similar functionality—without the animation—wherever there’s pagination on the site.
The pagination is using Ajax to enhance regular prev/next links—here’s the code.
The multi-step forms are using Ajax to enhance regular form submissions—here’s the code for that.
Both of those are using a wrapper I wrote for XMLHttpRequest.
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
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.
Saturday, December 15th, 2018
A terrific explanation of the
aria-live attribute from Ire. If you’re doing anything with Ajax, this is vital knowledge.
Tuesday, June 5th, 2018
A thorough explanation of the history and inner workings of Cross-Origin Resource Sharing.
Like tales of a mythical sea beast, every developer has a story to tell about the day CORS seized upon one of their web requests, dragging it down into the inexorable depths, never to be seen again.
Monday, May 21st, 2018
Friday, April 20th, 2018
This is a really good use-case for cancelling fetch requests: making API calls while autocompleting in search.
Wednesday, May 3rd, 2017
This is definitely the best review of any of my books.
Tuesday, January 3rd, 2017
Wednesday, November 16th, 2016
Usability Testing of Inline Form Validation: 40% Don’t Have It, 20% Get It Wrong - Articles - Baymard Institute
I saw Christian speak on this topic at Smashing Conference in Barcelona. Here, he takes a long hard look at some of the little things that sites get wrong when doing validating forms on the fly. It’s all good sensible stuff, although it sounds a bit medical when he takes about “Premature Inline Validation.”
Wednesday, October 12th, 2016
This is a truly fantastic example of progressive enhancement applied to a form.
What I love about this is that it shows how progressive enhancement isn’t a binary on/off choice: there are layers and layers of enhancements here, from simple inline validation all the way to service workers and background sync, with many options in between.
Tuesday, May 31st, 2016
Turbolinks intercepts all clicks on
a hreflinks to the same domain. When you click an eligible link, Turbolinks prevents the browser from following it. Instead, Turbolinks changes the browser’s URL using the History API, requests the new page using
XMLHttpRequest, and then renders the HTML response.
During rendering, Turbolinks replaces the current
bodyelement outright and merges the contents of the
documentobjects, and the HTML
htmlelement, persist from one rendering to the next.
Here’s the mustard it’s cutting:
It depends on the HTML5 History API and Window.requestAnimationFrame. In unsupported browsers, Turbolinks gracefully degrades to standard navigation.
This approach matches my own mental model for building on the web—I might try playing around with this on some of my projects.
Sunday, May 29th, 2016
A little progress
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
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.
Saturday, October 17th, 2015
It’s official: hash bang URLs are an anti-pattern, and if you want your content indexed by Google, use progressive enhancement:
Since the assumptions for our 2009 proposal are no longer valid, we recommend following the principles of progressive enhancement.
Tuesday, February 10th, 2015
Sensible words from Christian.
Web applications don’t follow new rules.
And frameworks will not help:
A lot of them are not really fixing fundamental problems of the web. What they do is add developer convenience. … This would be totally OK, if we were honest about it.
Tuesday, January 27th, 2015
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.
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?
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.
Sunday, March 2nd, 2014
Async, Ajax, and animation
- 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.
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.
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.
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 takes
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:
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.
Sunday, December 15th, 2013
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?
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.
Tuesday, June 18th, 2013
A terrific case study in progressive enhancement: starting with a good ol’ form that works for everybody and then adding on features like Ajax, SVG, the History API …the sky’s the limit.
Saturday, December 8th, 2012
A really nice explanation by Todd Kloots of Twitter’s use of progressive enhancement with Ajax and the HTML5 History API. There’s even a shout for Hijax in there.