Re: few questions

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.


Robinson, Norman B - Washington, DC wrote:


	One word: Preferences.

	Accessibility is something that is built into products and
services. Accessibility is quality. How the accessibility is used is by

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

gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]