This is a terrific collection of guidelines for form design.
A short web book on the past, present and future of interfaces, written in a snappy, chatty style.
From oral communication and storytelling 500,000 years ago to virtual reality today, the purpose of information interfaces has always been to communicate more quickly, more deeply, to foster relationships, to explore, to measure, to learn, to build knowledge, to entertain, and to create.
We interface precisely because we are human. Because we are intelligent, because we are social, because we are inquisitive and creative.
We design our interfaces and they in turn redefine what it means to be human.
The removal of all friction should’t be a goal. Making things easy and making things hard should be a design tool, employed to aid the end user towards their loftiest goals.
I guess, because browser-makers tend to be engineers so they do engineering-type things like making the browser an app-delivery platform able to run compiled code. Or fight meaningless user experience battles like hiding the URL, or hiding View Source – both acts that don’t really help early users that much, but definitely impede the user path from being a consumer to being a fully-fledged participant/maker.
So, why would you want to use a service worker? Here are some cool things you can do with it.
Chris lists some of the ways a service worker can enhance user experience.
The evolution of affordances on the web:
The URL for a page goes at the top. Text appears in a vertically scrolling column. A dropdown menu has a downward-pointing triangle next to it. Your mouse cursor is a slanted triangle with a tail, and when you hover over a link it looks like Mickey Mouse’s glove.
Most of these affordances don’t have any relationship to the physical characteristics of the interaction they mediate. But remove them from a website, application, or interface, and users get disoriented, frustrated, and unproductive.
This is an interesting project to try to rank web hosts by performance:
Real-world server response (Time to First Byte) latencies, as experienced by real-world users navigating the web.
4 Design Patterns That Violate “Back” Button Expectations – 59% of Sites Get It Wrong - Articles - Baymard Institute
Some interesting research in here around user expecations with the back button:
Generally, we’ve observed that if a new view is sufficiently different visually, or if a new view conceptually feels like a new page, it will be perceived as one — regardless of whether it technically is a new page or not. This has consequences for how a site should handle common product-finding and -exploration elements like overlays, filtering, and sorting. For example, if users click a link and 70% of the view changes to something new, most will perceive this to be a new page, even if it’s technically still the same page, just with a new view loaded in.
Thoughts on user experience design and service design, prompted by the Clearleft podcast:
I especially enjoyed the latest episode about a topic that has become a bit of a hyped buzzword over the last few years: Service design.
Rich with anecdotes and stories, the episode started with an investigation: What is service design, anyway?
Smart thinking from Sara to improve usability for keyboard users by using
aria-hidden="true" tabindex="-1" to skip duplicate links:
A good rule of thumb for similar cases is that if you have multiple consecutive links to the same page, there is probably a chance to improve keyboard navigation by skipping some of those links to reduce the number of tab stops to one. The less tab stops, the better, as long as it does not worsen or compromise on other aspects of usability.
I’ve cautiously implemented this pattern now over on The Session where snippets of comments had both a title link and a “more” link going to the same destination.
Spot-on description of “modern” web development. When did this become tolerable, much less normal?
Web developers: maybe stop insisting that your users compile your apps for you? Or admit that you’ll put them through an experience that you certainly don’t tolerate on your own desktops, where you expect to download an app, not to be forced to compile it every time you run it?
Some good thought morsels from Robin on product design:
Bad product design is when folks talk more about the UI than what the UI is built on top of.
There’s a lot of talk about how great design is invisible—mostly boring conversations with little substance—but! I think that’s true when it comes to product design.
Bad product design is when your interface looks like your org chart.
Progressive disclosure interface patterns categorised and evaluated:
- mouseover popups (just say no!),
- new pages,
- scrolling sideways.
I really like the hypertext history invoked in this article.
The piece finishes with a great note on the MacNamara fallacy:
Everyone thinks metrics let us measure results. But, actually, they don’t. They measure only what they are measuring. Engagement, for example, is not something that can be measured, so we use an analogue for it. Time on page. Or clicks.
We often end up measuring what is quick, cheap, and easy to measure. Therefore, few organizations regularly conduct usability testing or customer-satisfaction surveys, but lots use analytics.
Even today, organizations often use clicks as a measure of engagement. So, all too often, they design user interfaces to generate clicks, so the system can measure them.
Two observations of websites on mobile devices today:
- They are beautifully designed, with great typography, clear branding, all optimized for readability.
- I had to install Firefox, Adblock Plus and uBlock Origin, as well as manually select and remove additional elements such as subscription overlays.
Both observations are the result of conscious design decisions.
I love this little to-do app! Every time you tick something off your list, something grows in your virtual terrarium. Lovely!
Cargo cultism is not a strategy:
Apple and Google get it wrong just as often as the rest of us.
How design fiction was co-opted. A piece by Tim Maughan with soundbites from Julian Bleecker, Anab Jain, and Scott Smith.
Pages are often designed so that they’re hard or impossible to read if some dependency fails to load. On a slow connection, it’s quite common for at least one depedency to fail.
Fire up Reader Mode and read this excellent article informed by data from using a typically slow connection in rural USA today. Two findings are:
- A large fraction of the web is unusable on a bad connection. Even on a good (0% packetloss, no ping spike) dialup connection, some sites won’t load.
- Some sites will use a lot of data!