Journal tags: platform

I’ve been thinking some more about the technical experience of booking a vaccination apointment and how much joy it brought me.

I’ve written before about how I’ve got a blind spot for the web so it’s no surprise that I was praising the use of a well marked-up form, styled clearly, and unencumbered by unnecessary JavaScript. But other technologies were in play too: Short Message Service (SMS) and email.

All of those technologies are platform-agnostic.

No matter what operating system I’m using, or what email software I’ve chosen, email works. It gets more complicated when you introduce HTML email. My response to that is the same as the old joke; you know the one: “Doctor, it hurts when I do this.” (“Well, don’t do that.”)

No matter what operating system my phone is using, SMS works. It gets more complicated when you introduce read receipts, memoji, or other additions. See my response to HTML email.

Then there’s the web. No matter what operating system I’m using on a device that could be a phone or a tablet or a laptop or desktop tower, and no matter what browser I’ve chosen to use, the World Wide Web works.

I originally said:

It feels like the principle of least power in action.

But another way of rephrasing “least power” is “most availability.” Technologies that are old, simple, and boring tend to be more widely available.

I remember when software used to come packaged in boxes and displayed on shelves. The packaging always had a list on the side. It looked like the nutritional information on a food product, but this was a list of “system requirements”: operating system, graphics card, sound card, CPU. I never liked the idea of system requirements. It felt so …exclusionary. And for me, the promise of technology was liberation and freedom to act on my own terms.

Hence my soft spot for the boring and basic technologies like email, SMS, and yes, web pages. The difference with web pages is that you can choose to layer added extras on top. As long as the fundamental functionality is using universally-supported technology, you’re free to enhance with all the latest CSS and JavaScript. If any of it fails, that’s okay: it falls back to a nice solid base.

Alas, many developers don’t build with this mindset. I mean, I understand why: it means thinking about users with the most boring, least powerful technology. It’s simpler and more exciting to assume that everyone’s got a shared baseline of newer technology. But by doing that, you’re missing out on one of the web’s superpowers: that something served up at the same URL with the same underlying code can simultaneously serve people with older technology and also provide a whizz-bang experience to people with the latest and greatest technology.

Anyway, I’ve been thinking about the kind of communication technologies that are as universal as email, SMS, and the web.

QR codes are kind of heading in that direction, although I still have qualms because of their proprietary history. But there’s something nice and lo-fi about them. They’re like print stylesheets in reverse (and I love print stylesheets). A funky little bridge between the physical and the digital. I just wish they weren’t so opaque: you never know if scanning that QR code will actually take you to the promised resource, or if you’re about to rickroll yourself.

Telephone numbers kind of fall into the same category as SMS, but with the added option of voice. I’ve always found the prospect of doing something with, say, Twilio’s API more interesting than building something inside a walled garden like Facebook Messenger or Alexa.

I know very little about chat apps or voice apps, but I don’t think there’s a cross-platform format that works with different products, right? I imagine it’s like the situation with native apps which require a different codebase for each app store and operating system. And so there’s a constant stream of technologies that try to fulfil the dream of writing once and running everywhere: React Native, Flutter.

They’re trying to solve a very clear and obvious problem: writing the same app more than once is really wasteful. But that’s the nature of the game when it comes to runtime-specific apps. The only alternative is to either deliberately limit your audience …or apply the principle of least power/most availability.

The wastefulness of having to write the same app for multiple platforms isn’t the only thing that puts me off making native apps. The exclusivity works in two directions. There’s the exclusive nature of the runtime that requires a bespoke codebase. There’s also the exclusive nature of the app store. It feels like a return to shelves of packaged software with strict system requirements. You can’t just walk in and put your software on the shelf. That’s the shopkeeper’s job.

There is no shopkeeper for the World Wide Web.

Cennydd wrote a really good post recently called Why don’t designers take Android seriously?

I completely agree with his assessment that far too many developers are ignoring or dismissing Android for two distasteful reasons:

1. Android is difficult
2. User behaviours are different:

Put uncharitably, the root issue is “Android users are poor”.

But before that, Cennydd compares the future trajectories of other platforms and finds them wanting in comparison to Android: Windows, iOS, …the web.

On that last comparison, I (unsurprisingly) disagree. But it’s not because I think the web is a superior platform; it’s because I don’t think the web is a platform at all.

I wrote about this last month:

The web is not a platform. It’s a continuum.

I think it’s a category error to compare the web to Android or Windows or iOS. It’s like comparing Coca-Cola, Pepsi, and liquid. The web is something that permeates the platforms. From one point of view, this appears to make the web less than the operating system that someone happens to be using to access it. But in the same way that a chicken is an egg’s way of reproducing and a scientist is the universe’s way of observing itself, an operating system is the web’s way of providing access to itself.

Wait a minute, though …Cennydd didn’t actually compare Android to the web. He compared Android to the web browser. Like I’ve said before:

We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.

But Cennydd’s comparison does raise an interesting question: what is a web browser exactly? Answering that question probably requires an answer to the question: what is the web?

(At this point you might be thinking, “Ah, this is just semantics!” and you’d be right. Abandon ship here if you feel that way. But to describe something as “just semantics” is like pointing at all the written works in every library and saying “but they’re just words”, or taking in the entire trajectory of human civilisation and saying “but those are just ideas”. So yeah, this is “just” semantics.)

So what is the web? Well the unsexy definition I’ve used in the past is that the web consists of files (e.g. HTML, CSS, JavaScript), accessible at URLs, delivered over HTTP. So FTP is not the web. Email is not the web. Gopher is not the web.

But to be honest, I don’t think that the Hypertext Transfer Protocol is the important part of the web; it’s the URLs that really matter. It’s the addressability of the files that’s the killer app of the web in my opinion.

I also don’t think that it’s the file formats themselves that define the web. Don’t get me wrong: I love HTML …and I have nothing against CSS or JavaScript. But if HTML were to disappear, the tears I would weep would not be so much for the format itself, but for the two decades of culture that have been stored with it.

I was re-reading Weaving The Web and in that book, Tim Berners-Lee describes his surprise when people started using HTML to mark up their content. He expected HTML to be used for indices that would point to the URLs of the actual content, which could be in any file format (PDF, word processessing documents, or whatever). It turned out that HTML had just enough expressiveness and grokability to be used instead of those other formats.

So I certainly don’t consider anything that happens to be written using HTML, CSS, and JavaScript to automatically be a part of the web. I can open up a text editor and make an HTML document but as long as it sits on my computer instead of being addressable by a URL, it’s not part of the web. Likewise, a native app might be powered by CSS and JavaScript under the hood, but without a URL, it’s not part of the web.

Perhaps then, a web browser is something that can access URLs. Certainly in pretty much every example of a web browser throughout the web’s history, the URL has been front and centre: if the web were a platform, the URL bar would be its command line.

But, like the rise of HTML, the visibility of the URL in a web browser is an accident of history. It was added almost as an afterthought as a power-user feature: why would most people care what the URL of the content happens to be? It’s the content itself that matters, and you’d get to that content not by typing URLs, but by following hyperlinks.

There’s an argument to be made that, with the rise of search engines, the visibility of URLs has become less important. See, for example, the way that every advertisement for a website on the Tokyo subway doesn’t show a URL; it shows what to type into a search engine instead (and I’ve started seeing this in some TV adverts here in the UK too).

So a web browser that doesn’t expose the URLs of what it’s rendering is still a web browser.

Now imagine a browser that you install on your device that doesn’t expose URLs, but under the hood it is navigating between URLs using HTTP, and rendering the content (images, JavaScript, CSS, HTML, JSON, whatever). That’s a pretty good description of many native apps. There’s a whole category of native apps that could just as easily be described as “artisanal web browsers” (and if someone wants to write a browser extension that replaces every mention of “native app” with “artisanal web browser” that would be just peachy).

Instagram’s native app is a web browser.

Facebook’s native app is a web browser.

Twitter’s native app is a web browser.

Like Paul said:

Monolithic browsers are not the only User Agent.

I was initially confused when Anna tweeted:

Reading the responses to @Cennydd’s tweet about designers needing to pay attention to Android. The web is fragmented. That’s our job.

I understood Cennydd’s point to be about native apps, not the web. But if, as I’ve just said, many native apps are in fact web browsers, does that mean that making native apps is a form of web development?

I don’t think so. I think making a native app has much more in common with making a web browser than it does with making a web site/app/thang. Certainly the work that Clearleft has done in this area felt that way: the Channel 4 News app is a browser for Channel 4 News; the Evo iPad app is a browser for Evo.

So if your job involves making browsers like those, then yes, you absolutely should be paying more attention to Android, for all the reasons that Cennydd suggests.

But if, like me, you have zero interest in making browsers—whether it’s a browser for Android, iOS, OS X, Windows, Blackberry, Linux, or NeXT—you should still be paying attention to Android because it’s just one of the many ways that people will be accessing the web.

It’s all too easy for us to fall into the trap of thinking that people will only be using traditional monolithic web browsers to access what we build. The truth is that our work will be accessed on the desktop, on mobile, and on tablets, but also on watches, on televisions, and sure, even fridges, but also on platforms that may not even have screens.

It’s certainly worth remembering that what you make will be viewed in the context of an artisanal browser. Like Jen says:

The “native apps are better” argument ignores the fact one of the most popular things to do in apps is read the web.

But just because we know that our work will be accessed on a whole range of devices and platforms doesn’t mean that we should optimise for those specific devices and platforms. That just won’t scale. The only sane future-friendly approach is to take a device-agnostic, platform-agnostic approach and deliver something that’s robust enough to work in this stunningly-wide range of browsers and user-agents (hint: progressive enhancement is your friend).

I completely agree with Cennydd: I think that ignoring Android is narrow-minded, blinkered and foolish …but I feel the same way about ignoring Windows, Blackberry, Nokia, or the Playstation. I also think it would be foolish to focus on any one of those platforms at the expense of others.

I love the fact that the web can be accessed on so many platforms and devices by so many different kinds of browsers. I only wish there more: more operating systems, more kinds of devices, more browsers. Any platform that allows more people to access the web is good with me. That’s why I, like Cennydd, welcome the rise of Android.

Stop seeing fragmentation. Start seeing diversity.

Stop me if you’ve heard this one before. You’re reading an article on Smashing Magazine or A List Apart or some other publication. The article is about a specific feature of CSS, or maybe JavaScript, or perhaps it’s exploring some of the newer additions to HTML. The article is good. It explains how to use this particular feature in your work. Then you read the comments. The first comment is inevitably from someone bemoaning the fact that they can’t use this feature because it isn’t supported in every browser. Specifically, it isn’t supported in some older version of Internet Explorer that they have to support. Therefore the entire article is rendered null and void.

That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.

It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0.

If you use a CSS feature that isn’t supported in a particular browser—like, say, an older version of Internet Explorer—that browser will simply ignore that CSS rule. So you don’t get that rounded corner, or text shadow, or whatever it was. Browsers have the same error-handling mechanism for HTML: if they see something they don’t understand, they just ignore it. The browser will not throw an error. The browser will not stop rendering the page. Browsers are very liberal in what they accept.

It’s a bit trickier with JavaScript: browsers will throw an error; browsers will stop processing the script. That’s why it’s important to use feature detection. That’s also why you definitely don’t want to rely on JavaScript for rendering your content—it’s the most fragile layer of the front-end stack. Note, I’m not saying don’t use JavaScript; I’m saying don’t rely on JavaScript. Otherwise you’ve got yourself a SPOF.

Anyway, my point is—and I can’t believe I still have to repeat this after all these years—websites do not need to look exactly the same in every browser.

“But my client!”, cries the Smashing Magazine commenter, “But my boss!”

If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.

It’s like Mike Monteiro says about clients: if they just don’t get something about your design, that’s not their fault; it’s yours. Explaining your design work is part of your design work. It’s the same with web development. It’s our job to explain how the web works …and how the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.

That was true fourteen years ago when John Allsopp wrote A Dao Of Web Design, and it’s still true today. Back then, designers and developers were comparing the web to print and finding it wanting. These days, designers and developers are comparing the web to native and finding it wanting. In both cases, I feel like they’re missing the fundamental point of the web: you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

Paul Kinlan published a post called This Is the Web Platform where he tabulates the current state of browser support for various features. “Pretty damning” he says:

the feature support that is ubiquitous across the web is actually pretty small especially if you are supporting IE8.

That’s true …from a certain point of view. But it depends on your definition of “support”. If your definition of “support” is “must look and work identically to the latest version of Chrome”, then yes, you’re going to have a smaller set of features you can use (you’re also going to live a miserable existence). But if your definition of “support” is “must be able to access the content and accomplish the task”, then as long as you’re using progressive enhancement, you can use all the features you want and support Internet Explorer 8, 7, 6, 5 …you can support every browser capable of connecting to the internet.

Like Brad said:

There is a difference between support and optimization.

I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.

It’s a subtle Lakoffian thing, but when we talk about “the browser” as if it were a single entity we might be unconsiously reinforcing the expectation that there is one Platonic ideal of browser rendering and that’s what we’re designing for.

There’s another phrase that bothers me, and it’s the phrase that Paul used in the title of his article: “the web platform”. This is something I talked about back in November in my presentation The Power of Simplicity:

But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.

I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.

What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.

And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.

And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.

The web is not a platform. It’s a continuum.