Tags: technology

406

sparkline

Wednesday, December 12th, 2018

Is Tech Too Easy to Use? - The New York Times

Seams!

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.

Sunday, December 9th, 2018

The Case Against Quantum Computing - IEEE Spectrum

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

Voxxed Thessaloniki 2018 - Opening Keynote - Taking Back The Web - YouTube

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

Great Leap Years - Official site of Stephen Fry

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!

Essays « Object Lessons

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

Can You Still Send a Telegram? - The Atlantic

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.

Folding Beijing - Uncanny Magazine

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

UX past, present, and future | Clearleft

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!

Escape from Spiderhead | The New Yorker

Madeline sent me a link to this short story from 2010, saying:

It’s like if Margaret Atwood and Thomas Pynchon wrote an episode of Black Mirror. I think you’ll like it!

Yes, and yes.

Monday, October 15th, 2018

We are Oxvik

Ooh, this is an exciting collaboration! Jon and Brian have teamed up to form a lovely little cooperative.

Monday, October 1st, 2018

Two-Bit History

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).

Peter Gasston | People don’t change - YouTube

This talk from Peter—looking at the long zoom of history—is right up my alley.

Peter Gasston | People don’t change

Sunday, September 30th, 2018

CTS - conserve the sound

An online museum of sounds—the recordings of analogue machines.

Monday, September 24th, 2018

Salty JavaScript analogy - HankChizlJaw

JavaScript is like salt. If you add just enough salt to a dish, it’ll help make the flavour awesome. Add too much though, and you’ll completely ruin it.

Saturday, September 22nd, 2018

How To Kill Your Tech Industry

I’m currently making my way through Programmed Inequality by Marie Hicks. In that book and in this article, she describes how Britain squandered its lead in the field of computing through indemic sexism. There’s also the remarkable story of Dame Stephanie Shirley.

Thursday, September 20th, 2018

Good Tech Conf | Using technology for social good

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

CSS dismissal is about exclusion, not technology

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.)

Breaking the Deadlock Between User Experience and Developer Experience · An A List Apart Article

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.

Take the front-end stack, for example: HTML, CSS, and JavaScript. HTML and CSS are declarative, so you don’t get as much precise control as you get with an imperative language like JavaScript. But JavaScript comes with a steeper learning curve and a stricter error-handling model than HTML or CSS.

As a general rule, it’s always worth asking if you can accomplish something with a less powerful technology:

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 JavaScript to do animation, see if you can do it in CSS instead.
  • Instead of using JavaScript to do simple client-side form validation, try to use HTML input types and attributes like required.
  • Instead of using ARIA to give a certain role value to a div or 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

Internet Archive: Connections season 1, episodes 1-10

Videos for the whole first season of James Burke’s brilliant Connections TV series.

Internet Archive and chill.