Friday, June 7th, 2019
Wednesday, May 22nd, 2019
Bruce wonders why Google seems to prefer separate chunks of JSON-LD in web pages instead of interwoven microdata attributes:
I strongly feel that metadata that is separated from the user-visible data associated with it highly susceptible to metadata partial copy-paste necrosis. User-visible text is also developer-visible text. When devs copy/ paste that, it’s very easy to forget to copy any associated metadata that’s not interleaved, leading to errors.
Friday, April 5th, 2019
This article by Ian Bogost from a few years back touches on one of the themes in the talk I gave at New Adventures:
“Engineer” conjures the image of the hard-hat-topped designer-builder, carefully crafting tomorrow. But such an aspiration is rarely realized by computing. The respectability of engineering, a feature built over many decades of closely controlled, education- and apprenticeship-oriented certification, becomes reinterpreted as a fast-and-loose commitment to craftwork as business.
Sunday, February 24th, 2019
Programming lessons from Umberto Eco and Emily Wilson.
Converting the analog into the digital requires discretization, leaving things out. What we filter out—or what we focus on—depends on our biases. How do conventional translators handle issues of bias? What can programmers learn from them?
Friday, November 23rd, 2018
Some tips for getting responsive images to work well on the Apple Watch:
- test your layouts down to 136-
300w-ish resources in your full-width
- art direct to keep image subjects legible
- say the magic
Tuesday, July 10th, 2018
The ideas and images that come to mind when you think of technology as an instrument are more useful than if you think of it as a tool. Instruments — I’m specifically talking about musical instruments — are a way to create culture.
You approach instruments with a set of expectations and associations that are more humane. It’s built into their very purpose. Instruments are meant to make something for other people, not making things. When you use an instrument, you have an expectation that it is going to take effort to use it well. Using an instrument takes practice. You form a relationship with that object. It becomes part of your identity that you make something with it. You tune it. You understand that there’s no such thing as a “best” guitar in the same way that there’s not necessarily a “best” phone.
Wednesday, April 4th, 2018
Conceding that a typeface is a tool sounds dangerously close to an excuse: toolmakers cannot be held responsible for things made with their tools, or the tasks leading up to those things. They are only responsible for the making of the tool itself. If a person decides to use a hammer to drive home a screw, then so be it. The hammer was only designed for nails. It’s not our fault the typography doesn’t look good. The typeface is just a tool — you’re using it wrong.
Wednesday, March 7th, 2018
Metaballs, not to be confused with meatballs, are organic looking squishy gooey blobs.
Here’s the maths behind the metaballs (implemented in SVG).
Monday, December 18th, 2017
Spot-on take by Ted Chiang:
I used to find it odd that these hypothetical AIs were supposed to be smart enough to solve problems that no human could, yet they were incapable of doing something most every adult has done: taking a step back and asking whether their current course of action is really a good idea. Then I realized that we are already surrounded by machines that demonstrate a complete lack of insight, we just call them corporations.
Related: if you want to see the paperclip maximiser in action, just look at the humans destroying the planet by mining bitcoin.
Friday, December 8th, 2017
This 1993 article by Mark Weiser is relevant to our world today.
Take intelligent agents. The idea, as near as I can tell, is that the ideal computer should be like a human being, only more obedient. Anything so insidiously appealing should immediately give pause. Why should a computer be anything like a human being? Are airplanes like birds, typewriters like pens, alphabets like mouths, cars like horses? Are human interactions so free of trouble, misunderstanding, and ambiguity that they represent a desirable computer interface goal? Further, it takes a lot of time and attention to build and maintain a smoothly running team of people, even a pair of people. A computer I need to talk to, give commands to, or have a relationship with (much less be intimate with), is a computer that is too much the center of attention.
Tuesday, September 12th, 2017
Some great ideas here about using metaphors when explaining technical topics.
I really like these four guidelines for good metaphors:
Friday, September 1st, 2017
Manifest files can have categories now. Time to update those JSON files.
Wednesday, August 9th, 2017
Some of these really tickle my fancy bone.
That’s the icing on the iceberg
You let the horse out of the cart
What planet are you living under?
That opens a whole other kettle of fish
The cat’s out of the barn
Patience comes to those who wait
That’s right up my cup of tea
Friday, December 30th, 2016
This document provides Best Practices related to the publication and usage of data on the Web designed to help support a self-sustaining ecosystem. Data should be discoverable and understandable by humans and machines.
Friday, September 30th, 2016
This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.
<meta name="viewport" content="width=device-width, initial-scale=1">
viewport value for the
meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the
meta viewport gubbins that they made up.
That was nine years ago. These days, if you’re building a responsive website, you still need to include that
That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.
Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).
There are other browser default behaviours that might someday change. Right now, if I type
example.com into a browser, it will first attempt to contact
http://example.com rather than
https://example.com. That means the
example.com server has to do a redirect, costing the user valuable time.
You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for
HTTPS instead of
HTTP? I don’t think that will happen anytime soon, but someday …someday.
Wednesday, June 22nd, 2016
If you’re going to make a manifest file for an existing site, start with this very handy tool. You give it the URL of your site and it then parses the content for existing metadata to create a best first stab at a manifest JSON file.
Tuesday, January 19th, 2016
This a magnificent piece of writing from James …all about pieces of metal fabric.
A single technology – the vacuum-deposition of metal vapour onto a thin film substrate – makes its consecutive and multiple appearances at times of stress and trial: at the dawn of the space age, in orbit and on other planets, at the scene of athletic feats of endurance, in defence and offence in the mountains of the Hindu Kush, on the beaches of the European archipelago. These are moments of hope as well as failure; moments when, properly utilised, technological progress enables us to achieve something which was beyond our capabilities before. And yet: we are still pulling bodies from the water wrapped in material which was meant to send us into space.
Tuesday, December 1st, 2015
Saturday, November 28th, 2015
When something on your website is shared on Twitter or Facebook, you probably want a nice preview to appear with it, right?
For Twitter, you can use Twitter cards—a collection of
meta elements you place in the head of your document.
For Facebook, you can use the grandiosely-titled Open Graph protocol—a collection of
meta elements you place in the head of your document.
What’s that you say? They sound awfully similar? Why, no! I mean, just look at the difference. Here’s how you’d mark up a blog post for Twitter:
<meta name="twitter:url" content="https://adactio.com/journal/9881"> <meta name="twitter:title" content="Metadata markup"> <meta name="twitter:description" content="So many standards to choose from."> <meta name="twitter:image" content="https://adactio.com/icon.png">
Whereas here’s how you’d mark up the same blog post for Facebook:
<meta property="og:url" content="https://adactio.com/journal/9881"> <meta property="og:title" content="Metadata markup"> <meta property="og:description" content="So many standards to choose from."> <meta property="og:image" content="https://adactio.com/icon.png">
See? Completely different.
Okay, I’ll attempt to dial down my sarcasm, but I find this wastage annoying. It adds unnecessary complexity, which in turn, I suspect, puts a lot of people off even trying to implement this stuff. In short: 927.
We’ve seen this kind of waste before. I remember when Netscape and Microsoft were battling it out in the browser wars: Internet Explorer added a proprietary
acronym element, while Netscape added the
abbr element. They both basically did the same thing. For years, Internet Explorer refused to implement the
abbr element out of sheer spite.
A more recent example of the negative effects of competing
standards was on display at this year’s Edge conference in London. In a session on front-end data, Nolan Lawson decried the fact that developers weren’t making more use of the client-side storage options available in browsers today. After all, there are so many to choose from: LocalStorage, WebSQL, IndexedDB…
(Hint: if developers aren’t showing much enthusiasm for the latest and greatest API which is sooooo much better than the previous APIs they were also encouraged to use at the time, perhaps their reticence is understandable.)
Anyway, back to metacrap.
Matt has written a guide to what you need to do in order to get a preview of your posts to appear in Slack. Fortunately the answer is not yet another collection of
meta elements to place in the head of your document. Instead, Slack piggybacks on the existing combatants: oEmbed, Twitter Cards, and Open Graph.
So to placate both Twitter and Facebook (with Slack thrown in for good measure), your metadata markup is supposed to look something like this:
<meta name="twitter:card" content="summary"> <meta name="twitter:site" content="@adactio"> <meta name="twitter:url" content="https://adactio.com/journal/9881"> <meta name="twitter:title" content="Metadata markup"> <meta name="twitter:description" content="So many standards to choose from."> <meta name="twitter:image" content="https://adactio.com/icon.png"> <meta property="og:url" content="https://adactio.com/journal/9881"> <meta property="og:title" content="Metadata markup"> <meta property="og:description" content="So many standards to choose from."> <meta property="og:image" content="https://adactio.com/icon.png">
There are two things on display here: redundancy, and also, redundancy.
Now the eagle-eyed amongst you will have spotted a crucial difference between the Twitter metacrap and the Facebook metacrap. The Twitter metacrap uses the
name attribute on the
meta element, whereas the Facebook metacrap uses the
property attribute. Technically, there is no
property attribute in HTML—it’s an RDFa thing. But the fact that they’re using two different attributes means that we can squish the
meta elements together like this:
<meta name="twitter:card" content="summary"> <meta name="twitter:site" content="@adactio"> <meta name="twitter:url" property="og:url" content="https://adactio.com/journal/9881"> <meta name="twitter:title" property="og:title" content="Metadata markup"> <meta name="twitter:description" property="og:description" content="So many standards to choose from."> <meta name="twitter:image" property="og:image" content="https://adactio.com/icon.png">
There. I saved you at least a little bit of typing.
The metacrap situation is even more ridiculous for “add to homescreen”/”pin to start”/whatever else browser makers can’t agree on…
<meta name="msapplication-starturl" content="https://adactio.com" /> <meta name="msapplication-window" content="width=800;height=600"> <meta name="msapplication-tooltip" content="Kill me now...">
<link rel="apple-touch-icon" href="https://adactio.com/icon.png">
(Repeat four or five times with different variations of icon sizes, and be sure to create icons with new sizes after every. single. Apple. keynote.)
Fortunately Google, Opera, and Mozilla appear to be converging on using an external manifest file:
<link rel="manifest" href="https://adactio.com/manifest.json">
Perhaps our long national nightmare of balkanised metacrap is finally coming to an end, and clearer
heads will prevail.
Wednesday, November 18th, 2015