Context Makes Our Devices

Source: A List Apart

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.


Read the full article


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

Source: A List Apart

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.

Read the full article


This week’s sponsor: Beagle

Source: A List Apart

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.

Read the full article


Envisioning Experience Outcomes

Source: UXMatters

By Jim Nieters and Pabini Gabriel-Petit

Published: April 20, 2015

“When your organization’s goal is to differentiate on the experience, you must start every product-development project by defining the experience that you want people to have with your product or service. ”

When your organization’s goal is to differentiate on the experience, you must start every product-development project by defining the experience that you want people to have with your product or service. Companies that differentiate on the experience do not begin by defining feature sets. They first define a vision for the experience outcome that they intend to deliver to their users and customers. Only once your team fully understands the experience outcomes that you want users to have can you make good decisions about what features and technologies would optimally support that vision.

This is the fourth column in our series about what companies must do if they want to stop producing average user experiences and instead design great experiences. As we have already stated in our previous columns, great UX teams focus on differentiating their companies through design. If that’s your goal, you need to work for a company that shares your aspirations.
Envisioning Experience Outcomes


Can Good Design Be Measured?

Source: UXMatters

By Pamela Pavliscak

Published: April 20, 2015

“Teams need to have a way to know whether they’ve achieved their goal.”

Recently, I was invited to speak about this topic for the Collision Conference, which is coming up in May: Can good design be measured? This is a great, complicated tangle of a question. Immediately, I started thinking of ways to answer it. If it’s a question I’m supposed to answer it, right?

Can Experience Be Measured?

Answer 1: Yes, because we have to measure it. Teams need to have a way to know whether they’ve achieved their goal. Sure, it’s great to have a happy-customer story or even deep insights from contextual research, but teams also need to know where we’ve been, where we are right now, and where we’re going—and data tells us all of that. Usually, that data needs to tie into what an organization values, whether money earned or lives saved.

Answer 2: Yes, because it helps us to understand people in a different way. A good measure will tell you more than you knew before. It can tell you whether regular visitors to your site are spending more or less time on the site on each subsequent visit. That doesn’t tell you much about the design—and just a bit about the experience as a whole. But measures can also tell you whether people are reading long posts all the way through or which details seem to get the most attention. This may tell you something new and provide a good jumping off point to learning more.
Can Good Design Be Measured?


UX STRAT 2014, Part 1: Overview and Workshop Reviews

Source: UXMatters

By Pabini Gabriel-Petit, with Jim Nieters

Published: April 20, 2015

“UX STRAT 2014 was again a single-track conference, so all attendees shared a common experience.”

The UX strategy tribe gathered once again for the UX STRAT 2014 conference in picturesque Boulder, Colorado, at the foot of the magnificent Rocky Mountains. After a day of pre-conference workshops on September 7 at the beautiful Hotel Boulderado, the main conference convened for two days, on September 8 and 9, just one block away at the lovely Art Deco Boulder Theater.

In this review, I’ll provide an overview of the conference, covering the same dimensions as the star ratings to the right, and Jim Nieters and I will review four of the workshops that took place on Sunday, September 7.


Paul Bryan, producer of UX STRAT 2014, who is shown in Figure 1, did a great job of organizing another excellent and enjoyable conference. I was really glad that UX STRAT 2014 was again a single-track conference, so all attendees could share a common experience. As Paul promised in his UX Strategy column on UXmatters, “UX STRAT 2014: Focusing on UX Strategy,” “Experienced UX strategy professionals will present their approaches to guiding UX projects, products, and programs.” This year, Paul decided to dispense with panels and vignettes, which allowed more speakers more time for in-depth explorations of their topics. In my view, these were good decisions.
UX STRAT 2014, Part 1: Overview and Workshop Reviews


How and When to Involve Stakeholders

Source: UXMatters

By Janet M. Six

Published: April 20, 2015

Send your questions to Ask UXmatters and get answers from some of the top professionals in UX.

In this edition of Ask UXmatters, our panel of UX experts discusses several ways of involving stakeholders at different stages of a project.

What are the best ways to involve stakeholders in the research and design for a project—especially when you have a large number of them. Do you bring all of them into an initial design meeting? Or wait until you have a solid first design? Or should you wait to involve stakeholders until you have a very strong, well-iterated design? How should you best handle the different types of stakeholders—for example, those who will actually use the product versus those who would decide to buy the product.
How and When to Involve Stakeholders


Website Accessibility: The Untapped Global Income Stream

Source: UXMatters

By Ben Newton

Published: April 20, 2015

“I know of a relatively untapped market that, in the USA alone, accounts for over 12% of the entire population…. This market is, of course, people with disabilities (PWD), which has an estimated world-wide population of 1.3 billion people….”

“How does accessibility fit into our development and content strategy?” If I had a dollar for every time I’ve heard this in a meeting about a Web site or app, I’d be, well, only a dollar or two richer. In the ten years I have been developing digital products for clients and agencies, I could count on one hand the number of times we’ve discussed Web site accessibility.

Perhaps, as the knowledgeable developer, I should be raising my hand as the one who is culpable and accepting the blame for this. After all, shouldn’t I be championing all relevant standards that would lead to my Web sites being pillars of the Internet? This would be ideal. However, on the occasions when I’ve done this, I’ve encountered the all-too-familiar blank stare washing over the faces of decision makers, as my suggestions sail over their head as they wait for their turn to talk. And, when their turn does come, what they say usually takes the form of praise, followed by a request that I fit as much work as possible into half of the amount I’ve quoted.
Website Accessibility: The Untapped Global Income Stream


What Really Matters: Focusing on Top Tasks

Source: A List Apart

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.

Read the full article


Standardization and the Open Web

Source: A List Apart

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.

Read the full article

Older posts «