Phases

Note, the proof of concept part can probably be done concurrently with the ux investigation and design

• User eXperience investigation / gather requirements (pain points with current UI, workflows, etc)
• Design the UI screens, workflows, etc
• Proof of concept of accessible widgets and write framework code (custom tags, common javascript etc)
  • autocomplete
  • tree control
  • popup window
  • menu
  • layout (frame-like)
  • tooltips
• Development (iterative)
• Testing

Architecture

• In order to reuse work done in the existing Lite UI, the same architecture will be used: Javascript framework on top of jquery/dhtmlx.  There is no custom javascript per function, just server side java ajax which controls the screen via a Javascript layer
• The main screen design will be centered around a tree control on the left pane which will browse the repository, sort of like Windows Explorer or Eclipse or other similar software
• We could have two UI paths in the same UI application: one which is a rich application which might not be accessible, and one which is a very light application which will be accessible and mobile friendly.  The first page of the application should be a splash page which is accessible and mobile friendly where the user can set a preference about which UI they want associated with their account or which to use for this session.  Browser detection could help here too.  The accessible/mobile part could be purely based on Grouper WS-like operations...
• Favorites or recent activity could be associated with the user in the database (e.g. with membership attributes) so that it is easy for the user to setup tasks so they can quickly do their work the next time they use the Grouper UI

Guidelines

• Reduce number of screens required for actions
• Reduce number of clicks (e.g. feedback should be in a div which appears instead of a popup that requires an OK).  Note: the div should have a close button not auto-close
• Reduce the number of queries for actions
• Make sure most of the logic is in the API, not the UI code.  Would be nice if the gaps between what is used and the WS are noted
• Have the UI be usable by keyboard without requiring the mouse
  • Note, could use accesskey for buttons (probably need to add this to the UI framework)
• Do not keep stuff in session, just cache globally, and use request.  The only things in session would be things that can be cached for the user but figured out if needed.  e.g. authentication information.  The app should be able to be used in a load balanced environment with session clustering.  No unserializable stuff in session
  • Make sure app works in different tabs in same browser (it wills since no data in session)
• The tree control on the left of the UI prevents the URL from changing with clicks, however, we can put anchor URLs periodically as the user uses the app, so that bookmarks, back, forward, etc still work.  This is already somewhat in the UI framework, need to revisit
•  

Security

• All methods should be POST, though if GET is required, have a whitelist
• Prevent CSRF by having a key (SESSIONID?) which is transmitted with each request in a form variable (will this work for dhtmlx GET requests?).  Have a switch that turns this off

Ideas

• Overall search screen should allow search for all grouper objects
• Comboboxes should have filters (e.g. for which source)
• Comboboxes should show results with a <space> if there arent too many of them (maybe also if there is invalid text?)  See the action permission combobox
• Have recently used objects available
• Have a screen with each type of UI widget it in it for browser testing
• Hide dangerous operations (e.g. delete object) behind menus so they are less likely to be accidentally pressed
• Might need more custom tags to help display objects easier.  for instance a subject display custom tag...
• All searches should be case-insensitive (e.g. group searches, attribute searches, group searches in subject results), should search name, display name, and description, alias, etc
• Maybe if there arent too many options in dropdowns, it could be a select instead of combo
• Get query count for each operation and make sure it is minimal :)

Help framework

• Investigate using this: http://embedded-help.net/
• Perhaps could use some youtube movies too...

Community suggestions

I'm not sure how many Grouper installers also use JA-SIG CAS, but we do, and I know that it would be helpful for us if the new Grouper UI used the same technologies as that of CAS, namely Spring MVC and Spring Web-Flow.  This would decrease the skill-sets necessary to customize and maintain an identity solution that includes both CAS and Grouper.

It would also be very convenient if the HTML structure was designed so it could be themed using CSS (along the lines of csszengarden) and if the JSP pages used customizable header and footer “includes” built in from the start.

Universite de Montreal

We are also using the CAS authentication so we would like to keep that.

Internationalization (i18n) would be a nice to have. One language could be globally configured. Supporting multiple language would be better, but it's not a top priority. It could be detected from the browser (which is nice, but a default value would also work) but it has to be user-changeable using a drop-box or link of some kind since browser language might not be what the user prefers to see.

Display group relationships

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

Ideas on Gathering Community Input

Email the Grouper-Users List asking for input
Ask for input at the face-to-face Grouper WG at 2012 SMM
Reach out to specific campuses asking for input
Schedule a webinar to discuss UI planning with the community
Ask the UI experts at U-Chicago for their input on the UI and also on the process of involving the comity
Create a users group who to review the user interface as it is being developing