Initial onboarding experience for user accessing Tendrl UI

[julienlim]

We’ve put together 2 design proposals with varying navigation that focuses on the UI and user experience for what happens after the user has run tendrl-ansible and logs into the Tendrl UI. Both designs are focused solely on Monitoring for Gluster (though the design concepts conveyed will translate well for other storage subsystems, e.g. Ceph).

Key highlights of the designs include the following:

• addresses handling errors/failures related to misconfigured tendrl-ansible failed Import Cluster (dialog with messages and host list)
• Import cluster
• enabling / disable volume profiling during Import Cluster (cluster-wide) and at the volume level
• indicate where the “Launch Dashboard” (link-n-launch to Grafana) buttons would be located
• provide an element manager (single-cluster) focused navigation via 2 different design proposals, which includes updates to the navigation:
  • Concept A: Multi-Level Drill Down (re-uses existing design elements and implementation)
  • Concept B: Context Selector Navigation (optimizes the navigation and emphasizes the single cluster management/monitoring experience)
• Removed all CRUD actions (buttons)
• updated rebalance column in the Volumes list to be more monitoring focused (without the CRUD controls)
• added SNMPv3 configuration

The current assumptions for the Dashboards is that they would reside in a separate UI (Grafana) and would include the following:

• Cluster
• Host
• Volume

These dashboards would be launchable from the Tendrl UI without user having to specify URL and login credentials.

The reason for 2 design proposals (they differ based on navigation) is one design attempts to re-use as many of the existing design and implementation assets (Concept A: Multi-Level Drill Down) but has some drawbacks. The alternate design (Concept B: Context Selector Navigation) addresses the drawbacks encountered with Concept A.

Links to the Designs:

• Concept A: Multi-Level Drill Down: https://redhat.invisionapp.com/share/2RCOE72PE
• Concept B: Context Switcher Navigation: https://redhat.invisionapp.com/share/8QCOEVEY9

The following highlights the main differences between Concept A and Concept B designs:

Concept A: Multi-Level Drill Down

• Leverages the existing primary navigation and object detail designs
• Requires a two-level drill down to examine details of objects within a cluster, e.g. to see volume->brick-disk relationship information.
• Top-level objects being managed in the cluster is only accessible via drill down in the right pane.
• Leverages existing object details design and implementation
• Navigational bar has a static menu of global elements (e.g. Alerts, User management, SMTP and SNMP configuration), which may not be the right set of elements (menu items) we want to emphasize since they are not the core competency of managing a storage subsystem.
• It’s not easy to access cluster top-level objects (e.g. Hosts, Volumes, etc.) without doing a drill-down, thus, it’s not obvious to user where they to find volume information at a quick glance.
• To switch to another cluster (from a drill down), user has to go to the Clusters (menu item or breadcrumb) in order to choose a different cluster (2 steps).
• (FUTURE) When the cluster dashboard is embedded, it remains as a tab in a drill-down.

Concept B: Context Selector Navigation

• This concept proposes using a Context Selector menu in the masthead (top banner area).
• The left hand navigation bar is shown only in the context of a single cluster and allows the user to examine detailed information related to that cluster.
• Top-level objects being managed in the cluster is easily accessible in the navigation bar.
• The navigation bar is shown only when a cluster is selected (in the Context Selector). No navigational bar is shown when all clusters are selected.
• Global elements (e.g. Alerts, User management, SMTP and SNMP configuration) are accessible from the top right common utilities area.
• To switch to another cluster, user just has to go to the Context Selector to switch to a different cluster (1 step).
• (FUTURE) When the cluster dashboard is embedded, it should appear as another menu item in the Navigation bar.

Any additional designs not shown in this workflow (e.g. Rebalance) may be found at the Tendrl UI Designs Index.

[julienlim]

Related PR/Issues that I was able to track down:

• SMTP config in UI: https://github.com/Tendrl/specifications/issues/184
• Streamlined import cluster flow in the ui: https://github.com/Tendrl/specifications/issues/183
• Remove cluster specific objects from the main navigation bar: https://github.com/Tendrl/specifications/issues/182
• updated cluster list view: https://github.com/Tendrl/specifications/issues/181
• dashboard user management: https://github.com/Tendrl/specifications/issues/176

[julienlim]

@Tendrl/tendrl-core @sankarshanmukhopadhyay @japplewhite @Tendrl/qe @Tendrl/tendrl_frontend @anivargi @anmolbabu @nnDarshan @rghatvis@redhat.com @mcarrano

Please review this PR/issue above which lists 2 design proposals that cover the onboarding experience in the Tendrl UI and the rationale along with pros and cons for 2 design proposals. In addition, it includes additional design coverage for suggested features, e.g. enabling/disabling volume profile, dealing with tendrl-ansible misconfiguration or import failures (or any kind of failure modes while the cluster is unmanaged), SNMP configuration, etc.

Comments can be made in either Invision and/or in this PR/issue.

@r0h4n I've noted above the related PR/issues and I'm probably missing some more (since I couldn't find them), but hopefully, you are someone else can associate this PR/issue to the appropriate specs/PRs/Issues. Thank you.

[gnehapk]

Suggested changes to the designs

Context

• Use patternfly recommendations and defaults unless they specifically don’t cater to a particular problem.
• Avoid forcing the user to navigate to a new page to view read-only information, as much as possible.
• Have a consistent global navigation structure.
• Use a consistent language to provide an intuitive navigation experience.

Navigation (Primary, Secondary)

Proposed Design

Explanation

• Primary navigation should be consistent in all the pages.
• Dropdown In front of top navigation doesn’t go well with branding.
• The top and side navigation bars need to be coloured the same to indicate that they’re both in the same context. The rest of the page has content that changes based on the actions taken from the navigation, so has a different background colour.
• Secondary Navigation:
  • We can create context based menus.
  • Rely on patternfly’s implementation of secondary navigation.

Cluster List

Proposed Design

Explanation

• Patternfly recommends and implements expanded list views. This’ll allow us to reuse the default patternfly component for list views.
• Expanded list views allow the user to view important information about multiple clusters on the same page, without having to navigate away.
• Scaling would not be a problem on the cluster list page since it’s not expected to have to display number of clusters in 10s.
• In cases where a large number of objects need to be listed (volume lists eg.), either expanded views would not be required or the listing will be paginated. This’ll automatically reduce the number of items in the list view to be performant, even with expanded list views.
• Buttons automatically are seen as actionable. Having both hyperlinks and buttons is confusing. Throughout the designs, a consistent experience can be provided by having only the buttons as a navigation aide. Clicking on a clickable list view item only ever results in an expanded view and not navigation.
• Action buttons will have a pop-up for actions (not workflows), eg. import cluster.

Import Flow

Explanation

• All Nodes will always participate in the import cluster flow so the node selection feature should is not applicable.
• The Import flow should happen in a pop-up rather than shifting to a new page because it will reduce the number of steps required to perform import action and would not force the user to navigate away from the current view.

[brainfunked]

For now, it would probably make sense to go with just the secondary navigation linking directly to the different clusters to allow switching between them.

[julienlim]

@brainfunked - Do you mean Concept B. Please confirm. Thanks.

[brainfunked]

@julienlim No, I meant on the mockups provided by @gnehapk.

[brainfunked]

A discussion was had on a call regarding the designs proposed by @gnehapk. All the designs were discussed. There are pros and cons for all of the approaches.

The deciding factor, however, is that the with the redesigns from @gnehapk, it is easier to use off-the-shelf patternfly implementation without needing custom components to be implemented by tendrl. As such, for the short term, the designs provided by @gnehapk would be implemented. This has been agreed upon by @Tendrl/tendrl-core.

[brainfunked]

Given that the new UI would be covering only a subset of the fully tendrl functionality in the initial releases, it would be good to keep this issue open and evolving till a more concrete long term vision has been established. This would impact any UI implementation, as it must align with the long term vision of the project.

@r0h4n @nthomas-redhat thoughts?

[cloudbehl]

@julienlim As per the discussions in the Architecture call, you were talking about the context switcher availability in patternfly. So can you please point me to the document or the link which I can refer.

[julienlim]

@Tendrl/tendrl-core @sankarshanmukhopadhyay @japplewhite @Tendrl/qe @Tendrl/tendrl_frontend @anivargi @anmolbabu @nnDarshan @rghatvis@redhat.com @mcarrano

Thanks @gnehapk for sharing your design ideas and for trying to leverage PatternFly patterns as much as possible. It’s great to have an exchange of ideas and I’m glad to see folks sharing their thoughts.

Regarding @gnehapk’s proposed design by @gnehapk, I wanted to share some concerns and questions I have with regards to usability, potential user confusion, and inconsistencies. Below, I’ve attempted to address each of the areas of interest:

• Navigation - primary and secondary
  • Having a dropdown (context switcher) after product branding is an existing PatternFly pattern. See The application launcher is here: http://www.patternfly.org/angular-patternfly/#/api/patternfly.navigation.component:pfApplicationLauncher. Another similar pattern is the language selector at http://www.patternfly.org/pattern-library/forms-and-controls/language-selector/#/overview.
  • In @gnehapk’s proposal, there are some inherent usability concerns in that emphasis is put on primary navigation for non-core competency elements of the product, i.e. Clusters, Users, Mail Settings, and SNMP Settings - which are not common day-to-day or infrequently performed tasks. Day-to-day storage management is focused on managing the storage entities (e.g. volumes, bricks, etc.), creating or growing storage (e.g. volumes, bricks), troubleshooting issues, etc. This is the reason why in Concept B, we've moved these items to the Masthead area -- Clusters and cluster selection is in the masthead, and Alerts and Admin (Users, Mail, SNMP) in the global utilities are accessible when needed but not always in plain sight as we don't want to distract from the important day-to-day tasks that a Storage Administrator will want to perform.
  • The proposed 2nd nav comprises of a mixture of both showing the context (clusterN) and its top level objects (of clusterN) at the same time. In an emphasized single cluster scenario (element manager), you want the emphasis of the navigation to be on what you’re trying to manage (e.g. top-level objects or tasks), e.g. Hosts, Volumes, etc.
  • With this proposal and using buttons to see Cluster Details, you will end up in a multi-level drilldowns that exceed 3 levels (e.g. when you do a Volume -> disk drill down (or drill-up from bricks to see who/what is impacted when you replace a brick) which will be confusing to the user, and also increase the likelihood of a user getting lost in the navigation. We tried leveraging as much of the existing design/implementation, and that’s why we came up with Concept A (Multi-Level Drill Down), and as listed above and in the design, the drill down (and other limitations) were why we came up with the alternate Concept B (context-selector navigation design).
  • Furthermore, the 2nd nav is showing a dynamic list of the clusters detected and being managed. This list of clusters in the 2nd nav that can change placement (if new clusters get added/removed/renamed) - which is not predictable, i.e. the 2nd navigation can and will change when clusters get added/removed leading to undesired behavior as users who have learnt that clusterN is at the top may now be in the middle (after some change). In a multi-user scenario, if another user makes such a change, it will unexpectedly “surprise” other users of the application.
  • Currently, we have an object-based navigation model with task-based workflows. Adding this 2nd nav the way its proposes also mixes metaphors of putting the cluster list and top-level objects in the 2nd nav which is at odds with the primary (object-based) navigation of what users expect as it’s not consistent — doing this in Tendrl will mean being not only inconsistent with PatternFly but also inconsistent with the rest of the other community projects we're trying to be aligned with, e.g. ManageIQ, oVirt, OpenShift, Cockpit, etc.
• List expansion to see error message
  • How does the user know that expansion of the cluster list item (row) shows the error messages vs. showing cluster details? If expansion is to be done on the error message, the expansion indicator needs to be on the message and not the front of the row (which usually indicates to expand to see cluster details).
  • If there are no errors to be shown, what will the cluster list item (row) expansion show?
  • If Dashboard links-n-launches a separate dashboard (in another UI tab/window), does clicking on the Cluster Details show the cluster details in a UI tab/window/dialog) or is in place in a new page?
    • Note: The behavior of how you get to the cluster details will need to be consistent from every place where it’s triggered — whether it’s a list view or an Alerts / Events view.
  • In general, we like the idea of list view expansion as long as the content in the expansion is not too long as it will have its own set of usability (scaling) issues in terms of scrolling or pagination when the expansion content is too long.
    • The reason we moved away from doing list view expansions in our designs is for expansions that have a lot of content and/or actions to be performed, e.g. cluster details, seeing rebalance status, performing CRUD actions, etc.
    • Having the error message only as an expansion and all the other views are triggered as pages (or windows/dialogs), e.g. Dashboard, Cluster Details, etc. is somewhat inconsistent.
  • With regards to having both hyperlinks and buttons being confusing, @gnehapk’s proposal has 2 buttons — Cluster Details and Dashboard. The Dashboard button is temporary as that will need to be part of the menu option when we embed the Dashboard. As to Cluster Details, whether that’s hyperlinked or not, with a button as long as we have consistent behavior that’s fine. Note: This will require more buttons placed throughout other views, e.g. Alerts, where let’s say brickN in hostN that is consumed by VolumeN in ClusterN is impacted. We would need to now show 3 buttons to say Volume Details, Host Details, ClusterN in addition to showing Alert details vs. cleanly providing hyperlinks for the impacted objects and showing the Alert details. Having too many buttons may provide for more visual clutter and then having to make this scale and work in the Notifications Drawer (Alerts) will be that much more difficult.
• Alerts / Notifications — we propose that it be part of the Notification Drawer (comes down from the global utilities in the top right) as it’s accessible at any time vs. if you’re looking at cluster details, you’ll have to leave your context (e.g. looking at some cluster or if you’re in the middle of viewing a dashboard or volume to disk details) in order to see the Alerts. This allows the user to continue to keep context and working on whatever he/she is working on, and can quickly glance into an Alert (in the Notification/Alert drawer) and view/dismiss the Alert as needed) without leaving his/her context and then having to figure out how to navigate back to the context after looking at the Alerts.
• Import cluster
  • +1 that node selection is not needed if all nodes participating in the cluster is shown (and that no other nodes from other clusters would be shown).
  • Whether it’s a pop-up or page is the same number of steps as they both take you to a screen (page/pop-up) that ask for confirmation to import. Once confirmed, it still takes you back to the Cluster List. Whether or not to use pages / dialogs / expansions should be as consistent as possible, so that user can know and expect what the behavior is each and every time.
• RBAC — whether it’s Concept A or Concept B design that we propose, this isn’t an issue as fundamentally all users will see the monitoring information. What changes is what CRUD operations a user is permitted to perform, i.e. if a user has the appropriate privileges, the actions/tasks (buttons) permitting CRUD operations will be visible. If user has only read-only permissions, then he/she would not see those actions/tasks (buttons). This is true in all the designs to-date and does not change.

As previously mentioned, we’ve gone through reviewing all the use cases and necessary drill downs to support monitoring and CRUD operations and still strongly recommend Concept B (Context Selector Navigation) to address the above shortcomings and ensuring that the user has as optimal an experience when managing a cluster or being able to easily switch to another cluster to manage.

[dgutride]

@brainfunked - the example component in angular-patternfly is here: www.patternfly.org/angular-patternfly/#/api/patternfly.navigation.component:pfApplicationLauncher . Oftentimes, though, we'll just default to the bootstrap dropdown and use patternfly styling to match a specific design.

[gnehapk]

@julienlim @brainfunked @nthomas-redhat Where the menu for "Tasks" will reside in the navigation?

[julienlim]

Related Specs:

• https://github.com/Tendrl/specifications/blob/master/specs/global_navigation.adoc

@gnehapk If we're keeping Tasks, then they will appear alongside Events (present in the single cluster context), i.e Hosts, Volumes, Bricks, Configuration, Events, Tasks.

Is there a strong reason we're showing Tasks if the only "active" tasks a user can perform is import cluster and enable/disable volume profiling, and that it's a nice way to track all tasks that have occurred on the cluster via the Tendrl UI?

@brainfunked @nthomas-redhat @japplewhite @Tendrl/qe

[julienlim]

Another component that was suggested by @dgutride was using http://www.patternfly.org/pattern-library/widgets/#bootstrap-select.

[r0h4n]

Closing this one, please open new issue with relevant context