CCWG-1: UI/UX improvements

Goals

Short Description

There have been some expressed interest in variations in the UI/UX of COmanage. In some cases, it has been to simplify the interface to expose only a limited subset of the available functionality. In other cases, it has been to enable greater flexibility in the display and/or integration of COmanage in the context of other applications. In at least one instance, this desire has led to the forking of the COmanage code, effectively bifurcating the application, at least for the near term. 

This proposal has the following goals:

1. Clearly define and agree to the UI/UX needs of users and integration partners
2. Outlines a way forward to provide for these needs
3. Determine a model that will eliminate bifurcation so that the application can benefit from all developing on the codebase.

Need 1: Simplified User Interface

Earlier in 2019, the SURF team designed a simplified user interface to address their user’s needs in a  Collaborative Management System. At the TIIME meeting, the team described their ideal scenario: the ability to use the strengths of COmanage and cooperate in an international shared solution, while having a “simple, pleasant, flexible UX” for their CO admins in their -aaS offering. The team was facing a short deadline; their 12 pilot partners (of a SURF implementation of a AARC BPA-based solution using COmanage as MMS) indicated that they want to go to production ASAP, and would rather not have to wait for full service development. Due to the comments over the COmanage UX, the team designed and tested a new UX, and had some discussions whether it would be possible to change the COmanage UX in line with the designs. The team needed to move forward, so they are using their branched version of COmanage with their customized UX for now (and in the beginning of 2019 have build a light weight alternative MMS, SBS). Most pilot partners have expressed wanting to switch over to SBS, even though the SURF team is still optimizing the SBS UI/UX.

COmanage Light UI: https://wiki.surfnet.nl/display/SCZ/Collaboration+Management+System+%28Dutch%3A+SamenwerkingBeheerSysteem%29+-+SBS

Presentation: https://indico.cern.ch/event/775478/contributions/3268911/attachments/1793787/2923188/SCZ_SBS_for_FIM4R_TIIME2019.pdf

TIIME session discussion: https://tiimeworkshop.eu/proceedings/2019/sessions/session11/

Need 2: Custom User Interface

In several cases requests have been made to have greater control over the user interface for COmanage. At times these requests are for specific changes, and other times it is for an underlying change to the COmanage architecture to enable an API to COmanage functionality so a full custom UI/UX can be built on top of it. In some cases, these capabilities are possible under version 2.0 of the COmanage API.

Open questions

• What are the capabilities (user stories, not system architecture or solution) needed in an MVP to enable UI/UX flexibility needed by partners?
• What are the needs of the development team when addressing these capabilities (from a system architecture or solution point of view)?
• What are the timeframes for each of the parties? How does this reality affect the way forward?
• What are the fundamental differences of opinion? How can they be resolved?
• Given the answers to the first four bullet points, what are the key milestones for moving this effort forward?

Need 3: Ability to Act as a UI for Users to See and Manage Their Grouper Groups (Internet2)

Requirements for accessing Grouper groups would add the ability to:

1. Provide a single UI for non-administrative users to manage their own collaborations without the need to also learn the Grouper UI.
2. Tailor what a user can see and do in the UI based on the Grouper groups the user is affiliated with.  (This is similar to the existing Dashboard functionality provided in COmanage using COmanage internal groups but required for implementations where COmanage is employed to enroll and manage identities as a lightweight registry only (no authorizations using COUs or groups outside of internal COmanage administration) and Grouper is the authoritative source for identifying roles and driving authorizations.)
3. Enable any user to see the groups they are affiliated with and the nature of those affiliations (ie. Owner, Admin, etc)
4. Enable authorized users to manage groups where they are Owner or Admin including adding/deleting other users.
5. Provide enough context for users to understand what visible and manageable groups provide authorization for such as Confluence wiki spaces, Jira projects, AWS instances, etc.  

Additional Commentary

There appear to be a few categories of "UI/UX" epics:

1. Application Initiated Enrollment: The owner of an application integrated into a COmanage environment does not wish for its users to to leave the application during a signup process. This is probably more related to CCWG-8 (API based integration).
2. Legacy UI: An environment has an existing front end, and does not wish to retrain its users. It's not clear that the COmanage Project can generally solve this problem, other than via an API based approach (again, CCWG-8).
3. "It's Too Complicated": Certain classes of users find it difficult to accomplish certain tasks because of the way the current Registry interface is presented. There are two (not necessarily incompatible) approaches here:
   1. Continuous Refinement: Identify specific user stories and create RFEs to address them more or less independently. The RFEs identified as part of the evaluation of the SURF mockups are a good start in this direction.
   2. Lite UI: Design and implement, either as a standalone component or a setting on the current interface, a "Lite UI" with a simplified look and feel. The challenge here will be identifying broadly universal requirements that can be generally useful, and not just solve for a specific deployment's use cases (or worse, several deployments' worth of non-overlapping use cases).

Community Impact

The biggest community impact is related to the potential long-term bifurcation of the COmanage code base and community which would reduce resources for the forked versions, and potentially can lead to confusion by end users. The COmanage User Community Working Group recognizes the desire for a strong, community-capable COmanage application, so resolution of this topic is important.

Urgency

While the proposed solution may be less urgent, developing a way forward is very urgent. The code is already bifurcated by the release of a separate product based on the COmanage base code, but different in important ways that makes the merging of this code into the original codebase difficult.