Re: Suggested Revision to Definitions of Control and Configure

thanks Eric and Al.  I like the direction this discussion has gone, and
I especially like the new definition of "control"

At 11:05 AM 5/18/00, Hansen, Eric wrote:
>Date: 15 May 2000, 18:00 hrs
>To: UA List
>From: Eric Hansen
>Re: Suggested Revision to Definitions of Control and Configure
>
>I have been becoming uneasy with the document's distinction between
>"control" and "configure" and would like to propose a revision.
>
>Al Gilman's comment helped crystallize some of my thinking. He noted:
>
><Al's Comment>
>3.  Question using control/configure distinction in setting minimums, here.
>
>The forced distinction between "control" (i.e. adjustment through the UI
>that affect the current behavior) vs. "configure" (adjustments that may have
>to be done out of line with a use session, but persist) is unfortunate.
>
>The strongest user requirement is that they be able to adjust the UA
>behavior somehow.  Whether it fits into the narrower categories of "control"
>or "configure" as discussed above is secondary or tertiary, relative to this
>requirement.
>
>In the most usable implementation, and this is also quite common today,
>there is not a lot of difference between the user interface to
>current-session and next-session adjustments, aside from a prompt as to
>whether the user intends the adjustment to be temporary/local or
>global/permanent.
>(http://lists.w3.org/Archives/Public/w3c-wai-ua/2000AprJun/0369.html)
></Al's Comment>
>
>Instead of viewing "control" and "configure" as very distinct concepts, I
>would like to propose a softer distinction wherein to "configure" is to
>"control", but with greater emphasis on the persistence of the setting.
>
>I am inclined to think that, generally speaking, we want the checkpoints
>(especially the _minimum_ requirements!) to focus on control. We can
>encourage configurability and the use of profiles, etc., but control is the
>fundamental issue.
>
>I am hoping that with this revised definition, some of the other decisions
>that we are struggling with will resolve more easily.
>
>Following is may fix to the definitions of "configure" and "control".
>
>I invite comment.
>
><OLD>
>Configure
>
>In the context of this document, to configure means to choose, from a set of
>options, preferences for interface layout, user agent behavior, rendering
>style, and other parameters required by this document. This may be done
>through the user agent's user interface, through profiles, style sheets, by
>scripts, etc. Users should be able to save their configurations across user
>agent sessions (e.g., in a profile). The range of available configurations
>(e.g., colors, font families and sizes, sound quality, etc.) may depend on
>system or hardware limitations.
></OLD>
>
><OLD>
>Control
>
>In this document, the noun "control" means "user interface component" or
>"form component".
></OLD>
>
><NEW>
>Control (and Configuration)
>
>The term "control" is used in two major contexts in this document.
>(1) governance, such as a user may exercise over interface layout, user
>agent behavior, rendering style, and other parameters required by this
>document. Such control may be exercised through the user agent's user
>interface, through profiles, style sheets, by scripts, etc. The degree and
>kind of control that is possible (e.g., colors, font families and sizes,
>sound quality, etc.) may depend on system or hardware limitations. Control
>that persists, especially across user sessions, may be termed
><bold>configuration</bold>. A users may be able to save configurations
>across user agent settings in a <bold>profile</bold>.
></NEW>
><END OF MEMO>
>===========================
>Eric G. Hansen, Ph.D.
>Development Scientist
>Educational Testing Service
>ETS 12-R
>Princeton, NJ 08541
>609-734-5615 (Voice)
>E-mail: ehansen@ets.org
>(W) 609-734-5615 (Voice)
>FAX 609-734-1090

Received on Thursday, 18 May 2000 11:16:31 UTC