Tags: ia

1007

sparkline

Friday, September 6th, 2019

Recursive | Recursive

Play around with this variable font available soon from Google Fonts in monospaced and sans-serif versions.

Tuesday, September 3rd, 2019

Mark Zuckerberg Is a Slumlord

An interesting comparison between Facebook and tenements. Cram everybody together into one social network and the online equivalents of cholera and typhoid soon emerge.

The airless, lightless confines of these networks has a worrying tendency to amplify the most extreme content that takes root, namely that of racists, xenophobes, and conspiracists (which, ironically, includes anti-vaxxers.)

Sunday, September 1st, 2019

Why These Social Networks Failed So Badly

Ignore the clickbaity headline and have a read of Whitney Kimball’s obituaries of Friendster, MySpace, Bebo, OpenSocial, ConnectU, Tribe.net, Path, Yik Yak, Ello, Orkut, Google+, and Vine.

I’m sure your content on Facebook, Twitter, and Instagram is perfectly safe.

Bandstands: The industry built on Victorian social engineering - BBC News

As a resident of Brighton—home to the most beautiful of bandstands—this bit of background to their history is fascinating.

Saturday, August 31st, 2019

Thursday, August 29th, 2019

comment parade

A way for you to comment (anonymously, if you wish) on any post that accepts webmentions. So you can use this to respond to posts on adactio.com if you want.

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.

  1. Something you know (e.g. a password).
  2. Something you have (e.g. a security key).
  3. 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 autocomplete, type, maxlength, and 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:

  1. Start by reducing the number of form fields.
  2. Use the correct HTML to support autofill. Support password managers and password-pasting. At least don’t break that behaviour.
  3. Provide alternate ways of logging in. Federated login or the Credentials API.
  4. Test autofill and other form features.
  5. 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?

Friday, August 9th, 2019

Meaning without markup: Accessibility Object Model

Hidde gives an in-depth explanation of the Accessibility Object Model, coming soon to browsers near you:

In a way, that’s a bit like what Service Workers do for the network and Houdini for style: give developers control over something that was previously done only by the browser.

Sunday, August 4th, 2019

The Flawed Reasoning Behind the Replication Crisis — Nautilus

Bayesian analysis vs. statistical significance, clearly explained.

Tuesday, July 30th, 2019

Creating my logo animation - cassie.codes

What a wonderfully in-depth and clear tutorial from Cassie on how she created the animation for her nifty SVG logo!

Also: Cassie is on the indie web now, writing on her own website—yay!

Thursday, July 25th, 2019

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.

Friday, July 19th, 2019

The Guardian digital design style guide

What a lovely way to walk through the design system underpinning the Guardian website.

Bonus points for using the term “tweak points”!

Thursday, July 18th, 2019

Neil & Buzz

A delightful dialogue …on the moon!

Monday, July 15th, 2019

How to run a small social network site for your friends

This is a great how-to from Darius Kazemi!

The main reason to run a small social network site is that you can create an online environment tailored to the needs of your community in a way that a big corporation like Facebook or Twitter never could. Yes, you can always start a Facebook Group for your community and moderate that how you like, but only within certain bounds set by Facebook. If you (or your community) run the whole site, then you are ultimately the boss of what goes on. It is harder work than letting Facebook or Twitter or Slack or Basecamp or whoever else take care of everything, but I believe it’s worth it.

There’s a lot of good advice for community management and the whole thing is a lesson in writing excellent documentation.

Saturday, July 6th, 2019

The Hiding Place: Inside the World’s First Long-Term Storage Facility for Highly Radioactive Nuclear Waste - Pacific Standard

Robert McFarlane’s new book is an exploration of deep time. In this extract, he visits the Onkalo nuclear waste storage facility in Finland.

Sometimes we bury materials in order that they may be preserved for the future. Sometimes we bury materials in order to preserve the future from them.

Monday, July 1st, 2019

Variable Fonts for Developers

A showcase of fun experiments with variable fonts, courtesy of Mandy.

The Decolonial Atlas

The Decolonial Atlas is a growing collection of maps which, in some way, help us to challenge our relationships with the land, people, and state. It’s based on the premise that cartography is not as objective as we’re made to believe.

For example: Names and Locations of the Top 100 People Killing the Planet — a cartogram showing the location of decision makers in the top 100 climate-hostile companies.

This map is a response to the pervasive myth that we can stop climate change if we just modify our personal behavior and buy more green products. Whether or not we separate our recycling, these corporations will go on trashing the planet unless we stop them.

Sunday, June 30th, 2019

Get off of Twitter | Read the Tea Leaves

You can’t criticize Twitter on Twitter. It just doesn’t work. The medium is the message.

Nolan’s plea for sanity.

Write blog posts. Use RSS. Use micro.blog. Use Mastodon. Use Pleroma. Use whatever you want, as long as it isn’t manipulating you with algorithms or selling access to your data to advertisers.

Thursday, June 27th, 2019