Consistency and dependency

Hi,

Another topic that I've heard raised as being problematic in the Web
platform is the lack of consistency across technologies, and the general
feeling that getting different technologies to work one with another
ends up more convoluted than ideal.

This sounds likely to be a consequence of Conway's law
        organizations which design systems ... are constrained to
        produce designs which are copies of the communication structures
        of these organizations
        
In other words, technologies developed across Working Groups (and a
fortiori across organizations) are likely to suffer from a number of
impedance mismatch derived from these underlying structures.

This lack of consistency has been brought up recently by the TAG:
http://www.w3.org/2001/tag/2013/03/18-minutes#item09
and is under heavy discussions in public-script-coord with regard to the
particular coordination between WebIDL-based JavaScript APIs and
Ecmascript developments:
http://lists.w3.org/Archives/Public/public-script-coord/2013AprJun/thread.html#msg27

Native ecosystems in contrast are usually designed through a more
top-down approach, in a single organization with a clear hierarchy of
powers.

Now, nobody (I assume) wants to turn W3C into a feudal system, and there
are both good and bad reasons why it would be difficult or impossible to
make Working Groups obey a top-down approach.

But I think it would be useful to explore where our bottom-approach
tends to fail, and if there are tools or processes we should set up to
reduce or eliminate these failures.

Some ideas:
* there is already discussion about setting a review process for
JavaScript APIs via public-script-coord — the focus of that review seems
to be on idiomacy, but there are likely other focus: e.g. usability
(from a developer PoV), consistency with other similar APIs, etc

* some form of training for JavaScript APIs editors could probably go a
long way toward getting more consistency across APIs; I know Marcos has
given thought on this topic

* likewise, developing guidelines and checklist would help groups
understand what approach works best for them; again, there has been good
efforts in that direction (e.g.
http://darobin.github.io/api-design-cookbook/ ), but I feel they have
lacked authoritativeness, wide-spread reviews, and wide-spread adoption

* a tool that would give a complete overview of the various technologies
under work would help keep track of the need for coordination across
groups; there has been works here and there that achieve some of this
(e.g. the list of CSS properties under development, the W3C cheatsheet,
the mobile roadmap, PLH's WebIDL extractor), but this has been mostly
ad-hoc, with no strong guarantees on maintenance, etc. A more systematic
approach would most likely help

* at a more abstract level, getting a platform-wide picture of what
groups work affect what features of the platform would seem useful; to
take an example, the orientation of a device affects CSS, the meta
viewport, device orientation, orientation lock (all of which are handled
by different working groups); we would need some lightweight approach to
identify these commonalities, and then find out the best way for them to
be tackled

* and from a slightly different perspective, having a repository of use
cases that illustrate how our various technologies ought to be used
together would also provide a useful metric for Working Groups to assess
if their technologies fit the need of the community

Is anybody interested in working on a more refined proposal in this
space?

Dom

Received on Wednesday, 17 April 2013 09:47:13 UTC