The Web Standards We Need: Part I — Tightening the Feedback Loop (an experiment)

The Web is 25 this year, and on this its silver anniversary, there is a new campaign called (The) Web We Want organizing efforts around 5 guiding principles all about keeping the Web a place for free expression, decentralized infrastructure, privacy, affordability and neutrality. It’s a good effort. I applaud it. But it’s all for naught if the Web can’t survive and thrive in the first place. The Extensible Web Manifesto and articles about it lay out a new vision, but we need to carry through in practice. Specifically in my next two posts, I’d like to talk about one thing: Participation in standards — tightening the feedback loop and some new efforts to create the Web Standards We Need.

In reality, developer adoption is perhaps the most important element in a successful standard. It well outweighs technical purity or standards body approval. You need look no further than the specs we use compared with the ones we do not to see proof of this: Many failed standards are technically superior, but lost out for other reasons. Indeed, HTML itself is a less technically pure/capable offshoot of SGML and the more robust XML re-attempt also ultimately has largely lost out. Yet, many things we do use started out as low-end challengers to the standards.

There are many tens of thousands of Web developers, yet they remain largely uninvolved, despite the fact that there are ways in which they technically could be involved. Standards bodies have made few efforts to consider this problem. Even with recent improvements, when you look at how many people are actually involved in the creation of a standard, in many cases they would all fit in my (rather small) bathroom. Further, they tend to be the same small group of folks (measured in dozens) and, somewhat homogenous at that. Why?

Understanding Barriers to Participation

There are a number of reasons that this is the case — a lot of them are historical legacy.

First, because most developers who haven’t been around since nearly the beginning are unaware that such opportunities to contribute even exist. Since the main modes of participation are somewhat antiquated (mailing lists and IRC) and not exceptionally discoverable, this fact winds up just off the radar of the vast majority of developers.

Second, it’s a giant leap of faith to jump into the fray: These forums are public and full of the most knowledgeable (and opinionated and occasionally stubborn) people — that can be very intimidating. You might think you’ve got a pretty good grasp on science, but it’s very likely you don’t want to seem to publicly challenge Stephen Hawking with your pet idea about string theory. In some ways, that’s not entirely bad, it helps manage the noise level — I’m simply offering the observation that it is a deterrent that has probably helped to keep good ideas out.

If you can get past all that, you’ll see it can be wildly frustrating. If you’re unfamiliar, a recent article on the <picture> element captures some of the challenges in recounting the trials and tribulations (but ultimate success) of the Responsive Images Community Group (RICG).

Finally, there have historically been numerous conceptual and business disincentives to developers, and companies who might otherwise allow them to contribute. Time is a huge one. Developers work on projects where weeks or months can be the time from start to finish, web standards operate on a comparatively glacial scale. Let’s imagine that you’re a manager at a company and a developer says “I’ve got a great idea for something and if it were standard it would lower costs to develop and maintain”. Isn’t it worth some time? Actually, no, in most cases — it’s not: Chances that you’ll get something spec’ed and implemented in time for your project are literally zero. Chances that it might be there for your next project are infinitesimally small as well. Next year maybe? Probably not, no, sorry.

It’s hard to be excited about things for years that may or may not someday deliver you some value.

And so it is that the majority of developers wait years for things that often fail to materialize at all, and frequently when they do and we are finally able to spend the time to learn and try them in a dizzying number of use-cases, we find them lacking or at best, underwhelming.

Removing Barriers: Challenges

There are several challenges to removing these barriers. The Extensible Web Manifesto lays out a few guiding principles that help: The aim of experimenting outside of browser implementations (prollyfills) means that it’s plausible that participation could actually yield you real value soon and allow you to provide feedback. But who is writing them? We need involvement. But what if suddenly even 1% of developers were involved in standards in the traditional fashion? We’d go from dozens of emails on a particular list in a day to thousands — and a whole lot of that would be noise. We need some concrete, new experiments toward fixing this problem.

Experimentation

To this end, several of us around the world have been consulting and we have something we’d like to try. We’re calling it “Chapters”.

Chapters aims to be a world-wide effort to establish local meetups and gather groups of interested parties for involvement in the standards process. The aim is to provide local outlets for developers of all grades of experience can come together to discuss developing standards in smaller groups according to their interests with the combined goals of education, larger participation and information gathering (tighten the feedback loop).

The general idea is that smaller, local groups choose and review a draft (potentially even submit one). They discuss — in person and digitally. The barrier to entry is low — new developers can be much less intimidated in a small, local setting where they aren’t the only non-wizard. Wizards, on the other hand can help mentor. This alone would yield good and useful feedback which is currently late and lacking: If after much help, the majority of people can’t understand something, standards bodies need that feedback. More importantly though, together they can look at prollyfills that simulate, attempt to use features before things get too far, attempt to make prollyfills where they don’t exist. Participants can write tests, discuss alternatives, etc.

Very importantly, all of this feedback can be collected, distilled and fed back upward into the standards bodies by way of unified notes and a single champion in a manageable way that is productive and less disruptive than a thousand independent voices shouting, and even if a standard doesn’t arrive, both sides get some real value from the proposition.

I am currently putting together partnerships with local colleges, universities and meetups in my area for an early pilot and the University of Vermont has graciously donated a space. So, if you happen to be near Burlington, VT in the US on Monday, September 8th — I’d like to invite you to stop by UVM’s Perkins Hall between 6:30 and 9pm and help us see what we can do. Of course, we’ll adjust and tweak as we learn — it’s an experiment, after all. If you’re not in this area, but find the idea interesting — leave a comment, or feel free to contact me via Twitter @briankardell or email bkardell@gmail.com.