Cassie’s redesign is gorgeous—so much attention to detail! (And performant too)
Thursday, June 25th, 2020
Tuesday, May 12th, 2020
Although some communities have listed journalists as “essential workers,” no one claims that status for the keynote speaker. The “work” of being a keynote speaker feels even more ridiculous than usual these days.
Wednesday, May 6th, 2020
Saturday, April 25th, 2020
At the beginning of the year, Remy wrote about extracting Goodreads metadata so he could create his end-of-year reading list. More recently, Mark Llobrera wrote about how he created a visualisation of his reading history. In his case, he’s using JSON to store the information.
This kind of JSON storage is exactly what Tom Critchlow proposes in his post, Library JSON - A Proposal for a Decentralized Goodreads:
Thinking through building some kind of “web of books” I realized that we could use something similar to RSS to build a kind of decentralized GoodReads powered by indie sites and an underlying easy to parse format.
His proposal looks kind of similar to what Mark came up with. There’s a title, an author, an image, and some kind of date for when you started and/or finished reading the book.
Matt then points out that RSS gets close to the data format being suggested and asks how about using RSS?:
Rather than inventing a new format, my suggestion is that this is RSS plus an extension to deal with books. This is analogous to how the podcast feeds are specified: they are RSS plus custom tags.
Like Matt, I’m in favour of re-using existing wheels rather than inventing new ones, mostly to avoid a 927 situation.
But all of these proposals—whether JSON or RSS—involve the creation of a separate file, and yet the information is originally published in HTML. Along the lines of Matt’s idea, I could imagine extending the
h-entry collection of class names to allow for books (or films, or other media). It already handles images (with
u-photo). I think the missing fields are the date-related ones: when you start and finish reading. Those fields are present in a different microformat,
h-event in the form of
dt-end. Maybe they could be combined:
<article class="h-entry h-event h-review"> <h1 class="p-name p-item">Book title</h1> <img class="u-photo" src="image.jpg" alt="Book cover."> <p class="p-summary h-card">Book author</p> <time class="dt-start" datetime="YYYY-MM-DD">Start date</time> <time class="dt-end" datetime="YYYY-MM-DD">End date</time> <div class="e-content">Remarks</div> <data class="p-rating" value="5">★★★★★</data> <time class="dt-published" datetime="YYYY-MM-DDThh:mm">Date of this post</time> </article>
That markup is simultaneously a post (
h-entry) and an event (
h-event) and you can even throw in
h-card for the book author (as well as
h-review if you like to rate the books you read). It can be converted to RSS and also converted to
.ics for calendars—those parsers are already out there. It’s ready for aggregation and it’s ready for visualisation.
I publish very minimal reading posts here on adactio.com. What little data is there isn’t very structured—I don’t even separate the book title from the author. But maybe I’ll have a little play around with turning these h-entries into combined h-entry/event posts.
Thursday, April 16th, 2020
Naomi Kritzer published a short story five years ago called So Much Cooking about a food blogger in lockdown during a pandemic. Prescient.
I left a lot of the details about the disease vague in the story, because what I wanted to talk about was not the science but the individuals struggling to get by as this crisis raged around them. There’s a common assumption that if the shit ever truly hit the fan, people would turn on one another like sharks turning on a wounded shark. In fact, the opposite usually happens: humans in disasters form tight community bonds, help their neighbors, offer what they can to the community.
Tuesday, March 31st, 2020
I just love the way that Laurie Penny writes.
In the end, it will not be butchery. Instead it will be bakery, as everyone has apparently decided that the best thing to do when the world lurches sideways is learn to make bread. Yeast is gone from the shops. Even I have been acting out in the kitchen, although my baked goods are legendarily dreadful. A friend and former roommate, who knows me well, called from Berlin to ask if I had “made the terrible, horrible biscuits yet.” These misfortune cookies tend to happen at moments of such extreme stress that those around me feel obliged to eat them. They say that if you can make a cake, you can make a bomb; if the whole thing implodes, my job will not be in munitions.
Thursday, March 26th, 2020
It was a few years before I realized that worry stones had a name, that they were borrowed from cultures other and older than mine. Heck, it’s been more than a few years since I’ve even held one. But in the last few weeks, before and after launching the redesign, I’ve kept working away at this website, much as I’d distractedly run my fingers over a smooth, flat stone.
Wednesday, March 18th, 2020
Cameron’s blog is back, and very nicely redesigned/aligned it is too!
Saturday, February 15th, 2020
- Wrong: web workers will take over the world
- Wrong: Safari is the new IE
- Right: developer experience is trumping user experience
- Right: I’m better off without a Twitter account
- Right: the cost of small modules
- Mixed: progressive enhancement isn’t dead, but it smells funny
Maybe I should do one of these.
Thursday, February 6th, 2020
Tantek documents the features he wants his posting interface to have.
Sunday, January 19th, 2020
I feel like my problem with design in general today is that folks want to burn everything to the ground and start again all the time. Whether that’s with a website, or a new web standard, or a political policy. They don’t want to fix what’s wrong with things bit by bit, everyone wants Thing 2.0 whilst jumping over all the small improvements that are required to get there.
Monday, December 16th, 2019
I am not a believer in the AI singularity — the rapture of the nerds — that is, in the possibility of building a brain-in-a-box that will self-improve its own capabilities until it outstrips our ability to keep up. What CS professor and fellow SF author Vernor Vinge described as “the last invention humans will ever need to make”. But I do think we’re going to keep building more and more complicated, systems that are opaque rather than transparent, and that launder our unspoken prejudices and encode them in our social environment. As our widely-deployed neural processors get more powerful, the decisions they take will become harder and harder to question or oppose. And that’s the real threat of AI — not killer robots, but “computer says no” without recourse to appeal.
Wednesday, November 27th, 2019
Lynn gives a step-by-step walkthrough of the latest amazing redesign of her website. There’s so much joy and craft in here, with real attention to detail—I love it!
Thursday, November 21st, 2019
Frank is redesigning in the open. Watch this space:
By writing about it, it may help both of us. I can further develop my methods by navigating the friction of explaining them. I’ve been looking for a way to clarify and share my thoughts about typography and layout on screens, and this seems like a good chance to do so. And you? Well, perhaps the site can offer a clearly explained way of working that’s worth considering. That seems to be a rare thing on the web these days.
Wednesday, November 20th, 2019
I’m really enjoying this end-of-the-year round-up from people speaking their brains. It’s not over yet, but there’s already a lot of thoughtful stuff to read through.
Only a few years ago, I would need a whole team of developers to accomplish what can now be done with just a few amazing tools.
And I like this zinger from Geoff:
What you need to build a great website is restraint.
Tuesday, August 27th, 2019
Web Forms: Now You See Them, Now You Don’t! by Jason Grigsby
Jason is on stage at An Event Apart Chicago in a tuxedo. He wants to talk about how we can make web forms magical. Oh, I see. That explains the get-up.
We’re always being told to make web forms shorter. Luke Wroblewski has highlighted the work of companies that have reduced form fields and increased conversion.
But what if we could get rid of forms altogether? Wouldn’t that be magical!
Jason will reveal the secrets to this magic. But first—a volunteer from the audience, please! Please welcome Joe to the stage.
Joe will now log in on a phone. He types in the username. Then the password. The password is hodge-podge of special characters, numbers and upper and lowercase letters. Joe starts typing. Jason takes the phone and logs in without typing anything!
The secret: Jason was holding an NFC security key in his hand. That works with a new web standard called WebAuthn.
Passwords are terrible. People share them across sites, but who can blame them? It’s hard to remember lots of passwords. The only people who love usernames and passwords are hackers. So sites are developing other methods to try to keep people secure. Two factor authentication helps, although it doesn’t help us with phishing attacks. The hacker gets the password from the phished user …and then gets the one-time code from the phished user too.
But a physical device like a security key solves this problem. So why aren’t we all using security keys (apart from the fear of losing the key)? Well, until WebAuthn, there wasn’t a way for websites to use the keys.
A web server generates a challenge—a long string—that gets sent to a website and passed along to the user. The user’s device generates a credential ID and public and private keys for that domain. The web site stores the public key and credential ID. From then on, the credential ID is used by the website in challenges to users logging in.
There were three common ways that we historically proved who we claimed to be.
- Something you know (e.g. a password).
- Something you have (e.g. a security key).
- Something you are (e.g. biometric information).
These are factors of identification. So two-factor identification is the combination of any of those two. If you use a security key combined with a fingerprint scanner, there’s no need for passwords.
The browser support for the web authentication API (WebAuthn) is a bit patchy right now but you can start playing around with it.
There are a few other options for making logging in faster. There’s the Credential Management API. It allows someone to access passwords stored in their browser’s password manager. But even though it’s newer, there’s actually better browser support for WebAuthn than Credential Management.
Then there’s federated login, or social login. Jason has concerns about handing over log-in to a company like Facebook, Twitter, or Google, but then again, it means fewer passwords. As a site owner, there’s actually a lot of value in not storing log-in information—you won’t be accountable for data breaches. The problem is that you’ve got to decide which providers you’re going to support.
Also keep third-party password managers in mind. These tools—like 1Password—are great. In iOS they’re now nicely integrated at the operating system level, meaning Safari can use them. Finally it’s possible to log in to websites easily on a phone …until you encounter a website that prevents you logging in this way. Some websites get far too clever about detecting autofilled passwords.
Time for another volunteer from the audience. This is Tyler. Tyler will help Jason with a simple checkout form. Shipping information, credit card information, and so on. Jason will fill out this form blindfolded. Tyler will first verify that the dark goggles that Jason will be wearing don’t allow him to see the phone screen. Jason will put the goggles on and Tyler will hand him the phone with the checkout screen open.
Jason dons the goggles. Tyler hands him the phone. Jason does something. The form is filled in and submitted!
What was the secret? The goggles prevented Jason from seeing the phone …but they didn’t prevent the screen from seeing Jason. The goggles block everything but infrared. The iPhone uses infrared for Face ID. So the iPhone, it just looked like Jason was wearing funky sunglasses. Face ID then triggered the Payment Request API.
The Payment Request API allows us to use various payment methods that are built in to the operating system, but without having to make separate implementations for each payment method. The site calls the Payment Request API if it’s supported (use feature detection and progressive enhancement), then trigger the payment UI in the browser. The browser—not the website!—then makes a call to the payment processing provider e.g. Stripe.
E-commerce sites using the Payment Request API have seen a big drop in abandonment and a big increase in completed payments. The browser support is pretty good, especially on mobile. And remember, you can use it as a progressive enhancement. It’s kind of weird that we don’t encounter it more often—it’s been around for a few years now.
Jason read the fine print for Apple Pay, Google Pay, Microsoft Pay, and Samsung Pay. It doesn’t like there’s anything onerous in there that would stop you using them.
On some phones, you can now scan credit cards using the camera. This is built in to the operating system so as a site owner, you’ve just got to make sure not to break it. It’s really an extension of autofill. You should know what values the
autocomplete attribute can take. There are 48 different values; it’s not just for checkouts. When users use autofill, they fill out forms 30% faster. So make sure you don’t put obstacles in the way of autofill in your forms.
Jason proceeds to relate a long and involved story about buying burritos online from Chipotle. The upshot is: use the
pattern attributes correctly on
input elements. Test autofill with your forms. Make it part of your QA process.
So, to summarise, here’s how you make your forms disappear:
- Start by reducing the number of form fields.
- Use the correct HTML to support autofill. Support password managers and password-pasting. At least don’t break that behaviour.
- Provide alternate ways of logging in. Federated login or the Credentials API.
- Test autofill and other form features.
- Look for opportunities to replace forms entirely with biometrics.
Any sufficiently advanced technology is indistinguishable from magic.
—Arthur C. Clarke’s Third Law
Don’t our users deserve magical experiences?
Sunday, August 4th, 2019
Old technology seldom just goes away. Whiteboards and LED screens join chalk blackboards, but don’t eliminate them. Landline phones get scarce, but not phones. Film cameras become rarities, but not cameras. Typewriters disappear, but not typing. And the technologies that seem to be the most outclassed may come back as a the cult objects of aficionados—the vinyl record, for example. All this is to say that no one can tell us what will be obsolete in fifty years, but probably a lot less will be obsolete than we think.
Wednesday, May 29th, 2019
Here’s a clever tiny lesson from Dave and Brad: you can use
prefers-reduced-motion in the
media attribute of the
source element inside
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.
Monday, May 6th, 2019
A cli-fi short story by Paolo Bacigalupi.