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 <[EMAIL PROTECTED]> 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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
