EW Resource

Newsfeeds

There's a huge resource of Newsfeeds on the Net which brings up-to-date information and content on a wide range of subjects.

Here are just a few relating to web development.



A List Apart: The Full Feed
  • On Our Radar: The Empty Space That Is Not Empty 
    “Being in tech and not caring about tech culture is a luxury, only affordable to those with enough privilege to ignore it and too little empathy to care.”

    In her beautiful, award-nominated “A Talk About Nothing” at the 2015 .concat() web development conference, Lena Reinhard delivers a luminous exposition of how tech’s version of meritocracy is a brilliant system—for the people who get to define what merit is. When we overlook entire groups of people who could be making fantastic contributions to our future, we all end up with less. Don’t miss this talk. It’s full of stars. —Rose Weisburd, columns editor

    Your weekend reading

    1. “Hold on a second. I’m like a two-out-of-ten on this. How strongly do you feel?” In The Sliding Scale of Giving a Fuck, Cap Watkins shares a useful framework for communicating how strongly you feel about a topic you’re debating with colleagues. I appreciate that it’s intuitive enough to use without explanation, and provides a way to engage on opposite sides of a subject without needless drama. —Aaron Parkening, project manager
    2. You may be intimately familiar with a typeface like VAG Rounded from (until recently) Apple keyboards. Or perhaps you’ve chosen a rounded sans like Process Type’s Bryant for a project. But how well do you know the history of these letterforms? FontShop’s Ferdinand Ulrich recently published the second part of his comprehensive survey of rounded type. (Part 1 appeared in March, and Part 3 is on the way.) —Caren Litherland, editor
    3. I’ve been doing some research into virtual reality (VR) and, although this is a few months old, I’ve just stumbled across it and wanted to share it. Mozilla has a team working on virtual reality and the open web. Their video presentation, Virtual Reality & The Web: Next Steps, is a fascinating introduction to how VR works, with demonstrations on how to build experiences for it using HTML and CSS. —Anna Debenham, technical editor
    4. “Progressive enhancement just works.” Aaron Gustafson compares two real case studies—one built to progressively enhance and another built to degrade gracefully—to show how progressive enhancement from the ground up can save considerable amounts of time and money for a project in the long run. —Michelle Kondou, developer
    5. I can’t say that I’m 100 percent sold on my own lifelong vegetarianism, but I like to think that it lends me a small amount of objectivity in hamburger-related matters. As such, I’m on the same side as the BBC when it comes to hamburger menus and their inscrutability for the average user: just because we designers and developers have a taste for them doesn’t mean they should always be on the menu. —Mat Marquis, technical editor

    Overheard in ALA Slack

    “What kind of bears are we talking about here, exactly? The article is light on the details.”

    Your Friday Vine

  • Mark Llobrera · Professional Amateurs: Instant Web 

    Instant Articles are here, and the announcement is all about speed. From a user perspective, I think that Instant Articles are a good thing. But I bristle at the implications for the open web. Implicit in the sales pitch (and explicit in much of the commentary that followed) is the familiar criticism that the traditional HTML/CSS/JS web stack is too slow to deliver a first-class experience. Facebook may have been throwing shade, but others were more overt in their criticism.

    John Gruber put it in stark terms:

    I worry that the inherent slowness of the web and ill-considered trend toward over-produced web design is going to start hurting traffic to DF.

    I don’t believe that the web is inherently slow, although I do acknowledge that over-produced web design could give rise to that assertion. But that’s a fine distinction, because in practice it might as well be true—as Scott Jehl says so very succinctly:

    That the performance of bloated websites is the norm is profoundly disappointing, all the more so because we’re the ones who made it that way. Users of all kinds need the open web, because it serves everyone—including people without a Facebook account and people without access to the latest mobile devices. But even without the Instant Articles bar to measure against, we’ve been shipping slow sites and thus failing those very users. Tim Kadlec gets to the heart of the matter in his post “Choosing Performance,” and it’s simultaneously simple and complex:

    It’s not because of any sort of technical limitations. No, if a website is slow it’s because performance was not prioritized. It’s because when push came to shove, time and resources were spent on other features of a site and not on making sure that site loads quickly.

    This goes back to what many have been stating as of late: performance is a cultural problem.

    I think Tim’s point is dead on. Later in the piece he points out how culture change usually moves more slowly than technical solutions, and that’s specifically true for the folks building the web.

    In my experience, the biggest barrier to a high-performance web is this: the means of production are far removed from the means of delivery. It’s hard to feel the performance impact of your decisions when you’re sitting on a T3 line in front of a 30 inch monitor. And even if you test on real devices (as you should), you’re probably doing it on a fast wifi network, not a spotty 3G connection. For most of us, even the ones I would describe as pro-performance, everything in the contemporary web design production pipeline works against the very focus required to keep the web fast. Unless you make some fundamental choices and set up clear constraints, you can—and will—build and ship beautiful sites without feeling a single ounce of the pain and frustration that your users encounter when all of that beautiful imagery, CSS, and JavaScript comes trickling down their mobile network.

    My family and I are big fans of cooking-competition shows. I love how the judges save their harshest criticism for chefs who let their dishes leave the kitchen without tasting them. “Did you taste this dish before it went out?” they ask, and the chef can do nothing other than hang their head in shame and reply, “No chef, I did not.”

    That’s my biggest takeaway from Instant Articles: we (designers and our clients) have to start tasting our work. Not just in our proverbial kitchen, but where our users actually eat the stuff. How do we do this? Some of it is tactical. Dan Mall has a great primer on setting up a performance budget. Scott Jehl’s Responsible Responsive Design has a lot of good, practical advice on tooling and testing to make things fast, in both absolute and perceived respects.

    But again: we can’t just engineer our way to a faster web, because for every bit of extra speed we wring out, we’ll find a way to fill the gap with even more over-produced design. M.G. Siegler’s analysis of Instant Articles comes to this conclusion:

    Not only is the web not fast enough for apps, it’s not fast enough for text either.

    It’s a funny line, but it also rings a bit false to me. Because it isn’t just text, is it? Our sites feature more and more images, webfonts, CSS, and JavaScript layered over the basic text and markup. Siegler’s line raises a particularly difficult question, though: why? Of late it seems that many of those elements layered on top of the content are an attempt to emulate the slickness and behavior of native apps. And to an extent that can be a good thing—the web has always been great at absorbing and expressing characteristics of other mediums: books, magazines, movies, video games, apps—anything and everything, really. But that impulse needs a counterbalance: we can do this on the web, but should we, if it means users won’t even stick around to see the content?

    I don’t want this to be tantrum trigger, where we throw up our collective hands and yell, “We can’t do anything cool on the web! Fine! Just make it all text! ARE YOU HAPPY NOW?” I think we do have to be better at weighing the cost of what we design, and be honest with ourselves, our clients, and our users about what’s driving those decisions. This might be the toughest part to figure out, because it requires us to question our design decisions at every point. Is this something our users will actually appreciate? Is it appropriate? Or is it there to wow someone (ourselves, our client, our peers, awards juries) and show them how talented and brilliant we are?

    Lara Hogan’s Designing for Performance might be the most useful resource in this regard, because it talks about how to educate and incentivize our teams toward a performance-focused culture. If you, your team, and your client build that culture with your user in mind, then the sites you build can be beautiful and immersive without negating the accessibility and reach that makes the open web so vital.

    What’s exciting about this user- and performance-focused mindset is that it will still be valid and useful even if we see some much-needed advances in browser-based capabilities. I hold out hope that components like HTTP/2 and service workers will allow us to build smarter, more performant sites. But we have the means to build sites faster right this minute. If nothing else, Facebook just turned that into a higher priority for the entire web community. And that’s a good thing.

  • 15 Years Ago in ALA: Much Ado About 5K 

    15 years ago this month, a plucky ALA staffer wrote “Much Ado About 5K,” an article on a contest created by Stewart Butterfield that challenged web designers and developers to build a complete website using less than five kilobytes of images and code. Hundreds did, and their work far exceeded what any web professional could have reasonably expected:

    Halfway through the judging, we hated this contest. Not because the work was bad. But because so much of it was so very, very good. Arguably, more great work was submitted to this contest than to many of this year’s big-time awards shows. It was nearly impossible to pick a clear winner from among so many instances of sheer creative excellence.

    And we couldn’t help feeling unworthy, as one artist after another did more with their 5K than we typically pull off with 50.

    Having learned once again the importance of constraint and the empowering creative influence it can have on design, our community high-fived itself…and promptly forgot everything it had learned as we started building heavier and heavier sites.

    Soon, driven by fear that apps would make the web irrelevant, we began relying on frameworks that made even the simplest website act and feel like a mind-blowing application. Serving reams of code we didn’t need because, hell, it came with the frameworks, and abandoning principles like progressive enhancement because, hell, everybody uses JavaScript, we soon fell in love with high-resolution, full-screen background images, then fell even harder when those images quadrupled in weight thanks to Retina.

    And still the little article memorializing the little 5K contest sat online, its lessons forgotten in an arms race wherein the average home page now weighs over 2MB. Put that in your Edge network and smoke it.

    Ah, but what goes around (performance) comes around (performance). Beginning in 2013, conversations about responsive web design “shifted from issues of layout to performance” as leading web designers and data sifters came to realize that, even on speed and bandwidth-limited networks, users expected sites to render as fast on phones as they do on the desktop—if not faster. That if your site didn’t render as quickly as users expect, they would abandon it, perhaps forever. That a traditional, desktop-first approach to responsive web design guaranteed user disappointment and site abandonment; that, performance-and-bandwidth-wise, at least, a “mobile first” approach made far more sense—and not just for mobile users. That you could no longer give high design marks to a site (however innovative, however visually arresting) if it took forever to load over constrained mobile networks. Because performance was part of design, and always had been.

    As one group of web makers embraces performance budgets and the eternal principles of progressive enhancement, while another (the majority) worships at the altar of bigger, fatter, slower, the 5K contest reminds us that a byte saved is a follower earned.

    For more on performance:

  • Meta-Moments: Thoughtfulness by Design 

    Ever had a moment on the internet when you’ve been forced to stop and think about what you’re doing? Maybe you’ve been surprised. Maybe you’ve stumbled across something new. Maybe you’ve come to see things in a different light. I call such experiences meta-moments: tiny moments of reflection that prompt us to think consciously about what we’re experiencing.

    Take Google. In the early days, its clean white page helped distinguish it from the pack. While its competitors tripped all over themselves telling you how great they were and how much they had to offer, Google’s quieter strategy seemed bold and distinctive. “Our search experience speaks for itself,” it suggested. No need for spin or a hard sell. Over the years, as Google has continued to develop its search technologies, it has managed to retain that deceptive surface simplicity. I love that its minimal homepage has stayed intact (in spite of incessant doodling). Encouraging a thoughtful moment remains central to Google’s design.

    Yet the prevailing wisdom within user experience design (UXD) seems to focus on removing the need for thought. We are so eager for our users to succeed that we try to make everything slick and seamless—to remove even a hint of the possibility of failure. Every new service learns about our movements in order to anticipate our next move. Each new product exists in an ecosystem of services so that even significant actions, such as making a purchase, are made to seem frictionless. The aim is not only to save us time and effort, but to save us from thinking, too.

    Steve Krug’s seminal book Don’t Make Me Think! may have helped to shape this approach. This bible of usability is an undisputed cornerstone of UXD. But it can be taken too far. In fact, Krug himself has unofficially rechristened the book Don’t Make Me Think Needlessly! In doing so, he acknowledges that there are times when thoughtful interactions online are worth encouraging. While we shouldn’t need to think about where to find the search tool on a site (top right, please!), we should, of course, be encouraged to think before we purchase something—or, for that matter, before we make any significant commitment.

    It’s a question of courtesy, too. When asking for deeper attention, we should feel confident that we’re not wasting people’s time. What we offer should more than repay them for their efforts—though there aren’t many moments when we can guarantee this.

    I’m currently working on a project—an online version of a medical self-screening form—that has a valid reason for making users think. Success will involve making sure that users really understand the meaning of each question, and that they take the form seriously—that they take the time to answer honestly and accurately. My teammates and I find ourselves designing a slow experience rather than a fast one.

    But what slows people down and makes them more thoughtful? And what is it about a particular design that makes people really invest their attention?

    Laying the groundwork for thoughtfulness

    In my experience, there seem to be three main strategies for encouraging meta-moments.

    Roadblocks

    Inbox by Gmail makes you think by confronting you with a barrier. You can’t just try the service. You have to be invited. You can request an invitation (by following the instructions on their site), or a friend can invite you—but you can’t get started right away. Anticipation and excitement about the service has space to gather and develop. And it does. In its first few weeks, invites were going on eBay for $200.

    This strategy certainly worked on me. Within moments of landing on the page, I went from being slightly intrigued to a state of I-must-have-it. Following the instructions, I found myself composing an email to inbox@google.com requesting an invitation. “Please invite me. Many thanks, Andrew,” I wrote, knowing full well that no one but me was ever going to read those words. Why hadn’t they simply let me submit my email address somewhere? Why were they deliberately making things hard for me?

    Something clever is going on here. Adding a barrier forces us to engage in a deeper, more attentive way: we are encouraged to think. Granted, not everyone will want or need this encouragement, but if a barrier can create a digital experience that is noticed and remembered, then it’s worth talking about.

    Putting up a “roadblock,” though, seems like a risky way to encourage a meta-moment. Stopping people in their tracks may make them simply turn around or try another road. For the roadblock to be effective (and not just annoying), there has to be enough interest to want to continue in spite of the obstacle. When I encounter a paywall, for example, I need to be clear on the benefits of parting with my money—and the decision to pay or subscribe shouldn’t be a no-brainer, especially if you’re hoping for my long-term commitment. iTunes’s micropayments, Amazon’s “Buy now with 1-Click,” and eBay’s impulse bidding all represent a trend toward disengaging with our purchases. And in my own purchasing patterns, things bought this way tend not to mean as much.

    Smartphone apps have a similar impact on me. Most of the time, it seems that their only aim is to provide me with enough fleeting interest to make me part with a tiny upfront cost. As a result, I tend to download apps and throw them away soon afterward. Is it wrong to hope for a less disposable experience?

    In-app purchases employ a kind of roadblock strategy. You’re usually allowed to explore the app for free within certain limitations. Your interest grows, or it doesn’t. You decide to pay, or you don’t. The point is that space is provided for you to really consider the value of paying. So you give it some proper thought, and the app has to do far more to demonstrate that it deserves your money. FiftyThree’s Paper, my favorite iPad app, lets you have a blast for free and includes some lovely in-app promotional videos to show you exactly why you should pay.

    Roadblocks come in many shapes and sizes, but they always enforce a conscious consideration of how best to proceed. Navigating around them gives us something to accomplish, and a story to tell. This is great for longer-term engagement—and it’s why digital craftspeople need to shift their thinking away from removing barriers and instead toward designing them.

    Speed bumps

    Speed bumps are less dramatic than roadblocks, but they still encourage thought. They aim to slow you down just enough so that you can pay attention to the bits you need to pay attention to. Let’s say you’re about to make an important decision—maybe of a legal, medical, financial, or personal nature. You shouldn’t proceed too quickly and risk misunderstanding what you’re getting yourself into.

    A change in layout, content, or style is often all that is required to make users slow down. You can’t be too subtle about this, though. People have grown used to filtering out huge amounts of noise on the internet; they can become blind to anything they view as a possible distraction.

    Online, speed bumps can help prepare us mentally before we start something. You might be about to renew your vehicle tax, for instance, and you see a message that says: “Hold up! Make sure you have your 16-digit reference number…” You know that this is useful information, that it’ll save you time to prepare properly, but you might find yourself getting a little frustrated by the need to slow down.

    Although most of us find speed bumps irritating, we grudgingly accept that they are there to help us avoid the possibility of more painful consequences. For example, when you fire up an application for the first time, you may see some onboarding tooltips flash up. Part of you hates this—you just want to get going, to play—and yet the product seems to choose this moment to have a little conversation with you so that it can point out one or two essentials. It feels a little unnatural, like your flow has been broken. You’ve been given a meta-moment before being let loose.

    Of course, onboarding experiences can be designed in delightful ways that minimize the annoyance of the interruption of our desired flow. Ultimately, if they save us time in the long run, they prove their worth. We are grateful, as long as we don’t feel nagged.

    In spite of the importance of speed bumps online, we tend not to come across them very often. We are urged to carry on at speed, even when we should be paying attention. When we’re presented with Terms and Conditions to agree to, we almost never get a speed bump. It’d be wonderful to have an opportunity to digest a clear and simple summary of what we’re signing up for. Instead, we’re faced with reams of legalese, set in unreadable type. Our reaction, understandably, is to close our eyes and accelerate.

    Diversions

    Online diversions deliberately move us away from conventional paths. Like speed bumps, they make us slow down and take notice. We drive more thoughtfully on unfamiliar roads; sometimes we even welcome the opportunity to understand the space between A and B in a new way. This time, we are quietly prodded into a meta-moment by being shown a new way forward.

    A diversion doesn’t have to be pronounced to make you think. The hugely successful UK drinks company Innocent uses microcopy to make an impact. You find yourself reading every single bit of their packaging because there are jokes hidden everywhere. You usually expect ingredients or serving instructions to be boring and functional. But Innocent uses these little spaces as a stage for quirky, silly fun. You end up considering the team behind the product, as well as the product itself, in a new light.

    Companies like Apple aim for more than a temporary diversion. They create entirely new experience motorways. With Apple Watch, we’re seeing the introduction of a whole new lexicon. New concepts such as “Digital Touch,” “Heartbeat,” “Sketch,” “Digital Crown,” “Force Touch,” “Short Look,” and “Glances” are deployed to shape our understanding of exactly what this new thing will do. Over the course of the next few years, you can expect at least some of these terms to pass into everyday language. By that time, they will no longer feel like diversions. For now, though, such words have the power to make us pause, anticipate, and imagine what life will be like with these new powers.

    The magic of meta-moments

    Meta-moments can provide us with space to interpret, understand, and add meaning to our experiences. A little friction in our flow is all we need. A roadblock must be overcome. A speed bump must be negotiated. A diversion must be navigated. Each of these cases involves our attention in a thoughtful way. Our level of engagement deepens. We have an experience we can remember.

    A user journey without friction is a bit like a story without intrigue—boring! In fact, a recent study into the first hour of computer game experiences concludes that intrigue might be more important than enjoyment for fostering engagement. We need something a little challenging or complex; we need to be the one who gains mastery and control. We want to triumph in the end.

    Our design practices don’t encourage this, though. We distract our users more than we intrigue them. We provide the constant possibility of better options elsewhere, so that users never have to think: “Okay, what next?” Our attention is always directed outward, not inward. And it—not the technology itself, but how we design our interactions with it—makes us dumb.

    UXD strives toward frictionless flow: removing impediments to immediate action and looking to increase conversions at all costs. This approach delivers some great results, but it doesn’t always consider the wider story of how we can design and build things that sustain a lasting relationship. With all the focus on usability and conversions, we can forget to ask ourselves whether our online experiences are also enriching and fulfilling.

    Designing just one or two meta-moments in our digital experiences could help fix this. Each would be a little place for our users to stop or slow down, giving them space to think for themselves. There’s no point pretending that this will be easy. After many years dedicated to encouraging flow, it will feel strange to set out to disrupt users. We’d be playing with user expectations instead of aiming to meet and exceed them. We’d be finding little ways to surprise people, rather than trying to make them feel at ease at all times. We might tell them they need to come back later, rather than bend over backwards to satisfy them right away. We might delegate more responsibility to them rather than try to do everything for them. We might deliberately design failures rather than seek to eradicate them.

    How will we test that we’ve achieved the desired effect and not just exasperated our users? Usability testing probably won’t cut it, because it’ll be tricky to get beyond the immediate responses to each set task. We might need longer-term methods, like diary studies, in order to capture how our meta-moments are working. Our UXD methods may need to shift: from looking at atoms of experience (pages, interactions, or tasks), to looking at systems of experience (learning, becoming, or adopting).

    It will be a challenge to get people behind the idea of adding meta-moments, and a challenge to test them. The next time we create a design solution, let’s add just one small barrier, bump, or quirk. Let’s consider that the best approach may be a slow one. And let’s remember that removing needless thought should never end up removing all need for thought. Putting thought into things is only part of a designer’s responsibility; we also have to create space for users to put their own thought in. Their personalities and imaginations need that space to live and breathe. We need to encourage meta-moments carefully and then defend them. Because they are where magic happens.

  • Approaching Content Strategy for Personalized Websites 

    There’s a curious concept in astrophysics known as the Drake Equation. Developed to quantify the potential for intelligent life in our galaxy, it raises a number of odd questions, among them: does having intelligence, in the long run, actually benefit or harm a species? In other words, will amoebas ultimately outlive humans in the face of eternity?

    If you’re like me, these are the types of things you think about while listening to hold music before conference calls. But as a content strategist, I can’t help but ask the same question about something my clients suddenly seem to be clamoring for: personalized user content.

    It sounds great in theory: content that is more targeted to the user can provide a richer, more precise experience. But there is also a dark side: used improperly, targeting risks invading privacy and eroding trust. As Drake supposes, true intelligent life is rare, in part because it has the potential to destroy itself.

    So how might you dip into this intelligence without wrecking your content in the process? How can we approach personalized content in a way that is sustainable and respectful, not self-destructive?

    Personalization basics

    For good or for evil

    At a basic level, personalization (aka targeting) means serving unique content to a user based on something we know about him or her—from geographic location to specific browsing history. And as you’ve likely observed, the value of personalization is largely in how you wield it. It’s helpful to us when Amazon makes recommendations based on our past viewing history. Conversely, we’ve all been bothered at some point by a creepy targeted ad—the one that either somehow knows too much about you, or is trying to sell something you don’t want.

    Historically, the average UX person hasn’t played much of a role in either of these scenarios, the latter being controlled by online marketers, the former monopolized by the Amazons of the world. But the recent advent of so-called “experience management systems”—like Adobe Experience Manager, Sitecore Experience Platform, and Episerver Personalization Manager—has (somewhat precipitously) made the ability to personalize content more accessible to clients. You don’t have to look much further than the goodie bag from the last conference you attended to see that all of the big name CMSes are now aggressively marketing their own flavor of personalization software.

    Do you even need it?

    So what do you do when your client says they want to personalize content? The good news is that the foundation of personalized content strategy is the same set of tools you know and love: a core strategy statement, a set of guiding principles, and a basic content model. You now must consider how (or if) targeting can advance these directives. For example:

    Good reasons to target site content:

    1. Your audience can be segmented in ways that are meaningful.
    2. Narrowing your message provides incremental value to your users.
    3. Personalized content is tied to specific KPIs or business objectives.

    Bad reasons to target site content:

    1. Because we can.
    2. Some variation of #1.

    You may face some strong headwinds if your client just bought a shiny new EMS and can’t wait to start solving world hunger. Again, as is always the case with the technology du jour, the product demos for these things are very seductive and typically involve light shows and kittens and free ecstasy. You may have to be the voice of reason. But that’s why you went to content strategy school, right?

    Partial steam ahead!

    Next, consider your targeting technology. As a general rule, the systems that support targeted content will be one of two things:

    1. Rules-based: The more manual approach, this involves setting up discrete audience segments in the system and writing rules for when and how to show them content. Example: It looks like Colin’s IP address is from Washington, DC, so let’s show him what we show everyone in that location.
    2. Algorithm-based: The “secret sauce” approach, this focuses less on the overall segment and more on a specific user’s behavior. Example: Colin clicks on 3.65 articles/day about soup, so let’s show him a campaign for soup.

    For our purposes, we’ll take a closer look at a rules-based model, since this is more likely what you’ll be running into if your client is just starting out with personalization. You’ll first need to determine your “segments.” Similar to UX personas, segments are groups of users with some distinguishing set of traits like age, interest, or location. The difference here is that a targeted segment will be determined by real-time data, either internal or external to your site. Typically this data will be fed through some type of centralized rules engine accessed by your CMS.

    Applying a personalized content framework

    This is all getting a bit abstract, so let’s imagine for a moment that we’re creating a new site for An Airline Apart (obviously the next logical brand extension). We want to target busy creative professionals who travel regularly for work. What online content should we create to give us an edge with this audience?

    Our first bright idea is to start a content campaign that takes the stress out of business travel. Easy enough, right? But that actually makes a lot of assumptions—what does “stressful” even mean? Can we break it down by audience?

    Defining segments

    A recent study from Carlson Wagonlit Travel asked 7,400 global business people who travel regularly for work to rank how stressful business travel is to them at each stage of their trip. Here’s what they found, sorted by gender:

    Source: Harvard Business Review. Data from HEC, Carlson Wagonlit.

    There are clear differences: women tend to find the pre-trip phase the most stressful, while for men this is the least stressful phase. And for some reason, at the post-trip phase, it’s the complete opposite.

    It gets even more interesting. Here’s what happened when they sorted the data by role:

    Source: Harvard Business Review. Data from HEC, Carlson Wagonlit.

    According to this, business travel stress changes wildly depending on company role. For example, high-level employees are least stressed before the trip, and more stressed after; for support staff, it’s the total opposite.

    Now, if we were doing this properly, we would absolutely want to drive into the “why” behind this. But for the sake of our sample exercise, we have more than enough justification to pursue a segmented content approach to our campaign. We could potentially set up 12 segments across gender and role in our system; here, though, let’s limit our focus to senior execs, male and female.

    Mapping segments to content

    From a technical point of view, personalizing content comes down to running targeted rules on individual components on a page. So let’s say we have our An Airline Apart homepage with typical content zones. If we didn’t know who you were, we would show our usual default content:

    Art Credit: Kristina Bourlotos

    Now in theory, we could write rules to target content for all of these blocks for our users. But how do we know where to begin? This is the “substance” question in content strategy, and where we need to consider very specifically what value we are adding.

    To help us think through this, our team at ICF Interactive developed a framework for the four core types of personalized content. The first two have to do with the “task at hand,” or what the user came to your site to do today. The second two have to do with the “big picture,” or what you’re trying to get people to see and feel as part of your larger brand experience. Here’s how it breaks down:

    Source: ICF Interactive

    1. Content that alerts. This type of targeting improves the customer experience by displaying relevant, time-sensitive information, such as a weather delay, service disruption, or other real-time issue.
    2. Content that makes tasks easier. The second “task at hand” category, this type makes users’ lives easier by helping them do what they came here to do—e.g., “smart” navigation, deep links to useful tools, or automatically deprioritizing unrelated content.
    3. Content that cross-sells. This type may make your inner designer squirm, but it will realistically be one of your most important use-cases (and likely the one most directly tied to project ROI). Whether you’re a global oil conglomerate or a non-profit that provides hugs to reindeer, this is your place to market whatever it is you need to market. Again, the trick here is to show users something relevant, not just what you want them to see. Examples: ad for a new product, announcement for your upcoming conference, call to join or donate, etc.
    4. Content that enriches. A close cousin to the cross-sell, content that enriches a user’s experience is supplemental to their overall brand perception. This might include blogs, articles, community features, social networks, or third-party content. Think of this as the “soft sell” versus the “hard sell.” On a standard task-oriented page, this content will typically occupy the least critical zone.

    Going back to our example, here’s how we could apply this approach to the personalized content we want to show on the An Airline Apart homepage:

    Type of personalized content What to show senior execs
    Alert A list of flight cancellations impacting this user in real time
    Make easier Some shortcuts to content for our Priority Flyers service
    Cross-sell An ad for our new business class upgrade
    Enrich Tips on pre-trip (female segment)
    Tips on post-trip (male segment)

    Remember our bland default page? With our rules up and running, a senior exec will instead see this (color-coded by type):

    Art Credit: Kristina Bourlotos

    Notice we’re now showing content specific to our executives, with the added nuance that the bottom right zone (“enrich content”) differs for our female versus male audience, based on that research nugget around stressful travel.

    Bear in mind that these two are looking at the same site at the same time from two different locations—the CMS is targeting the content based on what we know about them, so they effectively get a different experience (and if everything is set up correctly, a better one).

    Content on crack

    You’re starting to see the implications, right? If we were to follow this through, instead of writing one content strategy, we now effectively need to write 12—one for each audience segment we had identified. As a content strategist, you’ve probably swallowed your content gum. The technology is there to help you accelerate that process to some extent, but this is precisely why taking a disciplined approach to personalized content is critical. Otherwise, you will be quickly overwhelmed, not only in terms of creation and execution, but also maintenance and support.

    Taking the first step

    What’s that you say? You’re not intimidated? Great! Just a few things to keep in mind.

    Have the right resources

    Remember that putting personalized content in the field requires not only a sound strategy, but also the resources to support it. You may still need some work if:

    • You don’t have enough content to make targeting useful
    • You don’t have enough staff to maintain targeted content
    • Your content is not semantically rich—you need a taxonomy, metadata, etc.
    • You don’t have a CMS that supports it
    • You don’t have analytics and tracking in place to gain insights and adjust

    Be respectful

    There’s a whole other conversation to be had around the ethics of targeting, but suffice it to say there is a line between providing helpful personalization and invading privacy. If you find yourself trying to force content on people with your newfound power, stop. Think of Ida Aalen’s core model. Is your content truly at the intersection of user and business goals, or just business goals? Approaching targeted content strategy with respect for your users will ensure that your site lands on the right side of web personalization history.

    To infinity

    Sound like a lot? Consider that it doesn’t have to be that complex. In fact, can you guess the number one method of personalized content in use today? That’s right, email. So chances are you’re probably already doing targeting on some level, and have an organizational starting point from which to build. With the right strategy and technology, you’re really only limited by your imagination, and your ability to adapt to mistakes along the way.

    And who knows? You may discover that the web can, in fact, support intelligent life.

  • Rachel Andrew on the Business of Web Dev: On Being King of a Shrinking Castle 
    If I am not for myself, who is for me?
    And if I am only for myself, what am I? And if not now, when?
    Ethics of the Fathers, 1:14

    Those of us who have been self-employed for a number of years sometimes joke that we are now unemployable. We’re used to being king of our own castle. We make our own rules. After having that autonomy, returning to a workplace and the need to comply with company process would be hard.

    Not everyone gets on with self-employment. It requires discipline, consistency, and the ability to self-manage. You have to do this for yourself; it all stops with you. As someone who has always sweated the small stuff, it suits me. I’m a planner, an organizer, I work hard and get stuff done. I like being king of my own castle, because I can get more stuff done without anyone else knocking my carefully laid plans off course. Much of this is baked into who I am, but I’ve taken a step back recently and realized that often I cross from staying organized and being reliable into making unreasonable demands—mostly of myself, but sometimes of other people. Anyone close to me has at one time or another had the misfortune of getting in the way of a Rachel-shaped steamroller fixated on Getting Stuff Done.

    I have found myself becoming so accustomed to being in charge that I start to micromanage every aspect of my life. I’ve heard the same sentiment voiced by other self-employed friends. In a workplace, even the most introverted of us is forced to work with and around the needs of others. Working alone, we can often avoid that, and that inflexibility then creeps into the way we see the rest of our lives.

    While being organized and reliable as a business owner is important, there has to be balance. The more we obsess about our plans playing out as we had imagined, the less we leave ourselves open to new things and to new people. When I travel (which is often), I plan my time as usual and don’t make any concessions to the struggle to find wifi and work in hotel rooms. To keep to my plan, I need to get back to my hotel after the conference day ends to make sure I can tick items off my to do list, get the planned things done. When a friend asks me to dinner, I can feel the panic of uncompleted tasks looming. I often decline, or I go but then spend the whole evening worrying about what will not get done.

    By sticking to the plan I might have a clear to do list, but I lose the chance to spend time with my friends and peers making new connections and strengthening old ones. I’m king of a castle whose walls protect my plans and my world, but that world is shrinking.

    There will always be times when, as a business owner, you will have to work incredibly and unreasonably hard in the short term. Being reliable is important, getting things done matters. However, the aim of self-employment for most of us was to free ourselves from the demands of a 9 to 5. We squander that freedom when we start to surround ourselves with rules and demands upon our own time. Worse, we squander the chances we have to make real and lasting connections with those around us.

    I heard the quote at the top of this column from Yitzchok Willroth—the keynote speaker at a conference I am also speaking at. The quote speaks of the balance I want to regain. There are times when I and my business need me to look out for myself, to put my things first. However, the happiness that lies in being there for others matters too much to put off until later. This year, when I have turned forty, is as good a time as any to ask: if not now, when?

  • Practicing Empathy With Teams 

    Empathy, as it’s been talked about recently, is most often framed as something important to practice for our users. It’s important to make sure we’re helping our users get the content they desire or get through the flow of our site to do what’s important to them.

    What is getting lost, though, is that empathy is just as important for us to practice as we interact with our team members—all of us, developers, designers, writers, and project managers, can practice empathy as we work with our teammates. Empathy is just as much about our interactions with each other while we build our sites, as it is about how we treat our users.

    As I’ve thought more about this, I’ve come up with a few ways to practice empathy with my teammates.

    Remember shared goals

    Designers want to build something just as great as I do, but they’re coming at it from a different angle. Spacing, margins, type-size tweaks—they all matter just as much as my clean markup and modular CSS. It’s easy to get annoyed at requests that don’t seem important, but instead, I actively remind myself that every part of a site is important.

    Learn something new

    To help me understand the perspective of designers, I’ve tried to learn more about design. Learning a bit about what the other folks on your team do and how they may come at the project can be eye opening. The time I’ve spent reading about design, content, JavaScript, and even learning a bit of Python, has helped me a lot. Recently, for example, I read Jason Santa Maria’s book, On Web Typography. I still have a lot more to learn about typography, but gaining a better understanding has helped me see how small changes in type can make a big difference. Even as we specialize in one particular field, it’s helpful to read up on other fields we work with. Instead of being annoyed at changes we’re asked to make, we can better understand the feedback. We’re all trying make things really sing as the final polish is put on.

    Listen to each other

    When I work with a new team, I start out by listening and observing the system they use to write code. Unless I’ve been brought in specifically to look at a process and make it better, I prefer to just watch, listen, and ask questions so that I can see where they’re coming from, learn the history, and understand why they do things the way they do.

    With my current team, I waited a bit and then started asking questions about tools and processes. To my mind, one of the tools they use seemed outdated and a bit painful. But after observing a bit, and then asking about it, I found out their reasons for using it and they’ve changed my mind: I now see it’s the best fit for the team. Those first few weeks working with a new team can be stressful for everyone, but listening and observing for a while can cut down on the stress and friction.

    Ask questions

    When trying to be more empathetic with team members, I try to ask myself:

    • What is the other person’s point of view? Since we all come from different specialities, we have different things we think are important. The old cliché of walking in another’s shoes is applicable here.
    • How do my skills fit in with the group and what can I do to make it easier for everyone to understand my point of view? Can I document a process or explain my ideas in a less technical manner for those members that don’t have my expertise?
    • What’s the final goal of the project and how does each person contribute to that goal? If I understand that, then I can also understand how I fit into it and how my colleagues do as well.

    We each have our own role on a team, so the questions you think about as you work with your team may be different, but being aware of these things is half the battle to reminding yourself that everyone doesn’t think the way that you do and that’s probably a good thing. Hopefully, it means you end up with a better completed project in the end.

    These are just a few of the ways I’ve come up with lately to practice empathy with my team. It’s just as important as making sure we are empathetic to our users, and it makes working together easier and more fun. I’d love to hear more ideas on how you think about empathy within your teams too, so please share them in the comments.

  • On Our Radar: What Engineers Look Like 

    Yesterday I stumbled across the wogrammer project by Erin Summers and Zainab Ghadiyali, which will hopefully seed the media—and our collective perception—with real images and stories of women in tech.

    Check out their Instagram feed for more stellar photos. And for more odds and ends the ALA staff dug up on the internet this week, read on. —Lisa Maria Martin, issues editor

    Your weekend reading

    1. In The Pastry Box this week, Eric Meyer reminds us: “In every heart, a secret calendar.” As more and more of our lives are recorded on the web, we have to build better, more human, tools that help us remember (and forget) our secret calendars on our own terms. —Marie Connelly, blog editor
    2. Luke Wroblewski adds another layer to the “fold or no fold” debate. What make this worth checking out is that he’s looking at the issue of the fold from a position of metrics and data, which provides a bit more context to the debate. —Erin Lynch, production manager
    3. Last week Mozilla announced that it is “setting a date after which all new features [in Firefox] will be available only to secure websites”—that is, those that use https instead of http. Mozilla’s heart is in the right place: it wants to minimize security threats to users and the web. But we wonder what impact this will have on sites that can’t, won’t, or don’t know to convert to https—especially if other browsers follow suit. A low barrier is what keeps the open web open. —Jeffrey Zeldman, founder and publisher
    4. Reverse OCR is Darius Kazemi’s ace record of what happens when a young bot tries to write words; “stunted chicken scratch” is pretty generous. Or, try your own hand at static bots—built in Google Sheets with no programming. Allison Parrish gives the rundown. Let’s make some toys. —Tina Lee, contributing editor
    5. “But no one really needs an Apple Watch!” Or do they? Deafblind advocate Molly Watts’s detailed account of her first five days with an Apple Watch will challenge your assumptions about why, how, and when people use all kinds of devices. —Sara Wachter-Boettcher, editor-in-chief

    Overheard in ALA Slack

    “It is all about ‘me’ for that generation. Unlike those other generations. Where individuals were primarily concerned with people named ‘Steve.’”

    Your Friday gif

    A gif of Bruce Campbell from the film Bubba Ho Tep.
    Look, man, do I look like an ichthyologist to you?
  • Nishant Kothary on the Human Web: SHOUTERS, Inc. 

    “I’m going to talk about privilege,” I replied when my wife asked what I’d be publishing for my next column.

    And then I stared at the screen for an hour. Thankfully, my Facebook timeline saved me with Dogs Who Fail At Being Dogs.

    This process repeated for a few days.

    What’s odd about this particular flavor of writer’s block I’ve suffered for years now is that I have no shortage of opinions when it comes to social issues. Ellen Pao. Freddie Gray. Dinesh D’Souza. TSA. Geist. Gun Control. Immigration. India’s daughters. Don’t even get me started.

    But ask me to write a few hundred words—something, anything—about one of these social issues, all of which directly or indirectly affect our industry, and me specifically or by association, and I feel paralyzed.

    I’m a brown, Indian citizen who moved to the United States at the age of 20. Even as of this writing, I’ve lived more years in India than I have anywhere else in the world, including the United States. What’s more, I have relevant experience. For instance, I completely Americanized my spoken accent over a summer during my time in Indiana because I felt it would earn me more privilege. It did, and continues to. (As a side note, the show “Fresh Off the Boat” just aired an episode that pretty much sums up my experience.)

    Coming back to the point, you would think that it’d be somewhat easier for me—what with having some ability to piece a sentence or two together, having my own little corner on the internet to publish—within reason—whatever suits me, and having a relevant background—to type a few thoughts on the topic from my own inevitably unique perspective.

    But evidently it’s not. Because even if my perspective is inwardly impassioned, outwardly it is positively devoid of ALL CAPITAL LETTERS.

    For instance, on the topic of the murder of Mike Brown in Ferguson a few months ago: I am interested in talking about a lot of things. What doesn’t interest me as much is SHOUTING about whether it was motivated (at least partially) by systemic racism in the Ferguson Police Department. To me, it feels like debating the existence of gravity when you consider all the incriminating evidence, neatly topped off by the Department of Justice report on the Ferguson Police Department (a report about the government published by the government). If you’re not in the mood to read the entire report, read the section “Racial Bias” (pages 4-5). It starts off with, “Ferguson’s law enforcement practices overwhelmingly impact African Americans,” and only gets more depressing from there.

    The problem is that you can’t really write or talk about Ferguson and other social issues without clearly shouting your outrage, either in support of the conclusion that racially motivated crimes by people in positions of power are still a thing, or in support of the idea that that’s just fiction fabricated by liberal white guilt. If you don’t believe me, go to any comment thread on the internet that has to do with Ferguson, and you’ll see an angry Red Sea parted neatly in the center as if by Moses himself. Let’s not even talk about the very articles that deal with the topic.

    This is not to say that shouting with outrage doesn’t have its place. On the contrary, it plays a significant role in not only book-ending every revolution, but also punctuating it. It is the pulse of our collective existence, and quite literally so, if you are to believe Martin Luther King Jr. when he said, “Our lives begin to end the day we become silent about things that matter.”

    But a sentence is more than the words it starts and ends with. Or the punctuation it comprises. Beyond a degree, there are diminishing returns to being a chest-thumping member of SHOUTERS, Inc. If what you’re interested in is the words that give the sentence its very meaning, then you have to not only be heard without typing in all caps, but also be resilient to abuse. Depending on what you’re saying, and who you are, the personal costs are anything from being, well, shouted at, to having your life threatened.

    A few days ago I was re-reading Sara Wachter-Boettcher’s editorial note from almost exactly a year ago when #yesallwomen was trending. Toward the end, she wrote, “We’ll be spending more time talking about sexism, racism, and other forms of discrimination, even if it makes some readers uncomfortable.” Yet, even with its hundreds of contributors, columnists, and bloggers, ALA has very little to show for this aspiration in a year (interestingly, what it does have to show was contributed almost entirely by women).

    I make this point not to criticize ALA—if anything, as a columnist, I’d be really just pointing a finger at myself because ALA is, ultimately, a platform—but to highlight just how difficult it is to talk about difficult things even when you explicitly and publicly set the goal of doing so. What’s worse is that barely anyone in tech journalism has even set this goal, but that’s a rant for another day.

    All that said, I believe in my heart of hearts that most of us not only want to talk about these issues, but we want to do so with the other side. We who’ve felt discriminated against because of our skin color want to hear from our white friends about what they think. We who’ve felt the effects of misogyny want to hear from men about what they think. We who have suffered any injustice because of the Stanford Prison Experiment that is life want to hear from our alleged—as SHOUTERS, Inc. has often led us to incorrectly conclude—foe. Maybe that’s a tall order right now, but I do have the recurring dream.

    For now, it feels like the first step to overcoming this paralysis is to acknowledge our fear. As Taylor Swift said, “I think that being fearless is having a lot of fears, but you jump anyway.” Or, more appropriately, as she sang, “Haters gonna hate, hate, hate, baby, I’m just gonna shake, shake, shake, shake it off.”

    And since I’ve got the cursor, I’ll go first: SHOUTERS, INC. SCARES ME SHITLESS!

    Maybe now I’ll be able to write about privilege.

    Baby steps.

  • Building Nonlinear Narratives for the Web 

    The Tiv people of Nigeria tell a story about the early world, when things were different. It’s about Aondo, the Sky, and how he lost his relationship with humans. When the earth was still new, Aondo was close enough that people could stretch out their hands and touch him. For many years, he and the humans led a quiet existence, and everyone went about their business.

    One day, though, everything changed. Aondo sat in his place above the earth, watching people come and go. And then: out walked the most beautiful woman he had ever seen. Aondo was fascinated by her, so he crept closer—too close—to watch her cook. As she was cooking, all of a sudden, she accidentally struck him in the nose.

    Aondo was hurt and embarrassed, so he retreated. Farther and farther, until he was far above the earth. That is why, the Tiv people say, you cannot touch the sky.

    Screenshot of Senongo Akpem’s Pixel Fable site, which is a collection of interactive African children’s stories.
    Pixel Fable is a collection of interactive African children’s stories.

    I’m Tiv, and I grew up with fables like this. In 2011, I started Pixel Fable as a way to tell these Nigerian stories digitally. That story about Aondo, “Why the Sky Is Far Away,” was the first one I designed and built. I used augmented reality to make the animations feel more interactive (along with some wonderfully spaghetti parallax JavaScript). But the story was still a single HTML page, told from one perspective, along a linear timeline. My translation from oral tale to web page was too direct—I hadn’t captured the multifaceted ways a story could exist online.

    For instance, I could’ve built two versions, based on the same HTML, split into the woman’s point of view and Aondo’s. The competing narratives would frame readers as detectives, exploring and contrasting details to figure out the whole tale. Or, I could’ve incorporated data visualizations to reflect Aondo’s mood: by combining weather data like thunderstorms and temperature with a “Sky Mood Indicator,” I could’ve designed Aondo’s emotional state as a separate, visual facet.

    Either route offers a way to twist or fragment the story, to add layers to the central narrative—to transform the original Tiv tale into a nonlinear, more nuanced, and linked experience, much closer to how the web itself works.

    I want to do that for Pixel Fable, and I want to show you how to do it, too. That means venturing beyond our basic scrolly-telling. But first, let’s take a deeper look at what nonlinear stories do.

    The role of nonlinear narratives on the web

    The web operates in ways that can conflict with our traditional view of what a “story”—with a set start, middle, and end—is. Content is chunked, spread across various channels, devices, and formats. How do we define story lines, characters, interactions, and the role of the audience, given this information sprawl?

    Cue nonlinear narratives. They’re collections of related content, organized around a story. They comprise video, text, links, audio, maps, images, and charts. Their chunked, compartmentalized nature gives them incredible flexibility, and makes them the perfect vehicle for how we explore online, jumping from one piece of information to the next.

    Even though they don’t necessarily follow classic story structure, they still have many of the same parts: heroes, villains, locations, plots. It’s how these are developed and connected that may seem unexpected. One of nonlinear narratives’ superpowers is how they let you build on and refine them over time. For example, Vox’s cards and story streams help us aggregate information on complex news stories by posting relevant bits as they develop—whether it’s a Q&A on the human exploration of Mars that provides context in bite-sized form, or a stream of more info on a disease outbreak. These updates over time allow designers and creators to react to audience feedback.

    Nonlinear narratives also offer audiences more agency. People want to learn, be surprised or intrigued, or entertained—and nonlinear stories prompt participation. Their fragmented structure needs an audience; without readers or viewers, the narrative cannot be experienced as a meaningful whole. In turn, this forces us to design stories that work with, not against, the fluid nature of the web (or what Frank Chimero calls the “edgelessness”).

    Say you have an idea for one of your own. How do you link those disparate elements in a cohesive way? You can start by choosing two or three parts and combining them into a larger block, which then forms a core part of your digital story. This block can be displayed anywhere, anytime, as the story demands. For example, one Pixel Fable story in the works pairs a Google map with images and text to define key places (like the birthplace of a mad baddie) or give the factual history of a setting.

    So those are the bones of a nonlinear narrative, but they come in a range of forms. Let’s take a closer look.

    Types of nonlinear narratives

    This format isn’t exclusive to the web. From Scheherazade’s ancient tales, which weave together multiple story lines, to the movie Memento, which mimics hypertext structures, we see plenty of effective nonlinear structures outside the internet. The same is true of Pixel Fable’s inspiration—but what started hundreds of years ago as interlocking oral histories takes new shape online.

    As we examine these new forms, I encourage you to note the story’s structure, how elements are linked, and how they grab your attention. You might ask yourself:

    • What does the site or app ask the audience to do? Look at the UI and copy: is the experience active (prompting visitors to do specific online/offline actions) or passive (asking only for their attention)?
    • How do elements relate to one another? Do they reinforce the central story, or do they offer a counterpoint? What content types appear to be “natural fits” with one another? How are elements ordered—do the interactions between pieces of content create a sense of rhythm?
    • What’s the smallest collection of content you could see and still understand the narrative?

    Extra-narratives

    Extra-narratives combine one central story or topic with lots of tangents. National Geographic’s “The Serengeti Lion” features a central theme: life for the Vumbi pride. Videos, images, and commentary are branches that enrich that story, allowing you to see—and hear—life on the plains, offering things like aerial views from a drone or the sounds of the pride crunching on zebra bones.You can quickly hop from branch to branch via contextual links, scrolling, or an index.

    Screenshot from National Geographic’s microsite, The Serengeti Lion.
    The Serengeti Lion.

    Disjointed narratives

    While disjointed narratives revolve around a common theme, the connections are much looser. They’re typically a series of chaotic vignettes. Documentaries about large, complex places are a good fit for this kind of narrative, and “Lagos Wide & Close” does this excellently. With a variety of content blocks forming multiple perspectives, interviews, and locations, the site evokes the dusty, jumbled vastness of the Lagos metropolis, both up close and from afar. The city acts as the central character, and the different interviewees and locations become vignettes about a wild megacity.

    Screenshot from the ‘Lagos Wide & Close’ documentary site.
    Lagos Wide & Close.

    Parallel narratives

    As the name says, these show two stories happening at the same time, often with competing goals and conclusions—which makes parallel narratives ideal for contrasts.

    Screenshot from UNICEF’s ‘Moon’ site.
    Moon.


    Moon, by UNICEF, follows the parallel lives of two kids. Each wakes in the morning and goes about their life: one ends up working in a factory for a living, while the other goes to school and becomes an astronaut. After you enter a short code to link the desktop site to your smartphone, your phone becomes a controller. When you rotate your phone, you flip the desktop screen 180° to watch that child’s life unfold.

    It’s a clever use of tech, and the story itself makes a clear point about poverty, wealth, and educational inequality. (I know, there’s a particular irony in interacting with a story about poverty on two expensive digital devices.)

    Database narratives

    These are perhaps closest to the types of work designers and developers do every day. Database narratives use metadata, ARIA roles, and tagged content to auto-generate content. They’re most commonly deployed in data visualizations, where a story’s meaning often comes from the explanatory framing (via copy) and juxtapositions of data.

    Subway-inequality map from the New Yorker Magazine.
    Subway-inequality map from the New Yorker.

    For instance, the subway-inequality map from the New Yorker builds an elegant, interactive narrative on wealth disparities, out of seemingly impartial census data. Visitors can click to see how income varies—sometimes dramatically—across subway lines and stations, and their neighborhoods. Database narratives are an effective way to convey a lot of data in a small space.

    Micro-narratives

    Sometimes we want to tell small, self-contained stories that, at most, may only share an interface with other micro-narratives. The focus is on the individual story—you can view micro-narratives on their own, with no loss of reference or concept. This structure is especially useful for user-generated content (like collections).

    Screenshot from the Hi site.
    Hi.

    The site Hi does this wonderfully. It’s a platform for capturing and writing about different moments in real time. Visitors explore stories of photos and text—bookended with optional private comments from readers—on places all over the world. Each story is also added to a Google map; this extra layer of shared functionality gives the site a more cohesive feel, while still allowing each story to stand on its own.

    Okay. We’ve covered the building blocks of your narrative toolkit. Now, let’s consider what really makes any of them truly meaningful: your audience. 

    Audience participation and feedback loops

    Digital narratives depend heavily on the audience experience. With so many potential entry points to your story, you must define the role you want the audience to play. One constant source of tension is who controls the story: you (as the author), or your audience? Whatever narrative form you’ve chosen, it’s something you’ve designed to achieve a specific goal. Your audience, however, probably won’t be content to sit in front of a screen and follow you around. Your visitors want the ability to choose their own paths—what they see, and the order in which they see it—into your content blocks. It’s up to you to design situations and narratives that take this into account.

    Happily, we have a few strategies to help you do so—and balance the tension between author and audience.

    Encourage exploration

    This approach draws on nonlinear narratives’ strengths—meaningful tangents over time. Create a framework with plenty of content branches, leaving your visitors free to choose what most interests them. Discoverability is key here; your job is to offer enough guidance so visitors know what to do, and then get out of their way. Clearly mark possible routes with instructional labels, animations, and even color-coding. Provide menu structures that prioritize choice over simple information retrieval. For example, group similar narrative blocks in a large slideout menu, or pair questions and thumbnails, instead of relying only on text links. As you develop more content, add it to the framework as a new offshoot to explore.

    Screenshot from the Guardian’s ‘Seven Deadly Digital Sins’ microsite.
    Seven Deadly Digital Sins.

    For instance, the Guardian’s “Seven Deadly Digital Sins” features an incredibly complex set of stories and dispersed content. The loose layout, which displays the sins in grouped thumbnails, and the slow, measured music encourage people to experience the narrative at their own pace.

    Prompt the audience to play a part

    Or, give your visitors even more agency. Build them into your story. With this approach, you take your framework and then set parameters for audience contributions.

    Screenshot from the Flight Paths site.
    Flight Paths.

    In 2001, the Guardian reported a sad, gruesome story. The body of a man fell out of the sky and landed in the parking lot of a home-goods store in the UK. It turns out he was a Pakistani stowaway who hid himself in the wheel well of a Boeing 777 out of Bahrain. Long since frozen to death, he had fallen out of the wheel well as the plane landed.

    Some years later, Kate Pullinger and Chris Joseph created Flight Paths, based on this and similar stowaway events. After devising a setup around the life of a fictional stowaway named Yacub, they invited about 70 readers to add images, video, and text to what they called a “networked novel.” They continue to develop the narrative, most recently with an API, which packages and publishes that nightmarish story in a variety of formats.

    It is a great example of how an internet community created an extra-narrative in bits and pieces. Your audience may feel more invested in a story they helped construct. However, it’s important to be clear about what your participants can expect. You’ll want to model the types of content you’re most interested in receiving (include specific prompts, give sample copy, etc.) You’ll also want to work out questions of attribution, ownership, and payment beforehand. For Pullinger and Joseph’s experiment, some potential contributors rightly asked if Flight Plans would be “monetized” and, if so, what was their work worth? Make sure you supply those answers in your terms and conditions.

    What is vs. what if

    In all this, understand the difference between what is and what if. When I first started Pixel Fable, I wanted the audience to see my story, characters, and action through my eyes. I wanted to determine what IS. But the internet asks us to give the audience control over essential aspects of the story so they don’t lose interest and move elsewhere. Remixes are another way to keep visitors entertained. By designing narrative blocks for the audience to repurpose, we enable users to ask themselves “what if”—which results in new fan art and digital tangents we may never have dreamed of. It’s a powerful thing.

    Screenshot from the Midsummer Night’s Dreaming site.
    Midsummer Night’s Dreaming.

    In Midsummer Night’s Dreaming, a collaboration between Google and the Royal Shakespeare Company, the audience was invited to participate in a live performance. Using Google+ as the digital “stage,” people could post videos acting out their favorite scenes, costumes, observations, and fan art. They could imagine alternate scenarios and endings for Shakespeare’s famous characters. The project let anyone who loved A Midsummer Night’s Dream answer the question, “What if I were center stage?”

    Creating narrative goals (friction points) and narrative threads

    So, you’ve designed collections of content for a story, perhaps even split them across sites or platforms. You have specific events you want the audience to interact with, ones that deepen their experience. Although the entrances and exits to your story are largely up to the audience, we can help their journey by defining clear narrative goals, or points of friction: places your audience will be compelled to stop, explore, and interact with key narrative elements.

    What does an effective narrative goal look like? Perhaps it’s a climactic event, fascinating images and videos, or even a puzzle to solve. What part of your experience will make people look further and fit some of the disparate pieces together? In the New Yorker’s inequality map, one primary goal is getting the audience to find their home station and discover the median income. Finding their neighborhood, or a place they recognize, is a task that forces the audience to slow down and view the data. The resulting visual contrast, in this case (relative) wealth and poverty, becomes the point of friction.

    Narrative threads are the pathways between your goals; they move the audience from one content block to another. A thread can be a simple link between two HTML pages, or perhaps a more complicated geotagged location on a map. In “Lagos Wide & Close” and “The Serengeti Lion,” we see these threads displayed as UI. The forward and back buttons, the location-selector menus, and other interface elements act as connectors. On the Hi site, the categories beneath each captured moment allow visitors to jump from story to story.

    A place for nonlinear narratives

    The internet continues to grow. As we design larger and more diffuse experiences, we need to make sure they are connected and accessible to our audiences.

    My experience with Pixel Fable has forced me to look beyond traditional story formats. I know the stories I want to tell. That’s where these ideas on nonlinear narrative come in. I can identify the content chunks I want, the points of friction and participation for the audience, and the way to use narrative threads to link them—all to create immersive, nuanced digital experiences.

    Throughout this article, we’ve looked at specific concepts and structures that you can adapt for your work. Entertain, surprise, and above all, engage your audience—encourage them to ask what if, as they navigate the worlds you’ve spun.

  • Do Androids Dream in Free Verse? 

    From ATMs to Siri to the button text in an application user interface, we “talk” to our tech—and our tech talks back. Often this exchange is purely transactional: we input commands; the machine complies. Newer predictive technologies like personal assistant apps have renegotiated this relationship, preferring to relate to us as peers, even friends. Scarlett Johansson’s flirtatious operating system in Her brought this idea to a lifelike apex, simulating love, even orgasm—all digitally mediated.

    As technology becomes more pervasive and gains access to greater amounts of our personal data, how can we design successful human-machine conversations? Should user interface text approximate the lilt, flow, and syntax of human speech? Or does humanizing UI conversations create a false intimacy that distances even as it attempts to foster familiarity?

    The answer, of course, is that it depends. Most of us have encountered voice-automated customer service systems. Some of them, in an effort to make their robot customer reps less droid-like, feature voices that try to approximate human diction. A calm, often female voice pauses, suggests brightly, bridges her prompts with almost-ums. Her attempts at realness further underscore the fact that she is fake, blocking you from an actual human encounter.

    A computer that cheerfully calls you by your first name can either delight you or creep you out, depending on the circumstances. Just as robots enter the uncanny valley when they seem too human, a user interface that’s too familiar can push people away. The copy needs to strike the right balance.

    Consistency within diversity

    Until recently, I was a UX writer and content strategist at Google. Specifically, I worked on Google Apps: Gmail, Docs, Drive—all of the productivity tools that help people work and communicate. Writing for a large, entrenched company poses particular challenges because the sheer array of products and experiences offered can make it difficult to achieve consistency in tone and style.

    Our audience included people who use Google tools at work. People at work are obviously a very different market from, say, a teenager absentmindedly browsing a consumer app like YouTube for video clips (though that isn’t to say that YouTube browsing doesn’t happen under the guise of work). But work tools should be as intuitive and (dare I say) delightful as the best consumer apps. They should help you be more productive and creative. You shouldn’t have to spend brain power figuring out how to deploy them.

    Consider, too, the many modes of work. Some people are desk-bound, whereas others are constantly mobile. Some companies have huge IT departments that can provide support; at others, workers have to learn to use products on their own, often without much technical background. This can be overwhelming. Most workers want to spend time getting stuff done, not learning to use Google Apps. So the experience, and thus the text, must serve the overall usability and ease of the product.

    There are ground rules that can guide the writing for all of these interfaces, though they exist in very different contexts and geographies. The YouTube-browsing teen can be in Osaka or Indianapolis. Modifying Chrome settings should be easy and seamless, whether in Farsi, Tagalog, or Italian.

    While we can strive for an overarching level of consistency defined by some core principles—be friendly, be helpful, don’t use jargon or technical language—each product carries slightly different conventions, expectations, and contexts. Yet they all have to be reconciled within a domain that is recognizably Google, in over 50 languages. Keeping text brief and scannable, and including only the most essential words, will smooth a user’s journey.

    “OK Google, search for Thai restaurants.”

    One particular UI conversation that Google may continue to fine-tune is how it initiates a voice search on a smartphone. “OK Google” is the voice prompt Google suggests for striking up interactions on mobile devices. This phrasing suggests that our relationship with both our phone and Google is informal and familiar, even chatty.

    If you ever actually “OK Google” your smartphone or wearable device, though, you’ll probably find that doing so feels forced and cheesy at best. I’d personally rather just say “Call Trevor” or “Find nearby Thai restaurants” and stick to semantic, if utilitarian, commands.

    “OK Google” is awkward because it insists that we’re chums with the search behemoth. Google is less a company in this recasting than a helpful friend. Yet this same Google also upholds “Focus on the user” as one of its founding pillars. “User” implies both a certain ascetic distance and an unpleasantly parasitic relationship. How can I simultaneously be buddies with and just a “user” to the same company?

    Language reveals social landscapes and highlights power struggles, and can shed light on intimacy or distance. When writing for an interface, the smallest words reveal relationship dynamics and cue motivations, even emotions. The microtext on, say, a button can alter the tenor of the interface conversation. Whether you label a button “Got it” or “Continue” signals more than just information conveyance. “Got it” connotes a certain confidence and informality, and assumes agency on behalf of users. “Got it” asks them to own their comprehension and acceptance of whatever information is presented before moving along, rather than merely assenting to “Continue.”

    Another common copy example: “enable” versus “turn on.” “Enable” feels unnecessarily technical and implies a subtle hierarchy between the enabler and enabled. The softer “turn on,” by contrast, could indicate the flow of water from a faucet, or—depending on where the mind goes—a sexy precursor to further action. When aiming for “friendly,” where is the line between cloying and mechanical?

    Brevity with soul

    Being conscious of words doesn’t mean that one needs to make UI language purely functional. Balancing well-placed, clever copy with short, concise text can add delight and magic to an experience. Note Chrome’s “Aw, snap” for a page-load error, or the sly personality that suffuses the airfare purchase flow on Virgin America’s site:

    Virgin’s brand voice is flirtatious, fun, and irreverent. Their approach resurrects an earlier age when air travel promised a thrilling luxury rather than a cramped seat, broken pretzels, and the purgatory of airport security. They don’t take themselves too seriously and their approach injects brassy humor into a task as lackluster as flight booking.

    That tone comes through in small ways, such as this playful modal dialog about additional upgrade charges. The button is labeled not with the expected “Okay,” but with “I understand, let’s do this.”

    When a user enters her name while booking a flight, the form field greets her with a sly bit of text: “Hey there.” Subtle winks like this can humanize an interface without being intrusive, yet aren’t so colloquial that they’re alienating.

    Text should inform readers and help them along—and then it should get out of the way. A well-written UI recedes into the background, imbuing—but never overpowering—the user experience. There’s poetry in writing for the web, but it isn’t the luxuriant run-ons of Whitman. Rather, it’s the economy of poet Masaoka Shiki’s haiku—so spare it’s almost missed.

    Friendly but functional

    The popularity of “digital detoxes” hints at a growing frustration with our reliance on tech interactions. The future may well contain more unobtrusive and silently helpful technologies, rather than intimate human-machine relationships à la Her.

    As such, UX writers and designers might consider how we can keep conversations friendly but functional. We can provide signposts without the baggage of a relationship. Sue Factor, a former colleague and Google’s first dedicated UX writer, taught me that short text is often the best text. Although I earn a living writing for the web, I don’t flatter myself that anyone opens an app to carefully read and savor my language. We’ve all got better things to do. As Shiki writes:

    My life —
    How much more of it remains?
    The night is brief.
  • Article Update: Don’t Rely on Default `sizes` 

    In “Responsive Images in Practice” I made no little hay that sizes was optional—leave it off, and browsers will substitute the default value: 100vw.

    That last part is still true: browsers will still use 100vw as a last resort. While the sizes-less examples in the article still function, they no longer validate. The spec has changed, and sizes is no longer optional when using srcset and w descriptors.

    validation error image

    Why?

    Too many people were relying on the invisible default for images whose display size wasn’t even close to 100vw, resulting in inappropriate srcset selections and wasted bytes. Developers learning the new markup were also getting tripped up on how sizes affects intrinsic sizing. Absent any CSS to the contrary…

    <img srcset="image.jpg 320w" />

    ...always displays at the full viewport width. If you don’t know about the 100vw default (and especially if you’re a little fuzzy on what intrinsic sizing is, or how sizes affects it), that’s pretty surprising.

    By requiring that authors explicitly state (and with any luck, think about) a sizes value whenever they use w descriptors, the spec eliminates reliance on the invisible 100vw default. This will hopefully cut down on mistakes; at a bare minimum, it ensures that incorrect values are visible. So carry on, and if you want your markup to be valid, easier to debug, and easier to understand—don’t forget the sizes.

  • Content-First Design 

    A few years ago, I started getting into video games like Katamari, Animal Crossing, and Borderlands 2. Their designs are astounding; each feels like I’m having a natural conversation with the game, and each introduces content in the moment I needed it. As a result, the game experience feels so dang smart, and I feel like a hero whenever I play.

    Here’s an example from the very first minute of Animal Crossing. All you’ve done is started a new game.

    If you watch it, you’ll see the game designers make assumptions about you so they can collect innocuous personal information in a conversational way. When their assumptions are wrong, they respond in a humorous way. No harm, no foul. Yes, yes, yes.

    So I started wondering how the video game industry has mastered this art of interactive storytelling so brilliantly. Who are the people on their teams? What are they called? How do they work?

    I started reading up on the history of particular games in development, which kinds of themes show up in forum discussions, and checked out job descriptions that Nintendo, Bethesda Games, and Gearbox Software used.

    I learned a few interesting things

    Game designers start with the story. What they add to the experience complements and builds on the core story; it doesn’t distract from the priority of “accomplish goal,” even when that takes a year longer than expected, as was the case with Journey, Sony’s award-winning game from thatgamecompany. (Journey doesn’t even have a single word as part of the main game story line. Unreal.)

    They design for discovery—learning in the moment not only increases retention and engagement, but it’s delightful and emotionally empowering.

    I also learned of a unique role that’s part of their design process; it isn’t “copywriter.” It’s called narrative writer, game writer, or story designer.

    These are content strategists, and they’re responsible for designing the conversation between player and game.

    Content as the product experience is par for the course in the video game industry. And since 60 percent of people (average age 30) play video games—and it’s an $82 billion industry that just keeps expanding into every interface imaginable—it’s to be expected that our web and mobile experiences should feel more like conversations.

    So I started practicing what the video game industry preached (and what the advertising industry leaders like George Lois preached before them): start with the word.

    I immediately changed my process. I started writing content on day one of projects I was involved with. Those included a mobile utility, magazine, and personal projects. They also included the Annie E. Casey Foundation (AECF) and Ben & Jerry’s site redesigns with Happy Cog, and User Interface Engineering’s conference and webinar content.

    AECF, for example, was redesigning its website, which included an enormous amount of content. More than 20 stakeholders from various internal teams had their own set of requirements and goals for the new website. So at the kickoff meeting, we facilitated discussions around how well the content seemed to be meeting audience expectations by asking those stakeholders, “What are the top questions your audiences ask? What are their top complaints?”

    That focused early discussions on the communication gaps we could solve with content. We then looked at “top content” and “time on site” data to qualify which pages in the existing experience were drawing the most eyeballs and interest.

    What we found was AECF’s research reports were highly sought-after, but the content in those reports wasn’t surfaced in a way audiences could easily find or understand. So we started there in week one of the project, rewriting the research report page using real content from them. After we did one, we asked, “How would someone get here?” and “Where would someone go next?” as a means of determining which content to write next. Doing this enough times, over and over, meant a natural structure (IA) emerged.

    This shift of working content first (conversation design) instead of structure first (system design) is how we worked for several weeks, all in a Google Doc, before we ever moved to layout and design. This approach also ended up reverse-engineering the conversation of the website—from most-sought-after content up and out—until we got to the homepage. By then, we’d already written all the content for other pages, so designing the homepage was loads easier.

    The artifact we continually used through this process is called a content workbook, and AECF so kindly lets me share it in its naked state.

    Working in this content-first way made for the most joyful and collaborative design projects I’d been involved in since starting my web career 12 years ago. They were iterative earlier on, focused on getting real content before trying to structure it (because designing for real content is real), and ended up leading me to join Capital One.

    I never dreamed practicing content-first design and talking about it at a couple conferences would lead me to work for a bank. Especially one I knew nothing about. But the idea of creating jobs for people who get that content is product design, well that was too dang good to pass up. So now we’re growing a niche team of UX content strategists, sort of like our equivalent of the video game industry’s story designer.

    Part of our process is working directly with designers and product managers to design conversations in plain text. We call them content prototypes, and they take many forms depending on the team and project.

    Content prototypes

    A content prototype is a Word document, text file, or Google Doc full of words that we can test with real customers to see if we’re speaking their language.

    Designers and product managers can make them just as a content strategist or copywriter could. The goal of the prototype is to write the conversation we want to have with someone, then design an experience that best brings that conversation to life, no matter the technology. How to start:

    • Start writing what kind of conversation you’d have in real life if you didn’t have an interface yet.
    • Start writing.
    • Write.
    • And don’t edit. (That’s the hardest part.)
    • Keep writing. How the conversation should go will become clearer the more you write. (And the more you test with other people.)

    For example, if we’re designing interactive experiences, we might create content prototypes using loads of if-then statements. (It’s like a Choose Your Own Adventure book: read some stuff, make a choice, see the corresponding story. Rinse and repeat.)

    For example, this is a content prototype the product and design team created for Ideas, which suggests things to do, see, or buy based on your purchasing history.

    Before launching the pilot in a few cities, the team wanted to A/B test some language for “Mary,” the persona they were designing for. But they already had an app designed and in regular usability testing. So they actually extracted the content from the design and put it in this Word document to isolate the conversation, then created a B version of that conversation. A few days later, they ran the test with real people. Here’s what Cary Feuer—a product manager on Ideas—said about it:

    “Content prototyping FTW” seems like a pretty good tagline, eh?

    More to come

    We’ve got content prototypes for different kinds of projects at different stages of development, from scripts we can test on the street or in user labs, to content experiments we can deliver through email or SMS, or prototypes that capture the full (real) content across time and channels.

    A lot of the content prototypes we’re creating at Capital One are for experiences that aren’t publicly available yet, but I’ll share them as I can in future posts. And hopefully you can get content at the table where you are. Content prototyping changes the way we work. It’s not a piece of real estate on a page. It’s not an asset. It’s experience design, after all.

  • Context Makes Our Devices 

    A few weeks ago, Josh Dzieza of The Verge had this to say about the Apple Watch, and really smartwatches as a whole:

    That seems nice but doesn’t really answer the question of why you’d spend a few hundred dollars (or more) for a device that does the same things as the device in your pocket.

    When smartphones were first gaining popularity, I could’ve expressed the exact same concern, swapping the word “pocket” for “backpack.” Why would I spend so much money on a phone when my laptop can already manage email, calendars, and notes?

    Statements like that overlook the reason why certain device categories become successful: context. Smartphones gained popularity because they proved so useful in contexts where laptops or larger devices weren’t feasible.

    New device categories often start out by doing the same tasks as existing devices, but history has shown that successful categories are those that bring an entirely new context and fundamentally change the way we use technology.

    Those new contexts provide opportunities for applications, services, and experiences that wouldn’t have been possible in previous generations of technology. Instagram grew so quickly because phones with high-quality cameras and always-on internet connections became a commonplace in pockets across the world.

    Podcasts came into their own because devices with large hard drives became portable enough to take anywhere. Highly-localized weather forecasting applications like Dark Sky, reading list services like Instapaper, and the entire industry of mobile gaming came into existence because of the contexts opened up by new device categories.

    What will be this new, always-on-you context’s star? Healthcare seems like an early leader to answer that question—the upcoming generation of wearables are finally pushing the category beyond the “fancy pedometer” stage.

    The Microsoft Band, Samsung Gear lineup, and Apple Watch all pack a heart rate sensor, which can help measure calorie burn, activity levels, and overall health through continuous monitoring. The upcoming Samsung Simband contains six sensors to monitor heart rate, blood pressure, skin temperature, oxygen levels, and displays a real-time electrocardiogram. Even though the strap looks like something out of Tron, it’s an impressive piece of technology.

    Beyond fitness, this type of monitoring can improve the lives of many people living with certain health conditions today. From early warnings for those with asthma and respiratory illnesses, to glucose monitoring for those living with diabetes, there is a ton of potential for technology to assist people in truly meaningful ways.

    Apple’s HealthKit and (recently-open sourced) ResearchKit are especially exciting when paired with these new devices. HealthKit enables the collation of a user’s data into a private, secure location, providing both high-level and detailed views of health statistics. ResearchKit is a way to use collected data to contribute to health studies around the world, and has already been making great progress.

    Stanford University had more than 11,000 people sign up for a cardiovascular study using ResearchKit less than 24 hours after the framework was announced. Alan Yeung, the medical director of Stanford Cardiovascular Health, said, “To get 10,000 people enrolled in a medical study normally, it would take a year and 50 medical centers around the country. That’s the power of the phone.”

    His last point is key—all of the current ResearchKit work has been done with iPhones—devices that sit in pockets, purses, and backpacks. Imagine what is possible when a non-trivial number of people involved in these studies have a device filled with sensors strapped to their wrist all day long. Participants around the world can wear these new devices to provide researchers a constant, holistic view of their health with precise and reliable data, enabling more accurate results.

    The progress made in these studies won’t just benefit those fortunate enough to afford the devices in the first place—healthcare providers anywhere can take advantage of new discoveries.

    Healthcare isn’t the only area with potential in this new context. If wearables are to be successful, communication patterns will change around them, the way we interact with services and tools in our lives will adapt to their use, and new things we haven’t yet experienced will be created.

    It’s important to remember that new device categories rarely replace existing ones. They are merely one more device type on the web, waiting to be used to their fullest potential—and that’s where our fun begins.

     

  • Rian van der Merwe on A View from a Different Valley: Why? 

    My two-year-old daughter is going through a “Why?” phase. I’m not too worried about it, though. I had plenty of practice when my five-year-old went through the same thing, and through trial and error I figured out the best way to survive it.

    So here it is: the only way to get a preschooler to stop asking why? is to out-why? them. Whenever they ask a question, answer it. Don’t get impatient, don’t sigh and say, “just because”—none of that stuff. Push right through those impulses. Instead, take it wherever it goes. Use Wikipedia if you need to. Never give in, never give up. If you answer every why? question with gusto, eventually your child will get bored and move on to another topic or game. It never fails.

    Well, it almost never fails. I recently had an experience with my two-year-old where I had to deviate from this tried and tested path. One morning she asked me, “Daddy, why do you go to work?” My preprogrammed brain immediately switched to out-why? mode; I geared up for another long session, opened my mouth… and then closed it. I didn’t know what to say. I was speechless.

    I didn’t want to say “To make money so we have food to eat.” That’s (part of) the truth, but I don’t want to teach her that we work only for material reasons. I couldn’t say “To make the world a better place,” because that just makes me sound ridiculous and it’s not the whole truth either (as much as I want it to be).

    So there I was, stuck on what should have been a pretty simple question. Why do I go to work? Why is that so hard to explain? Do I even know why? The thing is, it does get complicated very quickly once you start playing out some of the scenarios. Here’s just one way it could have gone down with my daughter:

    Emery, I go to work because it’s what society expects. So that we can have food and a place to live, and so that I can help pay for things we use every day like schools and roads. But I also work because I want to be creative and use my brain wisely—and preferably do that in a way that makes other people’s lives a little better or easier in some way.

    What’s that? Oh, Mommy chooses not to work, not because she can’t or doesn’t want to, but because what she wants more right now is to be with you guys as much as possible while you’re still so young. Not everyone gets to decide that, so we’re very lucky. And when she decides to go back to work it won’t be because she doesn’t love you but because she also wants to do all those things I mentioned earlier.

    Hmmm? Well, see, some people don’t work because they don’t want to, others because they can’t find a job—and that can be really hard for them and their families. Some people do jobs that they don’t want to do, but they have to because it’s all there is, and they don’t have a choice.

    As I played this scenario out in my mind, further and further into the depths of tangled reasoning, I realized why I didn’t know what to say. It’s because I’ve increasingly become aware of the reasons I am where I am, and live where I live. And as much as we all want to believe that our successes happen because we’re so awesome, the truth is that where we’re from and how we grew up and what kind of opportunities we had as children play an enormous role in all of it.

    When we water down work to pithy sayings like “do what you love” or “work is love made visible” we do the complexity of the topic an enormous disservice, and we ignore the huge role that—yes, I’m going to go there—privilege plays in all of it. You see, “do what you love” is only possible if you’re in a financial and social position to follow your passion wherever it goes. “Work is love made visible” is easier said than done when you have three jobs that you don’t like, and have to struggle to make it through the day.

    I don’t have an answer for my daughter on the work question yet. But I do know that why we work—and what kind of work we do—is a function of our privilege and our history as much as it is a function of our choices and our dedication.

    I do have a question for my daughter, though. A question we should probably explore together before we get into the work thing. I think I’ll go home tonight and ask her “why?” Why do we get to live here? Why does she get to go to school? What keeps some others from having the same opportunities? Is that fair? Can we become more conscious of our privilege? How can we shine a light on injustice all around us and get involved in our community in more helpful ways?

    My daughter probably won’t like it if I turn the why? tables on her. But I think it’s important. I think we should place emphasis a little more on how we can help others who don’t have our privilege and history than on how to be happy and rich. If my daughter and I both learn that out of the exchange, I’d consider it a win not just for parenting, but for my own life as well.

  • What Really Matters: Focusing on Top Tasks 

    Digital is a space of endless replication. It has never been easier to create—and create, and create. People love to publish, but they hate to remove, which leads to overloaded websites and constant, inevitable redesigns. The top layers get a shiny new coat of graphics and meaningless “we really care” content—but underneath, a teeming mass of out-of-date, badly organized information still swirls about.

    The solution is to make hard choices using Top Tasks Management. Top tasks are the small set of tasks (usually less than 10, often less than five) that matter most to your customers. Make these tasks work well, and you’ll be on the right track. Get them wrong, and chances are you’ll lose the customer.

    Top Tasks Management is a model that says: “Focus on what really matters (the top tasks) and defocus on what matters less (the tiny tasks).”

    Tiny tasks are a nightmare for web teams. On their own, these tasks seem innocent enough. It’s just one more page, one more link, one more graphic. But gather them up, and many a web professional has found themselves nibbled to death.

    Tiny tasks are also full of organizational ego. Often, the more important the task is to the customer, the less content is being produced for it; the less important the task is to the customer, the more content is being produced. This inverse relationship is very typical.

    Identifying top tasks

    The purpose of Top Tasks Management is to reduce complexity by identifying what really matters to customers. The following steps are involved in a task identification process:

    1. Comprehensively engage the organization in a process of gathering customer tasks.
    2. Work with key stakeholders to come up with a shortlist of these tasks.
    3. Get a representative sample of customers to vote.
    4. Create a league table of tasks from the one with the highest vote to the one with the lowest vote.

    Step 1: Gathering the longlist of potential tasks

    Use the process of gathering tasks to get outside of organization thinking and inside the customers’ mind and world. Actively engage the key stakeholders in this process. It can be a great way to get the whole organization thinking about what the customer wants to do, rather than what the organization wants the customer to do.

    When gathering the list of customer tasks, use as much data as possible. Here are some common data sources for customer tasks:

    • Corporate philosophy: Strategy, mission and vision, and corporate objectives.
    • Customer feedback: Survey results, frequent help requests, insight from support or service teams.
    • Stakeholder reviews: Interview key stakeholders and ask them what they consider top customer tasks.
    • Competitor or peer websites: Review competitor or peer websites and see what sorts of tasks are cropping up.
    • Traditional and social media: What sorts of tasks are being mentioned by customers on social media? Are there specialist traditional media that cover your industry?
    • Site behavior analysis: Most visited pages, most popular downloads.
    • Search analysis: Top search terms on the website, as well as Google public search behavior for your industry.

    Why go to all this bother? Why not just depend on the numbers for your most visited pages and top search terms? The truth is that these can be unreliable metrics:

    1. Page visits reflect what you have, not necessarily what customers want. There may be tasks that you don’t have content for—so it’s unlikely they will show up in search and site data. And analyses of page views often reflect an amalgam of tasks; it’s hard to separate the top tasks on these pages from the tiny tasks.
    2. Search is a window into customer behavior, but it doesn’t tell the whole story. For example, when we worked on the BBC intranet, we found they had a feature called “Top Searches” on their homepage. The problem was that once they published the top searches list, these terms no longer needed to be searched for, so in time a new list of top searches emerged! Similarly, top tasks tend to get bookmarked, so they don’t show up as much in search. And the better the navigation, the more likely the site search is to reflect tiny tasks.

    Cisco recently undertook a project using Top Tasks Management. When we completed their research, we had over 600 tasks. (In a typical project, we tend to gather between 300 and 500.) Here is a small sample of what the initial tasks looked like for Cisco:

    • Add a network diagram
    • Annual reports
    • Attendant console
    • Benefits of product
    • Network engineer blogs
    • US forums and communities
    • Bug toolkit
    • Bugs, debugging
    • Certifications
    • Cisco MeetingPlace
    • Collaboration
    • Get pricing
    • How to configure
    • Discussion forums
    • Technical forums
    • Support community
    • RV082 installation
    • Network Magic
    • Self-service

    There were duplicates, areas of overlap, branding words, and internal jargon. It needed a lot of cleaning up!

    Step 2: Getting to a shortlist of tasks

    The next step is to bring the longlist of tasks down to a shortlist of no more than 100. Getting a feel for the tasks takes time, which is why we recommend planning on four to six weeks to do the task research and get to the shortlist. Here are some guidelines for shortening your list:

    1. Don’t use brands, jargon, tools, or formats. Get to the essence of what the thing helps the customer do. Avoid specialized or vague phrases like “MeetingPlace,” “Network Magic,” or “Videos.” What is the essence of the task? Is it Pricing, Configuration, Troubleshooting, Training?
    2. Avoid product names or groups. Instead of “RV082 installation,” use “Installation,” as that covers all products. Don’t use “Collaboration” or “TelePresence,” as these are product groups.
    3. Eliminate overlap. “Bug toolkit” and “Bugs, debugging” are essentially the same thing, so you can bring them together into one task. There’s also a lot of overlap between “Technical forums,” “Support community,” “Forums and communities.” We probably only need one task here.
    4. Avoid lofty concepts and goals. A goal is wanting to spend more time with your family, but a web task is booking a vacation. All of the tasks on the list should be roughly at the same level. What do “Self-service” and “Knowledge Base” actually mean?
    5. Ignore audiences and demographics. Keep tasks universal. We don’t want “Network engineer blogs” or “US forums and communities.”
    6. Avoid verbs. The noun is the task. Only use verbs when they’re essential. The list becomes very difficult to scan when so many tasks begin with “find,” “get,” etc. We don’t need “Get Pricing”; the word “Pricing” is fine.
    7. Avoid phrase repetition. Try not to have more than four tasks in your final list begin with the same word. In the longlist, we had lots of tasks beginning with “Cisco.” In the final shortlist, we only used “Cisco” where we felt it was absolutely essential.
    8. Be concise. Use a maximum of seven words or 55 characters for any particular task.

    Your tasks might also include subtasks in parentheses. Subtasks should not be exhaustive—typically just two or three examples—and we do not use “etc.” at the end (or else every task would have it).

    At the end of the process with Cisco, they agreed on 67 tasks that reflected what customers wanted to do. It was the first time this organizational consensus had ever occurred. Here’s a sample of the list:

    • Troubleshooting (bug fixes, diagnostics, guides)
    • Blogs
    • Calculate return on investment (ROI)
    • Check product or service availability (lead times, back order, in stock, in my region)
    • Compare Cisco products, services and solutions to each other
    • Customer / user reviews and ratings
    • Download software, firmware, drivers, patches, updates
    • Follow Cisco on Twitter, Facebook, YouTube
    • Network design (tech guides, notes, examples)
    • Pricing for an individual product or service
    • Training (courses, calendar, locations)
    • Troubleshooting (bug fixes, diagnostics, guides)

    Notice that we did include “Blogs,” despite our rule against including formats. Sometimes we leave in a word or phrase just to prove that it will not get a big vote. If there’s a buzzword that is all the rage internally, consider leaving it on the list just to see how customers react.

    By far the most important part of the shortlisting process is involving as many key stakeholders as possible. We brought together people from Cisco’s marketing, support, communications, product, and other teams. It was a hugely enlightening process for everyone involved. They began to understand where there was overlap, and how they would need to collaborate on content and navigation.

    Step 3: Getting customers to vote

    The third step is to have customers weigh in on the shortlist. We usually send out a survey and ask each person to rank five tasks, giving 5 to the most important, 4 to the next-most important, and so on:

    A screenshot of a long survey, showing instructions, a list of 67 tasks, and spaces to rank the tasks.


    That’s a joke, right? Nobody would do that. It breaks all the rules of psychology and survey design. It’s simply not possible. Yet in the last 10 years, we have done over 400 similar surveys with close to 400,000 people voting. It’s crazy, but it works.

    The voting survey needs to be designed this way because:

    1. We want to find out what really matters to people—what they do versus what they say they do. The very length and overload of the survey forces the gut instinct to kick in. You don’t “read” the list; rather, the tasks that really matter to you jump out.
    2. The core deliverable of the survey is a league table of tasks. You get to know not just the top tasks, but also the tiny tasks, and how each task ranks in relation to other tasks. It gives you a hierarchy of importance that will allow you to make design and content decisions—what to prioritize, what not to prioritize.

    Step 4: Analyzing the results

    Cisco is a complex world. The 67 tasks in the final task list were all seen as top tasks. They had been edited down from a list of more than 600. And yet, when the votes were counted, here’s what happened:

    A pie chart divided into 67 unequal pieces, showing that three tasks take up a quarter of the chart and the bottom 44 tasks take up another quarter.

    Three tasks got the first 25 percent of the vote. Six tasks got from 25–50 percent of the vote, 14 tasks got from 50–75 percent of the vote, and 44 tasks got from 75–100 percent. Yes, three tasks got as much of the vote as the bottom 44. In fact, the top task (“Download software”) got as much of the vote as the bottom 23 tasks.

    We have done this process over 400 times and the same patterns emerge every single time.

    This is Cisco’s league table of the top 20 tasks:

    A table displaying the same data as the pie chart, but showing only the top 20 tasks and their percentage of the total vote.

    The top task (“Download software”) got 2,408 votes out of a total of 26,160 votes cast, representing 9.2 percent of the overall vote.

    Here are the tasks at the bottom of the vote:

    A table displaying the same data as the pie chart, but showing only the bottom 20 tasks and their percentage of the total vote.


    The bottom task (“Financing, leasing options”) got 29 votes. This is not to say that financing and leasing are unimportant; it’s just that people don’t go to Cisco.com for them. Also, notice how “Blogs” got just 76 votes out of 26,160 cast. People don’t care about the format. They care about the task of installing the RV082 router, for example. If they find a blog post about how best to install the RV082, then, sure, they’ll read that.

    Using the results

    The benefits of such an evidence-based, collaborative approach are worth the effort. For example, in 2010, downloading a typical piece of software could take 15 convoluted steps and an average of 280 seconds. Now, much of the software can be downloaded in four steps and an average of 45 seconds. Success rates have improved for many tasks by as much as 30 percent.

    Every six months, Cisco does a formal test of its top tasks, giving real customers real examples of top tasks and measuring success rates and time on task. These “Task Performance Indicators” have become Key Performance Indicators for the Cisco web team.

    Another key outcome of Top Tasks Management is a more collaborative work environment, where people come together to manage a task, rather than just manage a website or an app or publish content for a particular department. Cisco has embraced this approach; the Marketing and Support divisions are in regular contact, and employees from IT, usability, content, and experience design work closely and coordinate their efforts.

    The essence of a great customer experience is to help people quickly and easily complete their tasks—but to do that, you need evidence of those tasks, not opinions. Top Tasks Management gives you the data to focus on what really matters: removing (or at least deemphasizing) a whole plethora of tiny tasks, and improving the small set of top tasks that your customers really want.

  • Standardization and the Open Web 

    We’re done arguing over the importance of web standards. Accessibility, stability, quality control, and ease-of-use all helped to settle the debate long ago. Advocacy websites created to promote web standards—such as Chris Heilmann’s Web Standards for Business and The Web Standards Project—haven’t needed to change at all since the mid-2000s.

    What has changed, however, is the way standards are developed—an issue arguably as important as the standards themselves. The next community debate, then, isn’t about web standards; it’s about how web standards should be standardized.

    What’s in a standard?

    The idea that standardization is important is reflected in the language we use to describe our projects and communities. For example, the JSON API homepage states that it is a “Standard for building APIs in JSON.” The FAQ page describes JSON API as a specification, and developers are talking about its use in terms of compliance. A competing project, HAL, references the visual language of standardization on its website—the flow of the page reminiscent of a formal Request For Comment, before directing you to the actual Internet Engineering Task Force RFC.

    These projects illustrate a conflation of ideas about standards, which, left unaddressed, can lead to confusion. Both the JSON API specification and the HAL specification are de facto standards—an idea for a best practice approach to a common-use problem that is spreading organically through the developer community.

    The specifications we tend to think of more commonly, such as those for HTML and JavaScript, are voluntary consensus standards, meaning that international standards-setting bodies and industry consortia have agreed to work on and adopt these specifications, and create incentives for their implementation. But even in a voluntary consensus environment, differences of opinion can split a technology—JSON (not to be confused with JSON API) actually has two competing voluntary consensus specifications: one with the standards group Ecma, the other with IETF.

    While the term “standard” is used here in all cases, all specifications are not created equal. We sometimes even see RFCs for technical specifications that will never become standards because they are theoretical ideas for how something might work; ergo, all standards will have specifications, but not all specifications are standards.

    Making standards

    “Official” standards are specifications that have gone through a process of voluntary consensus. There is potentially a clear path for projects to evolve from a de facto specification to one that is standardized through voluntary consensus:

    1. Developer identifies problem and proposes solution to peers;
    2. Peer community provides feedback and proposes potential alternate solutions in public channels like GitHub or Google Groups;
    3. Peer community reaches mass consensus and hands specification off to a standards body;
    4. Developers implement solution while the standards body formalizes and legalizes the standard.

    Most developers I know are smart, resourceful, and prefer the path of least resistance; thanks to the all bugs are shallow mentality of the OSS community, they’re inclined to work together to solve issues of mutual concern. This is a fairly straightforward, not-at-all-new idea, and The Extensible Web Manifesto is essentially a call to action to implement more developer feedback on this very process.

    It’s exciting to think that the next official web standards might come from the developer community, but in practice this path to official standardization has been obfuscated. The Responsive Images Community Group experienced this firsthand when it proposed a specification for the picture element—noting an issue with the way HTML handled responsive images, the RICG proposed a developer-built, de facto solution to the Web Hypertext Application Technology Working Group, maintainers of the “living” HTML standard. In a well-documented series of events, WHATWG practically dismissed the developer solution in favor of a vaguely specified solution they created over the course of a few days. If it weren’t for the passion and persistence of the community and of RICG leadership, the developer solution would’ve been defeated.

    The RICG specification was ultimately accepted by WHATWG and the W3C, but the experience of the standardization process certainly left a bad taste in developers’ mouths. It would be easy enough to focus our attention on improving this process for community groups like RICG, and the web would certainly be a better place for developers if we did so—but wouldn’t it be nice if we could define standardization not as “a process that makes technology,” but as “a process that makes agreements about technology”?

    In reality, open standardization is a fundamentally power-laden and political process, and it’s making its way into how we think about Open Source project and community governance. Put in the terms of Eric Raymond’s seminal essay, we’ve built web technologies in the bazaar-style of the open source development ethos, but standardizing those technologies is a cathedral-building activity.

    As we seek to standardize technology, we need to recognize the tension inherent in building cathedrals that will later become central authorities for us to reject. Our challenge is to find the balance between capitalizing on the benefits of standardization processes without eroding our community ideals. Thankfully, there are long histories of standardization efforts in other industries and communities that can provide insight for standardizing the web.

    Old models for modern standards

    Open source communities can learn a lot from the histories and governance models of different standards organizations—indeed, web standards consortia like Ecma International and the W3C already have similar organizational structures, but it’s helpful to understand the prior art upon which we are laying our community standards-setting foundation. After all, the “keep what works” mentality only works in the long run if you understand why it works in the first place.

    Good programmers know what to write. Great ones know what to rewrite (and reuse).
    Eric Raymond

    The ideological origins of web standards bodies come from early efforts to standardize telegraphy and engineering in the 19th century, through committees such as the American Society of Civil Engineers, American Society of Mechanical Engineers, and American Institute of Electrical Engineers. Many hosted regular “congresses”—Victorian-era precursors to today’s web development conferences—that helped to create standards and to further define the identity of the professional engineer.

    As engineering disciplines began to overlap, it became clear that cooperation between these industrial societies would be necessary, so in 1918 the American Engineering Standards Committee was formed to encourage cooperation and coordination of standards across groups. The resulting structure was an “organization of organizations” that facilitated consensus-building among multiple engineering organizations, each comprised of a diverse pool of engineers from a diverse set of companies.

    Today, the AESC is known as the American National Standards Institute, but its 100-year-old model of governance—rife with community crises and ideals—is reflected in web standards groups. Then, as now, organizational disputes often arose between “shop culture” practitioners and “school culture” academics. A certain amount of tension between groups is healthy for moving ideas forward, and these early groups evolved organizational means for creating and releasing tension as necessary. Today’s default response to disputes in open-source software is to fork the specification in question, producing a network of rival camps who are incentivized to emphasize differences instead of areas of agreement.

    When ideals compete

    “Openness” is a core ideal in the Open Web community, as well as something of a polluted word. The rhetoric of openness is meant to communicate a favorable set of values, and those values often depend on the speaker and the audience. In his book Open Standards and the Digital Age, Professor Andrew Russell notes that “for individuals, ‘open’ is shorthand for transparent, welcoming, participatory, and entrepreneurial; for society at large, open signifies a vast increase in the flow of goods and information through a global, market-oriented system of exchange.” In the absence of a single definition that suits all parties, we tend to take “open” to mean “inclusive of everything.”

    Standardization, on the other hand, is often a process that defines what something is in terms of what it is not. Russell notes that the broader societal goal of standardizing technology is to create a “cohesive and flexible network” that can sustain complex social and economic activity. Thus, the process of making standards means incorporating a wide range of practices and ideas with political, economic, and cultural dimensions—all of which may be of strategic importance to creators, implementors, end users, and the general public. Put this way, standards are technically-oriented instances of diplomacy.

    In establishing the ISO subcommittee for developing open working standards in 1977, Charles Bachmann noted that “the adjective ‘open’ means to imply that all participants come to the system as equal partners.” In reality, participants don’t often come to the table as equal partners—the OSI’s own progress was stymied by organizational power plays and the growth of a competing technology, TCP/IP. But equality as an ideal of open standards-making has remained. This ideal is rooted in a deeply held opposition to centralized power, which, according to Russell, is reflected in the histories of many standards-setting organizations. Upholding this vision of equality and achieving successful implementation meant, at times, hiding conflicts and issues from those outside the meeting room—not exactly the transparent behavior one might expect from an “open” system. 

    If standards really are agreements between equal parties, then the agreement is the controlling authority. And if standards-setting is a rejection of centralized control, then the standardization process becomes one of creative destruction. It’s the ideological circle of open-standards-making life: a group makes a consensus standard on some technology; as the standard circulates, a new party arises to point out a flaw or an unconsidered use case for the existing standard. The original group then has to make room for the new party and rework the standard, or else face rejection of the group and the standard. In rejecting the original group, the offended party forms a competing group and standard, and the cycle begins anew. 

    It’s complicated

    It’s a tangled web we weave standardizing the Open Web—political, economic, and social relationships between people, technologies, companies, and industry groups are difficult to ascertain at a glance. On closer inspection, one can see that these organizations and communities are complex systems forming a complex network—so complex that I was compelled to create this interactive Open Standards network graph to help keep it all straight as I researched.

    Before we rush off to create a complex, decentralized network of open source standards groups, it probably warrants mentioning that complex systems fail 100% of the time. A decentralized network may let us fail smaller in most cases, but the key to longevity of the system is failing smart—and if the research has taught me anything, it’s that standardization fails on the human, not the technological, element. For better or worse, complexity is not viral—so to mitigate this, we need to make the complexity of the standardization system consumable without abstracting away meaningful parts of the process.

    In the absence of community coordination, methodless enthusiasm will ensue—and caught somewhere in the Bermuda triangle of competing standards bodies, implementers, and OSS maintainers is the developer community. If we want our community-driven projects to become official, internationally recognized standards, we need to understand the impact of our governance processes as well as we understand the technical specifications for our technologies.

  • Accepting Our Lack of Control 

    It’s easy to forget that our users have ultimate control over how they view the web, even though it has been said before. As people making the web, we merely offer suggestions. These suggestions of ours should make it easier, not harder for people to access our content in the manner that best suits them.

    Over the course of the last year I’ve worked on several projects for a wide array of products and sites. The common denominator across all of them was an end goal of a responsive site. Often that’s where the commonality ended, though. In some situations not everyone agreed or accepted that we lack control when it comes to how users experience our sites.

    As I work and write CSS, I try to do so in a way that acknowledges that I don’t have ultimate control. For instance, I prefer to use rems with a pixel fallback, ensuring that my line heights are unitless and work with whatever unit the font is in. That has the added bonus of not having a negative effect on the children of the element. In addition, I often prefer to base my breakpoints on the content of a page, rather than a set of device sizes. That can make the code a bit harder to maintain, but it benefits users. When it comes to grids, I’m happy to use percentages and let the browser round for widths and gutters to make things work.

    Of course all of those things mean we are giving up some control. When your line height isn’t an exact pixel number, you’re letting the browser decide and do some math. It may not look perfect. When you allow content to drive breakpoints rather than using standard breakpoints, you may have more complicated CSS to maintain. And with grids, as with line heights, when you allow the browser to do some of that work, the rounding may not always end up the way you desire.

    I’ve come to a place of peace with this lack of control, and at times I even enjoy it. The reality is, users ultimately have a lot of control: they can change their base font sizes, they can zoom in, they may even be reading our content in a different application, such as an RSS reader. The user gets to decide how they want to view and use our sites and applications.

    Not everyone I work with is as excited about losing some of the perfection, though. Many would prefer to be more precise with the CSS so that it looks exact in their browser of choice. But doing that would mean not allowing users to have as much control over the experience, and could mean a poor experience for some.

    When confronted with concerns or objections from teammates who would rather have more perfect CSS, I do my best to outline the reasons behind these practices. We need to be user-friendly, future friendly, and accept the “ebb and flow of the web,” so that the things we build can be viewed on whatever device comes along. As Anna Debenham reminds us, many users are grabbing what’s convenient, not necessarily what will give them the perfect experience.

    Learning to be ok with the ebb and flow of things allows us to think differently about how we can work with and use the web. As Frank Chimero writes in his wonderful essay “The Web’s Grain”:

    So, those media queries we write? It might be time to stop calling them breakpoints, and instead consider them points of reassembly.

    As I think about how I advocate for allowing the web to be the web, I’m drawn to Frank’s idea. Instead of making our sketches fit on the web, I’m trying to make our ideas and content work inside the various edges of the web as it appears across a myriad of devices.

    Which brings us right back to what John Allsopp said so well fifteen years ago:

    The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. We should embrace the fact that the web doesn’t have the same constraints, and design for this flexibility. But first, we must “accept the ebb and flow of things.”

    This tension of how we build for the web probably isn’t going away any time soon, but as Paul Ford reminded us last week: neither is the web—it will survive and continue on.

  • Coming May 6: Sass Talk 

    To preprocess or not to preprocess? Every time we run a piece about Sass (which we’ve done a lot of lately), we get tons of thoughtful comments on both sides of the issue. Here are just a few:

    There is no ‘dark side’ to pre-processors… Writing CSS Vanilla on a website with a large scale is just asking to be a maintenance nightmare in my eyes.
    Iain Spad
    I like writing vanilla CSS. It lets me have an intimate relationship with the code and it means I know everything that’s happening and why.
    garek007
    It’s not just garbage in, garbage out. It’s garbage in, 10x garbage out. But, used wisely, such tools are very valuable.
    Matthew Gifford

    Our next ALA: On Air event will continue these conversations. Join us on May 6 as our panel cuts through the clutter and shares how they’ve chosen to incorporate (or not) preprocessors and task runners in their work.

    Event details

    This event is free and everyone is welcome—but you have to register to participate in the Q&A. Here are all the details:

    Wednesday, May 6
    1–2 p.m. EDT
    via Google Hangout
    Register or get more details

    We’ll have 30 minutes of conversation between our panelists, and then open things up to questions from attendees. Like we did with our last event, “Designing for Performance,” we’ll also share the full video and transcript after the live show ends.

    Join our email list to get updates when new events, videos, and transcripts are posted.

    The panelists

    We’ve rounded up a few brilliant ALA contributors to participate:

    Big thanks to Pantheon

    Putting on events is a ton of work, and we couldn’t do it without the generous support of our sponsor Pantheon. Sign up for a demo to see Pantheon’s unified platform for building, launching, and running Drupal and WordPress sites.

  • Lyza Danger Gardner on Building the Web Everywhere: WAI-finding with ARIA Landmark Roles 

    Recently, as part of my research for a presentation about web accessibility for non-specialized teams, I asked around about how people were applying the HTML role attribute in their day-to-day web practice.

    Their answers didn’t surprise me. Many expressed chagrin at their apparent ignorance, admitting they copied and pasted examples a lot. Some had a passing familiarity with a few prevalent roles, but sensed beyond that a gaping chasm of things they didn’t know. The prevailing tone was guilt. It’s not that people don’t care about accessibility, it’s that the topic can feel overwhelming among all the other priorities we have.

    I’ve noticed a lack of easily-Googled, applied documentation for certain technologies or practices. On one end, we have specs, sometimes exhaustive. On the other end, we have a smattering of implemented examples. Synthesized documentation can be thin on the ground.

    I can’t change the world, but I can add some analytical documentation about something specific: my nutshell-in-a-nutshell view of landmark roles in WAI-ARIA, as I understand them, and as it translates to more easily adding website accessibility to your daily workflow.

    The Accessible Rich Internet Applications (ARIA) suite from the W3C’s Web Accessibility Initiative (WAI) is one piece of the web accessibility puzzle. Now, the first rule of ARIA usage is—I am not making this up—we do not use ARIA (unless we need to). Before you set out to use it, you should already have a solid authoring craft: careful, semantic treatment of content; proper use of attributes and textual alternates; sensitivity to contrast and font sizes. Support for accessibility leads to well-crafted HTML and vice versa.

    How ARIA fits in

    Applied ARIA in HTML is a combination of two things: roles and aria-prefixed attributes. Roles identify an element’s purpose, and attributes describe things about it (properties) and what it’s up to (states).

    ARIA is a gap-filler for HTML semantics. It allows you to be declarative beyond what HTML elements and attributes currently provide, and lets you be explicit about the relationships and meanings of elements on your page. It also provides a mechanism to attach semantic meaning when authors, by perversity or necessity, use non-standard elements to represent other things (e.g. using a div as button).

    The ARIA specification provides a standardized way for browsers and assistive technologies to evaluate HTML documents for people who access and use the web in different ways. There’s a lot to know about ARIA, and we don’t have all day, so today I’m going to focus on one important topic: landmark roles.

    Landmark roles for daily use

    The HTML element attribute role is the piece of the ARIA iceberg most often visible above the waterline, and the chunk of ARIA most immediately recognizable to web builders. <div role=“main”> (or even <main role=“main”>) may be familiar to some of us.

    main is one of a set of eight defined ARIA landmark roles. All defined roles express an element’s purpose, but landmark roles serve as key milestones, allowing AT (assistive technology) to map the lay of the land of an HTML document. This is why they’re a great set of roles to start with. Landmark roles make navigation between areas of your page more efficient for different kinds of users. They help convey basic semantic intent and can serve as hooks and helpers for other technologies (or even humans reading your source).

    Here are some landmark roles that can be used on practically every HTML page you write:

    • main: The main content of a document.
    • banner: The main header or masthead of a page; typically assigned to a header element.
    • navigation: A collection of links for navigation. A common usage is <nav role=“navigation”>.
    • contentinfo: A collection of metadata, copyright information and the like. Commonly applied as <footer role=“contentinfo”>.

    Those other landmark roles

    There are two further straightforward landmark roles you might be interested in: complementary—a chunk of content that supports main but remains autonomous, and search—an element containing your site’s search interface.

    The application landmark role should be used with care, so read up first if you want to use it. form is also a landmark role, but arguably redundant if you use it on a form element (doesn’t <form role=“form”> seem repetitive?).

    When are roles redundant?

    Here’s where it gets foggy. I’m arguing that <form role=“form”> is redundant and yet suggesting <main role=“main”> (or maybe <div role=“main”>) is good practice. What gives?

    Roles are semantic extenders. One of the things they do is provide training wheels for semantic elements that don’t exist or haven’t been adopted fully by all browsers.

    It’s safe to anticipate that all major browsers know what a form element is—its role is implicit in the element itself. This is less reliable, however, with the main element. Presently, Chrome and Firefox require <role=“main”> on an element to make the semantic role available to assistive technology and IE is all, main? Never heard of it. So we role on until broad adoption.

    Though I lean slightly toward not using <form role=“form”>, there are varying and vigorous views on this (and other aspects of ARIA). Don’t take my opinion as fact.

    Where to next?

    I talked about documentation being thin on the ground. That’s not untrue, but it gives short shrift to some fabulous efforts. There are some killer resources, like a11yproject.com’s accessibility checklist. That’s exactly the kind of applied reference web generalists need. Analytical documentation targeted at web implementors isn’t completely absent, although there seems to be a scarcity of it compared to other topics.

    There is far more to ARIA and accessibility. While landmark roles are a great place to start, your growing understanding may lead you to other kinds of roles (there are four categories, of which landmark is one) and to aria-*prefixed state and property attributes.

    What I’ve talked about here only begins to scratch the surface. But even if all you do is commit to using some of the ARIA landmark roles in your HTML, I am a happy person.

  • 15 Years of Dao 

    John Allsopp’s prescient essay is about the tension between the culture of print design and the culture of web design, circa 2000. That tension persists—not just between print and web, but between people who see the web as a publication medium and those who see it as a software development medium. It persists between people who see the web as a media delivery platform and those who see it as a software experience framework. We are still fighting the same fights—not just over text, but also over video, audio, interactive content, CSS minimizers, grid systems, and JavaScript frameworks. The HTML5 standard is nearly as long as Infinite Jest, so there’s a lot to discuss.

    The last 15 years have taught me that dynamism is in the eye of the beholder. My sensible publishing pipelines might look like digital chaos to a traditional print publishing person; their well-organized process looks fragile and balky to me. What I’ve come to understand is that all of us who work as craftspeople in digital media, whatever media or technology legacy informs our work, are seeking the same thing: order. Our audiences may want novelty, argument, gossip, and frolic, but we need order in order to deliver these. Standards bodies, licensing organizations, CMSes, character encodings, commercial software, venture-backed startups, shared spreadsheets—those are the tools we are using, as a culture, to prototype new cultural patterns along more orderly lines.

    I don’t know if the issues raised in “A Dao of Web Design” can ever be resolved, which is why the article seems so prescient. After all, the Tao Te Ching is 2500 years old and we’re still working out what it all means. What I do believe is that the web will remain the fastest path to experimenting with culture for people of any stripe. It will still be here, alive and kicking and deployed across billions of computing machines, in 2030, and people will still be using it to do weird, wholly unexpected things.

    Paul Ford, Writer


    I first read John’s “Dao” essay when I chanced upon ALA while researching web development to set up the long-gone “glasshaus” book publisher. I’d read lots of boring stuff about ASP, PHP, ColdFusion, and lots of stuff about “creating killer websites,” but nothing that helped me understand what the main defining aspect of web development was. And this was it. John’s ideas of flexibility being a feature led me to become interested in accessibility—our inaugural flagship book was the first book on web accessibility, and it launched my career.

    I read “Dao” again regularly and love pointing the new generation of web designers to it—the siren song of pixel-perfect designs that only look great on an iThing still seduces and deludes today.

    Hence, the essay is still important now; it hasn’t aged at all. Just like its author.

    Bruce Lawson, Open standards advocate at Opera


    As American philosopher Dominic Toretto once famously said, “The thing about street fights…the street always wins.” For years we waged a fight for control over the web. We tried imposing our will upon it. We tried taming it. We complained that it wasn’t bending to our will. We were idiots. John Allsopp understood this before many of us. The street always wins.

    Mike Monteiro, Design director at Mule


    Markup is music. A Beethoven piece or a Metallica song will be the same—and not be the same—when played by an electric foursome or a full orchestra. Amazingly, “Dao” is more relevant 15 years later with the rise of mobile and true multiplatform content consumption.

    Brian Alvey, CEO of Recurrency


    As designers, we often focus on the rituals of designing for what is.

    Devices that have been introduced since this article, like smartphones, tablets, and the Apple Watch, arise and we immediately seek to force our existing realm into it. To design “for” it with precision and refinement. Make the web work here!

    While this approach is a necessary step, these devices are a bridge between what is and a future not yet realized. Devices like these gently nudge us into new behaviors, new ways of thinking and doing. John is exactly correct when he writes about letting go of control to become flexible.

    Jaimee Newberry, Advisor, trainer, coach, speaker, writer


    I often revisit John’s article when I need a reality check about what the heck we’re all creating here. Or after I’ve been sobbing, gently, because of browser inconsistencies. The more people read it—and really understand it—the better the web will be.

    Dan Cederholm, Cofounder and designer of Dribbble, founder of SimpleBits


    I wonder if I ever would have read John’s brilliant article had he titled it, “Click here to find out 10 things you thought you knew about the web that will still be completely true in 15 years! You’ll never guess what happens next!” I’m not sure. However, I am sure the “Dao” was a great read then and it’s a great read now, even if it isn’t top clickbait in 2015.

    Jenn Lukas, Front-end consultant


    Standing the test of time in a world defined by a dichotomous amalgam of ephemerality and persistence, a platform driven by an unrelenting pace for evolution, John gave us the intellectual building blocks for a generation to grow up with access to the web as a given, and a framework by which to do right by the web itself, no matter what imaginative new idea we create for it.  “A Dao of Web Design” continues to inspire and be relevant.

    Faruk Ateş, Creator of Modernizr


    I had never read this. I had never seen this. I think this must have been published just before I started to look at the web seriously. (From 1996 I had been looking at it quite playfully, with reverence, but never with seriousness.)

    But, like I said: I had never read this. And I opened it now expecting just to peek. You know, glance and then close the tab. I read it all. It’s a wonderful article. It’s incredible to think about how myopic our universe was back then (as always is the case), how disjointed all the rendering technologies were, and how the biggest device discrepancy was a Windows display at 96 dpi or a Mac at 72 dpi. And yet everything holds true—even more so in an age where there is no way to anticipate screen size, dpi, or context. The magic of the web today is that it’s accessed by every kind of device—now ranging in the tens of thousands of variants at the least, scaled up from a mere two. The only way to build for such a thing is to be adaptable. And here is Godfather John, 15 years ago, telling us precisely how to build and think for the chaos and grandeur of the web for which we build today. Thanks, John, for putting this clear and critical stake in the ground so very long ago.

    Craig Mod, Writer and designer


    The future was already all there, written down in front of us—we just couldn’t see it yet. John knew, though. Accessibility, relational font sizing, “adaptive” design—and this was 15 years ago!

    Daniel Bogan, Senior software engineer at Zendesk


    For me there’s more to “Dao” than flexibility. This passage sticks out:

    Think about what your pages do, not what they look like. Let your design flow from the services which they will provide to your users, rather than from some overarching idea of what you want pages to look like. Let form follow function, rather than trying to take a particular design and make it “work.”

    Over the 15 years since John’s article, we’ve seen the call for function over form, content over creativity, taken to an extreme, where much of today’s web design lacks the spark of an idea that makes what we do memorable. Ideas still matter, and the look of websites matters, too, to communicate ideas about a product or a service or a brand.

    Making a website “pretty,” understanding layout, seeing typography—really seeing it—and creating color palettes that evoke emotions are skills that designers should be proud of.

    If John were writing “A Dao of Web Design” today, I’d ask my friend to remind his readers that the web is a medium for communication outside of “function.” That it’s a place for creative experimentation as well as for “services.” That it’s all these things and more.

    Andrew Clarke, Art director and designer at Stuff and Nonsense


    I went to school to learn how to control everything about design: typography, color, layout, distribution, medium, and context. Design concepts are difficult to understand without building a mastery of the tools and medium. John Allsopp’s article suggests that web design is a paradox: in order to have control of the web, you need to let go of trying to control it.

    What makes this piece enduring is that it is not just about practically designing for the web, but also about being a web designer. Flexibility, adaptability, and accessibility are not just the attributes of good websites; they’re also what makes a good designer and teammate.

    Samantha Warren, Independent designer


    Like everyone else, I started my HTML markup days trying to wrestle with how to make it do my bidding. Reading over John’s essay now, I shudder to remember the pixels versus points versus font sizes debate, or the thicket of issues related to color cross-platform and early stylesheet implementations, and the whole <em> versus <i> question, but the core message still shines. Flexibility is key, and not just with respect to one design, but the possibility that a well-structured markup document can have potentially infinite actual expressions, each the result of an interaction between user preferences, browser capabilities, and gentle suggestions on the part of a designer willing to embrace a myriad of possibilities while appreciating that constraints drive creativity. Web designers don’t do one design, they do thousands, even within the same page or template. That “Dao” predates CSS Zen Garden or progressive enhancement or responsive design by several years is a testament to Allsopp’s deep understanding of what for me is the core characteristic of web design. That he wrote it so soon after the browser wars and before widespread and reliable CSS implementations is a marvel.

    Steve Champeon, Lead researcher for Enemieslist


    We once took the tropes of print design and tried to apply them to the web. I fear that today we run the risk of treating web development no differently than other kinds of software development, ignoring the strengths of the web that John highlighted for us. Flexibility, ubiquity, and uncertainty: don’t fight them as bugs; embrace them as features.

    Jeremy Keith, Shepherd of unknown futures at Clearleft


    When “A Dao of Web Design” was published, I was a computer science student and I didn’t build websites. But this article must have settled in the back of my mind, because when I started creating websites, I did my best to make them fluid and accessible.

    Afterward, every time I had to use fixed widths for some reason, I felt like I was cheating on the web—like I was doing something wrong.

    Every time I teach web design to a new class, I cite this article to my students (who are graphic designers) to highlight the differences between designing for the web and for print.

    Valeria Brigatti, Founder and creative director of Italian A List Apart


    John’s piece came three years before Steve Champeon coined the term “progressive enhancement,” but it clearly and succinctly outlined its philosophy: “Make pages which are accessible, regardless of the browser, platform or screen that your reader chooses or must use to access your pages.” His insights—published a mere decade after the invention of the medium—still influence the work I do to this day.

    Aaron Gustafson, Web standards advocate at Microsoft


    When “Dao” was first published, I wasn’t interested. I had no patience for it. I was too busy trying to make the web conform to my perfect and immutable designs. While it’s no surprise that 15 years ago I was dead wrong, it is pretty amazing to see how right John turned out to be.

    Jim Coudal, Founder of coudal.com


    John Allsopp’s essay rings true even today. I think to take it a step further would be to include printed pages in the scope of flexibility that web designers aspire to. My most challenging projects in recent years are the ones that run the gamut from screen to print—enabling people to create sophisticated print counterparts to their web creations from the same source file.

    Rebecca Malamud, Founder of Point B Studio


    If you’d told me 15 years ago that my pocket would contain a supercomputer powered by the web, I’d have thought you were crazy. Yet here we are: the flexibility of the web is enabling another wave of technological growth. And just as we fretted over content moving from the inflexibility of paper to our unbounded browser, some are concerned with apps becoming predominant. None of us knows how the next decade and a half will play out, but I feel certain the web will continue to find new and exciting ways to deliver content.

    I just hope that I’ll still be able to enjoy my printed paper with a cup of coffee on Sunday morning.

    Craig Hockenberry, Partner at Iconfactory


    Designing for the web has always felt a bit like a double-edged sword. You don’t have complete control over every pixel, which felt like a limitation to me for a long time. But over the years I learned to embrace its flexibility, and to turn this limitation into a creative challenge. The web has never been as flexible as it is now.

    Veerle Pieters, Founder of Duoh.com


    The most elusive and often most desirable aim of any creative work is to remain relevant far beyond the period for which it was created. “A Dao of Web Design” is one of the very few documents in the volatile trade of technology that bears relevance not just a couple of years after its creation, but 15. 15! That’s an astounding testament of wisdom attributable not just to the document, but to its creator, too.

    Cameron Moll, Founder of Authentic Jobs

    “The web’s greatest strength, I believe, is often seen as a limitation, as a defect. It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility, and produce pages which, by being flexible, are accessible to all.”

    John’s insights are as sharp and relevant as ever, especially when we realize the web’s inherent flexibility isn’t just about layout—that, in fact, layout flexibility is one of the web’s least important features. I try to reread “A Dao of Web Design” at least once a year. You should, too.

    Eric A. Meyer, Cofounder, An Event Apart and author of CSS: The Definititive Guide


    15 years ago, I was struck by the poetry and simple truth of “A Dao of Web Design.” Little did I know that not only would the article still be relevant a decade and a half later, but it would essentially become our primary job. If there is one underlying theme to what we do for our clients, it is helping them let go of their perceived control and building a web that embodies the principles John espoused.

    Jason Grigsby, Cofounder of Cloud Four


    The web has changed a lot in the last 15 years, and in that time we’ve learned that embracing the web’s flexibility really is a requirement to do our jobs well.

    The tension between wanting control and at the same time realizing we don’t have it drives us to come up with creative design solutions. It’s a big part of what makes working on the web interesting to me. The journey, as John so aptly calls it, is ongoing.

    Val Head, Designer and author


    15 years ago, the “Dao” encouraged web designers to find harmony around the inherent characteristics of the web, which posed distinctly different problems than print design. There is a great deal of energy currently being spent on redefining those characteristics in response to today’s shiny new problems—juggling complex data, enabling real-time communication, supporting multi-device interactions. Opinions about where the web is going next, and the frameworks and tools to get us there, arrive at a fast pace. But in a world that contains so much that is new and shiny, we must be careful not to misidentify our projects as different than what has come before—when more often than not we are still building for the web described by the “Dao.” A web of living documents, not living data.

    Chris Casciano, Director of interface development at The Line


    It’s very rare that a post withstands the test of time and becomes even more clairvoyant as it gets older. At the time, the “Dao” challenged all of our tools, assumptions, and addictions to pixel-perfection. But here we are, 15 years later, clinging to its advice like a prodigal child. I’m sure that web design has many more twists and turns in its future, but to me the “Dao” also lends testimony to thoughtful blogging: our ideas can find life and inspire over and over again in ways we could never imagine.

    Dave Rupert, Lead developer at Paravel

      “What I sense is a real tension between the web as we know it, and the web as it would be.”

    I think we have moved on to a new tension that consists of the web as we know it and the web as it should be. I know I am being naive and incredibly optimistic to consider the possibility that the web can reflect more of what is highest and most noble about humanity as opposed to what is depraved or vulgar or just plain mean. Let’s envision a day where we can see the world through this taoist precept: “From wonder into wonder existence opens.”

    Debbie Millman, President of Sterling Brands


    Because of foundational advocacy and application (through practices like progressive enhancement and responsive design), the web is more adaptable today than it was 15 years ago. With easy-to-use templating frameworks, it’s easier than ever to provide flexible layouts.

    Unfortunately, over the last 10 years, we’ve seen the open system that is our internet fenced in—made less adaptable through design. The protocols are still open—HTTP, SMTP, etc. However, the designers of systems like Facebook and mobile apps decide how we can share (or not) with others. So, in many ways it feels like we’re going backward to the days of AOL and CompuServe.

    I <3 the internet because it connects people and changes our perspectives and, thus, our minds. Through embracing adaptability (and openness), we unleash the power of the internet and ourselves.

    Heather Hesketh, Founder of hesketh.com


    John’s brilliant piece asks us to stand back and look at our work in a fresh way each day: questioning, yielding, breaking down walls, and always learning. Rereading it always inspires me to be better at what I do. He helped show us a critically important path: we can always be more of a community than an industry—even when commerce is what allows us to stay. The web is information, but the web is also communication. This “Dao of Web Design” is part of what makes us truly love what we do. As the web becomes a rant machine, a fire hose, a tool of oppression, an industrial outlet, beneath it runs the quiet river of the “Dao”—urging us to preserve what is beautiful and radical about creating the web and nudging us toward humility, empathy, and inclusivity. It’s about more than code: it’s a call to make an open web for every person on earth, to empower us all and allow every voice to be heard.

    Carolyn Wood, Copywriter, brand/content strategist


    “Dao” challenged me to look at accessibility and limits in a completely new way. No longer could I focus on just removing barriers for people with disabilities. I became an advocate for deeply satisfying design for all users, refusing to let the limits of accessibility restrict the experience for users without disabilities.

    Glenda Sims, Team A11Y lead at Deque Systems


    Accessible design is design for everyone. And if there’s anything that embodies the true essence of the web, regardless of metaphor (the page or whatever), it’s this guardianship each of us inherits when we design things for people. In spite of the caprices of technology and taste, we can still control how broad our understanding is. And that’s what I strive for, anyway—honoring my guardianship. If I can do that with sincerity, then I think I’ve done the web right. This is the lesson I learned from the “Dao,” and one I hope it continues to teach, gray-haired as it is now.

    Michael L Johnson, Design director, Happy Cog


    We no longer worry about browsers with insufficient support for stylesheets, or the difference in dpi between Mac and Windows. Making a site appear identical everywhere finally bit the dust with the advent of the iPhone.

    We’re still working on making sites more accessible and adaptable—which is what really matters.

    While the minutiae of web design have evolved over the last decade and a half, the goal—the road—the way—the “Dao” itself—has not changed. We’re further down that right path, and “A Dao of Web Design” helped illuminate the map.

    Dori Smith, Author and programmer


    “A Dao of Web Design” outlined a philosophy that today holds more true than ever.

    Just as art imitates life, accessibility—the very foundation of the web—is direly needed beyond the web. It’s not only the guiding principle for interactive experiences on both smartphones and big-screen TVs, but for our societal development.

    In a world where 1.3 billion people still lack access to energy, social networks are blocked at the whims of leaders with dictatorial ambitions, net neutrality is at serious risk, and a gazillion frameworks and conflicting standards are in use for web development—a relentless focus on accessibility (to energy, information, entertainment, different devices) will make sure that everyone is included.

    We build the world we live in. Let’s make it accessible to everyone!

    Pär Almqvist, Chief marketing officer at OMC Power, Owner and creative director at Cultivat3


    I remember reading John’s article when it was first published and emphatically exclaiming “YES!!” to the idea of embracing that the web is not a fixed medium, unlike any of the dead-tree formats we have. Designing and building with flexibility in mind from the get-go helps ensure, and may even be critical to, transformability. That transformability may be represented by a simple change in browser viewport width, or containers that respect text resizing, or something more complex like text-to-speech from a screen reader, or completely overriding the author’s style suggestions with a user stylesheet. To me, when we design with flexibility and transformability in mind, we’re making a statement: that we believe the web is for everyone. John’s article and thinking helped set that fundamental belief for all of us in this profession.

    Derek Featherstone, Team leader and founder at Simply Accessible


    Although there’s only one web, it appears in many guises. Every browser/OS-combination is one such guise, and it frequently gets more complicated than that, especially on Android. Our job is to accommodate all of them.

    Too many people new to web development (and that not only means new programmers, but also people coming from server-side programming) think they create an application for the web platform, singular, while in fact they create it for web platforms, plural.

    Most other types of applications run in only one single environment, or at most a few. Not so the web: it runs in more environments than you can imagine. This is the next lesson we must learn. We work in many browsers, not in the browser. We run our apps on many web platforms, not on the web platform.

    Let go of the singular. Embrace the plural. That’s what the “Dao” teaches me.

    Peter-Paul Koch, Owner, QuirksMode.org and author of The Mobile Web Handbook


    It used to be that only forward-thinking web designers—the kind of people who read A List Apart in 2000—cared about designing sites that took advantage of the medium. Now, responsive design is taught to beginning web designers, and clients and users expect it.

    A fundamental next step is making our content responsive, not just the design. We’re starting to see this with things like Google Maps, which assembles a map on the fly based on your zoom level and viewport orientation. Personally, I’m trying to do it with music notation. And I want to see somebody do it for text—trim unneeded words and sentences depending on the reader’s knowledge or allotted reading time.

    Responsive content is a harder problem than responsive design. It’s about algorithms, domain-specific knowledge, and something approaching artificial intelligence. But when we get there, it’s gonna be great.

    Adrian Holovaty, Django co-creator, developer at Soundslice


    I feel like every conference talk I give these days is a variation on principles articulated in “A Dao of Web Design.” It comes up on most episodes of The Web Ahead. We are inventing a powerful new medium. What a crazy journey and privilege. And yet we don’t fully understand this thing, even two decades in. We still attempt to design sites like they are print publications, using software from print design, drawing on paper of a fixed size with hard edges. In a new trend, teams manhandle the web with JavaScript, attempting to make it behave like a single-platform application environment.

    Despite the passage of 15 years, the vision John articulated is more relevant than ever. We have more success on the web when we remember that the web’s strength comes from its inherent interoperability. The web was built to work on a wide range of computers and screens, across an extremely wide range of input and output options—across time itself. A website is a dynamic creature. Your content will morph in all sorts of unpredictable ways. John’s prescient article inspired us to lean into these qualities of the web. Not to fight them.

    (Note: Eric Meyer and I interviewed John Allsopp for The Web Behind, where we talked about “A Dao of Web Design.”)

    Jen Simmons, Host and executive producer of The Web Ahead

  • Designing Social Tools for Tweens 

    Designing any type of online social experience for kids is a tricky business. You need to strike the right balance between fun and private, personal and respectful. This becomes especially important for kids in the tween years, ages 8–12, as they are just starting to recognize the vastness of the online space. In my years of designing and researching with kids of this age group, I’ve found that the best way to design for these types of interactions is the FRESH method:

    • Fast
    • Rewarding
    • Easy
    • Safe
    • Human

    Let’s take a look at what that means in practice:

    Fast

    Kids and tweens are busy. Between karate class and soccer practice and music lessons and sleepovers, they’re always on the go. So when designing social interfaces for these folks, you’ll want to make sure that all interactions can happen quickly. This is an important differentiation from other types of games and apps for kids in this age group, where speed plays less of a factor. In my experience, I’ve found that kids generally like to take it slow with their screen time, focusing on every tap and click, enjoying the journey as they go. Not so for social interactions. These kids aren’t laboring through Facebook reading status updates and playing games, they’re taking photos and videos on Instagram, sharing them, liking them, and editing them.

    Why is speed an important consideration for social interactions? Because, like adults, kids think of socializing as an “in the moment” type of construct, where they capture ideas, thoughts, images, and interests in real time and share them, much as they would in person. In fact, apps like Vine and Instagram have started serving as a secondary “lunch-tables” where kids communicate with each other and comment on each other’s experiences.

    When designing these types of social tools, focus on the quickest path to sharing. Can you do it in one click? A single tap? Can you tighten the sign-in flow so it feels secure (safety is also important for kids) yet resolves quickly? These are important considerations for kids as well as adults.

    Rewarding

    This “R” could just as easily stand for “rush,” as in adrenaline. Kids as young as six are drawn in by the allure of online interactions, and love the excitement that comes from sharing something online that could be seen by thousands of people, if not more. The irresistible forces of seeing and being seen prove even more compelling as kids get older and more aware of their place within the world around them.

    You can ensure the systems you design for kids are rewarding by throwing in some extras, not to slow down the process, but to heighten the excitement. For adults, the excitement comes in seeing the results of what they share, but for kids, the excitement comes from the sharing itself. Make that “share” button big and bright and enticing. Throw in some crisp, catchy text while the image or comment is loading, like, “Your genius is being shared!” And, when the upload is complete, choose cool, branded imagery as well as text to communicate the greatness of the child’s accomplishment.

    Easy

    Sounds like a no brainer, right? Social systems have to be easy to use. This is especially true when designing for tweens, however, because they have no patience for tools that are hard to learn. When designing for adults, we can sometimes get away with more complex online social interactions, because the value proposition of communicating online is much higher, especially when it’s for business, finance, or medical reasons. Since there are few “make-it-or-break-it” situations like this for kids, where they absolutely, positively have to get it right, they’re quicker to abandon tools that seem hard.

    An exception to this is when kids are joining an existing online community that their friends are already using. In that case, they’ll be more likely to put the work in to figure out how to use it.

    Safe

    Unlike teenagers (and some adults), kids ages 8–12, for the most part, are focused on online safety. They don’t want to remain anonymous, necessarily, but they don’t want strangers to be able to find them or comment on what they share. This concern for safety likely comes from the admonitions of parents and teachers—usually starting around second grade when kids have more independence online—to “be careful,” “stay safe,” “pay attention,” and, the scariest, “go find a grownup if someone makes you feel unsafe.” When kids get a little older and figure out how to navigate the online world, they tend to be more carefree, and when they become teens, they start taking deliberate risks.

    When designing social experiences for these tweens, set up all defaults to “private,” and then allow kids and parents to make changes on a case-by-case basis. Want to share a photo with grandparents? Select their email address from a list (or enter it and save it for future use). Want to share with friends? Enter their usernames (most kids under 12 won’t have an email address, and if they do, they won’t know it offhand). Want to share something with a wider audience? Remove everything but your first name and location. Don’t want negative feedback? Remove commenting ability. This will make kids as well as parents feel more comfortable with your tool.

    It’s also a good idea to not allow tweens to be “findable” within a system, meaning that they have to share their actual usernames with their friends to get connected. These guidelines work if you’re designing a system to be used by both kids and adults as well.

    Human

    When you’re designing an experience that allows for any type of sharing, make sure you focus on positivity and eliminate any perception of judgement or negativity. Even a basic system that allows for simple “likes” or “thumbs-up” can be problematic, as kids take it very personally when, in their mind, they don’t get enough likes. Take a humanistic, communal approach when designing for these folks. You can show users the number of people who have viewed their image, post, or comment, but don’t allow others to judge the quality of the item. It’s best to remove anonymous feedback mechanisms for kids, as people tend to be more positive in their feedback when their comments can be traced back to them. 

    For some good examples of tween-friendly social design, check out apps like Storybird, DIY, and Poptropica. Designing social components for kids, especially ages 8–12, is a slippery slope. It’s always best to get user feedback early and often while designing any type of interface, but using this FRESH method as you design will help you focus on the most important aspects of social interaction that have meaning to kids at this age.

  • Initiation to Code 

    When you imagine a programming mentor, certain archetypes might flash into your mind. Maybe you see the wise monk who’s meditated on design patterns for decades. Perhaps it’s the sophisticated keynote speaker with a staggering list of open source contributions. Or it might be that mad scientist polyglot obsessed with a dozen languages you’ve never heard of.

    But if these characters aren’t on your team when the new hire straight out of school joins up, who’s going to take the reins of training?

    You, of course.

    With the rise of coding boot camps and increased enrollment in computer science courses at universities, the pool of junior developers is larger than ever. But when it comes to nurturing all this talent, many teams don’t know where to start. Some developers think they don’t yet know enough to be a good mentor, while others think they’re just too busy for it.

    Whatever your initial reservations may be, you can mentor, and you can do it well. All you need are the right guidelines and a little bit of structure.

    Starting the mentor–mentee relationship

    When you’re seeking a mentee, look for “someone who has something to teach you, but doesn’t know it yet,” as a friend of mine who mentors at RailsBridge recently suggested.

    I take this to mean two things. The first is to stay open to a range of personality types. Look for a mentee who’s not similar to you. It can be tempting to compare juniors to yourself-three-years-ago and jump to conclusions from there. But mentorship is a two-way street—it’s not about lecturing. In fact, it’s not even about passing your knowledge down to another person. It’s about making a mutual agreement to get better at what you both do. You’ll learn more from each other if you have different ways of thinking.

    The second is to choose someone you want to learn from. If your mentee isn’t the type of person you’d be happy to march into code battle with, you won’t get anywhere. The primary quality to avoid is arrogance; an arrogant person will have a slower rate of growth than someone who takes feedback gracefully.

    Because team dynamics are constantly in flux, you might not often establish formal mentor–mentee relationships with people on your team. That doesn’t mean you won’t find opportunities to mentor. Look for little moments to step in and help; you’ll be viewed as a leader, and more mentoring opportunities will begin to materialize.

    Agility is the key

    The key to being a good mentor is a concept you’re already familiar with, since it’s also the key to developing good software and learning new information effectively. That key is agility.

    Of course, “agile” has become a pretty loaded term that tends to confuse more than it clarifies. In a 2014 blog post, Dave Thomas, one of the original signatories of the Agile Manifesto, acknowledged this confusion. Then he reminded us how to do anything in an agile fashion:

    • Find out where you are
    • Take a small step toward your goal
    • Adjust your understanding based on your goal
    • Repeat

    Or as the Scrum Guide puts it: “inspect and adapt.” Inspecting and adapting are foundational to being a good mentor. If you don’t take the time to check up on your mentees and listen to their concerns, travails, and triumphs, then you will have no metric for achievement.

    Employing agility as a mentor requires sensitivity, creativity, and solid communication skills. It also requires the foresight to see what your mentee should be aiming for, and the hindsight to see what your mentee has already accomplished.

    To establish a framework for gauging your mentee’s progress, consider the three phases every new team member goes through in some form. The first phase is total unfamiliarity and constant discovery; the second is a transitional period with a clear trajectory of progress; and the third is self-driven competence. In all three phases, remember that agility remains your most vital tool.

    Phase 1: a little respect

    On the very first day, have a conversation with your mentee in which your goal is to discover exactly what their level and type of experience is right now. This conversation serves a dual purpose. First, it establishes a two-way discourse, a communicative relationship that will underpin your agile approach to mentorship. Second, it gives you a basis to decide what to assign to your mentee first. Starting off with a direct conversation can prevent an incredible amount of confusion and wasted time.

    Pair programming at this stage is pretty much mandatory. It’s far and away the best method for getting a new developer up to speed, especially if you have a large or confusing code base. A recent article by Sarah Mei makes some excellent points about how to pair effectively, but the most salient one is this: don’t touch the keyboard (much). Ask questions, and answer questions with more questions. The closer you are to your mentee’s level of experience, the harder it is to take the backseat approach, since you’re often just figuring things out yourself. But whenever you feel the urge to barge ahead and solve the problem, resist! Your mentee will learn much more effectively in the Socratic style.

    Keep in mind, though, that you aren’t only a technical guide. Early on, gaining technical experience probably won’t be the first thing on a junior developer’s mind—much to their surprise. They’ll be confronted with social puzzles and process nuances that everyone else takes for granted. Clear away confusion over all the things surrounding the work so your mentee has no obstacles to digging down into the work itself.

    As eager as you might be to keep things moving, make sure to be honest about your own limitations, too. Consider phrases like: “I don’t understand this, either.” “I need to take a break.” “I can’t help right now, but try asking Oleg.” All of these can be music to a beginner’s ears. The more truthful you are about when and how you and others can help, the more realistic your mentee’s outlook will be. And a realistic outlook leads to good decisions.

    Phase 2: challenge accepted

    With a solid communicative relationship established, your mentee will quickly move past the green stage. You’ll know that they’re in Phase 2 when they can easily figure out what needs to be done on a ticket, even if they don’t know quite how to do it. This means they’re starting to get comfortable, and it’s also when things get really fun. It’s time to add challenge to the mix.

    Whatever you do, don’t simply assign your mentee whatever happens to come up. Instead, inspect, adapt, and select assignments that build on what your mentee has done before. If possible, try to tell a story with your assignments. Something in the next ticket could elaborate on or reinforce a concept from the previous ticket. Or you could tell the story of a single request, from UI to database and back again.

    If you must assign your mentee something that looks relatively simple, use it as an opportunity to train them in looking at code with a pessimistic eye. What would a null input do? Does this open any vectors for attack? Could you have refactored another component to make this change easier? Do your tests cover all the new code? Even if your mentee decides that the code is airtight (which it never is), they’ll exercise their programming muscles trying to answer your questions.

    While you challenge your mentee at every turn, don’t forget to take a lot of opportunities to encourage. A task that seems routine to you might feel like a triumph for your mentee, so when they finish something, congratulate them. And never underestimate the power of a simple “Good job.”

    Phase 3: the initiation game

    Your ultimate goal is to transform your mentee into a productive, contributing team member—an equal. With enough time and practice, they’ll eventually get there. But why wait? There’s a better, faster way. When your mentee is ready, you can help the transition along with a tool as old as humankind: initiation.

    No matter who you are or where you’re from, you’re familiar with the narrative of initiation. Joseph Campbell identified it as one of the major elements of the hero’s journey, the underlying pattern shared by epic tales all across the world. From ancient mythology to pop culture mainstays like Star Wars and Fight Club, initiation stories have taken countless forms. The framework, however, is always the same: a harrowing ordeal that, if survived, yields the initiate to a new and higher level of awareness.

    Initiation isn’t just for epic heroes. It’s a powerful tool for transformation in any context. When you feel your mentee is ready to take a big step, assign a task that seems a little too complex, a little too far outside the scope of what has been done before, and just difficult enough to accelerate the transition into an equal, independent team member.

    An effective initiation for a software developer should have three qualities:

    1. It would not be trivial for someone with a few more years of experience.
    2. It demands communication with senior-level people. Ideally, the mentee will gain some insight into the factors that go into a high-level technical decision. Overhauling a UI component, modifying your deployment architecture, or hand-rolling a new caching strategy are all good candidates for this type of experience.
    3. It has a demonstrable, preferably quantifiable, value. It might be a new front-end feature, or it might be a graph that shows a decrease in page load time, but ideally, your mentee will be able to point to a visual representation of the change and say, “I’m responsible for that.”

    Often, initiations are accidental, a natural outgrowth of increasing experience and responsibility. But if you do set up a conscious initiation for your mentee, you don’t need to tell them that you’re doing it. In fact, you probably shouldn’t. Show your mentee you believe in them by treating them like a regular engineer.

    If the initiation is successful, your mentee will become an equal—though an equal who still has a lot to learn. They’ll be able to drive their own progress without much hand-holding, and pairing sessions will feel more collaborative than instructive. After this transition, you can take a big step back, but continue to guide and challenge when necessary. After all, as Robert Anton Wilson said, a true initiation never ends.

    Mentoring benefits the whole team

    When I first joined my team, I was the only junior developer. Now, our membership has grown and shifted, and almost half of us are juniors.

    I’ve seen firsthand how much this shift has changed our dynamic for the better. Experienced engineers pose questions to the juniors, motivating them to refine their knowledge—and the juniors pose questions right back. Instead of a couple good communicators bearing the brunt of training, everyone is actively skill-sharing all the time. Where once individuals were siloed, there’s now a spirit of collaboration and fun. Willingness to learn and adapt has become a core value for the entire team.

    It has also observably driven up our code quality. Fresh eyes are great at identifying anti-patterns, style issues, and confusing bits of code. With a healthy mix of juniors, we’ve become better at balancing technical debt repayment and pushing out new features, and the new code we merge is easier to maintain. Without mentorship, these improvements would never have come about.

    Software engineers are fortunate to work in an industry where the tools and processes for collaboration are both well-defined and popular. But to paraphrase the Agile Manifesto, it’s the people and interactions that really make or break a product. Mentorship is a powerful interaction that, done right, can elevate your team’s quality of both life and code, and lay the groundwork for a more successful organization.

  • Let Links Be Links 

    The concept of the web as an application platform has never been more popular, but the tools used to create these so-called “web apps” are still fraught with pitfalls that are often ignored or misunderstood. Single-page web app frameworks have gained traction because they can easily be used to create fast, complex applications that feel much more solid and interactive than traditional websites. But this benefit, and the changes in mindset and development practices that accompany it, comes at the cost of basic browser functionality that web developers sometimes take for granted.

    JavaScript can be fragile

    With vendors making it increasingly difficult to disable, we can get lulled into thinking that we don’t need to provide a fallback for users whose browsers don’t execute JavaScript. But explicitly choosing to disable JavaScript is far from the only reason a user’s browser might not run it. Government Digital Service (GDS), the team that maintains the UK government website, found that, out of every 500 visitors to GOV.UK, five did not receive JavaScript, but only one had JavaScript explicitly disabled. The other four could be missing out on JavaScript for any of several reasons: an overzealous corporate proxy server; a request for JavaScript timing out due to high latency; or even an unnoticed syntax error.

    Furthermore, JavaScript—unlike CSS and HTML—does not degrade gracefully. This means that if developers use a single ES6 syntax feature, or even make a single standard library function call without checking that the function has been defined first, their JavaScript could either stop running midway through execution or not run at all. When JavaScript is used to enhance websites, this doesn’t matter so much—visitors can still follow links and submit forms and generally use the web as intended. But when JavaScript is a requirement, anyone using even a slightly older browser is likely to get a blank page—and no explanation of what to do about it.

    Semantic structure is still important

    As designed by Tim Berners-Lee in 1993, HTML defined a common structure for the mesh of interconnected documents we now know as the web. The semantic meanings imbued in this common structure provide machine-readable context for the information contained in a web page. In practical terms, this extra information enables web browsers to enhance the user experience. For example, a web browser can implement a way to add events defined with time elements to a user’s calendar; a screen reader can read through a list differently than it would a paragraph. The difference between a list and a paragraph is clear to human viewers of a document; the common structure provided by HTML makes it clear to computers, too.

    The semantic meaning behind HTML sets the web apart from native application environments like Cocoa, Windows Presentation Foundation, and Qt. Structured information matters more to the web because of the diverse ways in which it can be accessed. When I create an iPhone application, I can safely assume that every person using that application will use it in a similar way. The information my app presents will always be presented in much the same way, and I will always have complete control over that presentation. Even if someone using my app interacts with it through VoiceOver (Apple’s assistive technology for people with vision impairments), they still interact with the application in a similar way to a sighted user: by tapping around on the screen. They just happen to be hearing the text instead of seeing it.

    The web doesn’t work that way. Websites aren’t viewed solely through web browsers. People consume websites through apps like Pocket or Instapaper, which try to use the structured information of a web page to extract its relevant content. A browser on a smartwatch might ignore your layout and present your information in a way that’s more suitable for a one-inch screen. Or—who knows?—your website might be used through some future device that will transform the information into thoughts beamed directly into a user’s brain. Even web screen readers don’t work like VoiceOver does on an iPhone, reading out the text in the order it’s laid out under a user’s finger. Web screen readers read through the whole document, ignoring layout, and infer meaning from the standardized semantic definitions of HTML tags. A simple example of when semantics like this matter is the recently introduced main element, used to define the main part of a document. To a sighted user viewing your website through Google Chrome, whether you use <main> or <div id=“main”> makes no difference. To someone using another web client, though, such as a screen reader or Instapaper, the meaning implied by the main element is very important to their software in helping them navigate your document.

    Developing an application for the web, therefore, is not as simple as developing for a native platform. Making sure it works the way we want it to in the five major browsers and pushing it out isn’t good enough for the web. We need to test our work in screen readers. We need to review our markup to make sure it provides as much semantic metadata as possible—not just for today’s web clients, but for tomorrow’s as well.

    Single-page web app frameworks

    When using “single-page web app” frameworks like Angular and Ember, the trend is to treat websites like native apps, with little regard for the nuances that make the web unique. Developers make assumptions about their users that can seriously damage the experience of people who don’t meet those assumptions. As an example of what this mindset can result in, consider the markup for a login button (since changed) that I recently found on Patreon’s site:

    <span class="patreon-button sub-section navigation-active" data-ng-click="triggerChangeWindow(navigation.login_url)">Log In</span>
    Example of a login button that once appeared on Patreon’s site
    Patreon’s fairly standard login button acts just like a link. No need for special JavaScript here.

    This link works fine for me in Safari, but in any environment other than a current mainstream browser, this button is totally useless. Let’s say we have a hypothetical smartwatch browser called WatchBrowse. Maybe it displays a list of links for the user to navigate through because this particular smartwatch doesn’t have a cursor that can interact with the page. Because HTML defines a standard way to create links on a web page (the a element), WatchBrowse could theoretically just list every a tag on the page with its href attribute and content—until a site like Patreon comes along and decides to shun web standards in favor of reimplementing basic browser functionality from scratch.

    If Patreon had used an a tag instead of a span, WatchBrowse could perhaps find the link and display it in the list. When a user selected the link, it could simulate a click event instead of just using the href attribute. But what about functionality that requires the browser to know where the link is going to lead ahead of time? A browser extension might allow you to search links on a page by their href values, which would be useful if you wanted to quickly find where somebody links to their Twitter account, for example. Firefox shows where a link is going to take me when I hover over it. When link href attributes are no longer static values but are, instead, decided by arbitrary JavaScript in click handlers, these helpful features are no longer possible.

    Patreon’s site is built with Angular, and while Angular is not at fault here per se, the mentality of treating HTML as a view layer that goes along with using these frameworks probably contributed to Patreon’s poor decision.

    What if we created the same link the way the framework developers recommend in their documentation? A more standard way to make a link in Angular might look like this:

    <a ng-href="/login">Log In</a>

    When rendered into the DOM by client-side JavaScript, that snippet turns into this:

    <a ng-href="/login" class="ng-binding" href="/login">Log In</a>

    Ember handles this similarly. A link is defined in an Ember template like so:

    {{#link-to sessions.new}}Log In{{/link-to}}

    And when it’s rendered into the DOM, it becomes this:

    <a id="ember-563" class="ember-view" href="/sessions/new">Log In</a>

    Ember and Angular then intercept the link’s click event to render the new content without reloading the page. Crucially, though, if the click event were never fired and the browser loaded the value of href, there would be no visible difference to the user other than an extra page reload, because Ember and Angular by default don’t try to reinvent the wheel by defining their routing in terms of URLs.

    In their current forms, however, Ember and Angular still require JavaScript to render their templates and create those links in the first place. Four out of every 500 people who visit a website built with Angular or Ember will encounter a completely blank page.

    A solution?

    When dynamic web page content is rendered by a server, rendering code only has to be able to run on that one server. When it’s rendered on a client, the code now has to work with every client that could possibly visit the website. Developers are now moving away from server-rendered websites because they don’t offer the sort of rich application experience that client-rendered sites can provide. But I think there’s still a role for server rendering in the new world of client-side applications.

    At the moment, requiring JavaScript is a tradeoff that developers using single-page web app frameworks have to make, but it seems to me that this is exactly the sort of problem that should be handled by a framework. We are fortunate as web developers in that we write application code for the web in one of the most universal programming languages that has ever existed. If framework developers could put in the effort (which, admittedly, seems large) to get apps running in Node just as they run in the browser, initial page rendering could be handled by the server, with all subsequent activity handled by the browser. Crucially, if a server can render links into a tags, like Ember currently does on the client, it would be possible for a user who did not receive JavaScript (for whatever reason) to navigate around the website. It might be possible to get forms working as well, by running all the validation and submission logic on the server instead of on the client. If this effort could be made at the outset by a framework maintainer, then every developer using that framework could immediately transform an app that only worked on the latest web browsers into a progressively enhanced experience compatible with virtually any web client—past, present, or future.

    Progressive enhancement has been important to web developers for a while now. It recognizes that the vital part of the web experience is content, and that any additional improvement to the user experience should not undermine the universal availability of content provided by the web. Current approaches to single-page web apps tend to abandon this principle, but progressive enhancement and single-page web apps are not fundamentally incompatible.

    In fact, progress is being made in this arena. To improve Ember’s compatibility with search engines, for example, an in-house team is working on implementing server-side rendering. But the solution to the problems caused by single-page web apps is not purely technical: there’s a growing problem in the way people think about the web. It has become commonplace to treat the web as just another application platform—but the web is so much more than that. The web is the universal information platform. It doesn’t matter if somebody visits a website on a $2,000 iMac, or a $50 Android tablet, or the $5 web client of a future we can’t even imagine yet—in theory, at least. In practice, it’s important to make sure that we don’t sacrifice the experiences of a small number of users just so we can slightly improve the experiences of the rest, damaging the universal nature of the web in the process.