Yesterday was the nth annual Blue Beanie Day. (I’ve lost track of what year the standardista holiday started.) I was awake at 1:00 AM on Friday night/Saturday morning, so I tweeted “Happy #BlueBeanieDay,” then slept. No blog post, no prelude—just a past-midnight tweet, over and out.
Saturday, once or twice, I checked Twitter and retweeted most of the Blue Beanie Day tweets I found.
Most, because I omitted a soft-porn one that seemed to be capitalizing on the hashtag to advertise its Instagram feed (which, to judge by the tweet, consists of reposts of old Suicide Girls pictorials). So maybe the hashtag trended briefly for that person. One measure of social media success on Twitter is when someone who doesn’t understand or care about your hashtag uses it to draw attention to a tweet that has nothing to do with your cause—which tells you a lot about Twitter, and social media, and where we are as a culture. But I digress.
That shrinking feeling
Generally, each year, Blue Beanie Day gets smaller, possibly in part because I’m too busy to promote it beforehand (or during, or after). And because it immediately follows U.S. Thanksgiving, so gets broadcast when many U.S. web folks are offline and in food comas.
Blue Beanie Day also gets smaller each year because web design as a practice and as a discipline keeps shrinking … even though frontend UX, or whatever we’re calling it this week, clearly continues to grow.
Mainly, though, Blue Beanie Day is receding from view because our industry as a whole thinks less and less about accessibility (not that we ever had an A game on the subject), and talks less and less about progressive enhancement, preferring to chase the ephemeral goal posts of over-engineered solutions to non-problems.
If web design were automotive design, we’d be past the invention of mass production and on to designing self-obsoleting tail fins. But I digress, and I regret the negative spin this mini-memoir is taking.
Because, really, I’m happy and grateful.
Blue Beanie Day matters
In spite of our industry’s (I hope temporary) focus on complexity for its own sake, there are still a lot of you who do this work in the service of people we used to call “end-users,” and who will care about web standards and inclusive, accessible design for as long as you’re here to practice it.
To you, the true believers, whether you knew about/celebrated Blue Beanie Day or not, I give thanks.
Thanks for showing up every day to try to make the web a little better. Thanks for your optimism, especially when it gets harder to stay positive. You make an inclusive web possible.
Thanks for keeping Blue Beanie Day alive, not just on your head, but in your heart.
ABOUT A YEAR ago, around the time I launched my new design studio, I moved nearly all business-related communications to Basecamp 3, the latest evolution of the web-based project and communications management tool from my Chicago designer friends who used to be called 37signals.
One of Basecamp 3’s nicest features is the ability to set up automatic check-ins, such as asking all team members “What did you work on today?” at 5:00 pm daily.
On the surface, it’s intended as a way of letting everyone know what their teammates are working on, thereby deleting needless meetings from everyone’s schedules. But the feature can go much deeper, as I’ve discovered to my great pleasure. A day at a time, it can build community and help you design your career and your life. It even brings back some of the joy we once derived from the days of the personal web.
What did you work on today?
Over the years, I’ve started or cofounded several web-related businesses. Rather than limit my new studio.zeldman Basecamp exclusively to the designers, developers, and UX specialists who make up my studio, I decided to include everyone from allthebusinessesI touch.
Naturally, I’m mindful of people’s bandwidth, so anyone who doesn’t wish to participate can opt out or selectively block threads or projects that don’t interest them. I also refrained from inviting two staffers from one of my businesses who, for whatever reason, have just never hit it off with Basecamp. (Evangelizing any tool, however much one personally loves it, is like trying to convince a carnivore to go vegan. It accomplishes nothing, and leaves everyone feeling hurt.)
Save those two folks, with whom I collaborate through other methods, everyone else I work with on a daily or weekly basis, across all my little businesses, has access to a shared Basecamp. And every day at 5:00 pm Eastern Time, Basecamp asks all of us, “What did you work on today?”
The evolution of open sharing
At first, those who chose to participate took the question literally, sharing the work-related tasks we’d accomplished that day. But, over time, we began something sharing else. We began sharing our lives.
As if in a Unitarian church group, or an AA meeting, we share daily joys and sorrows, hopes and aspirations. One of us has a child leaving the nest; another’s child may have had a tough day at school. One of us is writing a book, another has begun physical therapy. Some of us comment on each other’s shares; others use Basecamp’s “applause” feature to indicate that we read and appreciated what was shared. Some folks write essays; others share via bulleted lists.
Hearkening back to the old, personal web
Sharing and reading other people’s posts has become a highlight of my day. Of course it helps me get my work done, but more importantly, it also lets me focus on my life and professional goals—and those of my friends. I love getting to know people this way, and I deeply appreciate how respectful and safe our sharing space feels—partly because Basecamp designed the space well, and partly because I work with people who are not only talented and bright, but also kind and empathetic.
If we all sat together in the same office space, I doubt we would let down our guard as much as we do when responding to Basecamp’s automatic check-in. Indeed, far less personal sharing goes on with the non-remote colleagues in my NYC studio space—probably because we are all there to work.
It reminds me of what life was once like on the old web, where people shared honestly on their personal sites without fear of being harassed. I’m not the only old-timer who misses that old web; in recent years, several of my internet friends who once blogged blithely have switched to opt-in newsletters, sharing only with subscribers. Although I mourn the personal, open-hearted web we once shared, I understand this impulse all too well. Sharing with my colleague/friends on Basecamp restores some of the joy I used to take from sharing and listening on the old open web. You might try it.
THIS year’s Poynter Digital Newspaper Design Challenge was an attempt by several designers and pundits, working and thinking in parallel, to save real news via design. In Part 1 of my report from Poynter, I discussed the questions driving the challenge, and talked about the design work done in response to it by my colleagues Kat Downs Mulder, Mike Swartz, Lucie Lacava, and Jared Cocken. Here in Part 2, I’ll discuss my own work and the approach we took at my studio. But we begin with a quick look back at the past designs that brought us to this point:
Experiment 1: The Deck
During the past decade and a half, as both a publication designer and a publisher, I watched in horror as our publications became reader-hostile minefields of intrusive ads, overlays, and popups. The first thing I tried to do about this (besides removing the web equivalent of chart junk from my magazine) was to offer an alternative approach to advertising via The Deck, an ad network I cofounded with Jim Coudal of coudal.com and Jason Fried of Basecamp (formerly 37signals). The Deck permitted only one appropriately targeted ad per each page of content viewed. As primary instigator Jim Coudal put it:
A buy in The Deck reaches the creative community on the web in an uncluttered, controlled environment, far more valuable than a standard banner or a single text ad among dozens of others.
Jim, Jason, and I hoped that our cost-per-influence model would replace the CPM race to the bottom, and that our quasi-religious use of whitespace would be widely imitated by the smartest publications online.
But that didn’t happen. Advertising just got more intrusive. The Deck succeeded as a small business supporting a network of interesting small publications, but not at all as a primary influencer on the direction taken by advertising that supports web content.
Experiment 2: Readability
Then about seven years ago, my friend Rich Ziade and his engineers created Readability, an app that sat between you and the ugly site you were trying to read, the way screen readers sit between visual websites and blind web users. Readability grabbed an article page’s primary content, removed the junk, and replaced the cluttered and illegible layout with a clean, readable page inspired by the clarity of iBooks and Kindle, which were just taking off at the time.
Rich released Readability 1.0 as open source; Apple immediately absorbed it into the Safari browser, where it continues to provide Safari’s built-in “reader” mode. (Safari’s “reader” mode was Apple’s first step in decluttering the web and returning it to the people who use it; “content blocking” would be the second step.)
Moreover, Readability 2.0, released by Rich’s then-company Arc90 the following year, added automatic payment for content creators slash publishers, as I explained at the time to anyone who would listen. Had Readability been allowed to continue the experiment, content monetization might have been less of a problem than it is today, and publication brands (the notion that it matters who publishes what we read) would be in exactly the same pickle they’re in anyway—except that readers would get their news in Readability’s attractive and customizable format, instead of from Apple News, Facebook, and the like.
I used to go around the world on lecture tours, warning my fellow designers that if we didn’t figure out how to declutter and compellingly brand sites, apps like Readability would do it for us. I still go around on lecture tours, but I’ve moved on to other issues. As for Readability, it was killed by a digital lynch mob after one powerful blogger, misunderstanding the motivation behind it, issued the digerati equivalent of a fatw?. But that’s another story.
Experiment 3: Big Type Revolution
In 2012, inspired by Readability and frustrated by the industry’s determination to make ever less legible, ever more cluttered sites full of tracking and popups and everything except what readers need, I bet big on large type:
This redesign is a response to ebooks, to web type, to mobile, and to wonderful applications like Instapaper and Readability that address the problem of most websites’ pointlessly cluttered interfaces and content-hostile text layouts by actually removing the designer from the equation. (That’s not all these apps do, but it’s one benefit of using them, and it indicates how pathetic much of our web design is when our visitors increasingly turn to third party applications simply to read our sites’ content. It also suggests that those who don’t design for readers might soon not be designing for anyone.)
Writing in Forbes, Anthony Wing Kosner saw the future in my initially crude experiment:
If you want to know where the web is going, one clue is to look at the personal sites of top-tier web designers. And one trend that just bubbled to the surface is large body type—the kind you don’t have to command-plus to read.
Not to brag (okay, too late), but he wasn’t wrong. It was the future.
(Also, I’m fairly sure I wasn’t the only designer at the time who reacted against tiny type and cluttered anti-user layouts by stripping pages down to only their most necessary elements, and boosting the type size to enforce a more relaxed reading posture. The idea was in the air.)
An uncluttered page focused on the reading experience (reminder: big type and plenty of whitespace) is now the default at several leading news publications. But many smaller publications, struggling just to survive, have not kept up. And so we have a perfect crisis:
Publications that do not encourage reading, loyalty, or repeat visits are struggling to survive at the very moment real news is under attack from an authoritarian president. What to do?
My response to the Poynter Design Challenge
There are many ways to respond to an existential crisis like the one facing most news publications. You can rethink the relationship between reader and publication. Rethink the job of the publication. Make news work more like a lifestyle app. Make it more immersive. My colleagues followed those paths out brilliantly (as described in Part 1).
But I went for the low-hanging fruit. The thing any publisher, no matter how cash-strapped, could do. The thing I had seen working since I started yelling about big type in 2012. I went for a clean, uncluttered, authoritative, branded page. Authoritative because this isn’t fake news. Branded because the source matters.
The easiest, fastest, most readily attainable path to clean, uncluttered, authoritative, branded design is through typography.
Any publication can be readable
Any newspaper, however poor, can afford better typography. Any newspaper with a designer on staff can attain it, if the paper stops treating design as a lackey of marketing or editorial or advertising, and sets designers free to create great reading experiences.
In my work, which is still underway (and will continue for some time), I focused on creating what I call “reader” layouts (and probably other designers call them that too; but I just don’t know). Layouts that are branded, authoritative, clean, uncluttered, and easy to read.
I played with type hierarchies and created simple style guides. Most of my little pages began as Typecast templates that I customized. And then Noël Jackson from my studio cleaned up the HTML and CSS to make it more portable. We put the stuff up on GitHub for whoever wants to play with it.
CAN design create a better user experience that engages readers and drives revenue? Can it fight fake news and help save real journalism at a time when news organizations large and small are underfinanced and under attack?
The challenge began October 17–18 in New York, with five pundits and five designers, of whom I was honored to be one, workshopping a project brief during a two-day conference event at the Columbia Journalism School. (You can watch videos of all these sessions courtesy of Fora.tv.)
The next phase took place yesterday in St. Petersburg, Florida, as the four other designers and I presented our work to a live audience. In this short piece, I’ll talk about the designs my colleagues presented; in the next, I’ll discuss my own.
Reconnecting with the people: the challenge for digital news
Roger Black described the difficulties facing digital news publications:
The challenge is serious. Fake news crowds real news. Numbers no longer add up for publishers. Readers jump from site to site without knowing where they are, or staying for long. You can see the brief for this project here.
Can design help? Well, as a I designer, I think it can. I mean, the design of most news pages is not what you’d call attractive. But the solutions proposed at Poynter will be much more strategic than cosmetic. And they’re strategies that can be combined.
—Five design answers that add up, Roger Black, January 20, 2017
“A news publication might think a bit more like Fitbit”
Between us, we designers had about a century of experience designing digital publications—internally, as consultants, or both. This means that, even though an open “design challenge” brief necessarily omits an unknown number of the specific requirements any actual publication design assignment would include, all of us were aware of, and to some degree addressed, typical news publication requirements not included in our brief.
Kat Downs Mulder, Graphics Director at The Washington Post, shared a prototype for a big-brand news site. Kat had just given birth to a healthy baby boy (congratulations!), so her work was presented by two of her colleagues from The Post. Kat did not design with the avid, committed news reader in mind (since those folks are not the problem for most publications). Instead, she pondered how to engage the typically fragmented attention of today’s distracted and passive news reader:
“A big-brand news site [should be] aware that people have a lot more to do in their lives than read the news,” Kat posited. Thus, “A news publication might think a bit more like Fitbit. That is, it should make you feel like it’s working for you. A reader should say, ‘I’m reading everything I need to know.’”
Keep that dopamine pumping
Kat presented a multi-paned prototype. The wider pane on the right contained news content; the narrower pane at left was navigation. As I’ve just described it, this isn’t much different from the current Post website, but Kat’s prototype was very different, because it prized reader control over editorial director control; kept track of what you read; encouraged extra reading the way Fitbit encourages extra steps, and rewarded it the same way Fitbit does, with an accumulation of points that give the reader dopamine hits and create the perception that the “news app” is working for her—as a rewarding part of her busy lifestyle.
An Operating System for your city
Mike Swartz, Partner at Upstatement, a design and engineering studio in Boston, took on the challenge to smaller publications (such as his original hometown paper, the Pittsburgh Post-Gazette) which lack the resources of a Washington Post or New York Times.
Mike’s presentation, “information OS for a city: redefining the opportunity for local media,” turned the journalistic prowess of a good local paper into a superpower, connecting readers to their city the way the “terrible towel” stunt concocted in desperation by radio announcer Myron Cope in 1975 reconnected Pittsburghers to their hometown football team, and helped the Steelers win Super Bowl X over the Dallas Cowboys.
There’s a potential for an operation like the [Post Gazette] to rebrand itself as more of an “informational operating system” for its city. With different types of products that are focused and useful and not necessarily bundled into a traditional news format, we can create more enjoyable experiences and more useful products readers will love.
Building reader interest and finding a way to pay for it all
Where the rest of us avoided the elephant in the room, in her design Lucie Lacava, president of Lacava Design Inc., boldly confronted the challenges of advertising and monetization. Algorithm-driven advertising frustrates users, who, in desperation, block it. Choked for income as a result, publications and advertisers create more and more intrusive forms of unwanted advertising. Nobody wins.
And while subscription models have worked, at least partly, for some of the very top news publications, such models are not likely to help most news publications in the near term.
Digital publication as digital application
Lucie’s design addressed these challenges by recasting the news as a hyper-customized application targeted at younger users, who get to choose news streams and ads that are relevant to them. “The elusive millennial” was Lucie’s target. I cannot do her idea justice with a couple of paragraphs and a single screen shot.
Affordable, immersive VR is here
Jared Cocken, brand and product designer for hire and co-founder of STYLSH.co., approached the “attention war” by showing how any size publication could create “video or VR driven stories that enrich a user’s understanding of the world around them.”
Because VR video is immersive, it holds viewer attention. Because it is reality-based, it fights fake news. (It’s hard to call bullshit on a scene you can explore from any angle.) VR also, potentially, builds compassion. It’s one thing to read about conditions in a Syrian refugee camp, another to visually experience them in VR.
Until now VR and video have been cost-prohibitive, but, working (and co-presenting) with VR startup founder Anna Rose and Hollywood producer/actor Banks Boutté, Jared showed how even woefully under-financed newsrooms can use newly designed, super-affordable tools to create “video or VR-driven stories that enrich a user’s understanding of the world around them.”
Blogging about a conference is like tweeting about a sexual experience. You had to be there. I wanted to record and share the outlines of what my fellow designers presented, but these few paragraphs should in no way be considered authentically representative of the deep thinking and work that went into every presentation.
You may see holes in some of the arguments presented here. In some cases, I might agree with you—some ideas, while dazzlingly creative, did not seem to me like the right way to save news. But in most cases, if an idea seems wrong, blame my telling. If you had been there and heard and seen everything, the value of the proposal would have far more apparent than it can be here.
I love that each of us took on a quite different aspect of the problem, and addressed it using very different tools. I’ll be back soon with a short write-up of the design approach I took. Meanwhile, I want to thank all the pundits, designers, and attendees in New York and St. Petersburg—and the Poynter Institute, Roger Black, and William R. Hearst III for making it all possible.
SORRY. I disagree. Nonsemantic classnames that refer to visual styles will always be a bad idea.
I’m sure you’re a good coder. Probably much better than I am these days. I know most of you weren’t around for the standards wars and don’t know how much damage non-semantic HTML and CSS did to the web.
I’ve worked on big sites and I understand how bloated and non-reusable code can get when a dozen people who don’t talk to each other work on it over a period of years. I don’t believe the problem is the principle of semantic markup or the cascade in CSS. I believe the problem is a dozen people working on something without talking to each other.
Slapping a visually named class on every item in your markup may indeed make your HTML easier to understand for a future developer who takes over without talking to you, especially if you don’t document your work and create a style guide. But making things easier for yourself and other developers is not your job. And if you want to make things easier for yourself and other developers, talk to them, and create a style guide or pattern library.
The codebase on big sites isn’t impenetrable because developers slavishly followed arbitrary best practices. The codebase is broken because developers don’t talk to each other and don’t make style guides or pattern libraries. And they don’t do those things because the people who hire them force them to work faster instead of better. It starts at the top.
Employers who value quality in CSS and markup will insist that their employees communicate, think through long-term implications, and document their work. Employers who see developers and designers as interchangable commodities will hurry their workers along, resulting in bloated codebases that lead intelligent people to blame best practices instead of work processes.
The present is always compromised, always rushed. We muddle through with half the information we need, praised for our speed and faulted when we stop to contemplate or even breathe. Frameworks built on newish worst practices seem like the way out, but they end up teaching and permanently ingraining bad habits in a generation of web makers. Semantics, accessibility, and clarity matter. Reusability is not out of reach. All it takes is clarity and communication.
IN a world where newspapers are dying and half the public believes fake news, what online news experiences need is design that is branded, authoritative, and above all, readable:
Branded, because we need to convert the current hummingbird model (where readers flit from flower to flower) back to the idea that your news source matters—and that it is worth your time to return to a source you trust.
Brand helps the social-media-driven seeker notice that they’re returning time and again to a certain resource, facilitating a mental model shift back toward destination web browsing. When every site looks the same, it’s easy to see all content as equal—all spun from the same amorphous mass. A strong brand, which is individual to the given newspaper, can cut through that amorphousness, which is the first step in building (or rebuilding) loyalty.
Authoritative, because combating fake news means visually cueing the reliability of a particular source—one staffed by real journalists and editors, with real sources in real countries. In the coming years this will be more important than ever.
Readable, because an informed public needs to grasp stories that can’t always be reduced to headlines or sound bytes. Readability means even longer articles actually get read, sometimes even all the way through. Readability requires a combination of typeface, type size, leading, measure, hierarchy, contrast, etc.—as well as the introduction of visual information, both to break up the flow of text, and to further illuminate what is being said.
Related news keeps readers reading
Additionally, this branded, authoritative, readable content needs to become (to use an ancient word) sticky: through a combination of editing and algorithms, related content must be presented at the appropriate time in the reading experience, to engage the visitor in continued reading.
Currently two publications—nytimes.com and medium.com—achieve all these goals better than any other publications on the web. One is the newspaper of record; the other is a vehicle for anyone’s content. Yet both really do the job all newspapers will need to do to survive—and to help the Republic survive these next years. I particularly admire the way both publications surface related content in a way that practically demands additional reading.
Design won’t solve all the problems facing newspapers, but it will help. And unlike more “immersive” approaches such as WebVR, original full-screen imagery, and original embedded video, the basics of solid, readable design should not be out of budgetary reach for even the most cash-strapped news publisher—budget being a problem for any business at any time, but especially for newspapers now.
In my studio, we’ve been pondering these problems for content sites of all types (not only newspapers). At the Poynter Digital Design Challenge next month, I hope to share designs that nudge the conversation along just a bit further.
BOY, was this show overdue. For the first time ever on The Big Web Show, I chat with my friend, front-end developer extraordinaire Brad Frost, author of the spanking new book, Atomic Design.
We have fun. We go way over time. We kept talking after the show stopped. There was just so much to discuss—including Pattern Lab and style guides, being there for the iPad launch, working with big brands, how to say no and make the client happy you said it, avoiding antipatterns, mobile versus “the real web” (or the way we saw things in 2009), dressing for success, contributing to open source projects, building a community, the early days of Brad’s career, and that new book of his.
Jeremy Keith was the seventh speaker at An Event Apart San Francisco this month. His presentation, Evaluating Technology, set out to help us evaluate tools and technologies in a way that best benefits the people who use the websites we design and develop. We looked at some of the hottest new web technologies, like service workers and web components, and dug deep beneath the hype to find out whether they will really change life on the web for the better.
Days of future past
Its easy to be overwhelmed by all the change happening in web design and development. Things make more sense when we apply an appropriate perspective. Although his presentation often dealt with “bleeding-edge” technologies (i.e. technologies that are still being figured out and just beginning to be supported in some browsers and devices), Jeremy’s framing perspective was that of the history of computer science—a field, pioneered by women, that evolved rationally.
Extracting the unchanging design principles that gave rise to the advances in computer science, Jeremy showed how the web evolved from these same principles, and how the seemingly dizzying barrage of changes taking place in web design and development today could be understood through these principles as well—providing a healthy means to decide which technologies benefit human beings, and which may be discarded or at least de-prioritized by busy designer/developers working to stay ahead of the curve.
Resistance to change
“Humans are allergic to change,” computer science pioneer Grace Hopper famously said. Jeremy showed how that very fear of change manifested itself in the changes human beings accept: we have 60 seconds in a minute and 24 hours in a day because of counting systems first developed five thousand years ago. Likewise, we have widespread acceptance of HTML in large part because its creator, Tim Berners-Lee, based it on a subset of elements familiar from an already accepted markup language, SGML.
How well does it fail?
In our evaluating process, Jeremy argued, we should not only concern ourselves with how well a technology works, but also how well it fails. When XHTML 2.0 pages contained an error, the browser was instructed not to skip that error but to shut down completely. Thus, XHTML 2.0 was impractical and did not catch on. In contrast, when an HTML page contains an error or new element, the browser skips what it does not understand and renders the page. This allows us to add new elements to HTML over time, with no fear that browsers will choke on what they don’t understand. This fact alone helps account for the extraordinary success of HTML over the past 25 years.
Likewise, service workers, a powerful new technology that extends our work even when devices are offline, fails well, because it is progressively enhanced by design. If a device or browser does not support service workers, the content still renders.
Jeremy used the example of The Washington Post’s Progressive Web App, which has been much touted by Google, who are a driving force behind the movement for progressive web apps. A true progressive web app works for everyone. But The Washington Post’s progressive web app demands that you open it in your phone. This kind of retrograde door-slam is like the days when we told people they must use Flash, or must use a certain browser or platform, to view our work. This makes it the antithesis of progressive.
Dancing about architecture
There was much, much more to Jeremy’s talk—one of the shortest hours I’ve ever lived through, as 100 years of wisdom was applied to a dizzying array of technologies. Summarizing it here is like trying to describe the birth of your child in five words or less. Fortunately, you can see Jeremy give this presentation for yourself at several upcoming An Event Apart conference shows in 2017.
The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017. Tomorrow I’ll be back with more takeaways from another AEA San Francisco 2016 speaker.
12 LESSONS from An Event Apart San Francisco – ? 4: Jason Grigsby was the 10th speaker at An Event Apart San Francisco last week. Jason’s session, Adapting to Input, presented designers and developers with a conundrum many of us hadn’t yet considered when designing for our new spectrum of web-capable devices.
Responsive web design forced us to accept that we don’t know the size of our canvas, and we’ve learned to embrace the squishiness of the web. Well, input, it turns out, is every bit as challenging as screen size! We have tablets with keyboards, laptops that become tablets, laptops with touch screens, phones with physical keyboards, and even phones that become desktop computers. What’s a design mother to do?
During his session, Jason guided us through the input landscape, showing us new forms of input (such as sensors and voice control) and sharing new lessons about old input standbys. We learned the design principles needed to build websites that respond and adapt to whichever inputs people choose to use.
Four truths about web inputs
Jason began by sharing four truths about input in 2016:
Input is exploding — The last decade has seen everything from accelerometers to GPS to 3D touch.
Input is a continuum — Phones have keyboards and cursors; desktop computers have touchscreens.
Input is undetectable — Browser detection of touch‚ and nearly every other input type, is unreliable.
Input is transient — Knowing what input someone uses one moment tells you little about what will be used next.
A Golden Rule of Inputs
Just as many of us screwed up our early approach to multi-device design by consigning the “mobile web” to a non-existent “mobile context,” we now risk making a similar blunder by believing that certain tasks are “only for the keyboard”—forgetting that by choice or of necessity, the people who engage with our websites use a variety of devices, and our work must be available to them all.
One of my principal takeaways from Jason’s presentation was that every desktop design must go “finger-friendly.” Or, as Josh Clark put it back in 2012, “When any desktop machine could have a touch interface, we have to proceed as if they all do.”
For more illuminations on input, read Jason Grigsby’s “Adapting to Input” in A List Apart, and check out these amazing demos and articles:
Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017 in the shadow of Mr Sarrinenen’s fabulous arch. See you there!
12 LESSONS from An Event Apart San Francisco – ? 2: Eric Meyer was the 11th speaker at An Event Apart San Francisco, which ended Wednesday. His session, Compassionate Design, discussed the pain that can occur when our carefully crafted websites and applications, designed to create an ideal experience for idealized users, instead collide with messy human reality.
You can’t always predict who will use your products, or what emotional state they’ll be in when they do. A case in point: when Facebook’s “Your Year in Review” feature, designed by well-meaning people to help Facebook users celebrate their most important memories from the preceding twelve months, shoved a portrait of Eric’s recently deceased daughter Rebecca in his face, surrounded by dancing and partying clip-art characters who appeared to be celebrating her death.
With great power…
Certainly, no one at Facebook intended to throw a hundred pound bag of salt into the open wound of a grieving parent. What happened, surely, was that no one sitting around the table when the feature was planned asked the question, what if one of our users just had the worst year of their lives?
If even one of the talented Facebook folks charged with creating the new feature had asked themselves “what’s the worst that can happen?”—if just one of them had realized that not everyone using Facebook felt like celebrating their year—they might have put in safeguards to prevent their algorithm from assuming that a Facebook user’s most visited (most “popular”) post of the year was also their happiest.
They might also have made the “year in review” feature an opt-in, with questions designed to protect those who had experienced recent tragedy. Facebook didn’t build in those protections, not because they don’t care, but because our approach to design is fundamentally flawed, in that we build our assumptions around idealized and average users and use cases, and neglect to ask ourselves and our teammates, “what if we’re wrong? How could our product hurt someone?”
It’s not just Facebook. We all ignore the user in crisis.
Eric shared many examples from leading sites and services of unintended and sometimes horrifying instances of designs that hurt someone—from ads that accidentally commented sadistically on tragic news stories (because keyword exclusion is underrated and underused in online advertising); to magic keywords Flickr and Google added to their customers’ photos without asking, resulting in a man’s portrait being labeled “gorilla” and a concentration camp photo being tagged a jungle gym.
The problem, Eric explained, is that our systems have not been designed with people in mind. They’ve been designed with consumers in mind. Consumers are manageable fictions. But human life is inherently messy. To create sites and applications that work for everyone, including people who may be having the worst day of their lives at the time they encounter or product or service, we must always think about how our product could be used to hurt someone, and plan for the worst-case scenario whenever we design.
When we label a usage an “edge case,” we marginalize that user and choose not to care. Think “stress case,” instead, and design for that human.
We can do better.
Eric’s presentation included many techniques for bringing these new principles into our design workflows, and his book with Sara Wachter-Boettcher, Design for Real Life, goes into even greater detail on the matter. (It’s one of those rare and important books that defines how we should be looking at our design jobs today, and I would say that even if I weren’t the publisher.)
Tomorrow I’ll be back with another top takeaway from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017.