Grouper UI Analysis

The purpose of this UI analysis is to gather input, feedback, ideas and functional enhancements for the Grouper User Interface. This effort is currently (January '08) spearheaded by the University of Pennsylvania.

The motivation of this initiative is to improve the overall baseline UI to better coincide with the needs of a large scale deployment where end users (in mass) will be able to intuitively navigate and interact with the grouper functionality for which they have permissions.


The approach taken was to create a wire-frame model from the perspective of an end user who may want to search and find a group to join (opt in). Administrative functionality was then added without disrupting the consistency of the interface. The idea being that the interface remains the same and the amount of functionality exposed to the user is dependent on their underlying permissions.

Wire Frame

The wire frame is in PDF format and represents, conceptually, a different approach to a grouper front end

Proposed UI Modifications

A UI Subgroup was formed from interested members of the development community to review and discuss changes that would have a low technical implementation effort but provide a high impact to site usability.

This proposed UI redesign is in PDF format and details a variety of visual enhancements to the grouper user interface 

The proposed changes to the default grouper terms that are used by the user interface focus on more intuitive and common terminology

Initial Findings

Initial evaluation of the existing out-of-the-box user interface shows a number of issues that make it somewhat cumbersome to use.

  • Buttons and navigation are not used in a consistent manner
  • Inconsistent or inappropriate terminology for users to understand
  • The use of 'Saved' (in navigation) implies persisted across session while clipboard or workspace implies session specific
  • Cancel is used as a back button
  • No context sensitive help
  • Delete doesn't have a confirmation dialog
  • Make names more friendly (Terms like 'stem' or 'extension' don't convey an intuitive meaning across broad user groups)
  • Search Results don't show enough identifiable data to distinguish between two people named 'Ed Smith'

A navigation flow diagram shows the interaction between pages and functions. This was helpful in determining that search is a core utility that precedes most other site actions. This leads to the following conclusions:

  • Basically all operations are performed against search results
  • Abstract out search to its own utility-
  • Create utility/tool bar for Help, browse, search, log in/out
  • Simplify screen flow overall
  • Search results should show more attribute data in grid/table format and sortable by column.

UI Modifications to Baseline

The UI subgroup was amiable to a series of modifications that are thought to make the baseline user interface significantly stronger. The modifications will be deployed as part of the Spring 2008 release of v1.3. 

The scope of what will be in v1.3 is largely related to easier to understand terminology and help text. The help text will be in the format of tooltips and infodots. 

Details of what is implemeted can be found on the UI Modifications page and the supporting technical documentation pages for tooltips and infodots

     (question) Questions or comments? (info) Contact us.

  • No labels


  1. Unknown User (

    Initial Findings

    • Buttons and navigation are not used in a consistent manner

      Guilty. New features have been added ad hoc rather than to a functional scheme. I'm happy to address these if pointed in the right direction

    • Inconsistent or inappropriate terminology for users to understand

      This has always been an issue but it is unlikely we can provide terminology that would suit every one. Almost all on screen text can be configured by overriding If agreement can be reached the defaults can be changed, or you could contribute back an alternative so sites could choose which to use as their starting point.

    • The use of 'Saved' (in navigation) implies persisted across session while clipboard or workspace implies session specific

      Ideally it would be possible to persist the saved items, however, it has not been a priority.  I'm happy to change the terminology

    • Cancel is used as a back button

      I can look to change this

    • No context sensitive help

      This has never been a priority and there has been a general feeling we should not spend a lot of time on user documentation as we expect sites to customize the UI. On the other hand it would make sense for the UI to support  context sensitive help so there are place holders for text. The use of Resource bundles is inappropriate here due to the size of text blocks and the level of formatting that is likely to be used

    • Delete doesn't have a confirmation dialog

      I have tried to address this with 1.2.1. Let me know if I have missed a place

    • Make names more friendly (Terms like 'stem' or 'extension' don't convey an intuitive meaning across broad user groups)

      Again something to change in

    • Search Results don't show enough identifiable data to distinguish between two people named 'Ed Smith'

      The UI depends on the Subject API for displaying actual or potential group members. This API is an abstraction which allows any type of entity to become a group member, however, it also means we cannot assume any common attributes. The UI does, however, allow you to customize what is displayed based on the Source of the Subject. You can either configure the actual field you want to display in, or you can define a JSP template (dynamic tile) which allows you to display multiple attributes formatted as you choose

  2. Unknown User (

    Wire Frame

    This is very useful and makes it much easier to have a discussion. I'll make some general comments and then go into more detail on each of the pages.

    I think browsing for groups is as important as searching. Currently, for groups, both options appear in the page content but I can see that having search always available in the navigation instead would simplify things.

    The current UI defines various modes - My memberships, Create/Manage/Join/All groups which provide some context for browsing and searching. The wire frame does not show a context which is a big change. I think the UI can be refactored and the defaults changed e.g. Manage groups could be the default. Alternatively, one code base might support two different UIs:

    1. Manage/Create/All - solely focussed on manipulating groups
    2. My Memberships/Join/All? - focussed on maintaining your own memberships and possibly a gateway to resources associated with groups you are a member of

    The menu items which appear are customizable and could depend on an parameter passed at login - or a user preference.

    Stems are also searchable - they are searched in Create groups.

    As I mentioned on the conference call Person does not necessarily directly map to a single Subject Source. Some configuration would be needed to specify one or more Sources which should be searched.

    Group Search Results page 

    Grouper has some standard attributes for groups: uid, create time, last modify time, created by, last modified by. Some or all of these could be tabulated. Custom attributes would be more problematical since group search results may well have different group types, and so different attributes available. Also, which ones are displayed would have to be configured in some way. I will look at making tabulation an option and even the default.

    Sorting is currently pre-configured rather than parameterized, but that is something I can have a look at. The bigger issue is performance. Group searching can be quite slow and the sorting occurs in the UI. This means that the UI has to process each search result regardless of whether it will appear on the screen. I'm currently working on some caching in the API which may make it practical for the UI to cache resultsets - the group data itself would not be duplicated and so could scale.

    Path is one of the things that doesn't tabulate well but is an attribute users may well want to sort by. 

    Group Details page :: Information Panel view

    Path: FirstTierGroup: SecondTierGroup: ThirdTierGroup: FourthTierGroup: FifthTierGroup

    is misleading - the path is a series of Stems. Clicking on a Stem is effectively browsing and would show a list of child Stems and Groups

    You should be able to manage privileges here - non members may have privileges. 

    Group Details page :: Show Members tab 

    • Show all members
    • Show PERSONS only
    • Show GROUPS only

    The current UI can be configured to show only Subjects from a Single Source - and only lists Sources which provided members. If people are split across multiple Sources this would require more work.

    In Grouper you can have direct and indirect members. If Group B is a member of Group A then all members of Group B are indirect members of Group A. A member can also be a member by > 1 path. This undoubtedly leads to some of the complexity of the current UI, but it is nevertheless important. The current UI only shows a checkbox if showing direct members. Also, the Remove all members button removes all members not just the page of members shown.

    Tabulating members has the same issues as for tabulating groups -except there are fewer attributes you can depend on being present. Sorting of membership lists is also problematical, at present, for large memberships because, again, it means that the UI has to process each result and do individual external lookups - LDAP/RDBMS (or other) to retrieve Subject attributes. At Bristol I am working around this issue by pre-loading and caching all my Subjects (I use a custom Source adapter).

    Does the Modify privileges  button apply to selected members? If so you also need to be able to modify privileges for non members. You could, in principle, manage privileges for multiple Subjects, however, you have to take account of the fact that privileges may be indirect i.e. they may have been applied to a group where the Subject is a member (and there is no limit to the nesting of groups).

    Group Details page :: Enrollment tab (initial view) 

    Here you also need to have the advanced search option. Also, you should be able to browse. Say you have a large course group and you want to create some lab groups based on it, you would probably locate the lab groups close to the course group so it would be easier to find by browsing that searching. This could be achieved by having Search, Advanced search and Browse tabs - with sites able to configure the default.

    Group Details page :: Enrollment tab (full view)

    The current UI also allows management of privileges here. this could be made configurable.

    Person Search Results Page 

    No new comments

    Person Details Page :: Information Panel view 

    If you are managing memberships and privileges separately elsewhere then they should be managed separately here or the Show privileges button should be something like Show group memberships and privileges. Also, you should be able to view Stem privileges.

    I recently added the ability to show privileges a Subject has for a group search result set. I wanted to limit the results for performance reasons - hence the search rather than showing all groups. If you have a liberal view / read policy you may otherwise retrieve a large part of your repository. If you then want to sort that - especially by privilege - it would be very expensive = slow.