What better way to kick in this TPAC meeting than with a panel tackling the perception of W3C in the “real Web world”? What happens when you ask a small group of developers, designers, experts of making the Web work in the wild, tell a room of a few hundred W3C participants and decision makers what their perspective is?
N.B: following is a very summarized and lacunary record of the panel, with a few thoughts thrown in. For a much more complete transcript of the session, see Justin Thorp’s take. Kudos.
This is a big deal, and if not a first, it feels like it: after being slapped around quite a bit for giving the impression of not listening and not being open enough, this organization is getting used to talking to its communities in a faster, more informal way (through blogging – that’s a start). And now it is giving the stage to people who have to make the web work now, not in 1 or 10 years, what they think of the W3C. What they think the W3C should be, should do. This is scary. This is exciting.
Patrick Haney, Matthew Oliphant, Stephanie Troeth, Aaron Gustafson and Molly Holzschlag talk about the difficulty of getting buy-in for standards-based work in their companies or with their clients. The specs talk to the developers and designers, but who talks to their manager? Specs address technical and sometimes social constraints, but in the real world, companies are trying to make money.
Voices echo in the large conference room, full, packed: people have to stand at the back of the room to listen to the panel switch to concerns over standard and innovation.
Where should competition take place?
If standards become standard, where will the competition be? For the panel, implementation of the standards should be a given, and the competition should be on UI, security, performance. This is an interesting take on where the innovation should be, but indeed, it’s the same in a lot of standardized fields.
How can we improve the W3C process
Here comes a big piece of meat. More openness would be welcome… but maybe it’s already there. It’s not the first time this morning this panel gets to the conclusion that the w3c is not inherently broken, it just needs to communicate better. Where there is openness (public groups, public feedback, public lists), can W3C advertize it better?
We are reaching a tough point: the W3C process must be more agile. Agreed by all. The waterfall model doesn’t work. That too gets some agreement amongst the 5 on stage. But how does one speed things up while still making sure that “everyone gets their say”, which is one of the thing the W3C process tries to ensure?
Making W3C faster while including more people, getting more and more open, will be an incredible and exciting challenge, but worthwhile.
Paraphrasing Matthew… “when someone faces a technology that doesn’t work, or an unusable site, they don’t blame the W3C, they don’t blame technology: they blame themselves, they feel stupid”. Better testing and better implementations (consistent at least) would be a big progress in improving the Web experience.
How do we address the critical challenge of outreach and education?
Call to action. W3C isn’t a marketing organization, as mentioned earlier, but education is key to moving the web forward… which is core to W3C mission. How do we reconcile that?
Working more with organizations as advocating arm of W3C would work. Also touched on is the technical level of specs. Who are they written for? Is there a minimum level of technical competency needed to read W3C specs?
The panel ends the presentation with a shopping list:
- Create common baselines
- Clarify ambiguous specs
- Transparent development cycles
- Open dialog with the community (or should that be communities? — ot)
- (missed a few)
We move to Questions and Answers
- For most, frustration is not with the specs, but with the implementations.
- From the discussion between the floor and the stage, it almost looks like there are several “real worlds”.
- Håkon from opera brings the Acid test to the table. Browsers do try to implement, but tests are needed. Not always more tests. The Acid test, for instance, was a single test, but really efficient (because it was so easy to run – and so hard to pass?)
- Another world brings its concerns: huge companies with legacy content of 1 zillion web pages can’t rewrite their content every tuesday. As one participant on IRC notes, this is all the more interesting that big companies concentrate and make visible the problems of small companies