Tags: 25

641

sparkline

Friday, August 23rd, 2019

Replying to

Yowza!

Far from questioning AMP’s right to exist, I want it to exist and compete on a level playing field—without being propped up by an unfair advantage in search results.

Classic fascism, that.

Sunday, August 18th, 2019

Picture 1 Picture 2 Picture 3

@Wordridden on the Queen Mary 2.

Picture 1 Picture 2 Picture 3

Jessica on deck.

map

Checked in at The Roxy Hotel. Hello, New York! — with Jessica

Saturday, August 10th, 2019

Feeling cute, might delete later.

Feeling cute, might delete later.

Friday, August 9th, 2019

You, yes you, should come to Indie Web Camp Brighton on October 19th and 20th:

https://adactio.com/journal/15612

You can register now:

https://ti.to/adactio/indie-webcamp-brighton-2019

See you there!

Thursday, August 8th, 2019

At Homebrew Website Club Brighton, @orbific has sent me down a rabbit hole of nostalgia by pointing out that http://brightonbloggers.com/ is still online!

Wednesday, August 7th, 2019

Replying to

That’s not at all what a navigation preload is.

Thursday, July 25th, 2019

Replying to

Ah, I see. Sounds like a shitty app. Or maybe it’s a shitty iOS-level sharing thing.

Replying to

Where is this link?

Principle

I like good design principles. I collect design principles—of varying quality—at principles.adactio.com. Ben Brignell also has a (much larger) collection at principles.design.

You can spot the less useful design principles after a while. They tend to be wishy-washy; more like empty aspirational exhortations than genuinely useful guidelines for alignment. I’ve written about what makes for good design principles before. Matthew Ström also asked—and answered—What makes a good design principle?

  • Good design principles are memorable.
  • Good design principles help you say no.
  • Good design principles aren’t truisms.
  • Good design principles are applicable.

I like those. They’re like design principles for design principles.

One set of design principles that I’ve included in my collection is from gov.uk: government design principles . I think they’re very well thought-through (although I’m always suspicious when I see a nice even number like 10 for the amount of items in the list). There’s a great line in design principle number two—Do less:

Government should only do what only government can do.

This wasn’t a theoretical issue. The multiple departmental websites that preceded gov.uk were notorious for having too much irrelevant content—content that was readily available elsewhere. It was downright wasteful to duplicate that content on a government site. It wasn’t appropriate.

Appropriateness is something I keep coming back to when it comes to evaluating web technologies. I don’t think there are good tools and bad tools; just tools that are appropriate or inapropriate for the task at hand. Whether it’s task runners or JavaScript frameworks, appropriateness feels like it should be the deciding factor.

I think that the design principle from GDS could be abstracted into a general technology principle:

Any particular technology should only do what only that particular technology can do.

Take JavaScript, for example. It feels “wrong” when a powerful client-side JavaScript framework is applied to something that could be accomplished using HTML. Making a blog that’s a single page app is over-engineering. It violates this principle:

JavaScript should only do what only JavaScript can do.

Need to manage state or immediately update the interface in response to user action? Only JavaScript can do that. But if you need to present the user with some static content, JavaScript can do that …but it’s not the only technology that can do that. HTML would be more appropriate.

I realise that this is basically a reformulation of one of my favourite design principles, the rule of least power:

Choose the least powerful language suitable for a given purpose.

Or, as Derek put it:

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.

ARIA should only do what only ARIA can do.

JavaScript should only do what only JavaScript can do.

CSS should only do what only CSS can do.

HTML should only do what only HTML can do.

Sunday, July 21st, 2019

Picture 1 Picture 2 Picture 3

Thank you, @mezzoblue and @curio_research for a lovely day of cycling in the Canadian countryside.

Saturday, July 20th, 2019

There’s a lovely resonance in reading @RobinSloan’s Sourdough back to back with @EdYong209’s I Contain Multitudes. One’s fiction, one’s non-fiction, but they’re both microbepunk.

https://adactio.com/notes/reading

Tuesday, July 16th, 2019

T + 50 years - 30 minutes:

https://apolloinrealtime.org/11/

T + 49 years + 364 days + 19 hours and counting.

Counting down to T + 50 here: https://apolloinrealtime.org/11/

Happy launch day, everyone!

Thursday, July 11th, 2019

Na píobairí.

Na píobairí.

Pádraic Mac Mathúna playing Seamus Ennis’s pipes and Paddy Glackin playing Seamus Ennis’s fiddle.

Pádraic Mac Mathúna playing Seamus Ennis’s pipes and Paddy Glackin playing Seamus Ennis’s fiddle.

Wednesday, July 10th, 2019

Checked in at Tom Malone's Pub & Market House. 🎶 — with Jessica map

Checked in at Tom Malone’s Pub & Market House. 🎶 — with Jessica

Checked in at Friels Pub. 🎵 — with Jessica map

Checked in at Friels Pub. 🎵 — with Jessica

Sunday, July 7th, 2019

Checked in at Friels Pub. 🎶 — with Jessica map

Checked in at Friels Pub. 🎶 — with Jessica