While being driven around England it struck me that humans are currently like the filling in a sandwich between one slice of machine — the satnav — and another — the car. Before the invention of sandwiches the vehicle was simply a slice of machine with a human topping. But now it’s a sandwich, and the two machine slices are slowly squeezing out the human filling and will eventually be stuck directly together with nothing but a thin layer of API butter. Then the human will be a superfluous thing, perhaps a little gherkin on the side of the plate.
Monday, January 6th, 2020
Thursday, September 19th, 2019
When I liveblogged Jason’s talk at An Event Apart in Chicago, I included this bit of reporting:
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle.
Well, here is that story. It’s a good one, with some practical takeaways (if you’ll pardon the pun):
- Use HTML5 input features
- Support autofill
- Make autofill part of your test plans
Saturday, July 6th, 2019
This is a great piece! It starts with a look back at some of the great minds of the nineteenth century: Herschel, Darwin, Babbage and Lovelace. Then it brings us, via JCR Licklider, to the present state of the web before looking ahead to what the future might bring.
So what will the life of an interface designer be like in the year 2120? or 2121 even? A nice round 300 years after Babbage first had the idea of calculations being executed by steam.
I think there are some missteps along the way (I certainly don’t think that inline styles—AKA CSS in JS—are necessarily a move forwards) but I love the idea of applying chaos engineering to web design:
Think of every characteristic of an interface you depend on to not ‘fail’ for your design to ‘work.’ Now imagine if these services were randomly ‘failing’ constantly during your design process. How might we design differently? How would our workflows and priorities change?
Tuesday, June 18th, 2019
I’ve been kicking the tyres on this great new tool from Remy. Give it a URL and it’ll find all the links in its
h-entrys and automatically send webmentions to them. Very cool!
The documentation on the site is excellent, guiding you to the right solution for your particular needs. Read Remy’s announcement:
I’ve also tried very hard to get the documentation to be as welcoming as I can. I’ve tried to think about my dear visitor and what they want to do with the software, rather than type my typical developer approach to documentation - listing all the features and options.
Tuesday, February 19th, 2019
An Interview with Nick Harkaway: Algorithmic Futures, Literary Fractals, and Mimetic Immortality - Los Angeles Review of Books
Nick Harkaway on technology in fiction:
Humans without tools are not magically pure; they’re just unvaccinated, cold, and wet.
SF is how we get to know ourselves, either who we are or who we might be. In terms of what is authentically human, SF has a claim to be vastly more honest and important than a literary fiction that refuses to admit the existence of the modern and goes in search of a kind of essential humanness which exists by itself, rather than in the intersection of people, economics, culture, and science which is where we all inevitably live. It’s like saying you can only really understand a flame if you get rid of the candle. Good luck with that.
And on Borges:
He was a genius, and he left this cryptic, brilliant body of work that’s poetic, incomplete, astonishing. It’s like a tasting menu in a restaurant where they let you smell things that go to other tables and never arrive at yours.
Sunday, January 27th, 2019
Tuesday, January 22nd, 2019
A history of buttons …and the moral panic and outrage that accompanies them.
By looking at the subtexts behind complaints about buttons, whether historically or in the present moment, it becomes clear that manufacturers, designers and users alike must pay attention to why buttons persistently engender critiques. Such negativity tends to involve one of three primary themes: fears over deskilling; frustration about lack of user agency/control; or anger due to perceptions of unequal power relations.
Monday, January 7th, 2019
Dave on the opaqueness of toolchains:
As toolchains grow and become more complex, unless you are expertly familiar with them, it’s very unclear what transformations are happening in our code. Tracking the differences between the input and output and the processes that code underwent can be overwhelming. When there’s a problem, it’s increasingly difficult to hop into the assembly line and diagnose the issue.
There’s a connection here to one of the biggest issues with what’s currently being labelled “AI”:
In the same way AI needs some design to show its work in how it came to its final answer, I feel that our automated build tools could use some help as well.
I really like this suggestion for making the invisble visible:
I sometimes wonder if Webpack or Gulp or [Insert Your Build Tool Here] could benefit from a Scratch-like interface for buildchains.
Wednesday, November 21st, 2018
The terrific Hugo-winning short story about inequality, urban planning, and automation, written by Hao Jinfang and translated by Ken Liu (who translated The Three Body Problem series).
Hao Jinfang also wrote this essay about the story:
I’ve been troubled by inequality for a long time. When I majored in physics as an undergraduate, I once stared at the distribution curve for American household income that showed profound inequality, and tried to fit the data against black-body distribution or Maxwell–Boltzmann distribution. I wanted to know how such a curve came about, and whether it implied some kind of universality: something as natural as particle energy distribution functions, so natural it led to despair.
Saturday, September 1st, 2018
Just last week I came across an example of what Ethan describes here: accessibility (in a pattern library) left to automatic checks rather than human experience.
Tuesday, July 17th, 2018
Rachel follows up on my recent post about CSS grid in old IE with her thoughts.
As Jeremy notes, the usefulness of a tool like Autoprefixer is diminishing, which is a good thing. It is becoming far easier to code in a way that supports all browsers, where support means usable in an appropriate way for the technology the user has in front of them. Embrace that, and be glad for the fact that we can reduce complexity based on the increasing interoperability of CSS in our browsers.
Friday, July 13th, 2018
CSS grid in Internet Explorer 11
When I was in Boston, speaking on a lunchtime panel with Rachel at An Event Apart, we took some questions from the audience about CSS grid. Inevitably, a question about browser support came up—specifically about support in Internet Explorer 11.
(Technically, you can use CSS grid in IE11—in fact it was the first browser to ship a version of grid—but the prefixed syntax is different to the standard and certain features are missing.)
Rachel gave a great balanced response, saying that you need to look at your site’s stats to determine whether it’s worth the investment of your time trying to make a grid work in IE11.
My response was blunter. I said I just don’t consider IE11 as a browser that supports grid.
Now, that might sound harsh, but what I meant was: you’re already dividing your visitors into browsers that support grid, and browsers that don’t …and you’re giving something to those browsers that don’t support grid. So I’m suggesting that IE11 falls into that category and should receive the layout you’re giving to browsers that don’t support grid …because really, IE11 doesn’t support grid: that’s the whole reason why the syntax is namespaced by
You could jump through hoops to try to get your grid layout working in IE11, as detailed in a three-part series on CSS Tricks, but at that point, the amount of effort you’re putting in negates the time-saving benefits of using CSS grid in the first place.
Frankly, the whole point of prefixed CSS is that is not used after a reasonable amount of time (originally, the idea was that it would not be used in production, but that didn’t last long). As we’ve moved away from prefixes to flags in browsers, I’m seeing the amount of prefixed properties dropping, and that’s very, very good. I’ve stopped using
autoprefixer on new projects, and I’ve been able to remove it from some existing ones—please consider doing the same.
And when it comes to IE11, I’ll continue to categorise it as a browser that doesn’t support CSS grid. That doesn’t mean I’m abandoning users of IE11—far from it. It means I’m giving them the layout that’s appropriate for the browser they’re using.
Thursday, July 12th, 2018
A near-future sci-fi short by Hannu Rajaniemi that’s right on the zeitgest money.
The app in her AR glasses showed the car icon crawling along the winding forest road. In a few minutes, it would reach the sharp right turn where the road met the lake. The turn was marked by a road sign she had carefully defaced the previous day, with tiny dabs of white paint. Nearly invisible to a human, they nevertheless fooled image recognition nets into classifying the sign as a tree.
Saturday, June 16th, 2018
An even-handed assessment of the benefits and dangers of machine learning.
Sunday, June 3rd, 2018
I’ve come to believe that the goal of any good framework should be to make itself unnecessary.
The ultimate purpose of PhoneGap is to cease to exist.
That makes total sense, especially if your code is a polyfill—those solutions are temporary by design. Autoprefixer is another good example of a piece of code that becomes less and less necessary over time.
But I think it’s equally true of any successful framework or library. If the framework becomes popular enough, it will inevitably end up influencing the standards process, thereby becoming dispensible.
querySelector without jQuery. The library proved the need for the feature. The same is true for a whole load of DOM scripting features.
The same process is almost certain to occur with React—it’s a good bet there will be a standardised equivalent to the virtual DOM at some point.
When Google first unveiled AMP, its intentions weren’t clear to me. I hoped that it existed purely to make itself redundant:
As well as publishers creating AMP versions of their pages in order to appease Google, perhaps they will start to ask “Why can’t our regular pages be this fast?” By showing that there is life beyond big bloated invasive web pages, perhaps the AMP project will work as a demo of what the whole web could be.
Alas, as time has passed, that hope shows no signs of being fulfilled. If anything, I’ve noticed publishers using the existence of their AMP pages as a justification for just letting their “regular” pages put on weight.
Worse yet, the messaging from Google around AMP has shifted. Instead of pitching it as a format for creating parallel versions of your web pages, they’re now also extolling the virtues of having your AMP pages be the only version you publish:
In fact, AMP’s evolution has made it a viable solution to build entire websites.
On an episode of the Dev Mode podcast a while back, AMP was a hotly-debated topic. But even those defending AMP were doing so on the understanding that it was more a proof-of-concept than a long-term solution (and also that AMP is just for news stories—something else that Google are keen to change).
But now it’s clear that the Google AMP Project is being marketed more like a framework for the future: a collection of web components that prioritise performance …which is kind of odd, because that’s also what Google’s Polymer project is. The difference being that pages made with Polymer don’t get preferential treatment in Google’s search results. I can’t help but wonder how the Polymer team feels about AMP’s gradual pivot onto their territory.
If the AMP project existed in order to create a web where AMP was no longer needed, I think I could get behind it. But the more it’s positioned as the only viable solution to solving performance, the more uncomfortable I am with it.
Which, by the way, brings me to one of the most pernicious ideas around Google AMP—positioning anyone opposed to it as not caring about web performance. Nothing could be further from the truth. It’s precisely because performance on the web is so important that it deserves a long-term solution, co-created by all of us: not some commandents delivered to us from on-high by one organisation, enforced by preferential treatment by that organisation’s monopoly in search.
It’s the classic logical fallacy:
- Performance! Something must be done!
- AMP is something.
- Now something has been done.
By marketing itself as the only viable solution to the web performance problem, I think the AMP project is doing itself a great disservice. If it positioned itself as an example to be emulated, I would welcome it.
I wish that AMP were being marketed more like a temporary polyfill. And as with any polyfill, I look forward to the day when AMP is no longer necesssary.
I want AMP to become extinct. I genuinely think that the Google AMP team should share that wish.
Monday, May 21st, 2018
Almost every technological innovation over the last 300 years has had side effects which actually increase the number of opportunities for employment. The general trend is that the easier something is to do, the more demand there is for it.
Cameron looks at the historical effects of automation and applies that to design systems. The future he sees is one of increased design democratisation and participation.
This is actually something that designers have been championing for decades – inclusive design at all levels of the company, and an increase in design thinking at all stages of product development. Now that we finally have a chance of achieving that it’s not a time to be scared. It’s a time to be celebrated.
Saturday, April 28th, 2018
If you’re looking for an accessible standalone autocomplete script, this one from GDS looks very good (similar to Lea’s awesomplete).
Monday, April 23rd, 2018
During the Industrial Revolution, as new machines were invented to increase output, business owners often dreamed of an entirely automated workforce—of a factory without workers. I assume their workers had different dreams.
Ethan thinks through the ethical implications of increasing automation and efficiency über alles:
I can’t stop thinking about how much automation has changed our industry already. And I know the rate of automation is only going to accelerate from here.
At the very least, maybe it’s worth asking ourselves what might happen next.
Saturday, April 21st, 2018
A smart look back at historical examples of regulation and what we can learn from them today, by Justine Leblanc:
- Railways in the UK: Public interest as a trigger for regulation
- Engineering in Canada: Accountability as a trigger for regulation
- The automotive industry in the USA: Public outrage as a trigger for regulation
Friday, April 20th, 2018
This is a really good use-case for cancelling fetch requests: making API calls while autocompleting in search.