[Accessforall] [Profiles] Profiles (PNP Sets), Keys and Context?
cclark at ocadu.ca
Sat Jul 7 10:34:05 UTC 2012
As part of the basic Matchmaking services available to GPII developers, we are currently building a CSS-like system for ranking the specificity of a preferences match (comparable to CSS selector specificity). I don't see why we couldn't also take inspiration CSS's cascade for resolving multiple preferences documents. It's a very good idea.
On 2012-07-06, at 11:34 AM, Treviranus, Jutta (Academic) wrote:
> I was going to send the same message in response to Matthew's question. We have used something similar the inheritance strategy in CSS where local and specific trumps generic and you inherit the generic.
> On 2012-07-06, at 9:10 AM, Denis Anson wrote:
>> Could this work like CSS? You call up generic interface style sheet. When you make a change (e.g. font size), your change is recorded in your personal preference file, but all other settings fall through to the generic style sheet. This would make you personal style sheet more compact, saving storage.
>> Denis Anson, MS, OTR
>> Director of Research and Development
>> Assistive Technology Research Institute
>> Misericordia University
>> 301 Lake St.
>> Dallas, PA 18636
>> voice: 570-674-6413
>> fax: 570-674-8054
>> danson at misericordia.edu
>> On Jul 6, 2012, at 8:58 AM, Matthew Atkinson wrote:
>>> [ I've studied the wiki and follow these lists. Apologies if I've missed the answer to my question. ]
>>> This is a question based on the discussion of separating specific user identities from profiles (PNP sets) via the use of keys to identify PNP sets, as opposed to user IDs:
>>> What is the relationship between a PNP set and context-dependent preferences?
>>> Is the variability of preferences in different contexts:
>>> * contained/encoded within a single profile (PNP set) or even a single preference within that set,
>>> * or is it expressed by switching between different profiles (PNP sets), each of which would have a different key?
>>> Some context-dependent preferences might make sense when attached to a generic profile: e.g. most low-vision users would prefer larger print than normal [though /how much/ larger is of course going to be user-specific]. But some are more specific to individual users: e.g. choice of desktop theme when at home vs being at work (aesthetic preferences may be out of scope, but I'm sure there are other examples).
>>> That's the end of my question; I have thought about some ways this could work in practice, though I expect you are already some way ahead on this...
>>> Would it be the case that, when a user makes a change to a generic profile -- e.g. by setting a specific font size for their larger-than-normal text -- that a copy of this profile is created and then tied to that user by way of a new key and then that copy is edited in future rather than the generic profile?
>>> I'm not sure how a context-dependent preference is resolved. I can think of two main ways:
>>> Context description --> Key --> Profile/PNP set --> Preference, or
>>> Key --> Profile/PNP set --> Context description --> Preference
>>> By "context description" I mean anything that counts as context such as users' locations (home/work/...), device type in use (mobile/desktop/...), ambient lighting level, type of application in use, ...
>>> Would both (or other) situations be supported? How do "partial" profiles (PNP sets) fit in to this? (I gather there is the concept of a set of preferences that could be overlaid on the current set.)
>>> best regards,
>>> Matthew Tylee Atkinson
>>> Profiles mailing list
>>> Profiles at lists.gpii.net
>> Accessforall mailing list
>> Accessforall at fluidproject.org
> Accessforall mailing list
> Accessforall at fluidproject.org
Lead Software Architect,
Inclusive Design Research Centre, OCAD University
More information about the Accessforall