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

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

Received on Friday, 11 July 2008 11:04:59 UTC