[Accessforall] [SP2] Conditional preferences

Clark, Colin cclark at ocadu.ca
Fri Aug 3 21:00:09 UTC 2012


Hi Gottfried,

We were able to discuss several of these issues in Tuesday's call, but I thought I'd add a few comments here on list for the benefit of those who weren't able to attend.

On 2012-07-31, at 7:38 AM, Gottfried Zimmermann (List) wrote:
> 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.

I'm fully supportive of an iterative approach to development; that is the way we've been developing the Cloud4all architecture, too. To make good technical decisions, however, we have to have enough of a solid footing in real-world use cases that we can make informed decisions as we iterate. I'm still unclear on which use cases and goals for conditional preferences we are focusing on first. Is there a wiki page that describes them somewhere?

One area I'm particularly interested in understanding more clearly is the needs of a Matchmaker that automatically infers a preferences profile from a set of concrete application settings. During Tuesday's call, you mentioned that this task required conditional preferences in order to be feasible at all. Can someone elaborate on this point, perhaps also sketching out a handful of real-world use cases and example conditional statements to illustrate this point? I think it would very helpful for this discussion.

> 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.

Right. My point is that embedding a programming language like this isn't quite as helpful as we might initially think. I think that good help constructs typically a means for layering on higher-level abstractions that convey greater semantics to the system. That's why we suggested a model where the operators themselves were registry-based and thus extensible.

A conditional statement that consists of an unbounded collection of boolean operators will very opaque to a computer program. Such an expression can be evaluated, but probably not understood meaningfully. This will make it harder to write user interfaces for editing preferences documents. 

Christophe made the point on Tuesday that--even in a world where an AI-based Matchmaker can infer user preferences documents from application settings--the user will still have to get involved sometimes. They'll need to refine the results of the Matchmaker and to advise it or correct it. So we don't want to commit to a system that will cause major problems for UI development and preferences authoring tools.

To be clear, I think the scenario where users and their helpers will interact with wizards, editors, and authoring tools to edit, refine, and view their preferences profiles is an important mainstream use case, not an edge case.

> 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).

Agreed. Our suggested improvements to the JSON structure are intended to increase usefulness for developers and programs. I can't tell from your response if you've had a chance to look over these suggestions and if you think they are reasonable? Feedback is very much appreciated. They are documented here:

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

As a next step, I'm wondering if anyone would like to explore designs for an extensible, registry-based representation for conditional preferences? I know Antranig has already done some sketching in this regard, and some of the work we've done for Model Transformation in the core architecture might also serve as a precedent for this kind of an approach.

Colin

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



More information about the Accessforall mailing list