Streaming suicide and other design decisions

So reads the headline of a January 15 news story in The Washington Post. Saying that she’d been sexually abused by a family member, 12-year-old Katelyn Nicole Davis, of Polk County, Georgia, hanged herself, broadcasting the suicide via a 40-minute live stream seen worldwide.

While YouTube immediately removed the video, it “lingered on Facebook for nearly two weeks,” according to the Post’s reporting of Buzzfeed and other unspecified “media reports.”

First, it just hurts

I keep rereading the short article and its headline as if it will make sense or stop hurting on the next scan-through. As a human being, I can’t fully process the horror and sadness of this tragedy.

I was initially going to write “as a human being and the father of a 12-year-old girl,” but that last part shouldn’t matter. You don’t need to be the parent of a child Katelyn’s age and sex to feel the feelings.

Nor does there need to be someone in your life who was raped or molested—although, whether they’ve told you about it or not, there almost surely is. Statistically there are likely multiple someones in your life who have suffered unspeakably, too frequently at the hands of people whose main job in life was to protect them. I’m sorry to have to write these words, and I hope reading them doesn’t rip open wounds.

But the point is, even if you and everyone in your circle has lived a magical life untouched by too-common crimes and horrors, it is still unbearable to contemplate too closely what Katelyn must have felt, and what she did about it, and what watching what she did must have done to those who watched the video—both the empathetic majority, and the hopefully small minority of viewers who, because of their own damage, may have gotten off on it, edging just that much closer to some future sociopathic acting-out.

A designer’s job

On a personal level, I’m good citing horror and sadness as a reaction to this ugly story. But as a web and product designer, I can’t help but see it as another instance of what Eric Meyer and Sara Wachter-Boettcher warn about in their book, Design For Real Life. Namely:

For every wonderfully fresh use of the internet’s social power we conceive, we must always ask ourselves, how might this be used to make our world more hurtful, less loving, less kind? What unforeseen dangers might our well intentioned innovation unleash?

I published Design For Real Life, but I don’t cite Katelyn’s story or repeat Sara and Eric’s moral here to sell copies. I do it to remind us all that what we make matters. Our design decisions matter. The little qualms that might float through our minds while working on a project need to be examined, not suppressed in the interest of continued employment. And the diversity of our workforce matters, because it takes many different minds to foresee potential abuses of our products.

Streaming suicide, monitoring content

Live.me isn’t the first live streaming app, and, as a category, live streaming likely does more good than harm. The existence of a live streaming app didn’t drive a girl to kill herself, although, in despair at not being listened to, she might have found solace and an appeal in the idea that her suicide, witnessed globally, could lead to an investigation and eventual justice.

Similarly, when Facebook began allowing its customers to perform live streaming (or, in Nicole’s case) to post video streams from third parties, use cases like pre-teen suicide or the torture of a mentally disabled teenager most likely did not factor into those business decisions. But here we are.

And, as much content as Facebook produces in a day, you can’t really fault them for not always being johnny-on-the-spot when some of that content violates their guidelines. But surely they can do better.

Invention is a mother

There’s no closing Pandora’s box, nor would we wish to. But we who create websites and applications must remain mindful, honest, and vigilant. We must strive to work in diverse teams that are better than homogenous groups at glimpsing and preparing for the unforeseen. More than ever, we must develop design practices that anticipate the horrible and tragic—not to mention the illegal and authoritarian.

And in life, as well as design, we must do a better job of asking ourselves what we are not seeing—what struggles the people we meet may be hiding from us, and how we can help them before it is too late.

Kiss My Classname

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.

To Save Real News

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.

In Defense of Font Size Widgets

“You don’t get to decide which platform or device your customers use to access your content: they do.”—Karen McGrane, Content Strategy for Mobile

“When a person tells you that you hurt them, you don’t get to decide that you didn’t.”—Louis C.K.

“Discomfort with others’ burdens has no place in good design.”—Mica McPheeters

“Historically, teams simply have not been trained to imagine their users as different from themselves—not really, not in any sort of deep and empathetic way.”—Sara Wachter-Boettcher

“USER CUSTOMIZATION” on the web hearkens back to the deluded old days of portals, when companies imagined you’d start your daily “net browsing” session by “logging on” to their website’s homepage. Customization was among the chief (largely imaginary) inducements for you to return to their “start” page and not others.

The thought was that changing the fonts and color scheme would make their page feel more like your home. After all, Windows 3.1 users seemed to enjoy switching their home computers to “Black Leather Jacket” or other personalized settings—if only as an escape from the computer environment at work, where their bosses enforced a rigid conformist look and feel, and dictated which software and fonts were allowed on your workstation. Surely, the thinking went, pioneering web explorers would demand custom accommodations as plush as those found in the best-selling operating system.

MySpace … and beyond!

This fetish for pointless customization—customization for its own sake—persisted through the MySpace era, where it actually made sense as an early mass offering of page owner personal branding. Its descendants are the WordPress, Tumblr, and Squarespace themes that create a professional appearance for the websites of individuals and small businesses. This is a positive (and inevitable) evolution, and a perfect denouement for the impulse that began life as “user customization.”

But, except on a few quirky personal sites like Jeremy Keith’s adactio.com, where sidebar customization widgets live on as a winking look back to the early days of personal content on the web, user customization for its own sake has long been out of favor—because experience, referrer logs, and testing have long shown that visitors don’t bother with it.

Perhaps that’s because people don’t really visit websites any more. They drop in quickly on a page found by search or referred by social media, scan quickly and incompletely, and leave, mostly never to return.

When you use Google, Bing, or Duck Duck Go to find out what a knocking sound in your radiator or a pang in your gulliver might mean, you scan for the information you sought, find it (if you’re lucky), and leave. The notion that most sites could get you to come back by offering you the ability to change fonts or colors is self-evidently absurd. Why bother?

Readability and font customization

Ah, but there’s another kind of user customization that I’m hoping and betting will make a comeback: a subtle, inclusive sort of customization that doesn’t exist for its own sake, but rather to serve.

Our glowing, high-density screens are great for watching Westworld, but a bit too bright and backlit for prolonged reading compared to the paper they’re intended to replace. But screens have one advantage over printed books (besides storage and portability): namely, they offer accessibility features a printed book never could.

I once received an architecture book written by an important scholar, but I was never able to read it, because the layout was terrible: the type was too small, the leading too tight, and (most of all) the measure far too wide to be readable. If an ebook version had been available, I’d have purchased it; but this was before the mass market availability of ebooks, and the tome is now out of print. I own it, but I shall never be able to read it.

It wouldn’t be a problem with an ebook, because all ebooks offer readers the ability to alter the contrast and the basic theme (white text on black, black text on white, dark text on a light background); all ebooks offer the ability to adjust font size; and most include the ability to change fonts. Why do Kindle and iBooks offer this flexibility? Because it helps readers who might otherwise not be able to read the text comfortably—or at all. This isn’t customization for its own sake. It’s customization for the sake of inclusion.

The grey lady and user customization

Now notice who else provides some of this same inclusive customization function: the mighty New York Times.

People in our industry tend to repeat things they’ve heard as if they are eternal verities—when the real truth is that each digital experience is different, each person who engages with it is different, and each device used to access each experience brings its own strengths and limitations.

A font size widget may smell like the pointless old-fashioned “user customization” to be found on half the unvisited sites in the Wayback Machine, but it is the very opposite of such stuff. Even mighty responsive design benefits from offering a choice of font sizes—because there are just too many complications between too many screen sizes and device features and too many pairs of eyes to ensure that even the best designer can provide a readable experience for everyone without adding a simple text size widget.

Most of the sites we’ve designed in the past few years have not had a text size widget, but I believe this was due to our privileged assumptions and biases, and not to the reality of the needs of those we serve. Going forward on client projects at studio.zeldman, and in my publications like A List Apart, I hope to correct this—and I hope you will think about it, too.

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.

Accessibility Whack-a-Mole

DESIGN is a balancing act—and never more so than when it comes to accessibility (AKA #a11y). So what can you do when an a11y solution you’ve devised for one group creates a fresh a11y dilemma for another?

Through the prism of typeface choice, Eleanor Ratliff relates how she and her team tackled the problem of accessibility whack-a-mole for a rebranding project. In today’s edition of A List Apart, for people who make websites.

This year more than ever, Blue Beanie Day matters

AT FIRST GLANCE, November 2016 has bigger fish to fry than a small, cult holiday celebrated by web developers and designers.

Each day since November 8, 2016 has brought new, and, to some of us, unimaginable challenges to the surface. Half of America is angry and terrified. The other half is angry and celebrating. At a time like now, of what possible use is an annual holiday celebrated mainly on social media by a tiny posse of standards- and accessibility-oriented web developers and designers?

From Blue Beanies to Black Hats

Many web developers have “moved on” from a progressive-enhancement-focused practice that designs web content and web experiences in such a way as to ensure that they are available to all people, regardless of personal ability or the browser or device they use.

Indeed, with more and more new developers entering the profession each day, it’s safe to say that many have never even heard of progressive enhancement and accessible, standards-based design.

Firstly, many new developers will build powerful portfolios by mastering tools whose functioning and implications they may not fully understand. Their work may be inaccessible to people and devices, and they may not know it—or know how to go under the hood and fix it. (It may also be slow and bloated, and they may not know how to fix that either.) The impressive portfolios of these builders of inaccessible sites will get them hired and promoted to positions of power, where they train other developers to use frameworks to build impressive but inaccessible sites.

Only developers who understand and value accessibility, and can write their own code, will bother learning the equally exciting, equally edgy, equally new standards (like CSS Grid Layout) that enable us to design lean, accessible, forward-compatible, future-friendly web experiences. Fewer and fewer will do so.

Secondly, since companies rely on their senior developers to tell them what kinds of digital experiences to create, as the web-standards-based approach fades from memory, and frameworks eat the universe, more and more organizations will be advised by framework- and Javascript-oriented developers.

Thirdly, and as a result of the first and second points, more and more web experiences every day are being created that are simply not accessible to people with disabilities (or with the “wrong” phone or browser or device), and this will increase as standards-focused professionals retire or are phased out of the work force, superseded by frameworkistas.

#a11y is Code for “Love Your Neighbor”

This third point is important because people with disabilities are already under attack, by example of the U.S. president-elect, and as part of of a recent rise in hate crimes perpetrated by a small but vocal fringe. This fringe group of haters has always been with us, but now they are out of the shadows. They are organized and motivated, and to an unmeasured degree, they helped Donald Trump win the White House. Now that he’s there, people of good will ardently hope that he will condemn the worst bigots among his supporters, and fulfill his executive duties on behalf of all the people. I’m not saying I expect him to do this today. I’m saying I hope he does—and meantime it behooves us to find ways to do more than just hope. Ways to make change.

Do Not Go Gentle into that iTunes Store

AT HOME, sick with a cold and bored, my daughter buys a single packet of “My School Dance” in a freemium iTunes game. The manufacturer charges her (well, charges me) for ten packets. This same “accidental” 10x overcharge happens across three different games by the same manufacturer in the span of about an hour.

American Express notifies me of the spurious charges, but won’t let me dispute them until they are “posted.” I spend half an hour on the phone with a very nice gentleman at Amex learning this. Why would Amex notify customers about a charge days before they can do anything to resolve it? I don’t know. And I don’t ask the gentleman on the phone. His job is hard enough.

A few days pass. Amex “posts” the false charges and emails me with a link to resolve the problem on Amex’s “dispute a charge” web service.

Amex’s “dispute a charge” web service “encounters an error” when I try to use it to resolve the problem.

This happens every time I try. I try for three days.

So I call Amex, but I can’t resolve the problem because I don’t have the card in my wallet.

So I head to iTunes, where I should have gone in the first place, and click through two or three generations of iTunes “Report a Problem” interfaces: visually different generations of iTunes software, with different user paths, all still being served by Apple. Generations of iTunes software that, when they fail, link to other generations of iTunes software, which also fail.

I click and click my way through five years of iTunes interfaces.

Finally I find an iTunes page where I can manually “Report a problem” for each of the 27 false charges. (Three of the charges, remember, were legitimate. I’m willing to pay for the three items my daughter intended to buy. But not 30.)

If one software product overcharges your kid by a multiple of 10, that could be a software bug. When three products from the same manufacturer all do it, that’s not a bug, it’s a deliberate attempt to defraud families, by overcharging on purpose and hiding behind the opacity of iTunes’s purchase reporting. Simply put, the manufacturer is dishonest, and figures iTunes’s support section is impenetrable enough that you’ll eventually give up trying to get a refund.

But they didn’t count on my tenacity. I’m the Indiana Jones of this motherfucker. I have studied maps and bribed natives and found my way to the hidden iTunes refund page that actually, sometimes, works.

On this page, I inform Apple of the fraud 27 times, in 27 different boxes. Each time, after reporting, I click a blue button, which generally returns an error message that iTunes was unable to process my request. So I enter the data and click the button again. It’s only 27 boxes of shit. I’ve got all the time in the world.

The page tells me that only two refunds went through. Every other request ends with an error message saying iTunes could not process my request, and encouraging me to try again later.

Instead, I leave the page open, and, about ten minutes later, I manually reload it. When I do so, the display updates—I guess this generation of iTunes software preceded “Ajax”—and I learn that most of my refunds have gone through.

So the software actually works about 33% of the time, even though it indicates that it only works 5% of the time. Remember that wait-ten-minutes-then-randomly-reload-to-see-if-anything-changed trick. It’s the sign of excellently designed consumer software.

I’ve put over two hours of my time into this. Going on billable hours, I’ve probably lost money, even if I get all my overcharges refunded. But there’s a principle here. Several principles, actually. Tricking kids is wrong. Stealing is wrong. Building a beautiful front-end but neglecting customer service is wrong. Mainly, I’ve just had enough of 2016’s bullshit.

State of the Web: Evaluating Technology | Jeremy Keith

12 LESSONS from An Event Apart San Francisco – № 6: We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS, and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that?

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 argued that pages built on fragile technologies—technologies which are powerful when they work, but which fail poorly—are a dangerous platform for web content. Frameworks that require JavaScript, for example, offer developers extraordinary power, but at a price: the failure of even a small script can result in no content at all. Service workers technology also offers tremendous power, but it fails well, so is safe to use in the creation of responsive sites and web applications.

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.

It takes a village

Animation works best when the whole team plans for it. If it’s simply a wish—say on the part of the designer—everyone in the chain will be too busy with higher priority tasks, and the animation won’t get made.

Which is a pity, because well-considered animations (such as Val showed) can make interactions much easier to understand. Additionally, if choreographed by the entire team as part of a bigger picture, animations can reinforce your brand. (Done without consideration, and without the support of the entire team, they’re more likely to contradict important brand attributes.)

Better animation requires good communication, comprised of…

Shared vocabulary

Established animation values

Documentation and repeatability

Deliverables – the things that start conversations

The first deliverables for animation are conversation starters: storyboards and sketches that help the team envision where there is potential for animation in their user flow, see how an animation could make the screen easier for users to understand, and begin to plan how to animate between screens. Best of all, anyone can create a sketch or storyboard: artistic talent is not required (these are not Pixar animations but simple conveyors of ideas).

In every storyboard, we should draw or describe a trigger (what starts the action?), an action (what takes place?), and a quality (how does it happen?).

Motion comps and interactive prototypes

Motion comps answer questions about how the animations should look, move, and behave, and allow for quick iteration. When handing them off to the development team, it’s important to include the duration and delay values; details of the easing used; repeat values, and iteration counts.

Interactive prototypes come next. They allow the team to explore what the interaction will be like to use, decide if it feels right in context, and determine how animations interact with input or real data. Val took us through a number of tools that can be used for prototyping, from apps like Atomic to good old HTML, CSS, and JavaScript.

Define and document – save future you time and effort

Interface animations are most effective when they work in concert as part of the bigger picture. Designing and choreographing your web animation efforts from the top down leads to more effective animations that integrate into your design system. And, defining a motion language for your brand can help your team to develop a shared vision from which to work.

Don’t just create animations—define and document them. Define your brand in motion with the same care you take for your logo, style guide, and pattern libraries. Use design principles to inform motion decisions. Study Brand Pillars, Voice & Tone, and Experience Pillars, and build your animation guidelines from there. Animations are best when they’re brand-appropriate and repeatable.

Get input from everyone

Having brought us through the rationale for animations and a variety of potential workflows, Val took us deeply into the details that make for effective animations, and ended with a game plan enabling everyone on the team to become an undercover animation superhero.

Tomorrow I’ll be back with more top takeaways from another AEA San Francisco 2016 speaker. The next AEA event, An Event Apart St. Louis, takes place January 30-February 1, 2017