Forum OpenACS Development: Improving Group admin UI

Posted by Joel Aufrecht on 03/18/04 03:03 PM

The current UI for creating and modifying user groups is (click here">) here. Very few people have reported satisfaction with this UI. (Most recently, see this post.)

We can cobble together funding from several current, affected clients, plus our own contributions, and put some time into fixing it. The question is, what's the best fix?

At a high level, the direction I propose is to hide all mention of Group Types, Relational Segments, and Relationship Types and simply display them all as groups and subgroups. The new interface would then consist of one logical object, the "group", exposed through these pages

Group. This has two parts. The top is parameters of the group (name, anything else?), a link to set permissions for the group. The second part is a list of all members of the group, including subgroups. We could show all direct members (that is, members of any "relational segment" where the other side of the segment is the group") in one list and differentiate the relsegs via a column:
```
Group:  Foobar

Members       Type
Alice         Member
Bob           Member
Chuck         Admin
VIPs          Subgroup
```
Or we could treat all relsegs as subgroups:
```
Group: Foobar

Contains    Number
Member       2
Admin        1
VIP          (subgroup)
```
This page provides or links to all the functionality of the old group page and the old Relational Segment administration, including listing all members and subgroups, adding members and subgroups, removing members and subgroups, and controlling the status of members.
Add a Group: This page includes all the functionality of Add group type and Create relation type including adding new groups and adding new rel types.

2: Re: Improving Group admin UI (response to 1)

Posted by Tom Jackson on 03/18/04 05:31 PM

If someone does over the admin UI, consider that the current UI doesn't show all groups/relsegs. At some point the queries for these were tied to the current subsite package_id, so any groups or relational segments added via plsql/plpgsql will not show up in any admin UI.

3: Re: Improving Group admin UI (response to 2)

Posted by Joel Aufrecht on 03/30/04 02:16 PM

I've diagrammed the data model and initial groups in a new install. Can somebody who knows more about this than me review them for accuracy (and to see if I omitted important bits) before I add them to the docs?

4: Re: Improving Group admin UI (response to 1)

Posted by Jade Rubick on 04/26/04 08:11 PM

These are a step in the right direction, and any improvement you make will be welcome.

I used the group pages quite a bit, because some of the older ACS 3.4 applications I ported to OpenACS relied on group membership as a test of whether or not to do certain actions (such as sending out email notifications -- it would send a notification to every member of a group for example).

So one of the improvements I'd eventually like to get into OpenACS is the use-case of adding someone to multiple groups at one time. If someone doesn't do this, I'll do it when it gets painful enough. :)

5: Re: Improving Group admin UI (response to 1)

Posted by Lars Pind on 05/24/04 09:08 PM

Here are some screen shots from a competing system with a nice, simple user interface.

Group membership:

http://www.ramius.net/images/screens/member-profile.gif

Group permissions:

http://www.ramius.net/images/screens/membership-groups.gif

Can we get away with something as simple as this?

/Lars

6: Re: Improving Group admin UI (response to 5)

Posted by Jeff Davis on 05/25/04 12:03 AM

I don't understand the second screen, what does that big permission box do? Is it the permissions for the selected group?

Also, take their example: you have checkboxes for the groups, what if you wanted cities instead of provinces, then you would have lots of groups. Or take dotlrn, where you might have 100s of classes/clubs; too many to present like that.

It's nice if the list is short though.