Re: few questions

[Bill Haneman <Bill Haneman Sun COM>]

Hi Norm;

Within Gnome we will need to use the word "profiles" as the technical 
term for this, as "preferences" are already handled by another mechanism.

Outside of TLAs, 'user profile' may mean something very different.  So 
while I hear your point, I am not sure that the word "profile" is 
onerous in this context, for the general user.

Bill

Robinson, Norman B - Washington, DC wrote:

> Bill,
>
> 	One word: Preferences.
>
> 	Accessibility is something that is built into products and
> services. Accessibility is quality. How the accessibility is used is by
> preference.
>
> 	User profiles profile the user. They lead to terms and concerns
> that self-identify. They lead to terms that indicate the user is being
> tracked. If [insert three letter acronym agency here] created a
> distribution with user profiles, you'd likely wonder about the term.
>
> 	Just wanted to contribute a few years worth of experience in
> political correctness, personal arguments, and community preference for
> people who don't wish to self-identify. It isn't about being overly
> sensitive, it is about respect and eliminating discussions on semantics
> when you simply wish to focus on the technical aspects of a solution.
>
> 	Warm Regards,
>
> 	Norman B. Robinson
>
>
> 	P.S. I thought some feedback on what I view as generally bad vs.
> preferred from the below inline message would be of use:
> 	accessibility "options" vs. preferences
> 	a wizard or configuration assistant "helps users select" vs. a
> configuration assistant to set preferences
> 	non-accessible users vs. users that cannot access your content
> or information
> 	"Accessibility" section vs. preferences section
> 	"users don't self-identify as disabled" vs. "users have
> preferences"
> 	"ghettoize" accessibility vs. having user preference by function
> (visual, sound, mobility)
> 	"user profile" capability vs. "user preference" capabilities
>
> 	Don't forget that many times the user may want to change their
> preferences to simulate the use by a different user's preference
> (testing, remote support) or for a temporary disability (forgot glasses,
> etc.). It doesn't matter if those users have any particular or no
> disability! 
>
> 	Off topic; as it was mentioned I wanted to comment. By avoiding
> two separate dialogs which change the same feature, I think they've set
> the wrong mandate. Users should be able to change features or
> preferences from multiple interfaces, keyboard, system preferences, user
> preferences, applications calling the same panels. The mechanism should
> be the same, but it is a bad idea to force simplification for human
> factors reasons. Usability doesn't always equate to simplicity. I would
> recommend you create a user's preference panel that set and stores
> multiple preferences. Then you can create multiple default preferences,
> useful in testing and evaluation, based on user needs (profiling what a
> user needs in advance could be said to enhance the accessibility of your
> product) that can be selected as preferences.
>
> -----Original Message-----
> From: gnome-accessibility-list-bounces gnome org
> [mailto:gnome-accessibility-list-bounces gnome org] On Behalf Of Bill
> Haneman
> Sent: Tuesday, October 04, 2005 10:09 AM
> To: Jason Grieves
> Cc: gnome-accessibility-list gnome org
> Subject: Re: few questions
>
>
> Jason Grieves wrote:
>
>  
>
> > Hi Bill (and all),
> >
> > I am not quite sure if my last emails went through as I had some major
> >    
>
>  
>
> > email problems.  If these are repeats, pardon me.
> >
> > 1) Has an accessibility "options" center been discussed in Gnome 
> > before?  Similar to what Microsoft has in the control panel, along 
> > side with a wizard?  I know older and less technical welcome the 
> > wizards and configuration assistants.  It would not seem to hard to 
> > do, but I realize it could provide some discrepencies with 
> > non-accessible users.  Would there be 2 places to change the same 
> > feature?  I.e. keyboard accessibility via Preferences> Keyobard versus
> >    
>
>  
>
> > lets say a tab with the AccessX features
> >    
>
> We have resisted, for the most part, the temptation to put all of the 
> features that are of interest to accessibility into a special 
> "Accessibility" section.  There are many reasons for this, including the
>
> fact that many relevant features are of general interest, the fact that 
> some users don't self-identify as disabled, and our desire not to 
> "ghettoize" accessibility.   However, some sort of wizard or user-config
>
> helper would be useful, I agree.  I think the best way to do this is via
>
> a general purpose "user profile" capability for the Gnome desktop, but 
> this is still a project for the future.  In general Gnome's Human 
> Interface Guidelines say one should avoid having two separate dialogs 
> which change the same feature.
>
>  
>
> > 2) Bill does the magnifier need to be recompiled to work with the 
> > extensions (i.e. Damage) you spoke of?
> >    
>
> Yes, it must be built on a system that has the extensions, in order to 
> use them.  On most OS'es this should be true, because most distros will 
> probably be running a recent XOrg server when building.  However there 
> is no guarantee that this is true.  If the magnifier was built without 
> DAMAGE or COMPOSITE support, it will report this when started from the 
> console in standalone mode, i.e. if you run "magnifier -v -m" the 
> magnifier should report if it was compiled without DAMAGE or XFIXES
> support.
>
> Bill
> _______________________________________________
> gnome-accessibility-list mailing list
> gnome-accessibility-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
>