« TPAC 2007 - Let's start | Main | TPAC 2007 - HTML 5, XHTML 2.0, Future Formats »
TPAC 2007 - "Real World Perspectives on the W3C" panel
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
Q&A
- 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
Filed by olivier Théreaux on November 7, 2007 9:36 AM in Meetings, W3C Life
| Permalink
| Comments (3)
Comments
For most, frustration is not with the specs, but with the implementations.
I think this is the most vocal frustration because it is the most visible. But as we dig into what I view as an entire system of work I think we will be able to see more gaps and have a better understanding as to where the root causes of these problems lie.
That system of work extends from the W3C, to the browser makers that implement (or don't) the standards, to designers/developers, to the people who pay the designers/developers, and to end users.
There are likely more audiences that we need to take into account but that's probably one of the reasons we bash the browser makers so much; because we don't understand the landscape completely.
The basic principles of creating anything (in my idealistic world) consider who will use it and how they will use it. I think these are important principles to consider moving forward.
I feel like the core of the issue seems to have been missed here -- the problem is not with the level of W3C's openness, education, or in fact any of the efforts of the W3C -- but instead the issue is the W3C itself. Creating tests and "communicating with communities" sounds excellent on paper, but what will come of it if the public image of W3C remains the same?
Every serious developer that I know has one of two visions of the W3C:
* What, you mean the validator?
* Bureaucratic do-nothing spec-writers
I don't say this to insult anyone, but rather kick us back to the realization that the W3C doesn't speak to it's core target group (developers). Developers who attend W3C conferences rarely speak toward the majority of developers.
How to fix this? Radical change. Small changes over time will be of no use if no one's listening. The W3C needs community evangelists -- people like Ted Patrick, Tim Sneath. They need to contribute with the community, not to the community.
I'd say even this entry shows a bit of that preaching attitude -- for instance, what's TPAC? Sorry -- I've been too busy developing web sites ;) But it speaks to my point that the W3C is far more concerned with proclamations than working with developers. This is my own view, and one I know several other developers share.
Leave a comment
Note: this blog is intended to foster a polite, on-topic and interesting discussion. Comments failing these requirements and spam will not get published; others will appear on the entry page after review by the staff. This may take some time: thank you for your patience.
I think there a few other salient points we can summarise:
One of the points that Matthew made is that it's difficult to justify relevance of standards to the corporate world due to the cost of learning and training the team, and also the cost of debugging when the browser implementations are different. One of the few ways he finds he can justify standards through usability measured in terms of page weight. There's also a lack of understanding of how the standards are being used and abused in the real world. My example is the number of "email campaigns" that companies believe are a good way to market and advertise their products; the inconsistent handling of HTML/CSS in email clients is a cost factor and a lot of bad code. Clearly, there needs to be some strategic thinking into how we should establish common baselines between user-agents about what should be implemented, but perhaps this is only through fair and open discussion across all parties that are affected by the specifications.
Aaron mentioned some of his work with CSS11 and the CSS working group in helping to identify ambiguities and create use cases and test cases. This is certainly a welcome direction, and in a post conversation, we discussed how most members of the community would be happy to assist if they feel the are being listened to.