[Accessforall] [SP2] Conditional preferences

Gregg Vanderheiden gv at trace.wisc.edu
Fri Aug 10 20:42:10 UTC 2012

We had talked about the need to refer to preferences as  "needs and preferences"  for communication reasons. (it is hard to get public funds to ensure that people have their preferences met --- but it is much easier to get funding and commitment to get someone's needs met.)

But we had always equated them.  that is  -- we used  "needs and preferences" as a single entity where there is no bright line between them.  (and one persons preference is another person's need anyway)

I don't think we should try to separate them (I don't even think it is possible)

I DO think we need to keep "needs" tightly attached to 'preferences'.  But think they should be thought of as hyphenated needs-and-preferences into a single term and not separated. 

Gregg Vanderheiden Ph.D.
Director Trace R&D Center
Professor Industrial & Systems Engineering
and Biomedical Engineering
University of Wisconsin-Madison

Technical Director - Cloud4all Project - http://Cloud4all.info
Co-Director, Raising the Floor - International
and the Global Public Inclusive Infrastructure Project
http://Raisingthefloor.org   ---   http://GPII.net

On Aug 10, 2012, at 10:47 AM, "Clark, Colin" <cclark at ocadu.ca> wrote:

> Hi all,
> On 2012-08-06, at 3:18 PM, Andy Heath wrote:
>> axelrod:andy - I haven't followed every twist and turn in this
>> thread so I'm guessing and filling in the gaps, possibly wrongly,
>> but what I'm seeing here is a debate about whether preferences
>> should only be described in low level terms or whether there should be some notion of needs (or something like that, that is at a higher level) in there somewhere.  Am I interpreting this discussion reasonably ?
> While it may just be a question of terminology, I don't think making a distinction between preferences and needs is a good idea--we've always taken the approach that AccessForAll doesn't differentiate in any technical way between the user's needs, wants, tastes, etc. They're all important.
> The goal of this particular discussion, in my mind, is fairly focused: to brainstorm is a mechanism by which users can express conditional needs and preferences in a semantic and extensible way, rather than a with a fixed set of opaque, low-level boolean operators.
> Colin
> ---
> Colin Clark
> Lead Software Architect,
> Inclusive Design Research Centre, OCAD University
> http://inclusivedesign.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120810/ee068b8c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 7318 bytes
Desc: not available
URL: <http://lists.idrc.ocad.ca/pipermail/accessforall/attachments/20120810/ee068b8c/attachment-0001.bin>

More information about the Accessforall mailing list