Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper design call, Wednesday, 6 June 2012, 1200EDT (1600Z)

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper design call, Wednesday, 6 June 2012, 1200EDT (1600Z)

Chronological Thread 
  • From: Tom Barton <>
  • To:
  • Subject: Re: [grouper-dev] Grouper design call, Wednesday, 6 June 2012, 1200EDT (1600Z)
  • Date: Wed, 06 Jun 2012 08:32:46 -0500


I'm glad to hear you had a chance to visit with your daughter!

The audiences and associated important tasks were discussed on the last call and captured in the minutes. I will ensure that the result of our discussion later today will be captured on or under the UI redesign wiki page. And I think many agree with you that for an "ordinary user" audience, less and simpler is better.

Hope you can make it,

On 6/6/2012 8:26 AM, Steven Carmody wrote:
On 6/5/12 10:59 PM, Tom Barton wrote:

5. UI planning
. report from Michael & Chris of their webex on grouper demo
. do we have agreement on the following?
. audiences
. most important tasks each audience needs to accomplish
. will there be one UI for all audiences, one per audience, or somewhere
in between?
. should we circulate audience/tasks matrix to grouper-users for feedback?
. next steps

I'm going to try to make this call. But, our daughter has been visiting, and this afternoon we have to put her on a plane taking her back overseas. So, depending on how things go locally, I may miss the call.

Looking at the list of topics above, and the two urls, I don't see the word "audience" on either page ... where would I go to see "tasks each audience needs to accomplish" ?

Also,increasingly, here at Brown we're thinking of embedding a simple UI within various contexts (eg where an instructor manages groups and services to support their course; similar to the thinking behind Duke's Toolkit).

Also, #4 under Community requests:

Visual display of groups impacting membership of a given group.
Would illustrate subgroups and composite factors, perhaps expanded by levels.

We think its VERY important to hide some of the "plumbing" from a user who is is tweaking a group that is based on data from a business system. They need to see the membership, but we think its just plain confusing to show them the base group and a separate GUESTS group, which are then combined into the *REAL* group.

Here's an example of what I mean (described in a posting on may 29):

We have a potential mockup available here, and are interested in comments and

Archive powered by MHonArc 2.6.16.

Top of Page