Re: [HDP] Response to Review of HTML Design Principles Questionnaire

At 00:57 +1000 UTC, on 2007-08-23, Lachlan Hunt wrote:

[...]

> I'd like to suggest that
> the principles should be restructured into 4 categories, instead of the
> existing 3.

Seems like a good idea. This may also help make it more clear what each
principle is or isn't about.

[...]

> Additionally, I think it would also be a good idea to eventually
> describe techniques for applying each principle.  The idea is to clarify
> when and how each principle should and should not be applied, which will
> hopefully resolve some of the concerns about them being misused.

Another good idea :)

> 2. Support Existing Content
[...]
> This is my proposed rewording: [...]

Looks good to me.

[...]

> 4. Do not Reinvent The Wheel
[...]
> people have commented in the survey that it depends on the quality of
> the wheel, or equivalent, and they are absolutely correct.
> [...]  I believe this is a problem
> with the current wording and that these concerns are suitably addressed
> using [...]

   Evaluate the success and failure of existing solutions. For those
   that have proven reasonably successful in terms of benefits, usage
   and implementation, consider adopting, retaining and/or improving
   upon them in preference to dismissing and inventing new features

I don't think I could subscribe to this. The moment you start defining
"successful" (by adding "in terms of benefits, usage and implementation"),
you exclude other definitions of succes. That seems a very risky path to take
at this point. It would seem wiser to levae this much more open (say just
"reasonably sucesful"). Alternatively we could try to come up with a
watertight definition of success that most can subscribe to, but that would
probably be a lot of work with doubtful benefit. It seems more realistic to
leave a discussion of what is "reasonably succesful" to occur when it needs
to.

So I'd suggest simplifying your wording to:

   Evaluate the success and failure of existing solutions. For those that have
   proven reasonably successful, consider adopting, retaining and/or improving
   upon them in preference to dismissing and inventing new features

I've expressed the same type of concern with with the "Well-defined
behaviour" principle btw.

[...]

> 5. Pave the Cowpaths
[...]
> I believe these issues would be address using my previous suggestion to
> revise this example. [...]

   Investigate existing practices and design or adopt features that
   meet the desires of authors.  Where possible, solutions should
   leverage the existing techniques and skill sets of authors which
   will help promote the adoption of new features.

Agreed. I can more easily subscribe to that.

[...]

> 7. Solve Real Problems
>
> I support this principle, though I think it needs to be clarified to
> address the concerns others have expressed.  In particular, it needs to
> define what is and is not considered a real problem and describe
> techniques to determine if a problem is real or not.
>
> Despite what some have claimed in their survey responses, there are
> indeed cases where people think they are trying to solve a real problem
> when they're really not.

Well, yes. But there is also the opposite: problems that are real, but that
no one or hardly anyone has tried to solve yet. If it would be required that
the 'level of realness' be proven by pointing to attempts to solve something,
such cases would suddenly be 'not real'...

Take uniformity of equivalents mark-up for instance. That isn't something
that users or authors can try to solve. At the very best authors could
provide feedback to this WG, asking for uniformity. And given that so few
authors are even aware of the needs/possibilities of universality and
accessibility, there won't be many such requests. Does that make it an Unreal
Problem?

Same for authoring of multiple equivalents and how they should/could cascade.

Same for the legibility of the spec.

I'm sure others can think of many more such examples.

I do not see how these types of Real Problems can be proven to be real
through the often requested "evidence". So I think that either it should be
made clear how that can be done realistically, or the definition of 'real'
should remain undefined...

That aside, if we officially decide that "evidence" is required for anything,
"evidence" will need to be defined. And even then I'd have serious doubts,
because gathering evidence is something that can cost a lot. Such a
requirement would probably exclude the majority of the WG members. I don't
see how that could be solved.

[...]

> Henri gave some good examples of problems people try to solve that
> aren't real in IRC:
>
> <hsivonen> Regarding fantasy problems: the thing is people do try to
> solve them. sometimes the problems aren't 100% fantasy, but common sense
> says they aren't real problems. Examples: 1) "search engines could"

I really don't understand how this is a good example. "search engines could"
sounds like relevant context was omitted.

[...]

> 11. Support World Languages

As I commented in the survey: I don't understand what " Features to represent
a single web page in multiple languages are out of scope." means. Aren't
@lang and @dir such features?

Can someone help me understand?

> 12. Secure By Design
>
> I agree with this principle, though it needs to be expanded and
> clarified.  As others have pointed out, "security model of the web" is
> undefined and ambiguous.
>
> Joshue O Connor claimed:
>> For example accessibility and security are two forces (sic) that could
>> be at logger heads. In many ways they are opposing principles. How can
>> we make the web more accessible while still making it more secure? How
>> can they be reconsiled? Which one will get the bums rush when the chips
>> are down?
>
> I'm not sure what he's basing that claim on, I can't imagine how any
> security or privacy issue could affect accessibility.

It may depend on how one defines "acccessibility"... (In my mind
"accessibility" is pretty close to "usability", which is commonly recognised
as something that needs to be balanced against security. Perhaps Joshue was
thinking in that direction.)

Trying to think of an obvious example of universality vs security: perhaps
the issue of (visual-only) "Captchas" would be one?

[...]

> 13. Separation of Concerns [...]

FWIW, I've expressed serious concerns with this principle: this Design
Principle cliams that mark-up defines structure, ignoring that it also
defines meaning. If that omission is intentional it should be explained.
Also, I really can't agree with "Profound and detailed semantic encoding is
not necessary if the end can be reached otherwise." lt leaves the door way
too wide open for purely presentational mark-up, or non-mark-up (as in
"equivalents need not be marked up as such").

If you (or someone) think my concerns are based on me misunderstanding the
principle, could you explain please?


-- 
Sander Tekelenburg
The Web Repair Initiative: <http://webrepair.org/>

Received on Wednesday, 22 August 2007 20:39:24 UTC