The Year in Design

  • Mobile is today’s first screen. So design responsively, focusing on content and structure first.
  • Websites and apps alike should remove distractions and let people interact as directly as possible with content.
  • 90 percent of design is typography. And the other 90 percent is whitespace.
  • Boost usability and pleasure with progressive disclosure: menus and functions that appear only when needed.
  • One illustration or original photo beats 100 stock images.
  • Design your system to serve your content, not the other way around.
  • Remove each detail from your design until it breaks.
  • Style is the servant of brand and content. Style without purpose is noise.
  • Nobody waits. Speed is to today’s design what ornament was to yesterday’s.
  • Don’t design to prove you’re clever. Design to make the user think she is.

Also published in Medium

Translated into German (also here) by Mark Sargent

Translated into French by Jean-Baptiste Sachsé

Translated into Turkish by omerbalyali.

Translated into Spanish by Tam Lopez Breit.

Ad Blocking Phase II

screenshot of Choice app from Been, Inc.

THE WORLD has finally caught up with Been, Inc. Three years ago, this tiny start-up company shared my studio space in New York. Their product idea was remarkably original: instead of passively accepting the data collection and loss of privacy that comes with most ad networks on the web, what if people had a choice—to either block ads and third-party trackers entirely, or earn rewards for letting ads through?

The initial web-based product, playfully designed by Monkey Do, took the scariness and complexity out of tracking issues, and returned the decision making power to the consumer. Unfortunately, the mainstream web wasn’t ready for ad blocking, and consumers en masse either weren’t ready to think about privacy, or simply didn’t know the company’s value proposition because of its nonexistent marketing budget. (The only thing that kills products faster than no marketing is poor execution—although a handful of products have survived both.)

To stay afloat in the face of mass indifference, the company temporarily pivoted, using a portion of their technology to facilitate sharing of web content between consumers, much like the late lamented Ma.gnolia or Pocket’s new Recommended section. But where Ma.gnolia and Pocket were/are text-powered, the pivoted Been app was primarily visual, which helped it gain traction in the eduation market. Grade-school teachers and kids loved using the app for research projects—and their support helped the company stay in business long enough for the internet to catch up with their ideas.

Version 2.0 of their Choice app for iOS is the product of years of work on user privacy, data ownership, and control. iOS fans can download it at www.been.mobi/getv2edu.

The company’s site explains the push-button mechanics through which you can choose to block ads and third-party trackers in your apps and Safari, or earn rewards by letting ads through and sharing (strictly non-personal) information with Been. (Earn Mode is limited to US users for now.)

When I foolhardily put down my deposit on a New York studio that was larger and more costly than what I needed, my hope was that it would attract a like-minded community of designers and tech companies from whom I would learn and be inspired. That was certainly the case with my friends at Been! I wish them great success at helping to bring the changes our web needs.

Progressive Enhancement FTW with Aaron Gustafson

Book cover art - Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd EditionLONGTIME developer, lecturer, and web standards evangelist Aaron Gustafson and I discuss the newly published update to Aaron’s best-selling industry classic “love letter to the web,” Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition (New Riders, 2015) in Episode № 140 of The Big Web Show—everything web that matters.

Topics covered include: Aaron’s superhero origin story as a creator of progressively enhanced websites and applications; “we’re not building things we haven’t built on the web before;” “creating opportunities for people outside your comfort zone;” development in the world of Node.js; “every interface is a conversation;” “visual design is an enhancement;” “interaction is an enhancement;” nerding out over early web terminal interfaces; Microsoft, Opera, and more.

Sponsored by DreamHost, Braintree, and Thankful.

Deal

Save 35% off Aaron Gustafson’s Adaptive Web Design: Crafting Rich Experiences With Progressive Enhancement, 2nd Edition when you enter discount code AARON35 at checkout.

URLS

https://www.aaron-gustafson.com/about/ – About Aaron
http://adaptivewebdesign.info/2nd-edition/ – Adaptive Web Design Second Edition (“95% new material”)
[PDF] – Read the first chapter free (PDF)
http://adaptivewebdesign.info – First Edition, May 2011 (read the entire first edition free)
http://webstandardssherpa.com – Web Standards Sherpa
https://github.com/easy-designs/batch-ua-parser.php – UA Parser Script by Aaron – on Github
https://www.aaron-gustafson.com/notebook/ – Notebook: Aaron’s blog
https://www.aaron-gustafson.com/speaking-engagements/ – Engagements: Aaron’s speaking page, using Quantity Queries
http://alistapart.com/article/quantity-queries-for-css – “Quantity Queries for CSS” by Heydon Pickering in A List Apart
http://alistapart.com/author/agustafson – A List Apart: articles by Aaron Gustafson
http://alistapart.com/article/goingtoprint – Eric Meyer’s “CSS Design: Going to Print” in A List Apart
https://www.whatsapp.com – Whatsapp

Web Performance Today

WEB DESIGNERS have cared about web performance since the profession’s earliest days. When I started, we saved user bandwidth by employing GIF images that had the fewest possible colors—with no dithering, when possible, and by using actual web text instead of pictures of web text. (Kids, ask your parents about life before CSS enabled, type designers created formats for, browsers finally supported, and Typekit quickly popularized web fonts.)

Later, we learned to optimize JPEGs and blur their backgrounds: the blurrier large swathes of a JPEG image can be, the lower the bandwidth requirements for the image. We found the optimally performant size for repeating background tiles (32 x 32 and 64 x 64 were pretty good) and abandoned experiments like single-pixel-wide backgrounds, which seemed like a good idea but slowed browsers, servers, and computers to a crawl.

We developed other tricks, too. Like, when we discovered that GIF images optimized better if they possessed repeating patterns of diagonal lines, we worked diagonal background images into a design trend. It was the trend that preceded drop shadows, the wicked worn look, and skeuomorpic facades, which were themselves a retro recurrence of one of the earliest styles of commercial web design; that trend, which was always on the heavy side, performance-wise, eventually gave way to a far more performant grid-driven minimalism, which hearkened back to classic 1940s Swiss graphic design, but which our industry (sometimes with little knowledge of design history) called “flat design” and justified as being “born digital” despite its true origins going back to pixels, protractors, and a love of Greek mathematics.

All of this nostalgia is prelude to making the obvious comment that web design today is far more complex than it was in those golden years of experimentation; and because it is so much more complex, front-end performance is also far more complicated. You didn’t need an engineering degree to run DeBabelizer and remove needless elements from your markup, but, boy, does front-end design today feel more and more like serious coding.

All of which is to say, if you’re a front-end designer/developer, you should probably read and bookmark Nate Berkopec’s “Ludicrously Fast Page Loads – A Guide for Full-Stack Devs.” While you’re at it, save it to Pocket, and as a PDF you can read on your tablet.

I cannot verify every detail Nate provides, but it is all in line with recommendations I’ve heard over and over at top conferences, and read in articles and books by such performance mavens as Jake Archibald, Lara Hogan, Scott Jehl, and Yesenia Perez-Cruz.

You should also pick up these great books on performance:

(It’s not why I wrote this post, but if you order Scott’s book today, you can save 10% when you enter discount code ABAHARVEST at checkout.)

Even the most complex site should work in any device that reads HTML. It should work if stylesheets fail to load or the device doesn’t recognize CSS. It should work if JavaScript fails to load or the device doesn’t recognize JavaScript. The principles of standards-based design will never change, no matter how complex our web becomes. And as it becomes more complex (and, arguably, much richer), it behooves us to squeeze every byte of performance we can.

Websites can never be too rich or too thin.

You’re welcome: cutting the mustard then and now.

EVERY TIME I hear a young web developer cite the BBC’s forward-thinking practice of “cutting the mustard,” by which they mean testing a receiving web device for certain capabilities before serving content, I remember when my team and I at The Web Standards Project invented that very idea. It’s a million web years ago, by which I mean fourteenish human years ago, so nobody remembers but me and some other long toothed grayhairs, plus a few readers of the first edition of Designing With Web Standards. But I like you, so I will tell you the story.

Back then in those dark times, it was common practice for web developers to create four or more versions of the same website—one for each browser then in wide use. It was also a typical (and complementary) practice to send server-side queries to figure out which browser was about to access a site’s content, and then send the person using that browser to the site version that was configured for her browser’s particular quirks, proprietary tags, and standards compliance failings.

The practice was called “browser detection.” Nobody but some accessibility advocates had ever questioned it—and the go-go dot-com era had no time or care for those folks.

But we at The Web Standards Project turned everything on its head. We said browsers should support the same standards instead of competing to invent new tags and scripting languages. We said designers, developers, and content folks should create one site that was accessible to everyone. In a world like that, you wouldn’t need browser detection, because every browser and device that could read HTML would be able to feast on the meat of your site. (And you’d have more meat to share, because you’d spend your time creating content instead of crafting multiple versions of the same site.)

To hasten that world’s arrival, in 2001 we launched a browser upgrade campaign. Those who participated (example participant here) employed our code and content to send their users the message that relatively standards-compliant browsers were available for every platform, and inviting them to try one. Because if more people used relatively standards-compliant browsers, then we could urge more designers and developers to create their sites with standards (instead of quirks). And as more designers and developers did that, they’d bump against still-unsolved standards compliance conundrums, enabling us to persuade browser makers to improve their standards compliance in those specific areas. Bit by bit, stone by stone, this edifice we could, and would, erect.

The code core of the 2001 browser upgrade campaign was the first instance of capability detection in place of browser detection. Here’s how it worked. After creating a valid web page, you’d insert this script in the head of your document or somewhere in your global JavaScript file:

if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}

We even provided details for various flavors of markup. In HTML 4 or XHTML 1 Transitional documents, it looked like this:

<script type="text/javascript" language="javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->
</script>

In STRICT documents, you’d either use a global .js file, or insert this:

<script type="text/javascript">
<!-- //
if (!document.getElementById) {
window.location =
"http://www.webstandards.org/upgrade/"
}
// -->

You could also just as easily send visitors to an upgrade page on your own site:

if (!document.getElementById) {
window.location =
"http://www.yourdomain.com/yourpage.html"
}

Non-WaSP members (at the time) J. David Eisenberg, Tantek Çelik, and Jim Heid contributed technical advice and moral support to the effort. WaSP sysadmin Steven Champeon, the inventor of progressive enhancement, made it all work—under protest, bless him. (Steve correctly believed that all web content should always be available to all people and devices; therefore, in principle, he disliked the upgrade campaign, even though its double purpose was to hasten the arrival of truly standards-compliant browsers and to change front-end design and development from a disrespected world of hacks to a sustainable and professional craft. ((See what I did there? I’m still respectfully arguing with Steve in my head.)))

Discovering rudimentary DOM awareness or its absence in this fashion was the first time web developers had tested for capabilities instead of chasing the dragon in a perpetual and futile attempt to test for every possible browser flavor and version number. It was the grandparent, if you will, of today’s “cutting the mustard.” And it is analogous as well to the sensible responsive design practice of setting breakpoints for the content, instead of trying to set appropriate breakpoints for every possible device out there (including all the ones that haven’t been invented yet).

Which reminds us that the whole point of web standards was and is forward compatibility—to create content that will work not only in yesterday’s and today’s browsers and devices, but in all the wonderful devices that have yet to be invented, and for all the people of the world. You’re welcome.

—CHICAGO, Westin Chicago River Hotel, 1 September 2015


Hat tip: John Morrison

This Week In The Death of Publishing & The Web

FAST COMPANY writes:

Apple, like Facebook, has entered into a standoff with the publishing industry and the open, if for-profit, web. And it’s being done under the aegis of design: choose a better reading experience on our curated platform, they offer, or let us clean up that pesky advertising on the open web.

Source: Apple Saves Publishing… For Itself

N.B. This is not the first time this conversation has arisen, nor will it be the last. Off the top of my head, see also:

⇛ Is the web under threat? Will Facebook or Apple kill or save journalism? Share your thoughts or your favorite links on the subject. Bonus points for older articles.

No Good Can Come of Bad Code: Ask Dr Web in A List Apart

Remember: the future will come whether you design for it or not. If your company charges $300,000 for a website that won’t work on next week’s most popular device, your company won’t be able to stay competitive in this business. It might not even be able to stay in the business, period. After all, clients who pay for sites that break too soon will look elsewhere next time—leaving your company perpetually hunting for new clients in a downward spiral of narrowing margins and diminishing expectations.

Your company’s survival is tied to the ability of the products it makes to work in situations you haven’t imagined, and on devices that don’t yet exist. This has alwaysbeen the challenge of web design. It’s one A List Apart has taken seriously since we began publishing, and our archives are filled with advice and ideas you can boil down and present to your bosses.

Source: No Good Can Come of Bad Code

Material Design: Why the Floating Action Button is bad UX design

I HIGHLIGHTED so many passages in this brief, well-focused design argument, it’s almost embarrassing. Read it (it takes about three minutes), and you’ll wear out your virtual highlighter, too:

Material Design is a design language introduced by Google a year ago, and represents the company’s bold attempt at creating a unified user experience across all devices and platforms. It’s marked with bold colours, a liberal but principled use of shadows to indicate UI layers, and smooth animations that provide a pretty pretty user experience on Android (and some Google apps on iOS).

One thing about Material Design, however, has bugged me ever since it was introduced last year: Floating Action Buttons.

Floating Action Button | Image credit: Google

FABs are circular buttons that float above the UI and are “used for a promoted action,” according to Google. They act as call to action buttons, meant to represent the single action users perform the most on that particular screen.

And because of the bold visual style of Material Design, FABs are strikingly hard to ignore and stand out — and herein lies the problem.

While FABs seem to provide good UX in ideal conditions, in actual practice, widespread adoption of FABs might be detrimental to the overall UX of the app. Here are some reasons why.

Material Design: Why the Floating Action Button is bad UX design by Teo Yu Siang

Designer Blindness

AFTER USING the web for twenty years, and software for an additional ten, I’ve come to believe that I suffer from an affliction which I will hereby call “designer blindness.”

Put simply, if an interface is poorly designed, I will not see the data I looked for, even if it is right there on the page.

On a poorly designed table, I don’t find the column containing the answer I sought.

On a poorly designed interface, I don’t push the right buttons.

On a poorly designed social sharing site, I delete my data when I mean to save it, because the Delete button is in the place most designers put a Save button.

This doesn’t happen to everyone, which is why I call it an affliction. Indeed, it happens to almost no one.

My non-designer friends and family seem quite capable of using appallingly designed (and even undesigned) sites and applications. Somehow they just muddle through without pushing the button that erases their work.

In fact, the less concerned with aesthetics and usability these friends and family members are, the more easily they navigate sites and applications I can’t make head nor hair of.

Like the ex-girlfriend who mastered Ebay.

Or the colleagues who practically live in Microsoft Excel, an application I still cannot use. There are tabs on the bottom, way below the fold, way past where the data stops? And I’m supposed to scroll a blank page until I find those tabs? It’s easy for most people, but it never occurs to me no matter how often I open an Excel document. I could open a thousand Excel documents and still never think to scroll past a wall of empty rows to see if, hidden beneath them, there is a tab I need to click. Just doesn’t occur to me. Because, design.

It’s not a visual or mathematical disability. If something is well designed, I can generally use it immediately. It’s the logic of design that trips me up.

I recognize that I’m an edge case—although I bet I’m not the only designer who feels this way. Give me something that is well designed, and I will master it, teach others about it, and unconsciously steal my next five original ideas from it. Give me something poorly designed, something that works for most people, and I’ll drive a tank into an orphanage.

Not that I’m a great designer. I wouldn’t even call myself a good designer. I’m just good enough to get messed up by bad design.

Yet you won’t hear me complain about my designer blindness.

See, divorce is a terrible thing, but if you have a kid, it’s all worth it. The heartache, the anger, the loss of income and self-esteem, the feeling that no matter what you say or do, you are going to be someone else’s monster forever—all the unbearable burdens of failed love and a broken family are worth it if, before that love failed, it brought a wonderful child to this world.

For my daughter I would suffer through a thousand divorces, a million uncomfortable phone calls, a trillion emotionally fraught text messages.

And how I feel about my kid is how I also feel about my design affliction. The pain of being unable to use what works for other folks is more than compensated for by the joy of recognizing great design when I see it—and the pleasure of striving to emulate that greatness, no matter how badly I fail every time.