Writing, both code and prose, for me, is both an end product and an end in itself. I don’t want to automate away the things that give me joy.
And that is something that I’m more and more aware of as I get older – sources of joy. It’s good to diversify them, to keep track of them, because it’s way too easy to run out. Or to end up with just one, and then lose it.
The thing about luddites is that they make good punchlines, but they were all people.
What about a scarf or collar so the back of your neck prickles when somebody is talking about you on Twitter.
Or a ghost detector for homes, restaurants, etc that glows when someone is “visiting” in Google Maps/Facebook Pages or looking through a webcam? Maybe it would be better to control the air conditioning to produce a chill, or play barely audible infrasound, indications that there is a haunting in progress and the veil here is thin.
A new biography of Vera Rubin by Ashley Jean Yeager. One for the wishlist!
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.
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.
A look at the ubiquitous computing work that Bret Victor has been doing over the past few years at Dynamicland.
A bit of a tangent, but I love this description of reading maps:
Map reading is a complex and uniquely human skill, not at all obvious to a young child. You float out of your body and into the sky, leaving behind the point of view you’ve been accustomed to all your life. Your imagination turns squiggly blue lines and green shading into creeks, mountains, and forests seen from above. Bringing it all together in your mind’s eye, you can picture the surroundings.
Seamful design involves deliberately revealing seams to users, and taking advantage of features usually considered as negative or problematic.
This is the best explanation of quantum computing I’ve read. I mean, it’s not like I can judge its veracity, but I could actually understand it.
Design fiction from the UK parliament. I mean, it’s not exactly a classic of speculative fiction, but it sure beats a white paper.
There’s this idea that our homes — and our lives, and our workflows, and everything, really — should be micromanaged and accessed through technology, but, like many new experiments, this kind of technological advance has little actual real-world benefit. Like many new experiments, smart home technology is a perceived convenience masked as a wild hair — it’s advancement because we can, not because we need to.
A lyrical assessment of the current state of home automation.
Things are getting really smart on their own, but they’re still struggling to interact as a community — the promise of a smart home falling short because our appliances can’t draft a cohesive constitution. What’s more, we ourselves are struggling to modulate our reaction to these gadgets. We’re getting excited about automated lights and pretending the future has already come.
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:
select element.divs and spans).The advantage of the first choice is that it’s lightweight, it works everywhere, and the browser does all the hard work for you.
But…
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.
That’s where the second option comes in. By scripting your own dropdown, you get complete control over the appearance and behaviour of the widget. The disadvantage is that, because you’re now doing all the work instead of the browser, it’s up to you to do all the work—that means lots of JavaScript, thinking about edge cases, and making the whole thing accessible.
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.
Is it worth it? Rian Rietveld asks:
It is impossible to style select option. But is that really necessary? Is it worth abandoning the native browser behavior for a complete rewrite in JavaScript of the functionality?
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.
But I’m reminded of something that Eric often says:
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.
So far I’ve only been looking at the micro scale of a single interface element, but this tension between ubiquity and consistency plays out at larger scales too. Take page navigations. That’s literally what browsers do. Click on a link, and the browser fetches that URL, displaying progress at it goes. The alternative, as exemplified by single page apps, is to do all of that for yourself using JavaScript: figure out the routing, show some kind of progress, load some JSON, parse it, convert it into HTML, and update the DOM.
Personally, I tend to go for the first option. Partly that’s because I like to apply the rule of least power, but mostly it’s because I’m very lazy (I also have qualms about sending a whole lotta JavaScript down the wire just so the end user gets to do something that their browser would do for them anyway). But I get it. I understand why others might wish for greater control, even if it comes with a price tag of fragility.
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.
- Enhance!
Like, say…
select element.Or…
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:
Ubiquity, then consistency.
An interesting Xerox-PARC-like project dedicated to making a programmable platform out of paper and other physical objects.
A humane dynamic medium embraces the countless ways in which human beings use their minds and bodies, instead of cramming people into a tiny box of pixels.
Jonathan takes a look at the physical web. Like me, he’s excited by the possibilities. Although he says:
Sadly, my mind quickly devolved into the annoyance of numerous notifications, like popup windows and other distracting adverts, vying for my attention.
This is a common worry with the physical web, but it’s unfounded. All a beacon does is broadcast a URL. You have to actively look for the URLs being broadcast—they can’t send notifications.
It all just feels like QR codes. They’ll be all over the place and most of them won’t be very useful.
I understand this concern, but whereas QR codes are completely opaque to humans, at least URLs can—and should—be human-readable …so, unlike QR codes, a URL can give you some idea of what awaits.
The act of linking to this story is making it true.
“I don’t think there’s any law against this,” I said. How could there be a law against something that’s not possible?
In web development, we have this concept of progressive enhancement, which means that you start by building websites with the very most basic blocks - HTML elements. Then you enhance those basic elements with CSS to make them look better, then you add JavaScript to make them whizzy - the benefit being that if the JS or the CSS fail to load, you’ve still go the basic usable blocks underneath. I’m following this same principle in the house.
Related: this great chat between Jen Simmons and Stephanie Rieger.
I love this. I really love this. Remy absolutely nails what makes the web so great.
There’s the ubiquity:
If the viewer is using the latest technology beefy desktop computer that’s great. Equally they could view the website from a work computer, something old and locked in using a browser called IE8.
Then there’s the low barrier to entry—yes, even today:
It’s the web’s simplicity. Born out of a need to connect documents. As much as that might have changed with the latest generation of developers who might tell you that it’s hard and complex (and they’re right), at the same time it is not complicated. It’s still beautifully simple.
Anyone can do it. Anyone can publish content to the web, be it as plain text, or simple HTML formed only of <p> tags or something more elaborate and refined. The web is unabashed of it’s content. Everything and anything goes.
I might just print this out and nail it to the wall.
If you sit back for a moment, and think about just how many lives you can touch simply by publishing something, anything, to the web, it’s utterly mind blowing.
But we are promised and shown a world where technology is gorgeous and streamlined and helpful and light and unobtrusive. We don’t live in that world. That world is a fantasy. The hope that the Internet of Things will allow us to be free from daily headaches and logistical errors is naive.
Imagine a location service that sold itself on the fact that your personal information was securely contained in its environs, used by you and you alone. You could have devices on your person that used their sensors to know things about you – when you last ate, what your dining preferences are, what your blood-sugar is, and so on, but these devices would have no truck with the cloud, and they would not deliver that information to anyone else for analysis.
Any sufficiently advanced hacking is indistinguishable from a haunting. In the same way that many Internet of Things objects are referred to as ‘enchanting’ or ‘magical,’ with an intervention, they can very quickly become haunted.
history is time breaking up with itself
A great piece of hypertext from Aaron on the purpose of museums, the Copper Hewitt Pen, and matter battles.
A profile of the great work Aaron and Seb have been doing at the Cooper Hewitt museum. Have a read of this and then have a listen again to Aaron’s dConstruct talk.