Of all the buzzwords in tech, perhaps none has been deployed with as much philosophical conviction as “frictionless.” Over the past decade or so, eliminating “friction” — the name given to any quality that makes a product more difficult or time-consuming to use — has become an obsession of the tech industry, accepted as gospel by many of the world’s largest companies.
Wednesday, December 12th, 2018
Sunday, December 9th, 2018
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.
Monday, December 3rd, 2018
Here’s the talk I gave recently about indie web building blocks.
There’s fifteen minutes of Q&A starting around the 35 minute mark. People asked some great questions!
Thursday, November 22nd, 2018
I just binge-listened to the six episodes of the first season of this podcast from Stephen Fry—it’s excellent!
It covers the history of communication from the emergence of language to the modern day. At first I was worried that it was going to rehash some of the more questionable ideas in the risible Sapiens, but it turned out to be far more like James Gleick’s The Information or Tom Standage’s The Victorian Internet (two of my favourite books on the history of technology).
There’s no annoying sponsorship interruptions and the whole series feels more like an audiobook than a podcast—an audiobook researched, written and read by Stephen Fry!
Fax machines, pop-up books, radioactive televisions, writing boxes, microfilm readers, nuclear bomb cores, cupholders, bidets, jet engines, index cards, wiffle balls, oil barrels, lightning rods, playing cards, air conditioning, hair dryers, wheelchair ramps, handbags, diving bells, slippers, laundry chutes, sewing machines, pockets, skee-ball, safety pins, chalkboards, tote bags, holograms, hearing aids, dollhouses, billboards, airports, flash drives, cardigans, beer cans, stethoscopes, text editors, mugs, wallpaper, towel dispensers, bumber stickers, staplers, microscopes, fingerless gloves, wire hangers, toast, and more.
I’ll be in my bunk.
Wednesday, November 21st, 2018
The tools that characterize a person’s time and place in technological history are the ones that a person actually uses, the technologies relied upon so heavily that they can feel like an extension of oneself. This is part of how technology can define a culture, and why sometimes you forget the thing you’re using is technology at all. Until, eventually, inevitably, the technology is all but forgotten.
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.
Tuesday, October 23rd, 2018
This long zoom by Andy is right up my alley—a history of UX design that begins in 1880. It’s not often that you get to read something that includes Don Norman, Doug Engelbart, Lilian Gilbreth, and Vladimir Lenin. So good!
Monday, October 15th, 2018
Monday, October 1st, 2018
An ongoing timeline of computer technology in the form of blog posts by Sinclair Target (that’s a person, not a timeslipping transatlantic company merger).
This talk from Peter—looking at the long zoom of history—is right up my alley.
Sunday, September 30th, 2018
An online museum of sounds—the recordings of analogue machines.
Monday, September 24th, 2018
Saturday, September 22nd, 2018
Thursday, September 20th, 2018
This looks like a really interesting two-day event here in Brighton in November. Like Indie Web Camp, it features one day of talks followed by one day of making.
After a day of tech talks from project teams using their skills for social good, you’ll have the chance to take part in workshops and hackathons to use your own talents for a worthy cause.
And you get to go up the i360.
Friday, September 14th, 2018
As a community, we love to talk about meritocracy while perpetuating privilege.
This is playing out in full force in the front-end development community today.
Front-end development is a part of the field that has historically been at least slightly more accessible to women.
Shockingly, (not!) this also led to a salary and prestige gap, with back-end developers making on average almost $30,000 more than front-end.
(Don’t read the comments.)
Yes! Yes! Yes!
Our efforts to measure and improve UX are packed with tragically ironic attempts to love our users: we try to find ways to improve our app experiences by bloating them with analytics, split testing, behavioral analysis, and Net Promoter Score popovers. We stack plugins on top of third-party libraries on top of frameworks in the name of making websites “better”—whether it’s something misguided, like adding a carousel to appease some executive’s burning desire to get everything “above the fold,” or something truly intended to help people, like a support chat overlay. Often the net result is a slower page load, a frustrating experience, and/or (usually “and”) a ton of extra code and assets transferred to the browser.
Even tools that are supposed to help measure performance in order to make improvements—like, say, Real User Monitoring—require you to add a script to your web pages …thereby increasing the file size and degrading performance! It’s ironic, in that Alanis Morissette sense of not understanding what irony is.
Stacking tools upon tools may solve our problems, but it’s creating a Jenga tower of problems for our users.
This is a great article about evaluating technology.
Monday, September 10th, 2018
Robustness and least power
There’s a great article by Steven Garrity over on A List Apart called Design with Difficult Data. It runs through the advantages of using unusual content to stress-test interfaces, referencing Postel’s Law, AKA the robustness principle:
Be conservative in what you send, be liberal in what you accept.
Even though the robustness principle was formulated for packet-switching, I see it at work in all sorts of disciplines, including design. A good example is in best practices for designing forms:
Every field you ask users to fill out requires some effort. The more effort is needed to fill out a form, the less likely users will complete the form. That’s why the foundational rule of form design is shorter is better — get rid of all inessential fields.
In other words, be conservative in the number of form fields you send to users. But then, when it comes to users filling in those fields:
It’s very common for a few variations of an answer to a question to be possible; for example, when a form asks users to provide information about their state, and a user responds by typing their state’s abbreviation instead of the full name (for example, CA instead of California). The form should accept both formats, and it’s the developer job to convert the data into a consistent format.
In other words, be liberal in what you accept from users.
I find the robustness principle to be an immensely powerful way of figuring out how to approach many design problems. When it comes to figuring out what specific tools or technologies to use, there’s an equally useful principle: the rule of least power:
Choose the least powerful language suitable for a given purpose.
On the face of it, this sounds counter-intuitive; why forego a powerful technology in favour of something less powerful?
Well, power comes with a price. Powerful technologies tend to be more complex, which means they can be trickier to use and trickier to swap out later.
In the web front-end stack — HTML, CSS, JS, and ARIA — if you can solve a problem with a simpler solution lower in the stack, you should. It’s less fragile, more foolproof, and just works.
- Instead of using ARIA to give a certain
rolevalue to a
span, try to use a more suitable HTML element instead.
It sounds a lot like the KISS principle: Keep It Simple, Stupid. But whereas the KISS principle can be applied within a specific technology—like keeping your CSS manageable—the rule of least power is all about evaluating technology; choosing the most appropriate technology for the task at hand.
There are some associated principles, like YAGNI: You Ain’t Gonna Need It. That helps you avoid picking a technology that’s too powerful for your current needs, but which might be suitable in the future: premature optimisation. Or, as Rachel put it, stop solving problems you don’t yet have:
So make sure every bit of code added to your project is there for a reason you can explain, not just because it is part of some standard toolkit or boilerplate.
There’s no shortage of principles, laws, and rules out there, and I find many of them very useful, but if I had to pick just two that are particularly applicable to my work, they would be the robustness principle and the rule of least of power.
After all, if they’re good enough for Tim Berners-Lee…
Sunday, September 9th, 2018
Videos for the whole first season of James Burke’s brilliant Connections TV series.
Internet Archive and chill.