But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
The web is so much bigger than the little boxes we try to put it in. The web is good at many things and not great (yet) at others. The web is a snowball rolling down hill, absorbing other technologies along the way. The web is an interactive window across space and time, a near instant connection to anyone on the planet. The web is something different. I wish we’d see the web more for itself, not defined by its nearest neighbor or navel-gazing over some hypothetical pathway we could have gone down decades ago.
Forgive my excitement, but this transcript of Charlie’s talk is so, so good—an equal mix of history and practical advice. Once you’ve read it, share it. I want everyone to have the pleasure of reading this inspiring piece!
It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.
Let’s just stop and think about that, because we take it for granted. I’m pulling chunks of code out of a running computer application, AND IT IS STILL WORKING.
Just how… INCREDIBLE is that? Can you imagine pulling random chunks of code out of the memory of your iPhone or Windows laptop, and still expecting it to work? Of course not! But with HTML, it’s a given.
The first 22 years of the web platform were revolutionary. The open, accessible, and feature-rich applications that exist on the platform continue to drive the global economy. The next 5 years look like they’ll be filled with more innovation and growth than ever.
The web will be the platform of the Next Big Thing. Not just as the distribution network many see it as today; the web platform will deliver the most innovative experiences. They’ll be innovative not just for how they use new technology, but also because of how easy it will be for new users to experience.
I keep thinking about this post from Baldur Bjarnason, Over-engineering is under-engineering. It took me a while to get my head around what he was saying, but now that (I think) I understand it, I find it to be very astute.
Let’s take a single interface element, say, a dropdown menu. This is the example Laura uses in her article for 24 Ways called Accessibility Through Semantic HTML. You’ve got two choices, broadly speaking:
Use the HTML select element.
The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.
You don’t get complete control. Because the browser is doing the heavy lifting, you can’t craft the details of the dropdown to look identical on different browser/OS combinations.
This is the point that Baldur makes: no matter how much you over-engineer your own custom solution, there’ll always be something that falls between the cracks. So, ironically, the over-engineered solution—when compared to the simple under-engineered native browser solution—ends up being under-engineered.
The answer, as ever, is it depends. It depends on your priorities. If your priority is having consistent control over the details, then foregoing native browser functionality in favour of scripting everything yourself aligns with your goals.
The web does not value consistency. The web values ubiquity.
Ubiquity; universality; accessibility—however you want to label it, it’s what lies at the heart of the World Wide Web. It’s the idea that anyone should be able to access a resource, regardless of technical or personal constraints. It’s an admirable goal, and what’s even more admirable is that the web succeeds in this goal! But sometimes something’s gotta give, and that something is control. Rian again:
The days that a website must be pixel perfect and must look the same in every browser are over. There are so many devices these days, that an identical design for all is not doable. Or we must take a huge effort for custom form elements design.
I think Jake’s navigation transitions proposal is fascinating. What if there were a browser-native way to get more control over how page navigations happen? I reckon that would cover the justification of 90% of single page apps.
That’s a great way of examining these kinds of decisions and questioning how this tension could be resolved. If people are frustrated by the lack of control in browser-native navigations, let’s figure out a way to give them more control. If people are frustrated by the lack of styling for select elements, maybe we should figure out a way of giving them more control over styling.
Hang on though. I feel like I’ve painted a divisive picture, like you have to make a choice between ubiquity or consistency. But the rather wonderful truth is that, on the web, you can have your cake and eat it. That’s what I was getting at with the three-step approach I describe in Resilient Web Design:
Identify core functionality.
Make that functionality available using the simplest possible technology.
The user needs to select an item from a list of options.
Use a select element.
The user needs to navigate to another page.
Use an a element with an href attribute.
The pushback I get from people in the control/consistency camp is that this sounds like more work. It kinda is. But honestly, in my experience, it’s not that much more work. Also, and I realise I’m contradicting the part where I said I’m lazy, but that’s why it’s called work. This is our job. It’s not about what we prefer; it’s about serving the needs of the people who use what we build.
Anyway, if I were to rephrase my three-step process in terms of under-engineering and over-engineering, it might look something like this:
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.
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.
“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?”
Does anybody know where this is? Shout it out if you know where this is?
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.
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.
Given some recent hand-wringing about the web as a “platform,” it seems appropriate to revisit this superb article from Ben. The specifics of the companies and technologies may have changed in the past year but the fundamental point remains the same:
Everything about web architecture; HTTP, HTML, CSS, is designed to serve and render content, but most importantly the web is formed where all of that content is linked together. That is what makes it amazing, and that is what defines it. This purpose and killer application of the web is not even comparable to the application frameworks of any particular operating system.
John reinforces the importance of universal access above the desire to build only for the newest shiniest devices:
Universality is a founding principle of the web. It is the manifesto the web has been built on, and I believe one of the key drivers of the almost unimaginable success of the web over these last two decades. We ignore that at the web’s peril.