UI Options and user preferences stored locally

Colin Clark colinbdclark at gmail.com
Fri Jan 7 01:35:10 UTC 2011


Great conversation! I've included responses to your last two emails below...

On 2011-01-04, at 4:52 PM, Richard Schwerdtfeger wrote:

> We need to have user preferences available to corporate web sites, libraries, etc. What is extremely important to me is that users be able to use GPII to improve their prospects for employment. 

I think you're preaching to the choir on this point--this is definitely the goal that we're all keen to realize, so no worries there.

It's fairly clear to me that we have to look at more than one approach to user preferences storage for GPII. Our users are going to want to feel a sense of autonomy over their preferences profiles. They're going to want to have the choice of keeping their preferences "close to the hip," stored locally on their mobile device or in their desktop browser. They're also going to want the flexibility of keeping their preferences in the cloud, accessible to a wide variety of applications and Web services without having to manage lots of separate profiles, logins, or account information.

In both scenarios, we can be sure that users will want to be able to carefully manage permissions--they'll choose which sites are allowed to access their preferences, all with an easy and non-technical user interface.

Your library use case is an excellent one to look at a bit more closely. There are a lot of potential GPII users who won't have access to their own computers--they'll go to the library or community centre to access the Web. Local storage in a shared computer environment such as this won't work--preferences will need to be "out there" in the cloud so that users can use different workstations each time they visit. From a security perspective, they need to be sure that no one else can steal their preferences by having physical access to the workstation they were just using.

In the long run, one might imagine some kind of GPII-blessed single centralized storage server, but I don't think this is very wise from an architectural perspective. A healthy architecture should support decentralization and enable multiple means for storing and accessing preferences across the Web. As you said in a previous email, the key focus needs to be services and a shared vocabulary for preferences.

To be clear, I'm not a huge OpenID fan, but so far I don't know of any viable alternatives. If nothing else, it provide us with a flawed but workable example of Web-wide single sign-on and shared identities that many users and companies are happy with. It may not match IBM's own corporate goals, but it's hard to ignore. 

My argument here is not "let's build everything on OpenID," but rather, "let's ensure we can work with a variety of solutions that users actually use today." 

For the purposes of this thread, though, let's focus on the stuff we both want to build, and create a collaboration from there. Local browser storage sounds like where it's at.

> As I stated, what I would prefer is the HTML 5 local data storage approach with a browser add on. This plug-in would also synch up with GPII when a preference store is available. For this:
> - A user has full control over who accesses the preferences
> - Preferences can be accessed by web applications directly from HTML 5 constructs
> - A user can configure preferences locally in their browser

This approach is exactly in sync with what I have been thinking as well. It's even more appealing if we can ultimately move it from an add-on to a formal part of the HTML5 local data storage specification so it will be available to all users and Web applications without having to install anything.

In terms of actually implementing it, my suggestion for how we proceed is:

1. Build a Firefox Add-on using their new Jetpack SDK (https://jetpack.mozillalabs.com/) so that we can start do the interesting design work around preferences editing and permissions in a real-world scenario--build it, get it into the hands of real users, and iterate. From the API perspective, I see no reason not to expose this just like HTML5 local data storage's get/setItem(), but with an additional layer of approval/rejection from the user.

2. Work with you to look at how this approach can be fed directly into the HTML5 local data storage specification

We'd like to start on this work pretty much right away. Antranig's time is freeing up, and Jess and I have scheduled design and development time for preferences storage work as part of Infusion 1.4 between now and April. Now's a good time for you to get involved.

> Personally, I have a concern of delivering too much of my private data into the hands of a commercial business. Google is really an advertising company who make use of your private data for reasons not intended by the user. So, the fact that a company Google supports OpenID is not necessarily a plus. As for Yahoo I have concerns too. I wonder who will end up owning them going forward and where my personal data would end up. What this is saying is I would prefer to have greater control over my user preferences by controlling and manipulating them locally. 

This is a good point, but I actually think you're conflating two separate issues: 

1. How do we identify and authenticate people?
2.Where do the preferences get stored?

There's no question in my mind that GPII needs to help users choose trustworthy places to store their preferences. It should be a completely separate issue from any authentication and SSO strategies we use. The decision about trust is going to be an individual one, so our architectural goal is to weave together potentially diverse sources of preferences.

> Are you looking at AfA version 3.0? As you know Anastasia contributes to that specification. 

I've been following the AccessForAll 3.0 work closely. We're also keen to be able to take advantage of the new UI Component metadata/preferences we've adding to the ISO 24751 standard (which has emerged from our work in Infusion). The choice of which standard to use is something we still need to work out, and I'd be happy to chat more with you about it.

> The last time we spoke you indicated that you were working out the architectural issues on the browser plug-in. I believe that was in DC. It seems nothing has been done on that yet so I may have misunderstood you. Are you saying that you were planning to do the architectural work or are there documents available to review? 

If I remember correctly, that conversation was actually during our last GPII architecture in October. We were in the midst of a huge new release of Infusion (http://fluidproject.org/news/39/144/Infusion-1-3-is-here/) at the time, and haven't had as much time to put towards this as I would have liked. Now is the time.

So, with that, do you have any suggestions for next steps, Rich?


Colin Clark
Technical Lead, Fluid Project

More information about the fluid-work mailing list