[Accessforall] Conditional preferences

Andreas Stiegler stiegler at hdm-stuttgart.de
Wed Aug 1 16:04:46 UTC 2012


Heyho everyone,

Thanks for your detailed feedback! :)

I also support working with users to identify the perfect (or at least best)
structure and workflow. Yet I still think that the current proposal could
work as a first iteration on these journey.

I think it would be helpful to discuss the actual scenarios how and when
interaction between the user and the profile takes place and what the job of
the different fields (property, condition, value) is in this context. It
appears to me that this is an important step to get to a proposal as it
defines the requirements and usability parameters that the proposal will
have to obey.

I will prepare a few graphics on a wiki page over the weekend that might
serve as a base for discussions. That might be a good step to prepare and
discuss in our next full a2a meeting.

Best regards from then hot and humid Germany,
Qapla'
HdM:Andy

-----Original Message-----
From: Clark, Colin [mailto:cclark at ocadu.ca] 
Sent: Monday, July 30, 2012 8:25 PM
To: Gottfried Zimmermann (List); Andreas Stiegler
Cc: SP1 at cloud4all.info Member; sp2 at cloud4all.info;
Accessforall at fluidproject. org; Antranig Basman
Subject: Conditional preferences

Hi Gottfried and Andy,

Thanks for posting this conditional preferences proposal to the wiki. All
the detail and examples are really helpful!

http://wiki.fluidproject.org/display/ISO24751/2012-07-24+Meeting+on+Context+
Description
http://wiki.gpii.net/index.php/Device_Profile

Antranig and I have spent the past few days reviewing the proposal, and I
wanted to share a summary of our thoughts so far. Our general impression is
that we all need take some time to better understand the use cases,
representations, and implementation consequences before attempting to
standardize conditional preferences.

There are three particular areas we'd like to highlight:

1. Understanding user needs
2. A lack of semantics and the challenge of authoring conditional
expressions 3. Tweaks to our JSON binding 4. Next steps


1. Use Cases and User Needs

At the moment, most of our example conditional preference statements are
very simple and abstract--"I need a font size between certain hours of the
day." After chatting a bit with our interaction design team here at the
IDRC, it seems like we are putting the engineering work before the use
cases. My sense is that we haven't yet spent enough time with users to
assemble a clear understanding of their needs and goals, grounded in every
day reality. 

This proposal introduces a programming expression language into an otherwise
declarative preferences document. The approach brings with it lots of power,
but also substantial technical and user experience consequences that we
haven't fully explored. I'd advocate for more time spent with users to
better understand what they need and how they express those needs. This will
ensure that any technical solution we produce will scale to real-world
requirements.


2. Semantics and Authoring

This proposal models a user's conditional needs at a very low level: a
handful of boolean operators that can be unboundedly and recursively
composed into an expression. While on the surface this appears to offer
simplicity, it runs the risk of making preference editors and authoring
tools substantially more complex, both technically and in terms of user
experience. 

The first thing to keep in mind is that we don't expect our users to write
conditional statements by programming them in by hand. They'll use a
preference editor or authoring tool--something that speaks their language
and has been carefully designed to be easy to use. Conditional expressions
of this nature make it very difficult to write good authoring tools. The
problem is that there are no semantics within the conditional
statements--they're just an unbounded composition of basic operators,
lacking any of the user's underlying intention or meaning.

Let's take our one example conditional preference statement: "localtime >=
'18:00' && localtime < '22:00'." A time-based preference like this probably
means something a little bit more to the user than just "greater than or
equal to 6 pm and less than 10 pm." He or she might actually mean that they
are particularly tired in the evenings, or perhaps find it hard to read in
the evenings due to low light levels. At very least, they mean "in the range
of..." It is semantic preference statements like these that will help us
create an excellent and tailored user interface for editing preferences.

If we go with unboundedly recursive boolean operators, we will have a
substantially more complex job of inferring meaning in order to create good
user interfaces. Even the state of the art of in academic research on user
interfaces for ordinary users to create such expressions isn't very
promising. An example of such a system can be seen in the work of Brad
Myers' group at CMU:

http://www.cs.cmu.edu/~NatProg/topes.html

This Topes system involved considerable research and development, is only
valid for a small domain of expressions and, in our minds, presents a user
interface which far exceeds the typical tolerance for complexity by
non-technical users. If we go with an approach that lacks semantics, we'll
likely have to confront highly complex user interfaces like this, and I
think we want to avoid end-user complexity at all costs.


3. Suggestions for JSON

We've created a wiki page with a series of "before and after" comparisons of
some variations on your example preferences document. Hopefully these
suggestions will help make Cloud4all's JSON binding more idiomatic and less
verbose.

http://wiki.gpii.net/index.php/Simplifying_Preferences_Documents


4. Next steps

In true open source form, a -1 vote should always be accompanied by list of
next steps and an offer to help with them.

First, I think we need to talk to users in order to determine a series of
clear, solid use cases for conditional preferences. I'd love to get the IDRC
interaction design team involved in this effort if others are also
interested.

Second, several of the above suggestions for simplifying our preferences
format should help, regardless of whether we have conditional preferences
yet or not.

Third, I think we should consider alternative approaches to conditional
preferences that are:

    * Declarative
    * Semantic
    * Extensible

These three criteria lead to some interesting ideas. In particular, we may
want to consider including conditional declarations within the registry of
context values.  These declarations might take the form of meaningful
condition terms that can be bound by the implementing system to functions
capable of computing their value in a particular context. This idea is
already implicit in the registry of values held above. For example,
"http://example.com/context/localtime" cannot be held to have meaning in the
absence of the ability to locate an implementation computing its value in a
particular context. This approach would allow for an extensible model that
more closely represents the intentions of the user, and thus can enable much
more sophisticated and elegant authoring interfaces.

I hope this feedback is helpful, and I'm really looking forward to
continuing the discussion and the design effort!

Colin

---
Colin Clark
Lead Software Architect,
Inclusive Design Research Centre, OCAD University http://inclusivedesign.ca




More information about the Accessforall mailing list