- From: Jan Richards <jan.richards@utoronto.ca>
- Date: Fri, 11 Jul 2008 15:29:33 -0400
- To: Michael A Squillace <masquill@us.ibm.com>
- CC: AUWG <w3c-wai-au@w3.org>
Hi Michael, I like where you're going with "functionality" which I read as (user interface) functionality. I like "content-independent functionality" and suggest a couple other terms FOR UI STUFF THAT DEPENDS ON CONTENT: "content-dependent functionality" "content-contingent functionality" Cheers, Jan Michael A Squillace wrote: > So, pondering what Al wrote: > > > 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. > > and given that this is what we're trying to distinguish, it seems now > misleading to discuss "views" or other GUI artifacts at all. Part of the > problem (or, at least, part of my problem), I think, is conflating UI with > GUI. We're drawing a line based on features and functionality, not on, as > Al put it, "layout rectangles." What would we say, for instance, about an > authoring tool the display of which consisted only of an interpretation of > the content and all other features and functionality were accessed via > speech I/O? In this case, there would be no "chrome" or "UI components > independent of content" or "user interface," as we have understood these > terms. > > So I'd add the following choices to your list of possible terms, Jan: > 1. FOR UI STUFF THAT DEPENDS ON CONTENT: > "Chrome" > "content view" > "UI set by content" > "UI dependent on content" > "content View Mode" (suggests Reed) > "content-laiden features/functionality" > "content-oriented functionality" > 2. FOR UI STUFF THAT DOESN'T DEPEND ON CONTENT: > "content display" > "user interface excluding content views" > "UI not set by content" > "UI independent of content" > "user interface" (suggests Reed) > "content-independent functionality" > > --> Mike Squillace > IBM Human Ability and Accessibility Center > Austin, TX > > W:512.823.7423 > M:512.970.0066 > > masquill@us.ibm.com > www.ibm.com/able > > > > Jan Richards > <jan.richards@uto > ronto.ca> To > Sent by: Michael A > w3c-wai-au-reques Squillace/Austin/IBM@IBMUS > t@w3.org cc > w3c-wai-au@w3.org > Subject > 07/10/2008 03:58 Re: Attempt to simplify and > PM harmonize "content display" vs. > "chrome" distinction in ATAG2 > and UAAG2 > > > > > > > > > > > > Hi Michael, > > I think we will need the "Applicability" section either way because we > need to explain why we're putting labels of any kind after our success > criteria. But we could use "content view(s)" and "user interface > excluding content views" as the labels we explain that section. > > So...terminology possibilities so far (plus a few further brainstorms): > > 1. FOR UI STUFF THAT DEPENDS ON CONTENT: > "Chrome" > "content view" > "UI set by content" > "UI dependent on content" > "content View Mode" (suggests Reed) > > 2. FOR UI STUFF THAT DOESN'T DEPEND ON CONTENT: > "content display" > "user interface excluding content views" > "UI not set by content" > "UI independent of content" > "user interface" (suggests Reed) > > > Not to complicate things further but a further useful distinction is > between content marked up semantically and not (e.g. AJAX without ARIA). > > > Cheers, > Jan > > > > Michael A Squillace wrote: >> That's fine but I like the original terms better and using "content >> view" v. "USER INTERFACE EXCLUDING CONTENT VIEWS" seems to convey more >> about what we're actually trying to distinguish. What about just >> "content view" and "non-content view?" The approach below seems a bigger >> hit editorially, right? >> >> --> Mike Squillace >> IBM Human Ability and Accessibility Center >> Austin, TX >> >> W:512.823.7423 >> M:512.970.0066 >> >> masquill@us.ibm.com >> www.ibm.com/able >> >> >> *Jan Richards <jan.richards@utoronto.ca>* >> Sent by: w3c-wai-au-request@w3.org >> >> 07/10/2008 01:02 PM >> >> >> To >> WAI-AUWG List <w3c-wai-au@w3.org>, WAI-UA list > <w3c-wai-ua@w3.org> >> cc >> >> Subject >> Re: Attempt to simplify and harmonize "content display" vs. > "chrome" >> distinction in ATAG2 and UAAG2 >> >> >> >> >> >> >> >> >> >> Hi all, >> >> Talking with Jeanne the other day she was a bit concerned about the >> length of one of the terms I'm proposing to replace "Content Display" >> and "Chrome". >> >> "CONTENT VIEWS" >> "USER INTERFACE EXCLUDING CONTENT VIEWS" >> >> Thinking about it more, maybe we can get around this somewhat in the way >> the terms are used... >> >> we could add an "Applicability" section to both documents modeled on the >> some similar text from the Conformance Profiles section of UAAG 1.0: >> >> PROPOSED TEXT: >> >> Applicability: >> >> In some cases, a success criteria may apply equally well to all aspects >> of the [authoring tool/user agent] user interface, including *content >> views*. However, in other cases it is necessary to remove ambiguity >> about the scope of a success criteria, in which case one of the >> following labels will appear: >> >> - Applies to *content view(s)* only >> >> - Does not apply to *content view(s)* >> >> >> Thoughts, >> Jan >> >> >> >> >> >> >> >> >> >> 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. >> > >> > 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 >> >> >> >> > > -- > 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 > > > > > > -- 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 Friday, 11 July 2008 19:28:37 UTC