Grouper Developers Forum

[Chris Hyzer <>]

Grouper-All is not a group (though the UI could represent it however it wants).  i.e. there is no way in the API I believe to get all the “members of grouper-all”.  Think of it more as a “public” flag on a privilege on a group…

 

Thanks,

Chris

 

 

From: [mailto:] On Behalf Of Michael Girgis
Sent: Monday, December 17, 2012 3:50 PM
To: Tom Barton
Cc: <>; Brenda Janish
Subject: Re: [grouper-dev] Lo-fi wireframes

 

A little follow-up to this question:

 

On the View a Group screen, what's the meaning of the N/A memberships?

 

My answer was: The N/A memberships are those people who have privileges for a group but are not members. For example, an ADMIN who is not a member.

 

In the case where the Grouper-All subject has READ/VIEW privileges, setting the filter to display "Everyone" could theoretically end up showing a very large list of people, since it would include all those people in Grouper-All. So a lot of people would show up as N/A memberships. I can see this being very confusing. It might make sense to set the filter default to "Members only" so that the N/As are excluded, but leave Everyone as a filter option.

 

 

On Dec 17, 2012, at 12:13 PM, Tom Barton wrote:

Colleagues,

It would be great if you could give Michael & Brenda some feedback on the direction they are proposing for the new UI. Even a "looks good to me" is very helpful, and of course more specific questions or feedback is great too. Recall that we are trying to address basic-to-intermediate users and tasks, leaving advanced tasks as-is in the current "admin UI", at least for grouper v2.2.

Michael & Brenda,

I have a couple of questions. On the Add People screen, is that a depiction of a "wizard-like" work flow, ie, the UI first presents *only* the "Find people" panel, and when Next is clicked the "Assign privileges" panel comes up, etc?

On the "Assign privileges" panel, I wondered whether we should have membership and privilege check boxes together. Membership only is the objective far more often than privilege assignment. I see that's at the top of the panel, but it seems less prominent than the priv check boxes. I wonder if it should look more like this (please forgive crude attempt!):

[ 1 ] Find people  >  [ 2 ] Assign privileges  > [ 3 ] Review

Membership
[  ] Add Daniel Smith as a member

Privileges for this group
[  ] Admin    [  ] Update
[  ] Read       [  ] View
[  ] Opt-in     [  ] Opt-out

That makes membership and priv assignment equally prominent. Might even have the Privileges stuff hidden by a +/- to expand collapse, with default collapsed. I suggest not having the group name in the membership check box text - they can be long, and it's in the header area above, in large type I think. I also wondered about this organization of the privs themselves, grouping related ones together.

On the View a Group screen, what's the meaning of the N/A memberships? Also, I wonder if the "Show [drop down] entries" widget should move too the bottom, somewhere left of the paging controls. That would leave space at the top of the list for a heading element above the check boxes of "Select" and to its right a [drop down] of the actions that are possible. I suppose those things like are delete, change membership start/end dates, import/export member list, view membership paths (if that even belongs in a basic/intermediate interface). Finally, what's the difference between the Filter and the Search?

Is the right-hand column, for advanced tasks, a little redundant? I guess my question boils down to whether that task/action drop down in the header of the middle column covers everything that would go in the right column. Or are you really thinking that the layou needs a right column for a future phase, ie, when the new UI begins to take on some of the advanced tasks that we'll leave only in the admin UI for v2.2?

Finally, there's a build-in Subject called Grouper-All which can be used to indicate "all current subjects, whatever those are". It is most often used to indicate that everyone should be able to View or Read a given group, without needing to list "everyone". When Grouper-All is given a privilege like that, I wonder whether the Privileges for a given subject like Daniel Smith should show checked boxes for Read and View, but grey-out or otherwise indicating that they can't be unchecked just for Daniel.

Thanks,
Tom

On 12/13/2012 10:14 AM, Michael Girgis wrote:

Hi everyone.

 

Below, you'll find a link to a first pass at lo-fidelity wireframes for the Grouper 2.2 UI. A few notes before you take a look:

 

* These wireframes are only intended to convey the general direction I'm taking with the UI design and are clearly not fully spec'd or developed.

* Only a few key screens are represented here, related to the most common tasks of viewing/editing folders, groups and users.

* The first two pages simply describe the various page components in the three-column layout.

 

These wireframes will be used to validate that users can do the most basic tasks of navigating the site and finding and editing entities. So I'm mainly interested in higher-level feedback regarding the overall approach/layout, and less so the more granular functionality which may not yet be fully developed. Please feel free to email me directly with feedback.

 

http://grouper-ui.uchicago.edu/lofi/

 

If you have a lot of feedback you'd like to share and you don't mind creating an account on yet another website, let me know and I'll create an account for you on cageapp.com, where you'll be able to add notes directly to the screenshots.

 

Thanks in advance for your feedback!

 

Michael Girgis

University of Chicago