(Profile, Preferences, Account) UCamp Update

[John Norman]

I know I am late on this one, but I would like to introduce what I  
hope could be a useful concept.

We have a lot of variability around how different institutions want  
to handle account/profile/identity information and there will likely  
be no single profile of functionality that works for all out of the  
box. However, users will appreciate being able to maintain personal  
information in as few places as possible.

So how about thinking up a modular tool, that can pull (or recieve a  
push of) information blocks from different places and compose them on  
a page, show clearly which information can be modified from Sakai  
(some institutions may have central systems for ID but accept  
modifications from trusted other systems now or in the future) and  
which cannot, and allow that modification where it is allowed in a  
friendly way.

This seems like a tall order for a UCamp, but I think it is more  
future-proof.

John

On 19 Nov 2007, at 17:43, Ray Davis wrote:

> I've always been sorry that Sakai was unable to coordinate Indiana's
> Profile needs with framework development plans. (At the very least,
> supporting "EduPerson" attributes seems like a pretty basic LMS/CLE
> requirement!) Making Profile a pseudo-standalone tool was probably
> the only practical way for the team to deliver it in a timely
> fashion, but for obvious reasons its services and data end up
> bleeding into apparently separate tools (notably Roster). Similarly,
> the functionality described by Vivie is hardly JForum specific, and
> could be useful to many installations who prefer to deploy other
> discussion software.
>
> Trying to figure out a single UI that will meet the vastly varying
> detailed functional requirements of all our target users might be
> overwhelming. But I do believe there's a general need for some
> centrally managed store of person data that's more complex than our
> current "User" module or "Preferences" tool support: behind the UI,
> we need to allow for more efficiently handled properties and we need
> to allow for more contexts (e.g., a course-specific email address for
> instructors, or a project-specific username for language classes).
> While the usability research continues, maybe some of the people
> working on the user kernel services could begin to talk about ways of
> handling this problem. It's possible that with services in place, a
> suite of lighter-weight profile-style applications might be more
> cheaply produced.
>
> Ray
>
> At 08:36 PM 11/16/2007, Vivie Sinou wrote:
> ...
>> We use Jforum's My Profile which our users love
>> as it offers just in-time member data and opportunities for users  
>> to learn
>> about each other and connect while collaborating and communicating in
>> discussions.
>>
>> We eliminated Profile two years ago, as it was confusing to users  
>> to have
>> two profile tools. Jforum's My Profile is also global, reads  
>> Account data,
>> and offers great functionality to our users when they need it the  
>> most -
>> communicating and collaborating. Jforum's My Profile allows  
>> participants to
>> set preferences, avatars, IM info, interests, etc. We plan on  
>> expanding on
>> Jforum's My Profile functionality to provide opportunities for  
>> networking
>> and collaborating, based on profile interests.
>
> _______________________________________________
> fluid-work mailing list
> fluid-work at fluidproject.org
> http://fluidproject.org/mailman/listinfo/fluid-work