[Accessforall] Conditional preferences

Clark, Colin cclark at ocadu.ca
Mon Jul 30 18:24:44 UTC 2012


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