Re: Issues of @summary and use of data for "decisions"

Quoting Shelley Powers <shelley.just@gmail.com>:
> Now regardless of what you think about summary, the two are not the same.
>
> To merge summary into caption is to eliminate summary and redefine
> caption. User agents do handle the two differently. For instance,
> summary isn't printed out to the page; caption is.

This is true in visual UAs. My understanding is that in AT both  
caption any summary are typically read by default [1].

> So not only is this path causing confusion as to how to use summary,

This is an interesting assertion because it recognises that actual  
author behavior is one of the most important design considerations.

It seems to me that a great deal of the tension that arises in this  
group comes about because of a philosophical difference in the  
approach to markup language design.

People who favour the first approach (what I will describe as the  
"engineering" approach) first identify the features that people need,  
considering all the possible corner cases and possible future  
extensions. Then they design language features that map closely on to  
the identified needs, taking account of the full range of complexity.

People taking the second approach (which I will call the "HCI"  
approach) again starts by identifying needs but, when it comes to  
designing the features their approach is slightly different. Instead  
of looking at how to design the most powerful feature possible, they  
instead try to design a feature in a way that, when used by typical,  
uneducated, authors will, on average have the greatest success rate.  
This may come at the expense of fidelity in the solution to the  
original problem.

I am trying hard to present the two approaches in as unbiased a way as  
I can manage (and, of course it is an enormous simplification to  
present things in binary terms when in reality there is a spectrum of  
individual ideas) but I think it is no secret that I favour the  
HCI-type approach to design so that will inevitably colour my views.

There are some notable differences in behavior that you would expect  
from people adhering to each approach. The HCI approach advocates  
maximizing a (not quite well defined here, but I hope rather  
intuitive) measure of goodness that increases when users experience a  
positive effect from a feature and decreases when they experience a  
negative effect. Obviously whether a feature has a positive effect on  
users is affected by how authors use it. Different designs will work  
more or less well in this regard (for example, complex designs are  
rather more likely to be misused - and hence "unsuccessful" - compared  
to simple design). Hence studying how well existing markup designs are  
used in comparison to its design goals is an essential part of this  
approach in much the same way that doing usability studies of existing  
designs is an essential component of UI design.

In contrast, advocates of the "engineering" approach place much less  
value on study of existing markup because they are trying to maximise  
the power with which the markup design allows authors to solve the  
problem under the assumption it will be used as specified. People  
preferring this approach often  advocate that author education be used  
to increase the understanding of the correct use of their designs.

I should also note that another component of the HCI approach is  
intuition about what is likely to work well. This is less satisfactory  
because it is harder to reason about and can lead to accusations of  
rejecting proposals without adequate justification. Often, however,  
intuition can be backed up by general principles that have been  
inferred from studying a large number of similar problems.

A further difference between the "HCI" and "engineering" approaches is  
how closely the final design maps on to the original problem.  
Typically the "engineering" approach will map requirements closely  
onto features in the final design. Features designed using the HCI  
approach may not have this one-to-one mapping. Indeed they may not  
solve all the problems originally set out at all (since it may be  
considered better to have a solution that only solves a fraction of  
use cases but will be used by many authors than a solution that solves  
all use cases but is only used by a few authors). One effect of this  
is that "HCI" solutions can be accused of failing some users, even  
though they have been explicitly designed to help those people as much  
as possible. By contrast "engineering" type solutions generally make  
it obvious what has been addressed and how.

An interesting observation is that "HCI" design rather naturally  
benefits from the "baby steps" design principle that Hixie has  
previously advocated [2]. Since it is difficult to assess with  
confidence how successful features will be before they are deployed,  
it is better to build up a feature in stages over time, continually  
assessing and tweaking (if necessary and possible given legacy  
compatibility constraints) the design.

Anyway, back to @summary (although I stress that my above  
characterization of the two schools is, as far as I can tell, helpful  
in understanding many other difficult issues that the HTMLWG has come  
across).

According to the @summary wiki page the main use case it is designed  
to address is authors providing a description of the table's layout  
that is needed by the visually impaired but is not (generally) needed  
by sighted users. Clearly from an "engineering" point of view @summary  
provides this capability so someone approaching the problem from that  
angle would be expected to conclude that it is a valuable feature.

On the other hand, the data that has been collected about the actual  
use of @summary suggests that it is little used, when it is used it is  
often ignored by UAs (because e.g. it says "layout table" and AT is  
configured to skip @summary in those cases) and in the remaining case  
it almost never provides information about the two dimensional  
structure of the table even those the values are sometimes useful  
(e.g. [3]). From an "HCI" point of view this makes @summary look like  
a disaster.

So, given the original use case and the data, there are at least two  
possible conclusions: a) @summary is fine and we should just do more  
education; b) @summary has failed and urgently needs to be  
redesigned**. One possible redesign is motivated by noticing that in  
many cases where @summary values are helpful today they would also be  
helpful to sighted users and therefore we should just encourage  
authors to write useful captions with all the information available to  
all users. Since authors will no longer have the ability to have  
AT-only summaries and under the (possibly false) assumption that  
authors would not describe the layout of a table if a sighted user  
could read it [4], this would not solve the original problem as  
stated. From an "engineering" design point of view such a solution  
makes no sense but from a "HCI" design point of view it makes a great  
deal of sense (which is not to say it is necessarily the best  
solution) because it increases the simplicity by removing hidden data  
(which has been observed to be less reliable than visible data; [5])  
and focuses education on getting authors to do something that they  
actually do in practice and that has demonstrable benefits.

Of course there are other solutions that can be considered like adding  
<details> for <caption> which match the original problem better but at  
the expense of being somewhat harder for authors. These tend to appeal  
to "engineering" types more because they more obviously solve the  
original problem but "HCI" people worry more about the additional  
complexity. Some sort of judgment call is likely to be needed about  
whether the additional complexity is merited (personally I think it is  
but I also think that reasonable people could disagree).


So, no solutions, but hopefully a useful view on why there is such a  
strong disagreement.


** One point that has been brought up is a comparison to abuse of  
tables. It is clear that HTML tables are often used in an unintended  
way and this does indeed have bed effects. Nevertheless there exist  
fundamental differences between <table> and @summary; the abuse of  
<table> is mainly a failing of CSS and can best be addressed by  
designing CSS features that correspond to design patterns that authors  
actually want (and getting those features implemented in browsers). In  
contrast @summary is a pure markup feature. Additionally it is rather  
hard, even in theory to imagine how one could replace <table> with a  
feature that would work in the cases where <table> is currently used  
usefully but would not be open to the same abuse. By contrast this is  
rather easy with @summary.

[1] http://lists.w3.org/Archives/Public/public-html/2009Jun/0282.html
[2] http://lists.w3.org/Archives/Public/public-html/2007Aug/0495.html
[3] http://www.paciellogroup.com/blog/misc/summary.html
[4] http://lists.w3.org/Archives/Public/public-html/2009Jun/0604.html
[5] http://tantek.com/log/2005/06.html#d03t2359

Received on Tuesday, 23 June 2009 22:21:58 UTC