[Design][Cosmo] User Interface for Group management in Cosmo

[Mimi Yin]

So to reiterate the goals for the Cosmo Account Browser UI, the  
target user for Preview is specifically Jared. So Jared should really  
be who we should ask re: requirements for group management. By  
targeting Jared, we think we will also satisfy the needs of some  
subset of SNARF users, but we're not designing for the general SNARF  
user. This is the same thinking behind the Cosmo PIM UI, where we've  
decided to target the Casual Collaborator with the knowledge that by  
doing so, we will also satisfy some standalone and remote access use  
cases.

This means that when it does come time to define and target SNARF  
users, Cosmo PIM UI and Chandler Desktop users, we will most likely  
revisit all of these issues from the ground up to construct an end- 
user mental model of groups that makes sense for those particular  
scenarios.

For now, Jared should really be driving the design for Group  
management. Jared? any thoughts?

Mimi

On Feb 9, 2007, at 3:55 PM, Ted Leung wrote:

> I'd suggest that we keep this simple for now.   What Vinu has done  
> is implemented how WebDAV wants to do ACL's.  This is not a general  
> group model for Chandler, so let's not try to make it into one,  
> especially before preview.    I think that there are enough ways to  
> make good use of his work without trying to tackle a grand unified  
> desktop/server wide security model.   We'll need to do that, but  
> that's a comprehensive activity that is going to need coordination  
> between desktop and server/web ui needs.
>
> Let's keep it simple for now.
>
> Ted
>
> On Feb 9, 2007, at 11:27 AM, Mimi Yin wrote:
>
>> Okay, let's focus on assigning privileges for now. And this would  
>> be a SNARF administrator doing this? and/or Jared/Dave as  
>> administrators of the Hosted Service?
>>
>> Just thinking aloud, these are questions for everyone. (Vinu,  
>> screenshots would be great.)
>>
>> So the use cases would be something like:
>>
>> For a class schedule calendar.
>> A professor granting read-write privileges to all his TAs.
>> A professor granting read-only privileges to his students.
>>
>> For an office hours calendar, I presume the students would also  
>> have read-write privileges.
>>
>> It seems like these groups will stay pretty static. Although on a  
>> semester basis, the people will change. Are there scenarios where  
>> the people in the groups would change on a regular basis? Monthly,  
>> Weekly, Daily? Maybe in situations where people work with vendors  
>> and contractors a lot? e.g. You're an estate manager and you have  
>> a calendar for scheduling repairs and maintenance whatnot? Maybe  
>> you want to give certain people limited access to the  
>> calendar...for as long as a project is going on. Once it's over,  
>> you remove them from the group. However, if you work with the same  
>> people over and over again, you may just 'suspend' some people's  
>> access and then re-activate them when they're needed again.
>>
>> Question: Why would someone want/need to create a group to grant  
>> privileges? Is it so you can easily give the same group of people  
>> access to different shares? How common will it be in that scenario  
>> for their to be exceptions to the group? e.g. I'm a professor, I  
>> teach 3 classes. I have the same TAs for all 3 classes, except for  
>> 1. I give read-write privileges to my TA group for all 3 classes,  
>> except for the 1 TA who doesn't TA the 3rd class.
>>
>> Workflow question: Can you create a group after you've granted  
>> privileges to a whole list of individuals.
>>
>> What about query-based groups? Are these static or do they  
>> refresh? Can you have inclusions and exclusions? Everyone with a  
>> username that starts with a letter from A-M + this user who has a  
>> username that starts with '!' What are use cases for this? Is this  
>> mostly an admin feature?
>>
>> How often will users create short-lived shares?
>> For example, you manage a calendar for tour groups to visit Des  
>> Moines. For the week that the tour group is visiting, the tour  
>> organizers and the visitors can view and edit a shared calendar to  
>> figure out together what they would like to do.
>>
>> A twist on the tour group example. Say you work with the same  
>> travel agency, but the visitors themselves change. Would you want  
>> just a single group and then change the tour group members out  
>> every week? Or would you want one group for the travel agency  
>> people and then create a new group for each tour group every week?
>>
>> Workflow question: Can you create accounts for the tour group  
>> visitors as you populate the group? And then send the accounts +  
>> passwords to the members of the tour group, at which point they  
>> can change their password? As an organizer, it seems like you  
>> would want to do that, rather than waiting for the individuals in  
>> the group to create their accounts before assigning privileges one- 
>> by-one.
>>
>> 1. When you say adding users, do you mean adding user accounts? or  
>> email addresses?
>> 2. There will presumably be students who haven't yet signed up for  
>> an account? Using email addresses seems like it would cover both  
>> users with accounts and those without accounts.
>> 3. How do privileges interact with tickets? What about per-user  
>> tickets?
>>
>> Mimi
>>
>>
>> On Feb 7, 2007, at 1:56 PM, Vinubalaji Gopal wrote:
>>
>>> On 2/7/07, Mimi Yin <mimi at osafoundation.org> wrote:
>>>> Vinu, what will these groups be used for? Categorization and
>>>> Organization? Addressing emails? Assigning privileges? Managing
>>>
>>> right now it will be used for assigning priviliges, but it can be
>>> used in any context. So I am just designing the UI for group
>>> management as an administrator where new groups can be created and
>>> users, groups can be added to that  particular group. so far its
>>> similar to the user management ui except that modifying a group  
>>> shows
>>> a drag and drop ui (will add a few screenshots to show how it  
>>> looks).
>>>
>>> later we could have allow users to search and join a group :) and  
>>> all
>>> the other things like addressing a group (since each group will have
>>> all the emails), etc.
>>>
>>>
>>>
>>> -- 
>>> Vinu
>>>
>>> In a world without fences who needs Gates?
>>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>>
>>> Open Source Applications Foundation "Design" mailing list
>>> http://lists.osafoundation.org/mailman/listinfo/design
>>
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>> Open Source Applications Foundation "Design" mailing list
>> http://lists.osafoundation.org/mailman/listinfo/design
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design