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

On Tue, Jun 23, 2009 at 5:21 PM, James Graham<jgraham@opera.com> wrote:
> 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.
>

If one agrees with how you've separated the people. I don't. You're
basically saying there are two dimensional people and three
dimensional people, and luckily, you're one of the 3Ds. Of course, I'm
and others aren't 2D people, but we're not your black and white
"engineering" types either.

For instance, I don't think that there are people supporting keeping
summary that aren't also in favor of supporting HTML that is
intuitive. But their assumption is that the failure with summary is
less that it was unintuitive than HTML4 did not do a good job about
explaining what it is, or how to use it.

Then there are the folks who look at the data, disregard the fact that
probably 98% of the tables represented were, themselves, used
incorrectly, and deduce that what's really needed here is...

Let's put summary into caption.

Well, you're right in one thing: that's an intuitive leap I would
never have made.

>
> ** 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.
>

But again, you're basing this on your opinion, and treating it like
fact. Perhaps that's a failing with HCI folks.

Because this does boil down to opinions. Your opinion is that one can
merge summary into caption because they're really both the same, or
you think have been treated the same. I've read your IRC entries, you
dislike what you call "hidden" data, such as summary (and I imagine
RDFa).

You see the redefinition of caption, and elimination of summary, as an
"intuitive" solution, because you look at the data and that's the view
you derive. Purely from looking at the data.

I have listened and read what the accessibility folks have stated, and
I find myself in agreement with their opinion: that much of the data
that keeps getting dragged out is not a good tool to use for decision
making about the future of the web, because most of the source for the
data is flawed...and do we want to allow past year's flaws to
determine the best web of the future?

The accessibility folks have not once tried to hide the problems, have
acknowledged the problems, and have even provided a game plan for
addressing the problems that accounts for short term, intermediate,
and long term solutions.

But these folks are also operating under one serious restriction in
that there is no form of extensibility within HTML5, so they have to
work for, at least, a minimum of markup to address the needs of those
with visual impairments. A minimum of markup that already has seen
implementation.

Rather than see the collapse of summary and caption into one as being
an intuitive use of markup, one could see it as a wasteful use of
momentum in a very difficult environment. Support for the handicap is
never a high priority for anyone, much less web developers.

But the problems really go beyond summary and get into the heart of
how decisions are made within this group. There is a small group of
like minded folks who believe that they can look at the data that was
the web the last ten years and extrapolate from that to a best web of
the future ... typically without seeming to have to address concerns,
wishes, fears, worries of any _people_ who work with the web.

In other words, the perfect web of the future, the web seeming
envisioned by the HCI folks is one that is not tainted by human hopes,
dreams, or aspirations.

I am less concerned about the summary attribute -- or SVG, or RDFa --
then I the fact that a small, non-diverse group of people is using
data haphazardly collected from the web, as justification for
designing a web that suits the purposes of, basically, a small,
non-diverse group of people.

Shelley

> [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 23:16:31 UTC