Tags: universal



Monday, August 7th, 2017

Progressive Progressive Web Apps - Tales of a Developer Advocate by Paul Kinlan

Paul goes into detail describing how he built a progressive web app that’s actually progressive (in the sense of “enhancement”). Most of the stuff about sharing code between server and client goes over my head, but I understood enough to get these points:

  • the “app shell” model is not the only—or even the best—way of building a progressive web app, and
  • always, always, always render from the server first.

Sunday, July 23rd, 2017

What I’ve learned about motor impairment

James gives—if you’ll pardon the pun— hands-on advice on making sites that consider motor impairment:

  • Don’t assume keyboard access is all you need
    • Auto complete/Autofill
    • Show me my password
  • Allow for fine motor control issues
    • Don’t autoplay videos
    • Avoid hover-only controls
    • Infinite scrolling considerations
  • Be mindful of touch
    • Avoid small hit targets
    • Provide alternate controls for touch gestures

Far from being a niche concern, visitors with some form of motor impairment likely make up a significant percentage of your users. I would encourage you to test your website or application with your less dominant hand. Is it still easy to use?

Friday, February 3rd, 2017

Isomorphic rendering on the JAM Stack

Phil describes the process of implementing the holy grail of web architecture (which perhaps isn’t as difficult as everyone seems to think it is):

I have been experimenting with something that seemed obvious to me for a while. A web development model which gives a pre-rendered, ready-to-consume, straight-into-the-eyeballs web page at every URL of a site. One which, once loaded, then behaves like a client-side, single page app.

Now that’s resilient web design!

Thursday, December 8th, 2016

Server Side React

Remy wants to be able to apply progressive enhancement to React: server-side and client-side rendering, sharing the same codebase. He succeeded, but…

In my opinion, an individual or a team starting out, or without the will, aren’t going to use progressive enhancement in their approach to applying server side rendering to a React app. I don’t believe this is by choice, I think it’s simply because React lends itself so strongly to client-side, that I can see how it’s easy to oversee how you could start on the server and progressive enhance upwards to a rich client side experience.

I’m hopeful that future iterations of React will make this a smoother option.

Friday, October 28th, 2016

ZEIT – Next.js

I haven’t made a website with React, but if and when I do, this Node.js framework looks like it aligns nicely with my priorities. It’s all about the universal JavaScript (the artist formerly known as isomorphic JavaScript).

Saturday, August 6th, 2016

React Isomorphic Demo

It is possible to use React without relying completely on client-side JavaScript to render all your content—though it’s certainly not the default way most tutorials teach React. This ongoing tutorial aims to redress that imbalance.

Besides the main benefit of server rendering giving faster page loads, it also enables large amounts of the site to run without JavaScript. There are many reasons why you would want this, but my personal reasons are that it allows you to completely drop support JavaScript in older browsers, but still have the site function.

Tuesday, June 28th, 2016

Accessibility Matters: Meet Our New Book, “Inclusive Design Patterns” (Pre-Release) – Smashing Magazine

I think it’s a safe bet that this new book by Heydon will be absolutely brilliant.

It’s a handbook with valuable, time-saving techniques that will help you avoid hacky workarounds and solve common issues effectively.

Monday, May 30th, 2016

marmelab/universal.css: The only CSS you will ever need

Ensure that your class names never go out of sync with your style declarations with this one simple trick:

Take any CSS rule you want to apply, replace : by -, and dots by -dot-, and you get the name of the corresponding universal css classname.

The only thing missing is immutability, so I would suggest also putting !important after each declaration in the CSS. Voila! No more specificity battles.

Sunday, May 22nd, 2016

Building Web Apps for Everyone - O’Reilly Media

Here’s a fantastic and free little book by Adam Scott. It’s nice and short, covering progressive enhancement, universal JavaScript, accessibility, and inclusive forms.

Download it now and watch this space for more titles around building inclusive web apps, collaboration, and maintaining privacy and security.

Did I mention that it’s free?

Monday, March 21st, 2016

Microsoft’s Radical Bet On A New Type Of Design Thinking

On universal design: “We’re reframing disability as an opportunity.”

One day someone will write a history of the Internet, in which that great series of tubes will emerge as one long chain of inventions not just geared to helping people connect in more ways, but rather, to help more and more types of people communicate just as nimbly as anyone else.

Saturday, December 5th, 2015

Universal React ◆ 24 ways

I have no hands-on experience with React, but this tutorial by Jack Franklin looks like a great place to start. Before the tutorial begins he succinctly and clearly outlines the perfect architecture for building on the web today:

  • The user visits www.yoursite.com and the server executes your JavaScript to generate the HTML it needs to render the page.
  • In the background, the client-side JavaScript is executed and takes over the duty of rendering the page.
  • The next time a user clicks, rather than being sent to the server, the client-side app is in control.
  • If the user doesn’t have JavaScript enabled, each click on a link goes to the server and they get the server-rendered content again.


Y’know, I had a chance to chat briefly with Jack at the Edge conference in London and I congratulated him on the launch of a Go Cardless site that used exactly this technique. He told me that the decision to flip the switch and make it act as a single page app came right at the end of the project. I think that points to a crucial mindset that’s reiterated here:

Now we’ll build the React application entirely on the server, before adding the client-side JavaScript right at the end.

Wednesday, May 13th, 2015

The Many Faces of The Web

Instead of coming up with all these new tools and JavaScript frameworks, shouldn’t we try to emphasize the importance of learning the underlying fundamentals of the web? Teach those who are just stepping to this medium and starting their careers. By not making our stack more and more complex, but by telling about the best practices that should guide our work and the importance of basic things.

Saturday, May 2nd, 2015

It’s a Website | treevis


Apps must run on specific platforms for specific devices. The app space, while large, isn’t universal.


Websites can be viewed by anyone with a web browser.

And that doesn’t mean foregoing modern features:

A web browser must only understand HTML. Further, newer HTML (like HTML 5) is still supported because the browser is built to ignore HTML it doesn’t understand. As a result, my site can run on the oldest browsers all the way to the newest ones. Got Lynx? No problem. You’ll still be able to find matches nearby. Got the latest smartphone and plentiful data? It’ll work there, too, and take advantage of its features.

This is why progressive enhancement is so powerful.

My site will take advantage of newer technologies like geolocation and local storage. However, the service will not be dependent on them.

Friday, March 7th, 2014

The Pastry Box Project, Scott Jehl, Friday, 7 March 2014

Scott writes an absolutely spot-on skewering of the idea that progressive enhancement means you’re going to spend your time catering to older browsers. The opposite is true.

Progressive Enhancement frees us to focus on the costs of building features for modern browsers, without worrying much about leaving anyone out. With a strongly qualified codebase, older browser support comes nearly for free.

Thursday, January 30th, 2014

Realizing One Web

A nice look at responsive design, progressive enhancement, and the principle of One Web.

Wednesday, August 7th, 2013

The Pastry Box Project | 7 August 2013, baked by Karen McGrane

Preach it, Karen!

“Why would someone ever want to do that?” is the wrong question. It doesn’t matter why they want to do it. The fact is that people do. The right question, the one that we all should be asking, is “how can we make a better experience for them?”

Friday, August 2nd, 2013

Being Practical - TimKadlec.com

Yet another timely reminder from Tim, prompted by the naysayers commenting on his previous excellent post on progressive enhancement, universal access, and the nature of the web.

Thursday, August 1st, 2013

Crippling the web - TimKadlec.com

A great call-to-arms from Tim, simply asking that we create websites that take advantage of the amazing universality of the web:

The web has the power to go anywhere—any network, any device, any browser. Why not take advantage of that?

Inevitably there is pushback in the comments from developers still in the “denial” stage of coming to terms with what the web is.

Sunday, January 15th, 2012

One Web, Many Devices

A presentation from the Update conference held in Brighton in September 2011.

Hello everybody.

Does anybody know where this is? Shout it out if you know where this is?

Ghent in the morning

Ghent! Yes, correct! Well done. Are you from Belgium, sir? Welcome. Welcome to Brighton. You’re from Ghent? Fantastic! You have a beautiful, beautiful town in Ghent.

I was there earlier this year and had a lovely time. I was speaking at an event there about the web, about digital preservation, and I really, really liked the place. And I met some lovely people.

Benny and Joke

This is Benny and Joke from Ghent. They were looking after me, making sure I had a good time. They drove me back to Brussels as well when it was time for me to get my Eurostar back here.

On the drive back, I was chatting with Joke about various things and we got to chatting about music. I play in a band and it turns out that Joke plays in a band as well. She played in a hardcore punk band.

We started talking about the whole hardcore scene and stuff, and all these different bands like the Subhumanz and Citizen Fish—going to see them play at all these different venues—and how inspiring that whole scene is, how egalitarian it is.

Joke said something to me that really resonated. Why she felt inspired to start making music herself—this kind of music—why she felt inspired to create a band, she said the great thing was that with this kind of music, you don’t need to ask for permission. You could just do it. You could form a band.

And as we talked about it some more we realised that’s exactly the same reason why we like doing stuff on the web. Because on the web you don’t need to ask for permission either, thanks to this guy: Sir Tim Berners-Lee. He could’ve made a lot of money from the web. But no, he decided it would be completely open and that you didn’t need to ask for permission.


Here we are, twenty years later. The web is twenty years old this year, which is pretty fantastic, going stronger than ever.

Coming up to the twentieth anniversary of the web, Sir Tim wrote an essay reiterating the design principles underlying the web. He said that the primary design principle underlying the web’s usefulness and growth is universality. That means that the web should be accessible to people with disabilities. It also means it should work with any kind of information, whether it’s a document or a point of data; whether it’s a silly tweet or a scholarly document. And he also reiterated the fact that it should be accessible from any kind of device: small screen or large, stationary or mobile.

The result is this huge tangled mess of a web. It’s chaotic, it’s unplanned, and it’s gorgeous …because none of these nodes on this web needed to ask for permission. That’s what makes it so beautiful.

Every single resource out there has a name, and that’s its URL. And once you know the name, once you know the URL, you can link to it. And you don’t need to ask for permission to link to that resource.

Every other kind of hypertext system that was proposed before then pretty much had some kind of idea of two-way linking. Sir Tim said “No, one-way linking: let’s see how it works out.” Sure, we’ve got problems, we’ve got linkrot, we’ve got all sorts of issues, but look at the result. Look at this amazing web we have.

So the web, I consider to be: resources (mostly HTML) delivered over HTTP, addressable at URLs. HTML, HTTP, URLs. That’s the web.

That means you could take two disparate, completely unconnected resources from over here and over here, and you could write a third resource that links the two of them together, creating something completely new, and you can publish that—and you didn’t need to ask for permission from either of those resources to create that. It’s pretty wonderful: you don’t need to ask for permission.

In the early days of the web, it had some competition from other types of media; CD-ROMS, for example. Does anyone remember Microsoft Encarta? It was pretty cool, it was pretty amazing: you had an encyclopedia on this small disk where previously you had all these books. It was great …but it didn’t scale. Eventually you’re going to need another CD-ROM, and another CD-ROM, and yet another CD-ROM, and you can’t link between them. I can’t link from one point in one CD-ROM to another point in another CD-ROM. These things aren’t addressable. I can’t just link them up (and I need permission).

Well it was CD-ROMs back then. Today it’s iPad apps, iPhone apps, other kinds of native apps: great little things, but they sit in isolation. I can’t link from one to another. I can’t join them up. Thousands—millions—of islands that are unconnected, unlike the web, this messy, tangle of interconnected nodes. It might not be as perfect as those native apps but in aggregate it’s absolutely gorgeous.

People often compare a great native app and say “Oh yeah, try and do that with a web app.” But I think a more fair comparison is to take any native app and compare it with the whole web.

The web is the killer app.

Ask yourself: what would you rather be contributing to—Encarta or Wikipedia?

Something that the internet is good at—not just the web, but the whole internet—is real-time communication. Before we had the web there was email. The web came along and there was a lot of talk about the real-time web. Now we have apps that are connected to the internet making it possible for people to communicate. And that’s great. I’m very excited about real-time communication. Because what the internet has done is collapsed geography so that we can instantaneously communicate from one side of the globe to the other. And that’s fantastic.

But there’s another kind of time, not just the real time, there’s the long time. How long does something stick around? How long will a resource remain?

Well, when something has a name—like a URL—if you take care of it, you can ensure that you are contributing to the long time as well as the real time; that something that’s valuable today should remain valuable next week, and next month, next year, five years from now, ten years from now.

I think that’s possible on the web. I think it’s a lot harder to do if what you’re creating is tied to a specific technology …requires a specific device. When that device goes, your creation goes with it.

Robin Sloan talks about these two kinds of time. He calls them flow and stock. He says:

Flow is the feed. It’s the stream of daily and sub-daily updates that remind people that you exits. Stock is the durable stuff. It’s what people discover via search. It’s what spreads slowly but surely. Flow is in the ascendent today but we neglect stock at our peril.

Steve Jobs once said:

You don’t need permission to be awesome.

And that’s absolutely true …on the web. In the app store? …you need permission to be awesome.

Has anyone here contributed an app to the app store? I’m sure you guys could tell me some stories about what it’s like to have to ask permission to be awesome.

I don’t just mean the app store. I mean any kind of walled-garden ecosystem—it was Facebook apps, it was Adobe Air for a while there—something that’s tied to a specific technology or a specific kind of device. You are now in debt to the company maintaining that.

I see a lot of Flash developers (or ex-Flash developers) moving to making iPhone apps and iPad apps, and I think I understand why it appeals. Because the whole time they were making these Flash creations, these Flash movies, pieces of art, products, services …they were putting them out there on the web but they were never really of the web. They required that plug-in. They were always enslaved to Macromedia (and then Adobe) and they simply saw the web as a distribution mechanism—and that’s fine. They were never contributing to the web so much as using the web to get their creations out there.

So when the iPhone and the iPad came along with its app store, it was simply another ecosystem that they could use as a distribution channel. All they were really doing was swapping one form of lock-in for another form of lock-in. So I understand the appeal there.

Here’s the thing… you might hear me talking about y’know, “Ah, the web the way it was twenty years ago was best and all these new fangled app stores and ecosystems and things …grrr! Get off my lawn, kids!” Right? That I’m being a curmudgeon, that I’m standing in the way of progress, that I’m standing in the way of the evolution of the internet.

I don’t think that’s true. Quite the opposite, actually…

So, the world before the web was a world of atoms rather than a world of bits. The thing with a world of atoms is there’s only so many atoms to go around. There’s limited shelf space in the real world. That means we need systems, we need companies, we need entities do decide what goes on those shelves.

Entire industries have sprung up built around deciding what books are going to get published, what films are going to get made, what music is going to get recorded. Effectively you’ve got companies—corporations—deciding what films you’re allowed see, what books you’re allowed read, what music you’re allowed listen to.

The web came along and smashed all that. Now everything—no matter how big or how small—everything is one link away. I can link to anything; something hugely world-famous or something incredibly obscure. That’s powerful and that threatens the existing ecosystem of control.

So we had publishers and consumers in the old world. We had the controllers and the controlled. Then the web came along and threatened all that.

There are obvious entities that are threatened by this new system. A totalitarian regime—to them, the web is definitely a threat. But it’s not just totalitarian governments that are threatened by the web. Other industries too.

There’s the music publishing industry. The film industry. We hear a lot about newspapers and magazines. All of these entities threatened by the web …these are all the same companies that are really, really excited about app stores.

Why are the excited? Because they see there is a way to turn back the clock, to turn back progress, to bring back scarcity and control, to return to a world of limited shelf space.

Magazine publishers are creaming their pants about the iPad. It’s going to “save” publishing. They think they can put the genie back in the bottle.

So when I rail against these closed ecosystems, I’m not railing against progress. Quite the opposite. I want more progress. I want more disruption. More chaos. More disorder. I want to see things fall apart a little bit more.

That’s why I publish on the web. I put something out there at a URL (it has a name) and it can be accessed from any device, large screen or small, stationary or mobile, colour or monochrome. And it will remain accessible.

I’ve been publishing on my site for ten years now. I fully expect to be publishing in another ten. I’m contributing to the stock, not just the flow. For ten years I’ve been linking to things without asking for permission and for ten years, if you wanted to link to me you didn’t need to ask me for permission, you could just do that. And the different devices, they’ve come and they’ve gone over those years and new devices will come and go but the formats I’m publishing in are open, are standards. Publishing HTML over HTTP at a URL.

So when you’re creating something, when you’re putting something out there, putting your creativity and your talent to work …ask yourself “Why?” What’s your motive? What’s your purpose? See if the medium and the format that you’re publishing in fits that purpose.

The first purpose—I guess there’s kind of hierarchy of purpose—the first purpose is simply to do it for the fun of it. And that’s fantastic. I think we need to do that, to just create stuff for the heck of it, for the joy of creating, of making, of figuring something out. Seb is someone who’s great at doing this. He just makes all sorts of stuff. Brendan Dawes does something new every week just for the fun of it. We need to keep doing that. That’s great.

Then I guess the next level is when you’re doing that as a profession. You’re getting paid for it. Now you’re not doing it for yourself, you’re doing it for your boss or your client. And, y’know, that doesn’t always work out so well. Because if the only reason you’re building something is to please your boss or please your client because they’re paying the bills …well you’re no better than a prostitute really.

The next step up is to do it for the end user. That’s what you’ve been hearing about today, to empathise with the people who will be using your creation, to think about their needs. I think our industry in general has got to that stage where we are thinking about the user, thinking about the people, thinking about their needs. We’re making these things to make their experiences better. User experience is definitely in the ascendent. That’s great. We’ve got a great point.

But there is another level …where you’re not just thinking about the user right now today and their flow, but where you start to think about all people. Start to think about our species and ask yourself if your creation is going to contribute to the betterment of our species.

I think publishing on the web, there’s a net gain for our species, there’s a net gain for our planet because we’re contributing to the stock as well as the flow. It’s not just for today. It’s for future generations as well.

That’s why I don’t want to tie my creations to specific technologies, specific devices. I don’t want to be locked in. I want this stuff to survive over time and contribute to our collective good.

I began by talking about music—specifically hardcore punk music—and I’m going to finish with another musician: John Lennon. Because when I see really talented makers, really talented creative people, pouring their talent and their creativity into these silos, into these walled gardens, where they’re just contributing to what one company wants—they think they’re being creative when actually they’re creating something that’s going to bloom and die—it saddens me. It saddens me and it makes me kind of angry as well. That creativity could be contributed to the greater good.

And I think John Lennon summed it up pretty well in his song Working Class Hero. He said:

You think you’re so clever and classless and free

…but you’re still fucking peasants as far as I can see.


This presentation is licenced under a Creative Commons attribution licence. You are free to:

Copy, distribute and transmit this presentation.
Adapt the presentation.

Under the following conditions:

You must attribute the presentation to Jeremy Keith.