Re: Attempt to simplify and harmonize "content display" vs. "chrome" distinction in ATAG2 and UAAG2

Hi there,

So forgive me if my newbie comments seem naive but...

If we think there is a convergence of control and access via the  
chrome, content presentation, and client side programatic  
manipulation, and that this will be intensified in the future; why  
are we trying to make a distinction here - why are we not just using  
a catch-all term to describe all functionality and presentational  
components exposed to the user, regardless of how or when they are  
generated?


Cheers
Si.

====
Simon Harper
University of Manchester (UK)

Human Centred Web Lab: http://hcw.cs.manchester.ac.uk
My Site: http://hcw.cs.manchester.ac.uk/people/harper/
My Diary (iCal): http://hcw.cs.manchester.ac.uk/diaries/SimonHarper.ics


+----------------------[ NEW &  
INTERESTING ]--------------------------------------+
   ASSETS 2008                . 13-15 Oct 2008 . http:// 
www.sigaccess.org/assets08
+----------------------------------------------------------------------- 
----------+




On 11 Jul 2008, at 14:10, Jan Richards wrote:

>
> Hi Al,
>
> Thanks for your thoughts. I'm actually in agreement with you.
>
> As you say, there are many places where a "bright line" is  
> impossible to draw, but to me there are places it can be and in  
> doing so clarify the requirements.
>
> In one part of your message you say:
>
> > To me, the only clean statement is something like "features and
> > functions" which the UA presents to the user through the UI that are
> > independent of the content vs. those that reflect an  
> interpretation of
> > the content.
>
> This is what I'm trying to get at (e.g. that for a browser or  
> authoring tool rendering an image with no alt is ok if that image  
> is part of the content produced by the author, but not ok if the  
> image is in the tool's own interface). I'm definitely NOT stuck on  
> layout rectangles.
>
> In fact in my post yesterday (http://lists.w3.org/Archives/Public/ 
> w3c-wai-au/2008JulSep/0017.html) one of my suggestions is "UI  
> independent on content" vs. "UI dependent of content" which is  
> quite similar to what you say: "UI that are independent of the  
> content vs. those that reflect an interpretation of the content".
>
> Cheers,
> Jan
>
>
>
>
>
>
>
> Al Gilman wrote:
>> ** summary
>> Keying success criteria to this binary distinction, which is a  
>> [gross?] approximation
>> in my eyes and perhaps fading in the Web, leaves me uncomfortable.
>> Maybe I can't see the forest for the trees, being too close to a  
>> data-engineering-driven
>> view of Web operations (including the UI).
>> Sorry this is so long and replete with arcana.  But I felt I had  
>> to say something.
>> On 7 Jul 2008, at 5:04 PM, Jan Richards wrote:
>>>
>>> Hi all,
>>>
>>> Both ATAG2 and UAAG2 often require specific terms to distinguish  
>>> the part of the user interface that reflects the content being  
>>> editing/viewed and the part that is the software's own. For some  
>>> time we've tried using the terms "content display" and "chrome",  
>>> but "chrome" is especially off-putting for people. Also the fact  
>>> the "chrome" covers help documentation, which might be HTML pages  
>>> is also confusing.
>> There is a problem with using the terminology 'content views' or  
>> even 'the *part* of the UI' to communicate this distinction.
>> To me, the only clean statement is something like "features and  
>> functions" which the UA presents to the user through the UI that  
>> are independent of the content vs. those that reflect an  
>> interpretation of the content.   In other words, properties of  
>> least-discernable objects in the UI, not layout rectangles.
>> You are using one heavily-used presentation concept to identify a  
>> binary selector, where the truth revolves around selectors over a  
>> richer space of information including multiple possible answers to  
>> the question "With whom am I talking, here?"
>> lurking in the background on any such discussion are two big  
>> trends that do not augur well for making this particular binary  
>> distinction a prime feature in the guidelines:
>> a) the push to make the content look and feel like the OS UI  
>> (which the chrome already evinces).
>> b) the shift in user attention more and more into the WebApp in  
>> the content
>> at the expense of any attention paid to the chrome.
>> There are important functions where it is impossible to draw a  
>> bright line
>> between chrome and content presentation, as in the requirement to  
>> let the
>> user know where the focus is.  Or the 'visited' property.
>> Further, even where the information is from the application alone,  
>> we need to develop ways to present a distinction to the user as to  
>> what information is assured by the security sub-system of the  
>> user's computer (hardware and software), and not just "from the  
>> browser."  For the eyes-free browser, the distinction may be in  
>> what the user asks, and not solely in how the system presents  
>> information.
>> On the authoring side there are edit and preview views that both  
>> present page content but satisfy different profiles of success  
>> criteria.
>> To get at what is actually going on one would have to look at  
>> where UI information is coming from (author, browser, history,  
>> rating service, virtual AT service, ...) and where UI actions are  
>> going to (interaction state of local document copy, server,  
>> OS, ...), and how this interacts with different success criteria.   
>> Not just 'some author dependency' v. 'no author dependency.'
>> Unfortunately, this sounds like it is leading us straight back to  
>> the Gordian knot of "merging XAG and WCAG," bringing together the  
>> user experience and the Web architecture enabling that user  
>> experience and re-factoring our work according to somewhat  
>> different aspects.  That we've never been able to mount critical  
>> mass behind a project to do.
>> Al
>>> So here's another terminological try (note: [/] denotes AU/UA  
>>> versions)...
>>>
>>> [AUTHORING TOOL/USER AGENT] USER INTERFACE
>>> The display and control mechanism that [authors/people] use to  
>>> communicate with and operate the [authoring tool/user agent]  
>>> software. A user interface may be non-Web-based or Web-based or a  
>>> combination (e.g., a non-Web-based [authoring tool/browser] might  
>>> have on-line help pages). For the purposes of these guidelines,  
>>> there is an important distinction between (1) *CONTENT VIEW(S)*  
>>> the accessibility of which often depends to some extent on the  
>>> content being [edited/rendered, played or executed] and (2) the  
>>> rest of the [authoring tool/user agent] user interface (referred  
>>> to as the *USER INTERFACE EXCLUDING CONTENT VIEWS*) the  
>>> accessibility of which does not depend on the content being  
>>> [edited/rendered].
>>>
>>> CONTENT VIEW
>>> The [authoring tool/user agent] user interface functionality that  
>>> presents content for user interaction. Content views may be  
>>> distinguished by:
>>>
>>> (1) *Editability*: some content views allow authors to modify the  
>>> content as displayed (e.g., [an "editing view"/an editable  
>>> "source view"]), while others do not (e.g., [a "preview" feature/ 
>>> the rendered view typical of browsers, a read-only "source view"]).
>>>
>>> (2) *Nature of rendering*:
>>>
>>> (a) *instruction level content views* present the content
>>> encoding instructions in non-rendered form (e.g., [plain text  
>>> editing views, form-based editing views that provide direct  
>>> access to the instructions such as selecting attribute  
>>> values/"source view"]).
>>>
>>> (b) *rendered content views* result from fully or partially  
>>> rendering, playing, or executing the content. The broad range of  
>>> potential renderings covers conventional (often called "WYSIWYG")  
>>> renderings to less conventional renderings such as a graphical  
>>> wavefront of an audio file or the displays of text-only browsers.  
>>> *Partial renderings* are those in which some aspects of the  
>>> content are rendered, played, or executed, but not others (e.g.,  
>>> a frame-by-frame video [editor/player] rendering the graphical  
>>> aspect, but not the temporal aspect, of a video.
>>>
>>> (c) *meta content views* present properties, metadata or other more
>>> abstract information about the content (e.g., [a content  
>>> management system that creates a Web-based calendar based on the  
>>> author selecting only the month and year/a "page properties"  
>>> feature]).
>>>
>>> USER INTERFACE EXCLUDING CONTENT VIEWS
>>> All parts of the user interface other than the content view(s).  
>>> Includes all user interface components that surround, underlie,  
>>> or superimpose upon content views (e.g., text areas, menus bars,  
>>> rulers, pop-up context menus) and also other Web content made  
>>> available to the author/user by the developer of the [authoring  
>>> tool/user agent] (e.g. help files).
>>>
>>>
>>>
>>> Any thoughts on "CONTENT VIEW" and "USER INTERFACE EXCLUDING  
>>> CONTENT VIEWS" as a way forward?
>>>
>>>
>>> Cheers,
>>> Jan
>>>
>>>
>>>
>>>
>
> -- 
> Jan Richards, M.Sc.
> User Interface Design Specialist
> Adaptive Technology Resource Centre (ATRC)
> Faculty of Information (i-school)
> University of Toronto
>
>   Email: jan.richards@utoronto.ca
>   Web:   http://jan.atrc.utoronto.ca
>   Phone: 416-946-7060
>   Fax:   416-971-2896
>
>
>

Received on Monday, 14 July 2008 20:44:10 UTC