[Accessforall] [SP2] Conditional preferences

Andy Heath andyheath at axelrod.plus.com
Tue Jul 31 07:41:02 UTC 2012


To avoid confusion as is likely in the email below, to which I am 
responding (and noting the ambiguity contained already therein) -

namespace proposal:


example of use:

"Hi Gottfried and hdm:Andy",

;-) :-) - well you have to have *some* fun with this stuff.


There is a difference between the calculus of combining conditions and 
the way conditions are described.  It seems to me that having the 
logical conditions calculus is something we've been missing before, 
leading to a great deal of vagueness and wasted discussion about meaning 
and how to implement in the metatada communities.
The circularities of reference problem is adressable.
OTOH I agree with Jutta's and Colin's argument
about driving from the user experience end and having descriptions the 
users can use.  Isn't the solution to this to have a vocabulary of 
decriptors for context combined with the logical calculus ?  Tools 
should never expose URL's to users in any case. Design of the terms
in the vocabulary is then a separate matter to designing the mechanism
that uses them.

My own view on this is that there has always in standards in this
area been some conflict of view between an implementation perspective 
and a more human and user-oriented perspective.  I don't see the 
solution in being entirely in one position *or* the other - if we
fail to meet either perspective we will have failed.  If it doesn't meet
the user perspective then I don't know why we are here and if it doesn't
work - well that speaks for itself.  The task as I see it is to bridge
the gap between both views, each of which on its own is limited. 
Vocabularies seem to be a good ground to meet in.

On the json representations things - I also queried the representation 
the other day (I saw no response) - on the architecture group I think. 
However, since then, thinking about all the work going on around 
different potential bindings to content - RDFa, microformats, microdata 
etc. and the technologies with which sets of preferences are going to 
have to work in matching content marked up with Metadata I have changed 
my position.  In my earlier mail I argued that this:

{{ property: "blah",
   condition: "blah",
   value : "blah" },

{ property: "blah",
   condition: "blah",
   value : "blah" }}

was wasteful because of all the repetition of field names. However, in 
the light of the many and various technologies it will need to work with 
I think its important that there is an easily-understandable canonical 
form (which this could be). This argument has more validity during 
development/roll-out of gpii - perhaps for gpii 1.0 it should be this 
way then for gpii 2.0 it should be made efficient (and harder to 
understand and work with for non-geeks) ?

What I do see in looking around cloud4all material is many instances of 
json structures that are not flat at all - they may follow a style 
similar to the existing 24751.  I see these being used as an
argument that gpii has been implemented successfully.  I don't want
to be controversial or denigrate anyone's work - I'm thrilled
that something is working, but without agreement on these fundamental 
data formats  and their use in implementation I'm unsure how what's been 
implemented is different in kind from Web4all or any other 
implementation of 24751.

Hopefully we are moving towards agreement on these "forms of data".

I posted last week a question about data dependencies between terms. 
its a pretty crucial question to the interactions of stuff with other
technologies.  The answer may be "use the registry however you want". 
However, the surrounding technological ecosystem can't be ignored and 
imho we need to have a view on the way to approach these. We may have 
one and I don't know it.

Cheers, axelrod:andy

> Thanks Colin,
> I strongly support the user-centric perspective for discovering and declaring needs and preference statements. The feedback we have had so far is:
> - keep the interaction and choices simple (e.g., no more than 5 layers of nested questions)
> - fit the dialog or interaction to the situation of the user (e.g., kindergarten, vs. employment, vs. postsecondary)
> - the user should have full control and knowledge of all choices
> I agree with Colin that the criteria of a declarative, semantic, extensible approach to the conditional statements (derived through actual use cases) leads to a number of interesting designs. We may also want to consider enabling the user to create a set of personal "situations" which includes things like roles (e.g., when I'm at work, when I'm at home being a parent, when I'm chairing a meeting), complex situations (when I'm in a country in which I don't understand the language and I don't have my attendant with me). We probably don't want to register these but deal with them in some other way through the implementation.
> Jutta
> Jutta Treviranus
> Professor and Director
> Inclusive Design Research Centre and Inclusive Design Institute
> OCAD University
> On 2012-07-30, at 2:24 PM, Clark, Colin wrote:
>> 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
> _______________________________________________
> Accessforall mailing list
> Accessforall at fluidproject.org
> http://lists.idrc.ocad.ca/cgi-bin/mailman/listinfo/accessforall


Andy Heath

More information about the Accessforall mailing list