? The fragility of web design
Robin: This week I’ve been reapplying for my American visa and I’ve been unfortunate enough to visit a ton of websites with a lot of forms on them created by enormous and woefully underfunded government agencies. And as much as I don’t want to harp on them, it was an unavoidably stressful experience because the websites would often crash with a ton of very important and scary information that I had input – including my address, social security number, and visa credentials. Navigating these forms was stressful enough!
For example, text was often illegible and the areas in which you could tap the form inputs or checkboxes felt incredibly fragile. I think “fragile” is the word I often think of when I think about websites – software that’s easy to lose or leak information. The difference between an interface in a native app and a website is exactly that, in my opinion. Screw the animations and the device APIs; it’s all about the fragility of websites that upsets me.
Whenever I’m designing a new interface, I ask myself: how do I make this interface less fragile?
Anyway, as I was going through these forms, I tried to avoid stress by taking them as opportunities to learn something new. What could I get out of these poorly designed systems? How could I avoid making the mistakes that these folks had made here?
This got me thinking about rules we might make for form design so that we can avoid these types of usability issues.
After scurrying through my shelves looking for books about form design, I stumbled upon The Humane Interface by Jef Raskin, a book I’ve mentioned once before. I still regard it as the best book ever written about software design.
Jef writes about several rules and principles for software design and I think my favorite rule that applies to the web is this one:
An interface should be reliable. Aside from not crashing, the system should never lose any work you have done or any information you have received or retrieved, even if you make a mistake or are forgetful. This is often not thought of as a property of an interface, but one can build a reliable interface on top of an unreliable system (of the order of unreliability of todays operating systems).
This is what I’ve been thinking about this week: how do we make websites less fragile and more reliable? How do we avoid writing CSS that causes confusion and usability issues? How do we make websites fast and obvious and not a barrier to extremely important moments of our lives?
I think I’m probably going to spend the rest of my life trying to answer that question.
? From the Blog
Testing for Visual Regressions with Percy: Percy is an application that you can use to test visual changes on your website. So, let’s say you change the color of some text. Percy can catch that before you merge your branch and show any visual regressions that may cause:
Nifty, huh? Paul Ryan’s post dives much deeper, including how to get Percy setup and integrated into GitHub. He also shows how easy it is to see those changes once it’s all up and running.
Decaying Sites: Chris has some thoughts about link rot and how websites have a tendency to disappear from the web altogether. Specifically, Chris writes about how we might identify old websites from new ones, and I kinda like this idea a lot. It reminds me of two things.
First, I think there are a lot of bloggers out there who always want to see the date of a post at the very top of the page. Every couple of years, I see a lot of folks chime in on this subject when someone mistakes a really old post and spends half a day trying to solve a complex technical issue with old information.
Second, this reminds me of an interview with the game designer Hideo Kojima. While I cannot dig up the link, I read years ago where he said that he wanted to design a game where you only had one life. If you died in the game then the disc would burn up and you wouldn’t be able to play any longer and that was just the way your story ended. Always thought that was both very cruel and very neat.
Design Tokens: Last month, I started hearing a lot about “design tokens” from the design systems community and so I began to take a look into what they are and how they’re useful:
[…]design tokens are an agnostic way to store variables such as typography, color, and spacing so that your design system can be shared across platforms like iOS, Android, and regular ol’ websites.
Today, that means you can store all your variables in a JSON file which is then output into CSS or iOS/Android formats. It’s nifty because that means we have a single source of truth and can easily update our core application styles across multiple platforms at the press of a button. Cool, huh?
Oh, and they don’t just have to be stored in a JSON file, as I also found some folks that have been keeping their source of truth in a Figma document and then using the API to abstract that data.
Make it hard to screw up driven development: There’s a ton of tools out there to make it harder for us to screw things up in our codebase and Chris take a tour of a bunch of techniques for helping us on that front.
There is probably no practical way to make it impossible to write sloppy, bad code, but it is fascinating to consider how tooling has evolved to make it harder.
I think my favorite process of all the ones that Chris looks at is getting other people on your team to review code. I’ve found that it’s still pretty easy to write bad code that’s unorganized or hard to read with a tool, but if you have a single person that will give you earnest feedback, then they’re worth a million applications put together.
WooCommerce
WooCommerce is the most popular eCommerce platform on the web. Use WooCommerce to sell anything from luxury mattresses and cupcakes, to date-driven sales like kayak lessons, to one-off items like beautiful hand-crafted jewelry.