Walking down an aisle in a library, I no more than glance at the vast majority of books shelved on either side of me. Only a madman would suggest that my disregard of these books should sanction their pages being torn out. Nonetheless, because research has shown that visitors don’t read the average Web page in full, and because the “success” of a page is more easily measured by user action than cognition, we are often encouraged to marginalize our writing in favor of visual signifiers or action cues.
Sure, most people will “bounce” your content, but if you really have something to say, don’t alienate the people who are willing to give your writing a chance. Good typography does justice to your words, and good wording does justice to your ideas. If readers are comfortable reading your type, then they will more likely be comfortable with what you are writing about.
For years, we studied teams rolling out new designs, to see if we could mitigate negative reaction to new releases and design changes. We studied hundreds of product and service rollouts. We watched and learned from the reactions of thousands of users.
When we dug into what those users’ reactions, patterns emerged. The users told us the changes inconvenienced them. They had no idea the change was coming and suddenly it was in their face. Users were upset because they were surprised.
They also told us the old version worked fine. Even when it took a while to get comfortable, they learned it. Many users mastered difficult-to-use designs.
Everything was different when the new version arrived. What they’d mastered before didn’t help them now. The company said it was an improved design, but they couldn’t see the improvements. Why should these users learn something new that doesn’t help them? Users were upset because they couldn’t see the value.
We also saw many instances where users didn’t react negatively to changes. Often, they didn’t react at all. We saw new designs that didn’t affect the users’ behaviors and they didn’t pay attention to it.
In these cases, the changes were often not noticeable. Sometimes the changes were small and isolated. Yet, we also saw users seemingly not notice several updates with extensive changes. (In more than one instance, an entire application’s infrastructure had been rewritten without a single user noticing.)
In cases when the design changes were noticeable, the designers gave the users control to switch when they wanted. The designers showed why the change was valuable to the users. And the designers made the transition easy by taking the knowledge and experience their users already had with the product into account.
A reminder of why reader modes exist in browsers and to embrace them as a user’s right:
Good design isn’t about forcing someone to walk a tightrope across your carefully manicured lawn. Nor is it a puzzle box casually tossed to the user, hoping they’ll unlock it to reveal a hidden treasure. Good design is about doing the hard work to accommodate the different ways people access a solution to an identified problem.
For reading articles, the core problem is turning my ignorance about an issue into understanding (the funding model for this is a whole other complicated concern). The more obstructions you throw in my way to achieve this goal, the more I am inclined to leave and get my understanding elsewhere—all I’ll remember is how poor a time I had while trying to access your content. What is the value of an ad impression if it ultimately leads to that user never returning?
Great details of how touch and mouse events interact or overlap, and contains this super handy reference of event order:
From videoconferencing tutorials to inline form help notes, this lists all sorts of useful ways to help clients use the site you built for them.
For perhaps the first time since the original Macintosh, we can get excited about using system UI fonts. They’re an interesting, fresh alternative to web typography — and one that doesn’t require a web-font delivery service or font files stored on your server. How do we use system UI fonts on a website, and what are the caveats? System UI fonts being amazing kind of snuck up on us. Google has been toiling away at Roboto with great success (including regular updates), Apple made a splash with San Francisco, and Mozilla asked renowned type designer Erik Spiekermann to create Fira Sans.
Code language: CSS
font-family: /* 1 */ -apple-system, BlinkMacSystemFont, /* 2 */ 'Segoe UI', 'Roboto', 'Oxygen', 'Ubuntu', 'Cantarell', 'Fira Sans', 'Droid Sans', /* 3 */ 'Helvetica Neue', sans-serif;
The first grouping is CSS properties that map to the system’s UI font. That covers a lot of ground, and there is no chance that these fonts will be mistaken for something else:
-apple-systemtargets San Francisco in Safari on Mac OS X and iOS, and it targets Neue Helvetica and Lucida Grande on older versions of Mac OS X. It properly selects between San Francisco Text and San Francisco Display depending on the text’s size.
BlinkMacSystemFontis the equivalent for Chrome on Mac OS X.
The second grouping is for known system UI fonts:
Segoe UItargets Windows and Windows Phone.
Robototargets Android and newer Chrome OS’. It is deliberately listed after Segoe UI so that if you’re an Android developer on Windows and have Roboto installed, Segoe UI will be used instead.
Ubuntutargets… well, you can guess, and
Cantarelltargets GNOME. This is beginning to feel futile because some Linux distributions have many of these fonts.
Fira Sanstargets Firefox OS.
Droid Sanstargets older versions of Android.
- Note that we don’t specify San Francisco by name. On both iOS and Mac OS X, San Francisco isn’t obviously accessible, but rather exists as a “hidden” font.
- We also don’t specify San Francisco using
.SFNSText-Regular, the internal PostScript name for San Francisco on Mac OS X. It only works in Chrome and is less versatile than
The third grouping is our fallback fonts:
Helvetica Neuetargets pre-El Capitan versions of Mac OS X. It is listed close to the end because it’s a popular font on other non-El Capitan computers.
sans-serifis the default sans-serif fallback font.
Ever get annoyed with carousels and similar widgets that have that sort sticky pause when you swipe and release? Well, Flickity totally fixes that by handling momentum in an intuitive way.
[T]he basic questions an empty state should answer are:
- What is this screen?
- Why am I seeing it?
- How can I fix this problem?
On top of this, you should aim to:
- Communicate personality. Make your app a joy to use and connect feelings with features.
- Explain the benefits. This is critical for your first-use empty states so your users know why they should care.