If you end up with a draft of a short story or a few paragraphs of a typical UX interaction scenario, or a storyboard, or a little film of someone swiping on a screen to show how your App idea would work — you have not done Design Fiction.
What you’ve done is write a short story, which can only possibly be read as a short story.
What you should ideally produce is something a casual observer may mistake for a contemporary artefact, but which only reveals itself as a fiction on closer inspection. It should be very much “as if..” this thing really existed. It should feel real, normal, not some fantasy.
Friday, January 10th, 2020
Wednesday, January 8th, 2020
Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it’s important, critical, or fundamental, write it up, don’t chat it down.
This one feels like it should be Somebody’s Law:
If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
Monday, January 6th, 2020
Websites sit on a design spectrum. On one end are applications, with their conditional logic, states, and flows—they’re software.
On the other end of the design spectrum are documents; sweet, modest documents with their pleasing knowableness and clear edges.
For better or worse, I am a document lover.
This is the context where I fell in love with design and the web. It is a love story, but it is also a ghost story.
Monday, December 16th, 2019
The goal in putting these stories together has never been to create a warm glow, or lull anyone into a false sense of complacency. The challenges facing the human family right now are big and scary and there’s no guarantee we will overcome them.
As millions of people have demonstrated in the past 12 months though, action is possible, better solutions are available and a better future can be built.
Monday, December 9th, 2019
Brad gets ranty …with good reason.
Friday, November 22nd, 2019
This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.
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.
Monday, November 11th, 2019
Here, then, is my speculation. Work is something we struggle to get and strive to keep. We love-hate it (usually not in equal measure). Sometimes it seems meaningless. I’m told this is the case even for surgeons, teachers and disaster-relief workers: those with jobs whose worth seems indisputable. For the mere facilitators, the obscure cogs in the machinery of the modern economy whose precise function and value it takes some effort to ascertain, the meaning in what we do often seems particularly elusive (I should know). I contend, however, that while our lives need to be meaningful, our work does not; it only has to be honest and useful. And if someone is voluntarily paying you to do something, it’s probably useful at least to them.
I have such fondness for this film. It’s one of those films that I love to watch on a Sunday afternoon (though that’s true of so many Spielberg films—Jaws, Raiders Of The Lost Ark, E.T.). I remember seeing it in the cinema—this would’ve been the special edition re-release—and feeling the seat under me quake with the rumbling of the musical exchange during the film’s climax.
Ariel invited Rose Eveleth and Laura Welcher on to discuss the film. They spent a lot of time discussing the depiction of first contact communication—Arrival being the other landmark film on this topic.
If we send a message into space, will extraterrestrial beings receive it? Will they understand?
You can a read an article by the author on The Guardian, where he mentions some of the wilder ideas about transmitting signals to aliens:
Minsky, widely regarded as the father of AI, suggested it would be best to send a cat as our extraterrestrial delegate.
Don’t worry. Marvin Minsky wasn’t talking about sending a real live cat. Rather, we transmit instructions for building a computer and then we can transmit information as software. Software about, say, cats.
It’s not that far removed from what happened with the Voyager golden record, although that relied on analogue technology—the phonograph—and sent the message pre-compiled on hardware; a much slower transmission rate than radio.
But it’s interesting to me that Minsky specifically mentioned cats. There’s another long-term communication puzzle that has a cat connection.
The Yukka Mountain nuclear waste repository is supposed to store nuclear waste for 10,000 years. How do we warn our descendants to stay away? We can’t use language. We probably can’t even use symbols; they’re too culturally specific. A think tank called the Human Interference Task Force was convened to agree on the message to be conveyed:
This place is a message… and part of a system of messages… pay attention to it! Sending this message was important to us. We considered ourselves to be a powerful culture.
This place is not a place of honor…no highly esteemed deed is commemorated here… nothing valued is here.
What is here is dangerous and repulsive to us. This message is a warning about danger.
A series of thorn-like threatening earthworks was deemed the most feasible solution. But there was another proposal that took a two pronged approach with genetics and folklore:
- Breed cats that change colour in the presence of radioactive material.
- Teach children nursery rhymes about staying away from cats that change colour.
This is the raycat solution.
Thursday, November 7th, 2019
I really like the work that IF are doing to document patterns around handling data:
- Signing in to a service
- Giving and removing consent
- Giving access to data
- Getting access to data
- Understanding automated decisions
- Doing security checks
Each pattern has a description, advantages, limitations, and examples.
Friday, November 1st, 2019
Testing on a <$100 Android device on a 3G network should be an integral part of testing your website. Not everyone is on a brand-new device or upgrades often, especially with the price point of a high-end phones these days.
When we design and build our websites with the outliers in mind, whether it’s for performance or even user experience, we build an experience that can be easy for all to access and use — and that’s what the web is about, access and information for all.
Tuesday, October 29th, 2019
If we want design to communicate, we need to communicate in the design process.
I might get that framed.
Monday, October 28th, 2019
Silent push for the web
While I’m very unwilling to grant permission to be interrupted by intrusive notifications, I’d be more than willing to grant permission to allow a website to silently cache timely content in the background. It would be a more calm technology.
Phil Nash left a comment on the Medium copy of my post explaining that Seb’s demo of using the Push API without showing a notification wouldn’t work for long:
The browsers allow a certain number of mistakes(?) before they start to show a generic notification to say that your site sent a push notification without showing a notification. I believe that after ~10 or so notifications, and that’s different between browsers, they run out of patience.
He also provided me with the name to describe what I’m after:
You’re looking for “silent push” as are many others.
Silent push is something that is possible in native apps. It isn’t (yet?) available on the web, presumably because of security concerns.
It’s an API that would ripe for abuse. I mean, just look at the mess we’ve made with APIs like notifications and geolocation. Sure, they require explicit user opt-in, but these opt-ins are seen so often that users are sick of seeing them. Silent push would be one more permission-based API to add to the stack of annoyances.
Still, I’d really like silent push for the web—the ability to update a cache with fresh content as soon as it’s published; that would be nifty! At the same time, I understand the concerns. It feels more powerful than other permission-based APIs like notifications.
Maybe there could be another layer of permissions. What if adding a site to your home screen was the first step? If a site is running on HTTPS, has a service worker, has a web app manifest, and has been added to the homescreen, maybe then and only then should it be allowed to prompt for permission to do silent push.
In other words, what if certain very powerful APIs were only available to progressive web apps that have successfully been added to the home screen?
Frankly, I’d be happy if the same permissions model applied to web notifications too, but I guess that ship has sailed.
Anyway, all this is pure conjecture on my part. As far as I know, silent push isn’t on the roadmap for any of the browser vendors right now. That’s fair enough. Although it does annoy me that native apps have this capability that web sites don’t.
It used to be that there was a long list of features that only native apps could do, but that list has grown shorter and shorter. The web’s hare is catching up to native’s tortoise.
Friday, October 25th, 2019
Here’s a nice example of showing pages offline. It’s subtly different from what I’m doing on my own site, which goes to show that there’s no one-size-fits-all recipe when it comes to offline strategies.
Sunday, October 20th, 2019
A terrific—and fun!—talk from Zach about site deaths, owning your own content, and the indie web.
Oh, and he really did create MySpaceBook for the talk.
Wednesday, September 18th, 2019
When your only tool seems like a smartphone, everything looks like an app.
Amber writes on Ev’s blog about products that deliberately choose to be dependent on smartphone connectivity:
We read service outage stories like these seemingly every week, and have become numb to the fundamental reality: The idea of placing the safety of yourself, your child, or another loved one in the hands of an app dependent on a server you cannot touch, control, or know the status of, is utterly unacceptable.
Saturday, September 7th, 2019
An interesting proposal to allow websites to detect certain SMS messages. The UX implications are fascinating.
Sunday, September 1st, 2019
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
Bayesian analysis vs. statistical significance, clearly explained.