Prompted by two things, I continue this rant after more than a year's absence.
The first thing was a few lengthy discussions with the wonderful Bruce Lawson about "the state of the Web". Those discussions led me to point him to my post about "The View Source" principle. Bruce then linked to that in a tweet, but kindly withdrew the tweet in deference to my saying I thought it wasn't that well written and was not really intended for public consumption.
Bruce, while questioning how coherent it was to write a public blog and yet not want people to read it, respected my request not to be "outed". Well, he makes a good point, and the post by Mat Marquis that Bruce quotes and links to makes that point most eloquently: if I want things to change then I need to make my voice heard, irrespective of the quality of the writing that I don't have time to hone and adjust to the standards of what, say, a W3C spec deserves.
The second of the two things (also Bruce-inspired) led on from that, when Bruce pointed to the "meet the TAG" event that he writes about.
Kudos to incoming TAG co-chair and my former W3C Mobile Web Best Practices co-chair, Dan Appelquist. The rest of this post is to comment that while I applaud W3C's spirit of openness and desire to target one of its constituencies, I think it needs to think about what it want to get out of that, and how much change that actually entails to W3C fundamentals and working practices to be really worth while.
The third (of two, think Monty Python) is discussion in the W3C "Closing the Gap" Initiative. I've been meaning to contribute to that list on a whole range of things, but in an echo of what follows, simply haven't (as a developer, or a development manager) found the time. One of the topics that has come up has been exactly the point of developer feedback and how it can fall on stony ground ... what's here also serves as a contribution to various threads there.
Both Bruce's post and the comments on it are really interesting and raise a panoply of questions. I'll try to keep the following focussed.
W3C - Not a place for "developers"
In comment 2 on Bruce's post, what Karl says resonates strongly. My day job has me responsible for a team delivering real (mainly mobile) Web sites for real companies on real and limited budgets and very real difficulties explaining to our customers what kinds of guarantees we can make about how well it will all work.
Like Karl I too have "previous" with W3C. To think that anyone who is not paid to do so has the time, commitment and (frankly) tedium thresholds to engage with the W3C process is "unrealistic". And what purpose would that actually serve?
Coherent output from W3C as a whole
W3C works in the way it does, which is that it represents the interests of member companies to join together to do stuff for mutual benefit and to try to arrive at coherent and compatible outcomes of feature standardisation.
What it doesn't appear to do is to ask, or require, is that the efforts of the working groups cohere properly into some kind of whole. Andrew's point (comment 5) about the complexity of the Web is presumably a result of that. Kudos to Andrew and FT Labs for joining in at the W3C - irrespective of his modesty most of us think we have a serious amount to learn from him and his colleagues.
The result of feature by feature standardisation does not appear to have an emergent property of coherence of the features taken as a whole. Surprise!
What would a jobbing Web developer want from the Web?
Broadly speaking I don't think Web developers care one way or another about how a feature is implemented. "I don't care, I just want it to work reliably" might be a common answer. A possibly more helpful answer might be "I don't care, but please make sure it works with x, y and z." However, that kind of answer would presuppose that your jobbing Web developer knows about a sufficient range of features x, y and z to be able to articulate that response.
Most Web developers would struggle to make a response like that. It's because in general, a Web developer is task focussed in trying to deliver a specific outcome - and their boss (me, for some small set of unfortunate souls) is going to be quite reluctant to explore the solution space beyond what seems like a pragmatic answer to the question they are trying to answer (on a restricted budget).
So, ask a Web developer what they want (or what their boss wants), it might be:
a) less complexity of the whole Web standards shooting match,
b) some properly articulated answers about layering and structuring that allow innovation and evolution of the underlying standards, without causing major and minor fracture points that result in "develop once, work-around everywhere",
c) some consistent ordering of implementations (OK, profiles if you like) so that for any project you do not have to have a stadium size wall chart of feature x browser x version conformance - and can with some reliability say that there are bundles of features that you can rely on being present together.
If what developers want is easily articulated, what's the problem?
If you accept (for the sake of argument, at least, for the moment) that individual developers don't care about the finer points of individual feature specification, they just want the feature - where should the idea that the Web as a whole should have developer friendly properties be articulated? Well the TAG maybe?
That would be great, but aside from the Architecture of the World Wide Web, what are the work outcomes that the TAG supposes that will (eventually) result in increased coherence, decreased complexity and what not? And how would you measure that anyway?
Bruce asserts that under the current W3C process the Web that has emerged is successful. "I don't disagree"™ with that assertion, up to a point. However, as I argue in the premise behind writing this blog in the first place, I think the Web could be more successful and I think there is a danger that its future success is compromised by an assumption that past successful process will lead to future successful outcomes.
The Web is W3C's Flagship Product
So what I'd like to see is that the Web, though in many ways a social construct, is viewed by the W3C as its product, and that product management is required in order to make good products.
I believe that the emergent uses of the Web and its specific features, that go way beyond its original creators' intentions, remains an essential feature and objective. Saying that it is a product does not a priori compromise an objective of wanting openness and (deliberately) stimulating emergent properties. What past experience does say, however, is that coherence, comprehensibility and layering doesn't appear to be an outcome of that approach, and does require careful deliberation.
So, TAG, yes, please, make sure you define your constituencies, or actually those of the W3C. Billions of people are the users of the Web. For them to enjoy a usable experience a massive number of Web developers is needed, and the task of mastering the Web to a level of competence that allows for cost-effective reliable outcomes is beyond reasonable expectations of developer training and skill. In fact, today, many simple use cases can't be addressed because of fractures, major and minor.
However, and this is a big however, surely people don't "write" Web pages on a mass scale anyway, and surely people who create content on the Web do so via tools and intermediaries, Facebook to name but one. So in saying that W3C wants to engage with developers, that's great, but for widespread adoption surely the job of the W3C is to encourage a widespread ecosystem of intermediary tool vendors, of various kinds, since they're the people who make the fundamental difference to widespread adoption and use of the Web. Jobbing developers are too numerous and have far less impact, individually in terms of the effect they have on the use of the Web.
I'm not making the point that developers should not be engaged with. Far from it. I'm just making the point that W3C like any organisation has limited resources and effectiveness of outcome needs to be measured, bang-for-buck wise.
I'm not making the point that developers should not be engaged with. Far from it. I'm just making the point that W3C like any organisation has limited resources and effectiveness of outcome needs to be measured, bang-for-buck wise.
Sticking with the idea, then, that developers are to be engaged with: I think we need to bear in mind that in other industries the approach to customer engagement don't consist of inviting potential end users into design meetings. If you're making a new car, asking potential drivers to actively assist in the design of the wheels and tyres makes no sense. Certainly ask them questions that inform the outcomes, put them in usability labs, show them prototypes … whatever you do, as Cliff says, under comment 6 on Bruce's post (and oh, yes he makes a good point, so powerfully) treasure their feed back and act on it.
The TAG is the developer representative
In the end, without a proper definition of what the TAG is trying to achieve and on behalf of whom, things won't make much progress, In my view the TAG should own the product definition and just as a product manager is the representative of the customer in any discussion, the TAG should be the developer representative.
Having an informal drinks evening is a start. Much more is needed. Well done, Dan, for starting down a very long road.
