GUI baggage [was: Re: Role attribute values]

[I don't claim to have processed the whole message, but I think I should
clarify one point.]

On 10 Apr 2008, at 8:39 AM, Roland Merrick wrote:
> This is the only term that caters for an affordance that enables  
> user-triggered actions. "button" carries a certain amount of  
> baggage in terms of preconceptions. There are many ways of enabling  
> user action without the use of a "button" uless your definition is  
> such that it covers all activation mechanisms. Since I am unsure as  
> to your intent it is hard to suggest an alternative but perhaps  
> "activator" might be close.

The implication in the comment is that the terminology should reflect  
pure, presentation-unaware abstraction of the widget.

That is not what we chose.

We like the GUI baggage.

The approach is to provide widgets that are full-function for use across
presentation/activation diversity, but designate them with terms  
of the GUI cliches that are their most familiar concretion, i.e. as
most commonly bound to presentation.  These are the roles known in the
accessibility APIs and they come there from a very thin  
deconstruction of the

This, we believe, will allow more designers to learn the ontology  
fast and
to use it correctly in their work.  They don't have to become experts in
disability access or behavior modeling.

Web designers make buttons look, statically and interactively, like
physical buttons on the front-panel of electronic equipment.  They do  
because the end-user will recognize what they are for more readily  
that way.
And the end-user needs to know "what can I do?"

We call them 'button' because the designers now think of them as buttons
and we do better to build on what they know here, rather than give
ourselves a need to re-educate them.

/me, myself


This is my personal interpretation of a theme through a
lot of concrete decisions.  This is the first time the
PFWG will have seen this particular explanation.  YMMV


Received on Thursday, 10 April 2008 17:02:41 UTC