UI Analysis

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 nav.properties. 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 nav.properties

• 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 media.properties, or you can define a JSP template (dynamic tile) which allows you to display multiple attributes formatted as you choose

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.