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
  • 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.

     

  • This week's sponsor: Beagle 

    Thanks to Beagle​ for sponsoring A List Apart this week. Take a look at their tools to help you save time, collaborate with your team, and create more effective proposals.

  • 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.

  • On Our Radar: Self-Centered Edition 

    Okay, we admit it: it’s all about us. From steps to sleep to social activities, we’re counting every kind of personal data you can think of. But what’s all that data add up to? How could we look at it—and ourselves—differently? This week, we’re asking ourselves—and our self—the tough questions. 

    My so-called lifelog

    While waiting for an invite from gyrosco.pe, which promises to help me lead a healthier and happier life by harnessing my personal data, I started reading about life resource planning: the idea that we can administer every aspect of our lives using our timeline, our life feed, as a tool. LRP isn’t just the lifelogging data gathered by all the apps we use (health, finance, commuting, social graph, etc.). It’s about a user interface to make sense of it—a personal agent telling my story.

    This has me thinking, how can I ever reinvent myself if my life feed becomes part of a documented history? The answer seems to lie in the notion of storytelling, becoming active autobiographers ourselves, using the same tools that tell our history, only to tell it better. When people are prompted to “tell a story” rather than state “what’s on their mind,” a character emerges—a qualified self (as opposed to the notion of the quantified self)—that may defy “big” data.

    Michelle Kondou, developer

    Mirror, mirror

    A couple of days ago, I came across dear-data.com, a project by data visualization pros Giorgia Lupi and Stefanie Posavec. Instead of building digital charts and graphs, they’re documenting details of their lives onto handmade postcards—translating quiet moments of the everyday into colors and lines of self-awareness, and reinventing the rules each week. With a flickering edge of whimsy and objectivity, those moments are real life—through a filter.

    What I love about Dear Data is that their conditions create new filters; they end up with a different view of themselves each week. Getting out of their usual medium and having to create new ways to tell each story is a tactic for hunting down catalysts. I also like how they went to something so square one: paper and colored pens, no expectations to be fancy, no need for neat lines.

    Dear Data has me thinking about how we can all gain momentum from reimagining our digital selves every once in a while—from ditching our habitual means of describing and defining. How I can so easily show myself a new mirror and allow a situation to filter through me—I’d discover a different result each time. Those moments are grounding: they’re a sharp instant of humility, a moment of recognition that you’ll never see anything in the same way again.

    Mica McPheeters, submissions and events manager

    My birthday, my self

    Ah, spring—that special time of year when a young developer’s fancy soon turns to thoughts of lexical scoping, and I’ve got ECMAScript 6 arrow functions on the brain.

    Defining a function as usual introduces a new value for the this keyword, meaning we sometimes need to write code like the following:

    function Wilto() {
    	var self = this;
    	self.age = 32;
    
    	setInterval( function constantBirthdays() {
    		self.age++;
    		console.log( "I am now " + self.age + " years old");
    	}, 3000 );
    }

    Since the meaning of this is going to change inside the constantBirthdays function, we alias the enclosing function’s this value as the variable self—or sometimes as that, depending on your own preference.

    Arrow functions will maintain the this value of the enclosing context, however, so we can do away with that variable altogether:

    function Wilto() {
    	this.age = 32;
    
    	setInterval(() => {
    		this.age++;
    		console.log( "I am now " + this.age + " years old");
    	}, 3000 );
    }

    Thanks to ES6, we can finally start getting over our selfs.

    Mat Marquis, technical editor

    A gif about: self(ie) love

    President Obama using a selfie stick
    Haters gonna hate.
  • Laura Kalbag on Freelance Design: The Illusion of Free 

    Our data is out of our control. We might (wisely or unwisely) choose to publicly share our statuses, personal information, media and locations, or we might choose to only share this data with our friends. But it’s just an illusion of choice—however we share, we’re exposing ourselves to a wide audience. We have so much more to worry about than future employers seeing photos of us when we’ve had too much to drink.

    Corporations hold a lot of information about us. They store the stuff we share on their sites and apps, and provide us with data storage for our emails, files, and much more. When we or our friends share stuff on their services, either publicly or privately, clever algorithms can derive a lot of of detailed knowledge from a small amount of information. Did you know that you’re pregnant? Did you know that you’re not considered intelligent? Did you know that your relationship is about to end? The algorithms know us better than our families and only need to know ten of our Facebook Likes before they know us better than our average work colleague.

    A combination of analytics and big data can be used in a huge variety of ways. Many sites use our data just to ensure a web page is in the language we speak. Recommendation engines are used by companies like Netflix to deliver fantastic personalized experiences. Google creates profiles of us to understand what makes us tick and sell us the right products. 23andme analyzes our DNA for genetic risk factors and sells the data to pharmaceutical companies. Ecommerce sites like Amazon know how to appeal to you as an individual, and whether you’re more persuaded by social proof when your friends also buy a product, or authority when an expert recommends a product. Facebook can predict the likelihood that you drink alcohol or do drugs, or determine if you’re physically and mentally healthy. It also experiments on us and influences our emotions. What can be done with all this data varies wildly, from the incredibly convenient and useful to the downright terrifying.

    This data has a huge value to people who may not have your best interests at heart. What if this information is sold to your boss? Your insurance company? Your potential partner?

    As Tim Cook said, “Some companies are not transparent that the connection of these data points produces five other things that you didn’t know that you gave up. It becomes a gigantic trove of data.” The data is so valuable that cognitive scientists are giddy with excitement at the size of studies they can conduct using Facebook. For neuroscience studies, a sample of twenty white undergraduates used to be considered sufficient to say something general about how brains work. Now Facebook works with scientists on sample sizes of hundreds of thousands to millions. The difference between more traditional scientific studies and Facebook’s studies is that Facebook’s users don’t know that they’re probably taking part in ten “experiments” at any given time. (Of course, you give your consent when you agree to the terms and conditions. But very few people ever read the terms and conditions, or privacy policies. They’re not designed to be read or understood.)

    There is the potential for big data to be collected and used for good. Apple’s ResearchKit is supported by an open source framework that makes it easy for researchers and developers to create apps to collect iPhone users’ health data on a huge scale. Apple says they’ve designed ResearchKit with people’s privacy values in mind, “You choose what studies you want to join, you are in control of what information you provide to which apps, and you can see the data you’re sharing.”

    But the allure of capturing huge, valuable amounts of data may encourage developers to design without ethics. An app may pressure users to quickly sign the consent form when they first open the app, without considering the consequences. The same way we’re encouraged to quickly hit “Agree” when we’re presented with terms and conditions. Or how apps tell us we need to allow constant access to our location so the app can, they tell us, provide us with the best experience.

    The intent of the developers, their bosses, and the corporations as a whole, is key. They didn’t just decide to utilize this data because they could. They can’t afford to provide free services for nothing, and that was never their intention. It’s a lucrative business. The business model of these companies is to exploit our data, to be our corporate surveillers. It’s their good fortune that we share it like—as Zuckerberg said—dumb fucks.

    To say that this is a privacy issue is to give it a loaded term. The word “privacy” has been hijacked to suggest that you’re hiding things you’re ashamed about. That’s why Google’s Eric Schmidt said “if you’ve got something to hide, you shouldn’t be doing it in the first place.” (That line is immortalized in the fantastic song, Sergey Says.) But privacy is our right to choose what we do and don’t share. It’s enshrined in the Universal Declaration of Human Rights.

    So when we’re deciding which cool new tools and services to use, how are we supposed to make the right decision? Those of us who vaguely understand the technology live in a tech bubble where we value convenience and a good user experience so highly that we’re willing to trade it for our information, privacy and future security. It’s the same argument I hear again and again from people who choose to use Gmail. But will the tracking and algorithmic analysis of our data give us a good user experience? We just don’t know enough about what the companies are doing with our data to judge whether it’s a worthwhile risk. What we do know is horrifying enough. And whatever corporations are doing with our data now, who knows how they’re going to use it in the future.

    And what about people outside the bubble, who aren’t as well-informed when it comes to the consequences of using services that exploit our data? The everyday consumer will choose a product based on free and fantastic user experiences. They don’t know about the cost of running, and the data required to sustain, such businesses.

    We need to be aware that our choice of communication tools, such as Gmail or Facebook, doesn’t just affect us, but also those who want to communicate with us.

    We need tools and services that enable us to own our own data, and give us the option to share it however we like, without conditions attached. I’m not an Apple fangirl, but Tim Cook is at least talking about privacy in the right way:

    None of us should accept that the government or a company or anybody should have access to all of our private information. This is a basic human right. We all have a right to privacy. We shouldn’t give it up.

    “Apple has a very straightforward business model,” he said. “We make money if you buy one of these [pointing at an iPhone]. That’s our product. You [the consumer] are not our product. We design our products such that we keep a very minimal level of information on our customers.”

    But Apple is only one potential alternative to corporate surveillance. Their services may have some security benefits if our data is encrypted and can’t be read by Apple, but our data is still locked into their proprietary system. We need more *genuine* alternatives.

    What can we do?

    It’s a big scary issue. And that’s why I think people don’t talk about it. When you don’t know the solution, you don’t want to talk about the problem. We’re so entrenched in using Google’s tools, communicating via Facebook, and benefitting from a multitude of other services that feed on our data, it feels wildly out of our control. When we feel like we’ve lost control, we don’t want to admit it was our mistake. We’re naturally defensive of the choices of our past selves.

    The first step is understanding and acknowledging that there’s a problem. There’s a lot of research, articles, and information out there if you want to learn how to regain control.

    The second step is questioning the corporations and their motives. Speak up and ask these companies to be transparent about the data they collect, and how they use it. Encourage government oversight and regulation to protect our data. Have the heart to stand up against a model you think is toxic to our privacy and human rights.

    The third, and hardest, step is doing something about it. We need to take control of our data, and begin an exodus from the services and tools that don’t respect our human rights. We need to demand, find and fund alternatives where we can be together without being an algorithm’s cash crop. It’s the only way we can prove we care about our data, and create a viable environment for the alternatives to exist.

  • Matt Griffin on How We Work: Readable Wearables 

    A few weeks ago we added our first wearable to the Bearded device lab, and it was an eye-opening experience. The same day that Apple showcased the soon-to-arrive Apple Watch, a Samsung Gear S showed up at our door. This device is a large smartwatch with pixel dimensions slightly greater than the iPhone 3GS. It has Opera Mini and its own cellular and wifi connections, so it functions as a standalone web interface.

    So will people use their watch-like devices for browsing the web? Though some may scoff at the idea (and believe me, there’s been plenty of scoffing), stranger things have happened. And if the last few years have taught us anything, it’s that if you can use something to get on the web, people will get on the web with that thing.

    After some personal use, it seems to me that these watch-sized screens are a totally reasonable way to access web content. And it’s equally reasonable for us to present our content in readable ways on these screens.

    As Brad Frost recently wrote, responsive design and future-friendly strategies go a long way to making sure our websites work and display the best they can on devices that haven’t even been invented yet. And it’s true that my first reaction to seeing the sites we’ve built displayed on the Gear was “not bad.” But, as I began to look closely and interact with these familiar sites via a tiny curved screen on my wrist, my perspective began to subtly, but significantly, shift.

    My gut reaction to these new smallest-of-screens: I’ve been starting with too big of a browser window. Lucky for us, if we’ve been prescient enough to be writing our CSS in extensible ways (and goodness knows mobile has given us plenty of reasons to do this already), there’s some pretty great low-hanging fruit for us to grab.

    The current Bearded site is super simple; a static two-pager with no navigation and very little in the way of bells and whistles. It struck me as a perfect candidate to try out some wearable-friendly optimizations without a lot of distractions. So let’s have a look at what could be done in an afternoon to make it more pleasurable to read on a watch.

    Let’s get small

    The Samsung Gear S, according to my tests, registers with media queries as a 213px-wide viewport. This is a far cry from the 300px-wide starting point I’ve become accustomed to when styling.

    On this new screen size, the range of acceptable type sizes is tighter than what I’ve been used to. My type was mostly either huge and unwieldy or eye-strainingly small. The original site styles utilized headings set in Quadon Regular, which range from 0.875em to 2.5em. But a 213px-wide viewport, to my sensibilities, only tolerates type sizes from 1.1em to 1.6em with that same typeface.

    Boldly oversize type loses its appeal on the very small screen. (Left: before; right: after.)

    A closing of the typographic aperture seemed called for, but how to do that without reworking a ton of CSS? Enter Past Bearded being kind to Future Bearded. Here’s how, thanks to Sass, we’ve been writing our heading styles for years. First we define the font stack:

    
    @mixin title-face {
    	font-family: Quadon-Regular, arial, “helvetica neue”, helvetica, sans-serif;
    	font-weight: normal;
    }
    

    Then we roll that mixin into our general heading mixin, where we add margin-bottom, line-height, and color:

    
    @mixin heading {
    	@include title-face;
    	margin-bottom: 0.35em;
    	line-height: 1.2;
    	color: $heading-color;
    }
    

    Next, we snowball all of that into the various specific heading mixins, and add font-size:

    
    @mixin heading-1 {
    	@include heading;
    	font-size: 2.5em;
    }
    
    @mixin heading-2 {
    	@include heading;
    	font-size: 1.8em;
    }
    
    ...
    

    Which we can apply to all our headings by default:

    
    h1 {
    	@include heading-1;
    }
    
    h2 {
    	@include heading-2;
    }
    
    ...
    

    This approach may at first seem a little overwrought, but it provides some terrific practical benefits over time. For instance, should you have something that semantically deserves to be lower down the chain from an h1 (say a paragraph or an h2), but you want it to have the visual appearance of an h1, you can just apply the heading-1 mixin:

    
    h2 {
    	@include heading-2;
    
    &.title {
    	@include heading-1;
    }
    

    Best of both worlds, right?

    As is often only possible with Sass, this approach also abstracts major styling decisions away from the low-level CSS implementations. This allows for us to be more agile with changes, even later in the project when our CSS files have grown more unwieldy.

    For our wearable type hierarchy issue, I was able to easily make adjustments to my heading sizes by adding media queries to those mixins, like so:

    
    @mixin heading-1 {
    	@include heading;
    		font-size: 1.6em;
    
    	@include breakpoint($breakpoint-s) {
    		font-size: 2.5em;
    	}
    }
    

    Then I got to sit back, refresh my browser, and watch my sitewide heading typography do its thing. Past Bearded, thank you for being awesome.

    Limitations breed innovation

    The tiny screens of wearables further restrict the design options we have at our disposal, even more so than mobile screens did before them. But working within this more limited palette is not necessarily a bad thing.

    In the letterpress world, for example, we’re restricted to the type we have physically sitting in our cabinets. The weights, sizes, typefaces, and variations we have to work with are extremely limited. And this can lead to some very exciting design work that otherwise we’d never be forced to do.

    When we work to come up with a sensible typographic hierarchy for any size screen, we must first consider what we have to work with:

    • font-family
    • font-size
    • font-weight
    • font-style
    • font-variant
    • font-weight
    • text-transform
    • color

    The most obvious things (aside from size) that you can use to accentuate your headings are uppercase and bold. Small caps, italics, a new font-family, or color changes may be reasonable options for you, as well.

    Though you may not have enough variations in font-size between 1.6em and 1.1em to effectively distinguish six heading sizes from each other, you can mix up font size changes with other type qualities to have that effect, then shift back to your size-based hierarchy as screen size allows for it.

    For instance, with the Bearded site headings I chose to use uppercase as a differentiator for two headings with the same font-family and font-size. Then, when the screen is wide enough, I can use media queries inside the mixins to return to my font-size based hierarchy, like so:

    
    @mixin heading-3 {
    	@include heading;
    		font-size: 1.1em;
    		text-transform: uppercase;
    
    	@include breakpoint($breakpoint-xs) {
    		font-size: 1.4em;
    		text-transform: none;
    	}
    }
    
    @mixin heading-4 {
    	@include heading;
    		font-size: 1.1em;
    
    	@include breakpoint($breakpoint-xs) {
    		font-size: 1.2em;
    		}
    }
    

    Where’s that breakpoint gonna go?

    Speaking of which, at what point should one add this no-longer-wearable breakpoint? The answer: at a width at which your larger screen design decisions start making sense again. The Gear clocked in at 213px, but it seems like those smallest-screen decisions would be beneficial for widths wider than that. When enlarging my browser up from 213px, my wearable-focused design decisions applied for the most part up until 290px, at which point typography could stretch out a little more, and some multi-column grid layouts could comfortably be put to use.

    But not all of the layout decisions from the existing mobile-centric site design made sense at 290px. What’s interesting is that, working at that scale, I actually needed an extra breakpoint. Previously I’d been working with these breakpoints:

    1. < 400px
    2. 400px
    3. 550px
    4. 700px

    Now, starting with smaller widths, I’d arrived at:

    1. < 290px
    2. 290px
    3. 350px
    4. 550px
    5. 700px

    Not surprisingly, the smaller the screen, the greater the impact that a few pixels has. The difference between 1000px and 1050px may not warrant any design changes at all, whereas the difference between 250px and 300px almost certainly does.

    Too small for small

    The last thing I addressed was a bit surprising to me: my 1em (16px) body copy type was too small to comfortably read. I’ve always thought of 1em as a font size that was great for web reading. It feels almost clunky, in fact, when compared to the 8pt reversed type I frequently saw in the world of print design. But on this tiny screen on my wrist, there seemed to be a huge difference, at least with this font-family, between the 1em body type and the 1.1em intro paragraph copy.

    Increasing the font-size from 1em to 1.1em helped readability. (Left: before; right: after.)

    On this site, fixing that was a breeze—I could just increase the font-size of all paragraphs to 1.1em. There was no need to worry about accidentally missing anything, because there was no non-paragraph body copy (i.e. lists or tables). But for a bigger site, this would be too specific of a solution. I could easily end up with well-sized paragraphs and—on some forgotten page—a tiny definition list or errant span. So what might a more extensible solution look like?

    Easy—we can just bump up the site-wide font-size for everything below a certain breakpoint! Something like:

    
    html {
    	font-size: 110%;
    
    	@include breakpoint($breakpoint-s) {
    		font-size: 100%;
    	}
    }
    

    Of course, now our small screen heading sizes are 10 percent too big. Oh man! Good thing we used those mixins, huh?

    Thanks to the Sass-based typographic system we established earlier, adjusting those values a second time won’t be so bad. Who knows, we might even be in pretty good shape when those web-enabled holographic refrigerators finally hit the market in 2016.

  • Don’t Forget About Contrast 

    Several years ago I wanted to get an external monitor to go along with the laptop my work provided. I was a remote worker and decided to buy one myself that I could hang on to even if I left that job. But I was also a bit cheap. I drooled over the Apple Cinema displays, but I didn’t want to spend that kind of money.

    Enter the big-box electronics store and their wide range of displays. I stood in front of one, decided on a size, and purchased it. I bought an LG that seemed “good enough” for my need for more screen real estate for windows of code, browsers, and dev tools. To be quite honest, this monitor has met those needs. I’m still using it.

    It also pointed out a glaring issue that rears its head in a lot of our designs: we aren’t using enough color contrast to accommodate users who may not have the latest and greatest screens. I surfed the web the way I think a lot of people do, on a monitor that they took out the box and started using without doing any calibration. I was astounded by the lack of contrast all over the place. We like gray a lot and often we like it to be very subtle.

    So, even though this monitor is not exactly what I would have bought if I could have afforded something nicer at the time, I’m now grateful for it. While I’m working on client projects, I’m often pointing out to the designers when their design cues or colors may be a little too subtle. If I’m dragging a design over to my laptop screen to be able to differentiate the contrast and colors, then it’s probably a good idea to punch things up a bit.

    You don’t have to go out and buy a cheap monitor to see this, you can also test on older devices that don’t have the latest and greatest screens on them. Many cities have Open Device Labs where you can test on devices for free. If something like that is unavailable to you, there are other ways to find devices for inexpensive testing—Brad Frost has a great post on how to do that. There are many instances where our sites or applications aren’t going to be used on high-end, Retina devices or monitors and I think we have an obligation to consider that as we design so all our users can easily interact with the things we build.

    As an example of this, I recently worked on an application that was intended for use in hospitals. I couldn’t help but wonder, were those monitors going to be able to show subtle color differences? Many of us are making applications that may be used places like hospitals, or other settings where the screens being used aren’t calibrated to perfection so subtle contrast can get lost. That’s just one example of an audience where I would want to be careful about what I expect out of a screen or monitor.

    If you don’t have a cheaper monitor around, I highly recommend using developer tools to help you check for accessibility issues such as contrast. The accessibility team at Google has been doing a great job making tools that can help point out where there may be issues, so if you use Chrome, run an accessibility audit to see where you may need to make changes. Jenn Lukas wrote a great blog post here on ALA to describe testing color in the Chrome Dev Tools.

    I’m grateful for this monitor because it points out contrast issues and reminds me frequently that those issues exist, and like color blindness variations, need to be taken into account as we work. Color contrast plays a large role in our designs, so make sure you test for it, check out designs on less capable screens, and audit your sites with the tools available, so that your users can easily see all the pieces of your design.

  • 80/20 Practitioners Make Better Communicators 

    I spent the better part of 2014 working on two redesigns: one for a major pizza chain, the other for a major bike retailer. The five of us working on the redesigns were excited beyond words—two large-scale sites about two things we loved: pizza and bikes! We all wanted to be heavily involved in every phase of these projects to ensure their success. Along the way, we learned important lessons about how to fine-tune that involvement to arrive at a better outcome.

    Working with the same team on two simultaneous projects allowed us to experiment a little with our process and compare notes. The ecommerce-driven Pizza Site had a strong focus on user flows, so we began by creating HTML wireframes for every page. What had once seemed like a bunch of grandiose ideas on whiteboards morphed into actual working prototypes. As we moved into design, the prototypes came to life in all their melted-cheese glory. But by month nine of the engagement, as we started to polish up the templates, we realized that we were looking at the third installment of the same redesign.

    This isn’t an unusual occurrence. Teams often inadvertently recreate designs multiple times across phases; the end result looks almost nothing like what the team set out to achieve. What causes this disconnect?

    In my experience, it comes from insufficient communication among teams with varying skillsets. Some teams are composed of specialists who all want their ideas and voices heard (yielding vastly different results) while fighting for time, resources, and budget. Alternately, when a generalist works on the entire site, they risk getting spread too thin; the struggle to explore and iterate can produce stale, predictable solutions. Either too much specialization or too much generalization can overwhelm practitioners (and budgets)—and neither approach works.

    How to become an 80/20 practitioner

    Luckily, there’s a better way. When designers and developers (and entire web teams) work closely together with flexibility and shared understanding, they can use their time and resources more efficiently and creatively. Whether your process is waterfall or agile, a solid team foundation applies to everyone: it allows you to shape a solution that benefits all teammates on a project.

    To avoid the mistakes we made on our Pizza Site process, we balanced our responsibilities differently with the Bike Site. We became what I call 80/20 practitioners, focusing 80 percent of our time on our own respective strengths while distributing the remaining 20 percent across other disciplines to benefit the entire project.

    80/20 collaboration is about people. It’s about passions. Sounds great, right? So, where do we start?

    Establish the foundation

    Being a good practitioner means seeing beyond yourself to your team’s broader needs and goals. While molding your process, it’s important to maintain an open, honest discussion with your teammates. Take a comprehensive inventory of the people on your team. Instead of labeling someone a “designer” or a “developer,” take stock of their true skillsets and passions. I’ve worked with amazing graphic designers, amazing UX designers, and amazing interaction designers, all of whom had the same title: designer. What works depends on the person.

    We’ve all heard the argument that designers need to code. And while that might be ideal in some cases, the point is to expand your personal spectrum of skills to be more useful to your team, whether that manifests itself in the form of design, content strategy, UX, or even project management. A strong team foundation begins by addressing gaps that need to be filled and the places where people can meet in the middle. This is also how you, as a practitioner, can identify where you should develop your 20 percent of surplus abilities for a given project.

    If you imagine your team as a spectrum of skills, each person should have a skillset that covers one part of that spectrum (overlapping to some extent with another part). Let’s pretend this spectrum goes from graphic design (red), to code (blue), with every shade of purple in between. As a designer, I span from the reddest of reds to a reddish purple. That leaves the rest of the purple and blue to be picked up. Let’s say my team includes a designer/developer hybrid, Ava, who is all the varying shades of purple. And let’s say I also have a strictly blue backend developer, Carter, on my team. In this instance, we’ve covered all our bases. If it was just Carter and me, though, we’d be left with a significant void in the middle. We would need either to extend our 20-percent skillset into the purple area or to bring in an additional person to bridge the gap. The spectrum’s endpoints will vary from person to person and team to team.

    Strengthen weaknesses

    Whenever someone told me, “You should code!” I would think: “But Developer McCoderson can do it so much better and faster than I ever could!” Which was true, so I continued my deep dive into design. Over time, though, working very closely with my developers every day on the Pizza Site, my interest was slowly piqued. Once I started incorporating HTML wireframes into my design process, I began to see how it benefitted me. I could make faster content updates, my layout was automatically responsive, and I could focus purely on content hierarchy rather than worrying about resizing boxes every time content changed.

    The more I realized that coded deliverables could be design deliverables, the more I understood that I could get interactions in front of a client earlier. Animations, dropdowns, popovers, etc.—these things are design. We want the client’s feedback on this early, because seemingly minor details like hovers reflect the brand and reinforce the design just as much as an image or color choice do.

    This discovery was so liberating that I actually wanted to include code in my process from then on because I preferred working that way, not just because I thought “This will make me a better designer.” I now catch myself voluntarily reading about things like inline SVG and the picture element and almost don’t recognize myself!

    Take a candid look at your process and see where you want to expand your 20 percent, not where you think you should expand it. Let’s go back to Carter, the backend developer, for a second. Maybe he wants to improve his front-end skills—but by “front-end,” does he mean his code or his design eye? What’s missing is probably not a talent for writing beautiful DRY code, but rather the ability to recognize design nuances. Maybe the place to start is by reading articles about typography or checking out other design resources, instead of plunging into JavaScript.

    Once you start recognizing these secondary areas, you can begin to take your newfound interests offline and look into different meetups or talks than you’d normally attend. I discovered that nothing helped me improve my 20-percent skills more than simply befriending wildly talented developers, both in and out of the workplace.

    Learn from each other

    The developer on the Bike Site team created a Grunt file to accommodate our entire team’s needs, including design deliverables and how we handle wireframes. Once everything started being delivered within a code-based project hub, we were all on the same page—literally. We could jump in and help each other as necessary, especially on stressful delivery days. Even the project manager was able to use and update the hub.

    And the developers learned from me, too. Having them involved from day one meant that they were included in a lot of our design reviews. They began to understand the thought process behind our design decisions, and everyone could holistically understand the system we all were building together. When we began to figure out the wireframing and user-experience part of the site, every member of the team had behavior- and experience-driven suggestions that found their way into the project, both in terms of how it would ultimately look and how it would be built. With everyone involved from the beginning, new ideas that previously never would have been considered cross-pollinated the deliverables—whether it was a developer suggesting an out-of-the-box design pattern or a designer creating a performance budget.

    When these conversations happen, barriers between teammates gradually fall away. You’ll probably suggest tools to one another and start to merge processes; in that merging, a new collaborative process will take shape. When we borrow one another’s tools, we begin to learn their benefits and how they may work for our own needs, and we ultimately start speaking the same language. Being aligned on objective project goals helps to keep reviews on track and to more easily settle discrepancies. It isn’t about making anyone’s job easier; it’s about focusing on what’s best for the project. Shared process isn’t something that you can just decide to do; rather, it emerges from learning how another person works.

    Let go of ego

    To rapidly take a design to code, the overall direction needs to be mostly approved by the client. I say “mostly” because the best iterations happen in the browser once we begin interacting with our designs. This is where our 20-percent-spectrum overlap really kicks in. There will be holes in the design that need to be filled, and it’s up to the developer to create a useful roadmap for the designer to iterate on. Imagine that an early homepage concept is approved and we jump into developmental iterations, but I haven’t had a chance to style the navigation dropdowns yet. I love it when developers take a stab at styling these things. If need be, I can always tweak details that feel off to me. When developers have some design sense, they are able to jump in and make design decisions that the designer may not have considered in a fluid layout or behavior. Designers love to be perfectionists, but we need to learn to let go and not be afraid to allow developers to jump into coding a template of an “imperfect” mockup.

    There’s nothing wrong with piece-designing parts and modules as the developer finds holes in the page or media queries. As Dan Mall has stated, it’s about deciding in the browser, not designing in the browser. Everything might not be figured out yet, but that’s okay: we’ll figure it out together. Our websites are fluid; our process should be, too.

    Shaking up a process isn’t easy

    Change can be hard for any organization, especially when strict guidelines are in place for current processes. You have to work toward breaking down any barriers in communication—whether by getting to know a new teammate on a new project, working within your organization to dissolve silos, or trying to introduce a new workflow idea to your boss. A malleable process is a strong one.

    The best place to start is with your project manager. It’s difficult to fit a new process into an ongoing project retroactively, so try to address this at the planning stage. If you’re about to begin a project, make the manager aware of your ideas and how the project plan could be shaped a little differently. It’s important for the project manager to understand the plan so that they can set the expectations with the client accordingly. It’s equally important for them to understand how the timeline will be affected, as it may depart from the typical flow your team is used to.

    In large organizations, managers may need to run ideas past the managers of other departments. See if your next project can be a trial run for experimenting with a new process, and volunteer to head the initiative. Samantha Warren gave a fantastic presentation at An Event Apart on getting design ideas moved through an organization. If this doesn’t seem feasible, try building relationships with your counterparts yourself. See if they are open to trying new methods and working more closely together. If you get multiple people on board, it may be easier to convince the powers that be to try something new. Teams organically working well together are a powerful demonstration of just how effective collaboration can be.

    Everybody benefits

    Dive deeply into your passions while understanding the moving parts around you. Mastering your specialty is not only crucial for professional development and personal satisfaction, but it will also serve your team as you help to stretch that spectrum further. Projects benefit from experts who understand the whole while focusing on their strengths.

    When we speak openly about shared end goals, our teamwork gets stronger. When we jump in and help out on cross-discipline deliverables, our teamwork gets stronger. Most importantly, when we combine our collective strengths and work together fluidly, it gives us the perfect recipe for an amazing project.

    Remain true to your passions, but take the time to learn something about the skillsets of others to help you craft a unique team dynamic. The 80/20 guideline is a place to strive for—a place where we push our own skills and passions while rounding out our knowledge so that we can work better with our teammates. Being an 80/20 practitioner makes a stronger you and a stronger team.

  • Pluralization for JavaScript 

    Seventy-one percent of today’s internet users don’t speak English as a first language, and that number keeps growing. But few people specialize in internationalization. As a result, most sites get it wrong—because things that seem straightforward are often anything but.

    Take pluralization. Turning singular words into plurals within strings gets tricky quickly—even in English, where most plural words end with an s. For instance, I worked on a photo-sharing app that supported two languages, English and Chinese. It was easy to add an s to display “X like[s]” or “Y comment[s].” But what if we needed to pluralize “foot” or “inch” or “quiz”? Our simple solution became a broken hack.

    And English is a relatively simple case. Many languages have more than two plural forms: Arabic, for example, has six, and many Slavic languages have more than three. In fact, at least 39 languages have more than two plural forms. Some languages only have one form, such as Chinese and Japanese, meaning that plural and singular nouns are the same.

    How can we make sense of these complex pluralization issues—and solve them in our projects? In this article, I’ll show you some of the most common pluralization problems, and explain how to overcome them.

    Problems with pluralization

    Pluralization gets even more complex: each language also has its own rules for defining each plural form. A plural rule defines a plural form using a formula that includes a counter. A counter is the number of items you’re trying to pluralize. Say we’re working with “2 rabbits.” The number before the word “rabbits” is the counter. In this case, it has the value 2. Now, if we take the English language as an example, it has two plural forms: singular and plural. Therefore, our rules look like this:

    • If the counter has the integer value of 1, use the singular: “rabbit.”
    • If the counter has a value that is not equal to 1, use the plural: “rabbits.”

    However, the same isn’t true in Polish, where the same word—“rabbit,” or “królik”—can take more than two forms:

    • If the counter has the integer value of 1, use “królik.”
    • If the counter has a value that ends in 2–4, excluding 12–14, use “królika.”
    • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use “królików.”
    • If the counter has any other value than the above, use “króliki.”

    So much for “singular” and “plural.” For languages with three or more plural forms, we need more specific labels.

    Different languages use different types of numbers

    You may also want to display the counter along with the pluralized noun, such as, “You have 3 rabbits.” However, not all languages use the Arabic numbers you may be accustomed to—for example, Arabic uses Arabic Indic numbers, ٠١٢٣٤٥٦٧٨٩:

    • 0 books: ٠ كتاب
    • 1 book: كتاب
    • 3 books: ٣ كتب
    • 11 books: ١١ كتابًا
    • 100 books: ١٠٠ كتاب

    Different languages or regions use different number formats

    We also often aim to make large numbers more readable by adding separators, as when we render the number 1000 as “1,000” in English. But many languages and regions use different fractional and thousand separators. For example, German renders the number 1000 as “1.000.” Other languages don’t group numbers by thousands, but rather by tens of thousands.

    Solution: ICU’s MessageFormat

    Pluralization is a complex problem to solve—at least, if you want to handle all these edge cases. Recently, International Components for Unicode (ICU) did precisely that with MessageFormat. ICU’s MessageFormat is a markup language specifically tailored to localization. It allows you to define, in a declarative way, how nouns should be rendered in various plural forms. It sorts all the plural forms and rules for you, and formats numbers correctly. Unfortunately, many of you probably haven’t heard of MessageFormat yet, because it’s mostly used by people who work specifically with internationalization—known to insiders as i18n—and JavaScript has only recently evolved to handle it.

    Let’s talk about how it works.

    Using CLDR  for  plural forms

    CLDR stands for Common Locale Data Repository, and it’s a repo that companies like Google, IBM, and Apple draw on to get information about number, date, and time formatting. CLDR also contains data on the plural forms and rules for many languages. It’s probably the largest locale data repository in the world, which makes it ideal as the basis for any internationalization JavaScript tool.

    CLDR defines up to six different plural forms. Each form is assigned a name: zero, one, two, few, many, or other. Not all locales need every form; remember, English only has two: one and other. The name of each form is based on its corresponding plural rule. Here is a CLDR example for the Polish language—a slightly altered version of our earlier counter rules:

    • If the counter has the integer value of 1, use the plural form one.
    • If the counter has a value that ends in 2–4, excluding 12–14, use the plural form few.
    • If the counter is not 1 and has a value that ends in either 0 or 1, or the counter ends in 5–9, or the counter ends in 12–14, use the plural form many.
    • If the counter has any other value than the above, use the plural form other.

    Instead of manually implementing CLDR plural forms, you can make use of tools and libraries. For example, I created L10ns, which compiles the code for you; Yahoo’s FormatJS has all the plural forms built in. The big benefits of these tools and libraries are that they scale well, as they abstract the plural-form handling. If you choose to hard-code these plural forms yourself, you will end up exhausting yourself and your teammates, because you’ll need to keep track of all the forms and rules, and define them over and over whenever and wherever you want to format a plural string.

    MessageFormat

    MessageFormat is a domain-specific language that uses CLDR, and is specifically tailored for localizing strings. You define markup inline. For example, we want to format the message “I have X rabbit[s]” using the right plural word for “rabbit”:

    
    var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}';
    
    

    As you can see, a plural format is defined inside curly brackets {}. It takes a counter, rabbits, as the first argument. The second argument defines which type of formatting. The third argument includes CLDR’s plural form (one, many). You need to define a sub-message inside the curly brackets that corresponds to each plural form. You can also pass in the symbol # to render the counter with the correct number format and numbering system, so it will solve the problems we identified earlier with the Arabic Indic numbering system and with number formatting.

    Here we parse the message in the en-US locale and output different messages depending on which plural form the variable rabbits takes:

    
    var message = 'I have {rabbits, plural, one{# rabbit} other{# rabbits}}.';
    var messageFormat = new MessageFormat('en-US');
    var output = messageFormat.parse(message);
    
    // Will output "I have 1 rabbit."
    console.log(output({ rabbits: 1 }));
    
    // Will output "I have 10 rabbits."
    console.log(output({ rabbits: 10 }));
    
    

    Benefits of inlining

    As you can see in the preceding message, we defined a plural format inline. If it weren’t inlined, we might need to repeat the words “I have…” for all plural forms, instead of just typing them once. Imagine if you needed to use even more words, as in the following example:

    
    {
      one: 'My name is Emily and I got 1 like in my latest post.'
      other:  'My name is Emily and I got # likes in my latest post.'
    }
    
    

    Without inlining, we’d need to repeat “My name is Emily and I got…in my latest post” every single time. That’s a lot of words.

    In contrast, inlining in ICU’s MessageFormat simplifies things. Instead of repeating the phrase for every plural form, all we need to do is localize the word “like”:

    
    var message = 'My name is Emily and I got {likes, plural, one{# like} other{# likes}} in my latest post';
    
    

    Here we don’t need to repeat the words “My name is Emily and I got…in my latest post” for every plural form. Instead, we can simply localize the word “like.”

    Benefits of nesting messages

    MessageFormat’s nested nature also helps us by giving us endless possibilities to define a multitude of complex strings. Here we define a select format in a plural format to demonstrate how flexible MessageFormat is:

    
    var message = '{likeRange, select,\
      range1{I got no likes}\
      range2{I got {likes, plural, one{# like} other{# likes}}}\
      other{I got too many likes}\
    }';
    
    

    A select format matches a set of cases and, depending on which case it matches, it outputs the corresponding sub-message. And it is perfect to construct range-based messages. In the preceding example, we want to construct three kinds of messages for each like range. As you can see in range2, we defined a plural format to format the message “I got X like[s],” and then nested the plural format inside a select format. This example showcases a very complex formatting that very few syntaxes can achieve, demonstrating MessageFormat’s flexibility.

    With the above format, here are the messages we can expect to get:

    • “I got no likes,” if likeRange is in range1.
    • “I got 1 like,” if likeRange is in range2 and the number of likes is 1.
    • “I got 10 likes,” if likeRange is in range2 and the number of likes is 10.
    • “I got too many likes,” if likeRange is in neither range1 nor range2.

    These are very hard concepts to localize—even one of the most popular internationalization tools, gettext, can’t do this.

    Storage and pre-compiled messages

    However, instead of storing MessageFormat messages in a JavaScript variable, you might want to use some kind of storage format, such as multiple JSON files. This will allow you to pre-compile the messages to simple localization getters. If you don’t want to handle this alone, you might try L10ns, which handles storage and pre-compilation for you, as well as syncing translation keys between source and storage.

    Do translators need to know MessageFormat?

    You might think it would be too overwhelming for non-programming translators to know Messageformat and CLDR’s plural form. But in my experience, teaching them the basics of how the markup looks and what it does, and what CLDR’s plural forms are, takes just a few minutes and provides enough information for translators to do their job using MessageFormat. L10ns’ web interface also displays the example numbers for each CLDR plural form for easy reference.

    Pluralization isn’t easy—but it’s worth it

    Yes, pluralization has a lot of edge cases that aren’t easily solvable. But ICU’s MessageFormat has helped me tremendously in my work, giving me endless flexibility to translate plural strings. As we move to a more connected world, localizing applications to more languages and regions is a must-do. Knowledge about general localization problems and tools to solve them are must-haves. We need to localize apps because the world is more connected, but we can also localize apps to help make the world more connected.

  • On Our Radar: Present Tense 

    It seems like we’re always anxiously awaiting the future, complications and all. Take the present moment: HTTP/2 is on its way, with intriguing changes for web development; web publishing has never been easier, but Medium’s latest direction is a mixed bag for authors; and our attention is increasingly in demand (and for sale). We’re living in the future, and we’ve got some mixed feelings about that.

    Here’s what’s on our radar:

    HTTP/2: On the horizon

    HTTP/2 is on the horizon, a long-awaited upgrade to the web’s primary protocol. It promises better security and performance, but I’ve been curious about how it will impact development. Fortunately I came across two interesting posts that are a nice introduction to what HTTP/2 does and how it will affect the way we build websites:

    Speaking of better performance, have you seen Tim Kadlec’s What Does My Site Cost? If you live in Angola, this page may have cost $0.32 (USD) to download—something you can bet we’ll be taking a hard look at.

    Tim Murtaugh, technical director

    Mediummm?

    Last month, in a long Atlantic piece about the state of writing for the web, Robinson Meyer asked—for, like, the millionth time—“what is Medium, tho?” Is it publisher, or is it platform? Is it both?

    Is it “just Tumblr for rich people”?

    “All of the above” seems like the most accurate answer after yesterday’s announcement: custom domains for publications. Now, instead of going to medium-dot-com-slash-whatever to get the latest, you might head to cool-url-dot-biz, and find that it’s actually Medium now, too. You can already see this in action with Midcentury Modern. The magazine’s URL is midcenturymodernmag.com, but once you’re there, it’s Medium all the way down.

    So what’s this mean for people like us—people who make websites and work with web content? Will publications flock to replace their custom sites with Medium? Probably not. But many organizations that otherwise might have cobbled together a Wordpress blog could easily end up launching a Medium publication instead, and I’m not sure how I feel about that. On the one hand, Medium’s invested heavily in design and extremely thoughtful typography. It’s great to see so much content written to be read (not to mention discussed and shared). On the other, as both publisher and platform—both the magazine and the paper it’s printed on at the same time—Medium controls everything about how the content published with it is presented, regardless of the URL it ends up on: layout, type, functionality. Does that leave enough space for authors and organizations?

    Sara Wachter-Boettcher, editor-in-chief

    We’re living in a future predicted 60 years ago

    In my youth, old science fiction short story compilations were a mainstay of my summer reading. One story I vividly remember is Frederik Pohl’s “The Midas Plague,” set in a world so rich in stuff that the poor are obliged to consume constantly, while the wealthy can afford emptiness and silence.

    I was reminded of that world as I read Matthew Crawford’s “The Cost of Paying Attention.” It becomes even more real in light of Daniel Levitin’s explanation that the brain runs on a daily ration of fuel that is depleted with every target of focus and every decision—and it makes no difference whether they’re important or insignificant.

    Attention is a limited and very valuable resource that we have to protect when it’s our own, and respect when it’s our neighbor’s.

    Rose Weisburd, columns editor

    A gif about: uncertainty

    I am having second thoughts.

    What about you?

    What stories are drawing your attention? Got any posts, pictures, tools, or code you want to share? (We love sharing!) Tweet us what’s on your radar—and what should be on ours.

  • Nishant Kothary on the Human Web: There Is No Data vs. Intuition 

    Few things have widened the chasm between data and intuition as much as Marissa Mayer’s infamous matter of the 41 Shades of Blue a few years ago.

    For those of you who live under a rock, let me catch you up.

    Back when there were just 41 shades

    Back in the golden age when Google wasn’t evil, they used two different shades of blue for the hyperlinks in Search and Gmail ads. The decision was made to determine the one true blue, and it was ultimately Mayer’s to make. Her intuition to split the difference between two final contenders left her uneasy. So naturally, she devised a most elaborate A/B test to determine the best blue among 41 different blues.

    And then everyone wrote about it. Bowman. Clark. Fast Company. CNET. Gawker. Gigaom. The New York Times. Even I piled on in my own little way. And the verdict that came out at the end of the human centipede was a collective, “Eww, she did what?!”

    Taking a page from Kim Kardashian, who recently owned her own narcissism in this (really, quite effective) T-Mobile commercial, Google’s design team themselves embraced and commemorated their data-driven philosophy late last year in the Googliest of ways. In 41 successive tweets they tweeted—you guessed it—those infamous 41 shades of blue. And the 42nd tweet, in classic Google form, a puzzle:

    We have Will Kirkby to thank for bit-shifting his heart to the solution, an inspirational quote: “we seek to synthesize classic principles of good design with the innovation and possibility of technology and science…”

    *Slow clap*

    All made up but nowhere to go

    Judging by the fun and games, it seems like we’ve all made up. As much as I’d love to applaud us all for putting our demons to rest and working it out, it’s hard to ignore the underlying cause of this years-long kerfuffle: the data vs. intuition debate (if I can even call something this dogmatic a debate).

    The debacle quietly renewed the old, tired, artificial, and patently false, division between data and intuition. And from where I stand, divided they remain.

    Back to square one. Designers vs. Engineers. Emotions vs. Logic. Intuition vs. Data.

    So, before it gets too late, let me just get this on the record: if you find yourself arguing at dinner parties that intuition has no place in the decision-making process (have you noticed that nobody ever seems to do the opposite?), well, then first off: stop lying because nobody invites you to dinner parties. But more importantly, I want to do you a solid and tell you that you may be the accidental modern jackass. Because you’re plain wrong.

    And there’s a mound of data that supports that.

    Data vs. and intuition

    If you’re curious about the data supporting the intelligence of the gut, you can start with Malcolm Gladwell’s Blink. But I recommend it with acute awareness of the polarizing effect of referencing Gladwell as a case for science. So before you cut your losses and head back to your timeline, my second recommendation is the source of much of the great research out there on intuition: Gerd Gigerenzer’s very readable treatise on the topic, Gut Feelings: The Intelligence of the Unconscious. Its extensive bibliography will satiate those of you who want to dive into the p-values of the randomized control trials, while it doubles as a jumping-off point for the topic as a whole.

    You don’t have to go very far into the research before you realize something you’ve always known in your gut: that your gut is frikkin’ smart. From catching a flyball to becoming a world-class athlete, from picking winning stocks to dreaming up entirely new markets, the intelligence of the gut is awesome in the truest sense of the word: it draws awe.

    But, here’s the thing: data is just as awesome. 

    Data has a way of turning a suspicion into a verifiable fact. It has the ability to replace dogma with truth. To provide answers to vexing problems simply with math. As Christian Rudder writes in Dataclysm: Who We Are, “It’s like looking at Earth from space; you lose the detail, but you get to see something familiar in a totally new way.”

    Some of you already know where I’m going with all of this: we’re punching ourselves in the, well, gut, by continuing to pit intuition against data. It’s not one or the other. It never has been, and as much as we try to sell the narrative, it never will be. They are both mandatory in sound decision-making (there’s a good book on that, too, by the way).

    The fact is that there is no data vs. intuition.

    Finally

    Ironically, Mayer’s rationale for her design decision—her execution (or its reporting and our understandable reactions) notwithstanding—was actually pretty sound: “Every design starts with an instinct: It should look like this, or it should look like that. You can actually test it with data. The humbling thing about that is sometimes the data proves you wrong. So for every change I propose, you know, three out of four, four out of five the data will support the change.”

    And if you’re to believe the press, it was worth $200m a year. But who knows.

    Regardless, here’s a thought experiment: can you see an alternate universe where a Jobs-esque genius gets a standing ovation for employing Mayer’s line of reasoning?

    Let your gut noodle on that for a bit.

     

  • Brevity vs. Clarity 

    A few months ago, my good friend, Olivier Lacan, tweeted:

    He rightly points out that a lot of commonly-accepted abbreviations exist only because a critical mass of people use them. We understand what “btn” means because we’ve seen it before, not because it’s a clear shortening of “button.”

    Is the loss of clarity outweighed by the benefits of a shorter class name? In an era where most text editors provide autocompletion, three letters isn’t a huge difference from an authoring perspective.

    Inevitably, someone else will come along someday and work with the code we write. Even if you work by yourself, future you will be a different person because of the work you’ve done and the experiences you’ve had between the times you focus on a project. Clarity is invaluable when others (or our future selves) come in to work on something—we don’t have to struggle to understand what is happening, we can get work done more efficiently, and the overall process will be much smoother.

    On the technical side, brevity certainly has its place. The savings made by using a fewer letters each time a name is written can add up if your codebase is large enough. Better yet, minification and compression of CSS and JavaScript source files can save precious kilobytes and shorten page load times noticeably. There’s really no shortage of micro-optimizations you can find out there, all in the name of brevity and speed.

    There are clearly good reasons for both approaches, so like most things in our work, it all comes down to how you decide what’s right for you and your situation. Is there a tangible, data-proven benefit of brevity? If not, be descriptive, expressive, and clear.

    Hal Abelson and Gerald Jay Sussman said it best in their MIT Structure and Interpretation of Computer Programs course:

    Thus, programs must be written for people to read, and only incidentally for machines to execute.

    I let that guide me, but the lines between what’s for humans and computers can get blurry sometimes—JavaScript and CSS files are for both humans and machines, so it’s best to find a way to play to both sides’ advantages. Minification and compression are good tools here: clear source code for development, minified and compressed files for production.

    No matter what, avoid abbreviating for abbreviation’s sake. The benefits of clear, readable code are almost always greater than typing fewer characters. And if brevity is applied thoughtfully in technical situations, you’ll use resources more efficiently, and that will make everyone happy.

     

  • Rachel Andrew on the Business of Web Dev: Looking Outside 

    Running a business with your spouse has advantages. A year ago we decided—after asking Twitter where was nice to live—to move from Maidenhead to Bristol. We were able to relocate home and business easily because our work and life together is one thing. We can head out for a walk or a run together and chat through a possible new feature for Perch or a business decision that needs making. Our life and business goals are one and the same.

    My husband Drew McLellan and I are each a 50 percent shareholder in the business, while my college-aged daughter works for us part time. Other roles are fulfilled by contractors and freelancers. Major business decisions, from product features to financial issues, are made by the two of us.

    We do have defined roles. I started the company, so a lot of the business of doing business comes down to me. I also enjoy the activity of running a business, and have a good head for accounting and legal issues. Drew is lead developer on Perch, and the direction of the product and codebase is his. We discuss most decisions, but there are distinct areas of the business that we each take the lead on.

    However, when decisions need to be made that one partner is unhappy with, the overspill into non-work life can be difficult. How do we support each other as husband and wife while being able to argue the pros and cons as business owners? Where most people can leave work and head home to get outside input from their partner, couples in business can find themselves without that outlet.

    Even when things are going well, there is a danger of becoming insular. On many issues, Drew and I come to a shared conclusion quickly. Is that because we are right or just because we read the same things, have the same experiences? These are difficult questions to answer.

    Our small part of the web industry can be a navel-gazing place at times. Just watch how the same tweets circulate, the same products are mentioned, by the same small group of people. Asking advice from my friends in the industry can be very similar to asking advice from my partner. They know me and what I do too well, and are probably being influenced by the same books, blog posts, and speakers as I am.

    Sometimes it takes an outsider to point out the mistakes you are making, and to open up conversations and ask questions that you might never ask yourself.

    Getting some “business therapy”

    Drew and I really enjoy watching business reality shows on TV—especially the sort of thing where an experienced businessperson goes into a failing business to help them out. A show airing in the UK at the moment has hotelier Alex Polizzi performing this role in family businesses. We cringe as we see the TV businesses making seemingly obvious mistakes. We sometimes wonder how much our own perspective prevents us seeing our own errors and the opportunities we miss out on.

    Having an outsider look at your business can be incredibly helpful. We recently applied for, and were accepted into, the UK Business Growth Service’s Growth Accelerator scheme. This comes with several benefits, but the most interesting to us is the chance to work with a business advisor. When I first heard about the scheme, I had visions of being paired with an ex-bank-manager type, someone from a very traditional business. I imagined I’d spend more time explaining how our business worked than getting any real advice. That hasn’t been the case. Our advisor, Matt Spry, has enough technical background to understand what it is we do, but enough distance and wider business experience to be able to ask us questions we’d not ask ourselves.

    We’ve been led through exercises that we know are a good idea but that seem a bit odd to do on our own, especially as a couple in business. Last week we covered a table in a local café in sticky notes to work out which aspects of our product are most important to different groups of customers. Every time we meet with Matt, it sparks conversations we might not have had with each other. It does sometimes feel a bit like “business therapy.” Even though Drew and I tend not to have too many conflicting ideas for the business, having a third party pose questions that are very much in one of our areas of responsibility is certainly helpful.

    We’re still in the middle of this process with the Growth Accelerator scheme. It is too early to judge whether this input will increase the success and growth of the business. We have already found, however, that voicing concerns and considering a different viewpoint has started to make us confident to try changes we might have avoided before.

    Finding your own outside help

    We’re involved in a formal scheme, but there are other ways in which you could get input for your own business, whether you work alone or run a family business of some sort. Many of my peers are part of mastermind groups, groups of three or four people who meet regularly to offer input into the businesses of each member of the group. Episode 167 of Startups for the Rest of Us talks about how to set up and run such a group. Another method would be to try to find a business mentor. In that case, I’d advise looking a little outside of your direct field in order to gain a true outside perspective. Close friends are unlikely to ask the hard questions, and may just confirm the things you think you already know.

    It’s so tempting to think we know it all. It’s so easy to become inward looking, especially when working alone, or with a partner or close friend. I’ve come to realize just how valuable an outside perspective can be. I’d encourage every business to look for ways to get that kind of input.

  • Quantity Queries for CSS 

    Don’t you just hate documentaries that don’t deliver? They have enticing names like In Search of the Giant Squid, and tease you with shots of murky underwater shapes and excited scientists pointing far out to sea. You settle down to watch, eyes narrowed with suspicion, thinking, “I better see some squid or I’m writing an angry letter to the network.”

    Sure enough, 90 minutes of interviews with bored-looking fishermen later, the presenter is forced to conclude, “No… no, we didn’t find any big squids. But maybe one day [majestic orchestral flourish].” Great. You wanted Finding Nemo and got Not Finding Nemo instead.

    I wouldn’t do that to you, friends. This is your guide to creating style breakpoints for quantities of HTML elements, much as you already do with @media queries for viewport dimensions. I’m not pointing at some blurry specification in the distance or a twinkle in an implementer’s eye. We’re going to do this today, with CSS that’s already available.

    Dynamic content

    Responsive web design is primarily concerned with one variable: space. In testing responsive layouts, we take an amount of content and see which spaces it will successfully fit into. The content is deemed constant; the space, variable.

    The @media query is the darling of responsive web design because it allows us to insert “breakpoints” wherever one layout strategy ceases to be viable and another should succeed it. However, it’s not just viewport dimensions, but the quantity of content that can put pressure on space.

    Just as your end users are liable to operate devices with a multitude of different screen sizes, your content editors are liable to add and remove content. That’s what content management systems are for.  This makes Photoshop mockups of web pages doubly obsolete: they are snapshots of just one viewport, with content in just one state.

    In this article, I will be outlining a technique to make CSS quantity-aware using specially formed selectors. I will be applying these selectors to one classic problem in particular: how to alter the display of items in a horizontal navigation menu when there are too many to suit the initial layout mode. That is, I will demonstrate how to switch from a display: table-cell to a display: inline-block layout when the number of items in the menu becomes “more than or equal to 6.”

    I will not be relying on any JavaScript or template logic, and the menu’s list markup will remain devoid of class attribution. By using CSS only, the technique honors the separation of concerns principle, according to which content (HTML) and presentation (CSS) have clearly defined roles. Layout is CSS’s job and, where possible, CSS’s only.

    Comparing the initial menu bar layout for fewer than six items with the layout for six or more items

    The demonstration is available on CodePen and will be referred to throughout the article.

    To help me illustrate this qualification of quantity, I’ll be employing diagrams of squids in the article to represent HTML elements. Green squids with ticks represent elements that match the CSS selector in question, red squids with crosses are unselected elements, and grayed-out squids denote elements that don’t exist.

    A key for the three squid symbols to be used in following diagrams. A green squid (for selected elements), a red squid (for unselected elements) and a grey squid for elements that don't exist

    Counting

    The key to determining the quantity of elements in a given context is to count them. CSS doesn’t provide an explicit “counting API,” but we can solve the same problem with an inventive combination of selectors.

    Counting to one

    The :only-child selector provides a means to style elements if they appear in isolation. Essentially, it lets us “style all the child elements of a particular element, if counting those children returns 1 as the total.” Aside from its stablemate :only-of-type, it is the only simple selector that can be described as quantity-based.

    In the following example, I use :only-of-type to add a special style to any buttons that are the only elements of their element type among sibling elements. I give these lone buttons an increased font-size because singularity suggests importance.

    
    button { 
      font-size: 1.25em;
    }
    
    button:only-of-type {
      font-size: 2em;
    }
    
    

    Here’s the crucial part. If I were to start out with one button, replete with a larger font size, and add buttons before or after it, each button would then adopt a smaller font size. The style of all the elements in the set is dependent on a quantity threshold of two: if there are “fewer than two” elements, the larger font size is honored. Take a look at that code again with the “fewer than two” notion in mind:

    
    button {
      font-size: 1.25em;
    }
    
    button:only-of-type {
      font-size: 2em;
    }
    
    
    The fewer than two logic means one selected element (green squid) becomes two unselected elements (red squids) when an element is added

    If it feels more natural, you can turn the CSS logic on its head using negation and make the condition “more than one.”

    
    /* "More than one" results in a smaller font size */
    button {
      font-size: 2em;
    }
    
    button:not(:only-of-type) {
      font-size: 1.25em;
    }
    
    
    The more than one logic means one unselected element (red squid) becomes two selected elements (green squids) when an element is added

    Quantity n

    Styling elements based on the “more than one” and “fewer than two” thresholds is a neat trick, but a flexible “quantity query” interface would accept any quantity. That is, I should be able to style “more than or equal to n” for any value of n. Then I can style “more than or equal to 6” in our navigation menu.

    With a view to achieving this final goal, what if I were able to style discrete quantities like “exactly 6 in total” or “exactly 745”? How would I go about that? I would need to use a selector that allowed me to traverse sets of elements of any quantity numerically.

    Fortunately, the :nth-last-child(n) selector accepts the number “n”, enabling me to count sets of elements from the end of the set toward the beginning. For example, :nth-last-child(6) matches the element that is sixth from last among sibling elements.

    Things get interesting when concatenating :nth-last-child(6) with :first-child, introducing a second condition. In this case, I am looking for any element that is both the sixth element from the end and the first element.

    
    li:nth-last-child(6):first-child {
      /* green squid styling */
    }
    
    

    If this element exists, the set of elements must be exactly six in quantity. Somewhat radically, I have written CSS that tells me how many elements I am looking at.

    Of six squids, the first is green and the rest red. The first is subject to the nth-last-child(6) selector as well as the first-child selector

    All that remains is to leverage this key element to style the remaining elements in the set. For this, I employ the general sibling combinator.

    Six green squids because the first green squid is combined with the general sibling combinator to make all the red squids that follow green

    If you’re not familiar with the general sibling combinator, the ~ li in li:nth-last-child(6):first-child ~ li means “any li elements that occur after li:nth-last-child(6):first-child.” In the following example, the elements each adopt a green font color if there are precisely six of them in total.

    
    li:nth-last-child(6):first-child, 
    li:nth-last-child(6):first-child ~ li {
      color: green;
    }
    
    

    More than or equal to 6

    Targeting a discrete quantity—whether it’s 6, 19, or 653—is not especially useful because it pertains to such a specific situation. Using discrete widths rather than min-width or max-width in our @media queries would be similarly unhelpful:

    
    @media screen and (width: 500px) {
      /* styles for exactly 500px wide viewports */
    }
    
    

    In the navigation menu, I really want to switch layouts at a threshold: a quantity watershed. I want to switch at six or more items—not exactly six items. When I reach that threshold, I would like to change from a distributed table layout to a simpler, wrappable inline-block configuration. Importantly, I would like to retain that switched configuration as the number of items further increases.

    The question is, how does one begin to construct such a selector? It’s a question of offsets.

    The n+6 argument

    Another arithmetical argument adoptable by the :nth-child() selector takes the form “n + [integer]”. For example, :nth-child(n+6) styles all the elements in a set starting from the sixth.

    A set of red squids that become green at the sixth squid for the remainder of the set (which can be of any size), counting upwards.

    Though this has conceivable applications all its own, it’s not a “quantity-aware” selection method as such: we’re not styling anything because there are six elements or more in total; we’re just styling the ones that happen to enumerate higher than five.

    To begin solving the problem properly, what we really need is to create a set of elements that excludes the last five items. Using the opposite of :nth-child(n+6):nth-last-child(n+6)—I can apply the switched layout properties to all “last elements” starting from the sixth, counting back toward the beginning of the set.

    
    li:nth-last-child(n+6) {
      /* properties here */
    }
    
    

    This omits the last five items from a set of any length, meaning that when you reduce the length of the set below six, you cease to see any selected items. It’s a sort of “sliding doors” effect.

    A set of green squids (to the left) and red squids (to the right) become a set of just red squids when the set becomes fewer than six in number

    If, indeed, the set is greater than or equal to six in total, then all that remains is to style those last five items as well. This is easy: where there are more than six items, one or more items that “return true” (in JavaScript-speak) for the nth-last-child(n+6) condition must exist. Any and all of these extant elements can be combined with “~” to affect all items (including the last five) that follow it.

    When a set of red squids has squids added to it, the squids to the right of the set become green and can be used to make the rest of the red squids green too (with the general sibling combinator)

    The surprisingly terse solution to our problem is this:

    
    li:nth-last-child(n+6),
    li:nth-last-child(n+6) ~ li {
      /* properties here */
    }
    
    

    Naturally, 6 can be replaced with any positive integer, even 653,279.

    Fewer than or equal to n

    As in the earlier :only-of-type example, you can turn the logic on its head, switching from “more than or equal to n” to “fewer than or equal to n.” Which brand of logic you use depends on which state you consider the more natural default state. “Fewer than or equal to n” is possible by negating n and reinstating the :first-child condition.

    
    li:nth-last-child(-n+6):first-child,
    li:nth-last-child(-n+6):first-child ~ li {
      /* properties here */
    }
    
    

    In effect, the use of “-” switches the direction of the selection: instead of pointing toward the start from the sixth, it points toward the end from the sixth. In each case, the selector is inclusive of the sixth item.

    nth-child versus nth-of-type

    Note that I am using :nth-child() and :nth-last-child() in the preceding examples, not :nth-of-type() and :nth-last-of-type(). Because I am dealing in <li> elements and <li>s are the only legitimate children of <ul>s, :last-child() and :last-of-type() would both work here.

    The :nth-child() and :nth-of-type() families of selectors have different advantages depending on what you are trying to achieve. Because :nth-child() is element agnostic, you could apply the described technique across different element type siblings:

    
    <div class="container">
    
      <p>...</p>
    
      <p>...</p>
    
      <blockquote>...</blockquote>
    
      <figure>...</figure>
    
      <p>...</p>
    
      <p>...</p>
    
    </div>
    
    
    
    .container > :nth-last-child(n+3),
    .container > :nth-last-child(n+3) ~ * {
      /* properties here */
    }
    
    

    (Note how I am using the universal selector to maintain element agnosticism here. :last-child(n+3) ~ * means “any element of any type following :last-child(n+3).”)

    The advantage of :nth-last-of-type(), on the other hand, is that you are able to target groups of like elements where other siblings of different types are present. For example, you could target the quantity of paragraphs in the following snippet, despite them being bookended by a <div> and a <blockquote>.

    
    <div class="container">
    
      <div>...</div>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <p>...</p>
    
      <blockquote>...</blockquote>
    
    </div>
    
    
    
    p:nth-last-of-type(n+6),
    p:nth-last-of-type(n+6) ~ p {
      /* properties here */
    }
    
    

    Selector support

    All of the CSS2.1 and CSS3 selectors used in this article are supported in Internet Explorer 9 and above, including all reasonably recent mobile/handheld stock browsers.

    Internet Explorer 8 support is good for most selector types, but technically partial, so you might want to consider a JavaScript polyfill. Alternately, you could pair the selectors for the “safer” of the layout strategies with IE9-specific classes. In the case of the navigation menu, the safer option is the one catering to more items, using inline-block. The declaration block would look something like this:

    
    nav li:nth-last-child(n+6),
    nav li:nth-last-child(n+6) ~ li, 
    
    .lt-ie9 nav li {
      display: inline-block;
      /* etc */
    }
    
    

    In the real world

    Suppose our navigation menu belongs to a content-managed site. Depending on who is administering the theme, it will be populated with a greater or fewer number of options. Some authors will keep things simple with just “Home” and “About” links provided, while others will cram their menu full of custom page and category options.

    By providing alternative layouts depending on the number of menu items present, we increase the elegance with which we tolerate different implementations of the theme: we address variable content as we might variable screen dimensions.

    Comparing the initial menu bar layout for fewer than six items with the layout for six or more items

    So, there you have it: squid ahoy! You can now add quantity as a styling condition to your repertoire.

    Content-independent design

    Responsive web design solves an important problem: it makes the same content comfortably digestible between different devices. For folks to receive different content just because they have different devices would be unacceptable. Similarly, it’s unacceptable for a design to dictate the nature of the content. We wouldn’t tell an editor, “Lose that, will you? It makes the design look wrong.”

    But what form the content takes, and how much of it there is at any one time, is frequently indeterminate—another unknown. And we can’t always rely on text wrapping and truncation scripts. To get a real handle on content independence, we need to develop new tools and techniques. Quantity queries are just one idea.

    Web design is about mutability, difference, uncertainty. It’s about not knowing. Uniquely, it is a mode of visual design not about manifesting a form, but about anticipating the different forms something might take. To some it is unbearably perplexing, but to you and me it is a challenge to relish. Like the elusive giant squid, it is a seriously slippery customer.

  • Stopping the Infighting About Digital Standards 

    I grew up in Columbia, Maryland, a planned community (see Figure 5.1). And as with the word “governance,” people tend to react to the phrase “planned community” in a not-so-positive way. “Planned” sounds dull and uncreative to people: cookie-cutter homes, on cookie-cutter lots, on cookie-cutter streets—“Little Houses Made of Ticky Tacky,” to invoke Malvina Reynolds’ well-known song. And Columbia was all about that: a city built quickly based on a template. There were street naming conventions, standard model homes, standardized lot sizes, and a standard “village” configuration complete with strategically placed shopping and swimming pools.

    Map showing the neighborhoods of Columbia, Maryland.
    Figure 5.1: Columbia, Maryland—a planned community that opened in 1967.

    So what do you get when you build a city on a standards-based framework? Those who focus on the standards part like to say “boring,” “all the same,” “not diverse,” because they believe that any standardization leads to a lack of creativity or innovation. But that wasn’t all there was to it. Once you factor in the context and intent of Columbia, the picture becomes different. Columbia was one of the first planned communities intended to be racially and economically integrated. Its founder, James Rouse, had a vision about creating a place for people to live—a place that would make you feel good, a place where everyone would just get along. And there was the timing: Columbia was founded in the mid-sixties and started its initial growth spurt in the 1970s.

    In standardized fashion, villages and neighborhoods were often named after literary figures with streets being named after lines in their works. That standard resulted in street names like Evening Wind Lane, Wood Elves Way, and Plaited Reed. No Main Street. No Church Street. No School Street. Sure, there are some boring people in Columbia, but Columbia has spawned some interesting people, too, including the following:

    • The late Randy Pausch: The Carnegie Mellon professor who gave us “The Last Lecture: Really Achieving Your Childhood Dreams.” This one touched home, as his mother was an English teacher at the high school I attended.
    • Michael Chabon: Pulitzer prize-winning author. I like to think that Mike’s rich writing style was informed by the literary tradition of Columbia street names. But that might be a stretch. I think he just has a gift.
    • Dave McClure: Founder of 500 Startups and a rule-breaker if ever there was one.
    • Aaron McGruder: Of The Boondocks comics fame; another iconoclast.
    • Edward Norton: Okay, he’s just the grandson of James Rouse, but cool nonetheless. I mean, Fight Club, right?

    All this is to say that, contrary to popular belief from some of my clients, standardization does not have to give way to things boring or flat or uninteresting. It doesn’t mean that the standardized interface can’t be beautiful, or that your customer’s experience of your seamlessly integrated process that takes them from desktop to mobile to call center won’t be sublime. The belief that standardization necessarily leads to the boring and uninteresting is too simple. It’s what’s going on inside the structure that is important. You could have a beautiful, old, organically grown, charming town with nothing creative going on for it except that it looks good. Or you can have tract housing turning out really interesting people, music, and thought. It’s all about the substance and interactivity of the interior. What comes out of a community, planned or unplanned, is really contingent upon the intention and people within it.

    So, if you’re going to take the time to establish and implement a standards framework, it had better be around the right intention. And that intention is expressed through your digital strategy. Your standards are the tactical manifestation of your strategy that will bring into existence the intent of your digital strategy. That’s why organizations that have no real digital strategy struggle so much with coming up with a quality online presence and why their digital team spends so much time arguing and debating about standards. In the absence of clear business intent, standards can be left up to a matter of taste and debate. So, if you are undertaking to develop standards without first having defined a digital strategy, you may develop a standards compliant website and have consistently moderated social channels. But your digital target will likely not resonate as well as it could with your customers. Only standards derived from clear vision have the capacity to create a high user experience and deliver on the mission of your organization.

    I was lucky. I learned early that standards could enable rapid growth and provide a framework for coherent development, all the while creating a space for real creativity. Standardization can be, and often has been, the platform for creative and important work. But I’ll go further. Standards, in fact, might be an essential ingredient.

    Standards frame and limit what you can do so that you can get across a certain message or get a particular piece of work done. And that’s the message you should carry to digital teams who are reluctant to adopt a standards-based framework. Likewise, you can have a World Wide Web operating within the open standards of the W3C with the whole of humanity trying to express itself freely and creatively, or you could have something else, like an Internet and Web controlled by a few businesses and political interests. It’s about clarity of intention and the quality and sustaining quality of your implementation. It’s about having a vision and figuring out how to make it happen and holding true to your aims and your standards.

    Why Digital Standards Are Important

    Practically speaking, having digital standards enables an organization to put into place details for execution so that digital work can be performed consistently and effectively. From a governance perspective, knowing who has the authority to define standards saves time by minimizing the time that resources spend making decisions about the same factors, over and over again. For instance, it’s good to know which Web browsers your organization’s digital presence supports, what fonts you use for mobile applications, and when and where it’s acceptable to use your organization’s mark. It might also be good to know that your organization operates on a .NET platform, or that when you refer to staff on a public website it’s always “Ms. Welchman” and not “Lisa.”

    In an ecommerce environment, standards make sure that the right content gets to the right customer at the right point in the sales cycle. For example, it’s good for customers to know that whatever they are buying on a site, the sales checkout process will be the same. And it makes customers more comfortable knowing that whether they are purchasing a pair of trousers or a jacket, they will still have the same interface for toggling between garment color choices. In addition, it doesn’t just make the user’s task easier to accomplish, it also takes stress off internal digital workers.

    Adopting a standards-based framework takes the stress out of development. When you have standards in place, more time can be spent having conversations about the substance and purpose of the work that is to be done instead of arguing about the details of execution or who has the authority to make decisions about application coding standards or a graphical user interface.

    An organization’s digital standards steward’s job is to establish and maintain a standards-compliant environment within the organization (see Figure 5.5). Standards compliance exists in an environment where certain activities have occurred:

    • Standards have been defined and documented.
    • Standards have been effectively disseminated to all digital stakeholders.
    • Standards have been implemented.
    • Standards compliance is measured and managed.
    Illustration of the forces that influence the cycle of standards compliance.
    Figure 5.5: Creating a standards-compliant environment.

    The reason why most organizations have trouble with standards compliance is because they miss or incorrectly address these activities and then are only left with one alternative—to enforce (usually undocumented) standards after the non-compliant content and applications are already posted (or nearly posted) online. This reactive dynamic can lead to a stressful dynamic for digital teams. Too often, the core digital team is perceived as the last-minute bad guy, telling teams that the look and feel isn’t right or that the flow of the application screens is unusable.

    The core digital team shouldn’t be in the position of having to ask their colleagues to remove content and applications that might represent weeks or months of effort. In the best of cases, the organizational standards steward is not an enforcer, but someone who is able to create an environment where bad things don’t get online in the first place. Let’s take a look at what the standards steward does to make that happen (see Table 5.1).

    Table explaining the differences between policies, standards, and guidelines.

    Standards Definition and Documentation

    If you want your extended digital team to follow your standards, it’s important to write them down. This might seem self-evident, but many organizations, when asked, are unable to produce documentation of the standards that they claim their stakeholders will not comply with. This “I’m an expert, so do what I say” dynamic is hardly fair to digital stakeholders because these stakeholders often have some digital domain expertise and are heavily impacted by the business outcomes of their online efforts (so they are informed and they have a vested interest). Here are a few things to keep in mind when documenting standards.

    • Develop a standard for documenting standards. The first standard you should define is the structure you will use to document your standards. Having a consistent format for standards will allow your digital team to be able to access the information more efficiently and will enable you to consistently cross-reference standards. You also want to consider the platform you will use. A wiki can be a good platform for documentation. It allows for revision and version control and can be accessed by multiple standards authors. Some standards can also be integrated with various digital production systems [like a Web content management system (CMS)] so that the standards appear in the context of a workflow. For instance, there might be ready access to editorial and design standards within the context of a text editor in a CMS.
    • Determine what should be a standard. There is almost an endless list of standards that can be defined. It’s important to figure out which ones are most relevant to your organization. For instance, if your organization is getting ready to ramp up on mobile, standards related to responsive design might be important. Or, if your organization’s aim is multichannel content delivery, component content authoring standards might be a priority. Sometimes organizations will place high priority on documenting standards that have caused a lot of debate, such as graphical user interface or information architecture. Let your own organizational dynamics drive the standards prioritization process.
    • Leverage what you already have. The standards steward will also need to understand what standards your organization has already documented or where a digital standard can be largely informed by an already existing standard. Brand guidelines, style guidelines, applications development protocols, compliance mandates, and records management schedules are examples of information that might help inform or greatly impact the substance of your standards. It’s important to perform an audit and detail what information exists and where it is. That way, when standards authors sit down to write standards, you’ll be able to reference relevant standards easily and consistently.

    Standards Dissemination

    A common problem in digital teams is that they’ve often forgotten that their internal digital stakeholders are users as well. Typically, the experience of accessing and understanding digital standards for internal users in organizations is very low. For example, if you are a digital stakeholder trying to understand the rules of development for your organization, you are probably not interested in browsing through a beautifully designed PDF of a style guide. You just want to find the information quickly so you know, say, what font color to use for a visited link reference. The digital standards steward can help facilitate that information by being more strategic about standards dissemination.

    • Tell people about the information. If you have established a digital community of practice (CoP) inside your organization, be sure to discuss new standards and standards revisions as they arise. Frequently, resources aren’t told that a standard has changed until the standard is violated. Digital CoPs are effective because they bring together all the people in your organization who work with your digital channels. As you’ll see in Chapter 8, “The Decision To Govern Well,” these communities are ideal for sharing information and for training.
    • Web- or Intranet-enable your standards repository. It is essential to produce standards in Web-ready format. Often, digital standards are authored in word processing applications or published as large PDF files. Instead, organizations should make an effort to leverage the power of the hyperlink, making it easy for stakeholders and developers to click through to corresponding and related digital standards (and policy) to get the whole picture. Sometimes, there may be standards that individuals would not typically seek on their own, but might be relevant to their work at hand.

    Standards Implementation

    Digital standards stewards usually feel that their job is complete when they have documented the standards and placed them online. In reality, their job has just begun. The real work lies in ensuring that the standards are implemented.

    • Use tools. When possible, an organization should use tools to implement and ensure compliance with digital standards. If content contributors and developers must build through a narrow standards-based gate in order to get their content on the server, it’s less likely that you will end up with “rogue” or non-compliant content and Web pages. You can help support the implementation of standards for visual design page structure by establishing templates in a Web content management system. For example, you can raise the quality of writing by implementing an editorial review process and workflow. If you have certain metadata tagging requirements for an online catalogue, you might implement a sophisticated auto tagging system. This is a straight gate and narrow way, however, and not all outcomes can be achieved via tight constraints. Certain standards, particularly some editorial and design standards, need to be implemented via other means, such as employee training and education.
    • Training and education. Not everything that is a standard can be implemented with a tool. Certain editorial concerns, for instance, might require training from internal or external experts. Many teams have found value in providing education for areas like writing for the Web or graphic design for the Web. You often won’t get 100% standards compliance with training and education. People are unique, and they will interpret standards in different ways. At the end of the day, this means that you need to staff your digital team with the right people and trust them to do their job correctly.

    Standards Compliance Measurement

    Hopefully, if you have defined, disseminated, and implemented your standards well, compliance will be high. Still, websites and intranets are large, complex environments. Even in the best of circumstances, standards will be misunderstood or ignored in haste. That is why it is import to measure standard compliance in a consistent and automated way. You can monitor standards through spot checks and prepublication reviews, but in a large production environment, this is often a daunting task. Implementing a website auditing tool is often helpful because it allows the core digital team to provide quantified reports on things such as broken links, terminology language use, usability, compliance, and SEO. Reporting back to stakeholders about which standards they are upholding and which they are not, and creating a plan to lead the team to higher rates of compliance, is a more positive method of standards enforcement than threats that content or applications will be removed from the server.

    Even after you’ve implemented your standards lifecycle, there will still be exceptions to the rule. There will be times when digital workers will want to break with the standards. And then each organization will have to determine when it’s okay to break the rules and when it’s not. These types of situation can be touchy, particularly if the resources involved in the standards breach are fairly senior in the organization (like a CEO who insists on having the picture on a homepage or wants to write lengthy, dense blog posts). In the end, these types of situations will have to be negotiated by the standards steward, authors, and the “standards breaker.” During the discussion and negotiation, it is important to emphasize how the business is being put at risk due to a standards breach and how the business could benefit if the standards were complied with. At the end of the day, you’ll never have 100% compliance, but hopefully the vast majority of your digital presence will follow the rules as defined by digital standards authors.