[Accessforall] Some statements for discussion regarding the further work of this group

Gottfried Zimmermann (List) zimmermann at accesstechnologiesgroup.com
Mon Jan 16 10:22:00 UTC 2012


[My apologies if you have received this email twice since I am sending this
to the list and to individual email addresses.  We may soon switch
completely to the list, but at this point I don’t know who of you have
already subscribed and who not.]

 

Hi all, 

 

since our last telecon i have spent some time thinking about our process,
goals, and next steps.  We have started to discuss the notion of “context”,
and have begun to realize that our undertaking can quickly become too big
for us, both in terms of sheer volume and in terms of instability (changes
over time).  At this point, i am not convinced about the “Look at needs
first and discuss structure later” policy that we seem to have imposed on
ourselves.  

 

You may also want to have a look at the minutes of our call last week,
http://wiki.fluidproject.org/display/ISO24751/2012-01-10+Meeting+Minutes. 

 

Below my signature are 5 statements that I would like to discuss with you
(also posted on the Wiki at
http://wiki.fluidproject.org/display/ISO24751/Statements+for+user+profile+st
andard+development+%28for+discussion%29).  Maybe you could give them some
thoughts, even though you may not agree with them.  I’d like to discuss this
in our meeting tomorrow.

 

Looking forward to a good discussion,

Gottfried

___________________________________________________

 

 Prof. Dr. Gottfried Zimmermann

Access Technologies Group, Germany

___________________________________________________

 

 

 
<http://wiki.fluidproject.org/display/ISO24751/Statements+for+user+profile+s
tandard+development+%28for+discussion%29> Statements for user profile
standard development (for discussion) 

*	Added by
<http://wiki.fluidproject.org/display/%7Egzimmermann@acm.org> Gottfried
Zimmermann, last edited by
<http://wiki.fluidproject.org/display/%7Egzimmermann@acm.org> Gottfried
Zimmermann on Jan 16, 2012  (
<http://wiki.fluidproject.org/pages/diffpages.action?pageId=29491575&origina
lId=29491576> view change) 

 

Here are some statements for discussion that may help us in determining our
strategies and planning of work.  Please feel free to add your comments to
each of the statements, or add statements yourself.

Gottfried

 

The development of a set of preference items for user interface adaptation
should be based upon various use cases, including a range of user groups and
a range of contexts of use.

*	Use cases need to be defined, and different kinds of adaptive user
interfaces constructed for testing and evaluation purposes.
*	This is what Cloud4All is doing through its SP1 and SP3, on various
platforms.  This takes time and ressources, and requires the involvement of
many partners.
*	Other projects (aside from Cloud4All) may have done or may be doing
similar activities.  This working group is suitable for information exchange
and coordination of these efforts.

 

The set and structure of preference items for user interface adaptation
depends on the context of use (applications, platforms, assistive
technologies).  There is no universal set of preference items that would
suffice for all existing contexts of use.

*	This is an implication of the first statement.

 

The set of preference items for user interface adaptation will never be
complete.  New applications, assistive technologies and user interaction
techniques will eventually require an extension of any existing set of
items.

*	What if we want to accommodate new interaction techniques that
require new preference items?  For example, consider the introduction of
sign language output by avatars.  We would need a new preference item for
the speed of the sign language performance, for the preferred avatar, etc.
Or for gesture-based input we would need additional preference items that
specify a gesture alphabet.
*	We need to define a framework that sets the structure of a user
profile independent of its vocabulary items.
*	The vocabulary (preference items) should be repository-based so that
it can be updated on a regular basis.
*	The framework (without vocabulary) should be defined in an ISO
standard.  Also, a process of approval for new vocabulary items for the
repository should be specified in a second ISO standard.
*	For an efficient development process, properties, structure and
approval process can be developed in parallel.

 

A flat set of properties (key-value pairs) is most appropriate for practical
reasons.

*	In most cases, hierarchical constructs of user properties can be
approximated by a flat set of properties with URIs as keys.
*	See as an example the WURFL properties database for mobile devices.
This simple collection of key-value pairs for thousands of mobile devices is
a de-facto standard in industry today for the user interface adaptation
based on mobile device characteristics. WURFL is regularly updated by a
community.   <http://wurfl.sourceforge.net/> http://wurfl.sourceforge.net/
*	Many standards in this area have a flat structure, and some use URIs
as keys (e.g. Dublin Core, ETSI ES 202 746).  This is a pragmatic approach,
and allows for core properties and extension properties based on domain
names. Also, using URIs as keys allows for formal definition of preference
items (and constraints) in RDF.  Note that doesn't mean that the preference
values need to be coded in RDF.
*	The core items will have a commonly defined domain name (namespace)
as part of their URI.  Third parties such as user groups and vendors can
define their own extension items by using a different domain (namespace).

 

In general, the user properties stored in a user profile should be based on
requirements rather than functional descriptions of the user.  However,
functional descriptions may help to efficiently derive requirements-based
properties for the initialization or fine-tuning of user profiles.

*	Our framework should be able to accommodate both requirements-based
user properties and functional user properties.
*	There will likely be stricter ethical constraints for functional
user properties than for requirements-based user properties.  For example,
functional user properties could be permitted only in a local environment
and temporary context (no storage on a central user profile repository).

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120116/12d46a85/attachment-0001.html>


More information about the Accessforall mailing list