[Accessforall] [SP2] Conditional preferences
Gottfried Zimmermann (List)
zimmermann at accesstechnologiesgroup.com
Tue Jul 31 11:38:03 UTC 2012
Thanks much, Colin and Antranig, for sharing your thoughts.
I think, we can discuss some of it in today's call, but I wanted to share a
few comments ahead:
Re: 1. Use Cases and User Needs
I fully agree with you. We need to derive our system from user research,
and user scenarios that are based on user research. What we have now, is a
first structure to start our first iteration of prototypes, to implement the
scenarios. We had to come up with some system for structuring the
information that will be derived from the scenarios.
If, after our first iteration, we will see that the current structure
doesn't fit the needs of the users, we can still change it.
Re: 2. Semantics and Authoring
In my view, the conditions are just a help construct for expressing a
multitude (possibly infinite number) of preference sets. I'll explain that
later on the Wiki.
Re: 3. Tweaks to our JSON binding
That's okay for machine readability and transmission of information.
Anyway, the JSON notation is not meant to be read by humans (developers are
not human in this case). For the user, we will have to present this
information in a different form (e.g. in tables).
Re: 4. Next steps
Yes, we are just at the beginning. I expect the following next steps:
- Implementation of the registry database
- Development of approval guidelines (to be part of ISO/IEC 24751)
- Establishment of an approval board for registering common terms
- User research, mainly done by SP1 (which I am not part of) and SP4
- Revision of our current structure based on user research (end of first
- Possible revision of ISO/IEC 24751 drafts based on user research (end of
- The same for the end of the second and third iterations
Hope this helps.
Von: SP2 at cloud4all.info [mailto:SP2 at cloud4all.info] Im Auftrag von Clark,
Gesendet: Montag, 30. Juli 2012 20:25
An: SP2 at cloud4all.info
Cc: SP1 at cloud4all.info Member; sp2 at cloud4all.info;
Accessforall at fluidproject. org; Antranig Basman
Betreff: [SP2] Conditional preferences
Hi Gottfried and Andy,
Thanks for posting this conditional preferences proposal to the wiki. All
the detail and examples are really helpful!
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
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
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
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
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:
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
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
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:
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!
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
More information about the Accessforall