Project

General

Profile

Actions

Story #19465

closed

Review hover behavior of the nav buttons at the top of the collection / process panel

Added by Peter Amstutz 25 days ago. Updated 13 days ago.

Status:
Resolved
Priority:
Normal
Assigned To:
Category:
Workbench2
Target version:
Start date:
09/15/2022
Due date:
% Done:

100%

Estimated time:
(Total: 0.00 h)
Story points:
-

Description

The problem

The original implementation used a simple panel-toggling behavior when the user clicked every button.
This mechanism worked fine, except when all the panels didn't fit on the viewport and scrolling was needed:
  • Panels 1 to 5 were open, and panel 6 closed.
  • The user clicked on button 6, so panel six started to show but off-viewport, leaving a confused user about what happened.

The follow-up changes (and current behavior) made the buttons open and scroll to the selected panel when the user hovers over it with the mouse cursor. Button clicks are a no-op, so users attempting to use the old way of things would get an equivalent result.
The problem is that this is not what users expect of a "taskbar" widget, making the viewport move a lot without the user's intention. We attempted to mitigate this problem by adding a delay on the hovering handler so that the scroll happens only when the user left the mouse pointer for 150ms or more, but this wasn't enough, and adding more time means making the UI seem laggy.

The proposed solution

To bring the multi-panel-view widget to the expected behavior, I think the changes required aren't so difficult:
  • Panels 1 to 5 are open, and panel six is closed (and would be off-viewport if visible)
  • The user clicks on Button 6, panel six is opened, and the viewport scrolls to it.
To complete the expected behavior, we should see if every panel can publish its "visible" state so we can add the following:
  • Every button lights up when its corresponding panel is visible (or, to avoid multiple buttons lighted up simultaneously, only do it for the first visible panel). It would be the equivalent of highlighting the "windows in focus" in a desktop environment.
We can also add some visual aids:
  • Add a panel animation only when closing it with the [X] button (and not when panels close because of some other being maximized).
  • Add a similar animation when opening a closed panel. It would be necessary to scroll to where the panel will appear and only then show the opening animation, all of that in an amount of time that's not bothersome (i.e., <200ms?)

Subtasks 1 (0 open1 closed)

Task #19512: Review 19465-minimal-fixResolvedSarah Zaranek09/15/2022

Actions
Actions #1

Updated by Lucas Di Pentima 19 days ago

  • Description updated (diff)
Actions #2

Updated by Peter Amstutz 19 days ago

  • Category set to Workbench2
Actions #3

Updated by Peter Amstutz 18 days ago

  • Assigned To set to Lucas Di Pentima
Actions #4

Updated by Lucas Di Pentima 18 days ago

  • Status changed from New to In Progress

Updates at arvados-workbench2|30d0e55 - branch 19465-minimal-fix
Test run: developer-tests-workbench2: #876

This branch is implementing the minimum changes that produces the bigger impact in solving the presented problem:

  • Instead of scrolling to different panels by hovering over the button bar, the user needs to click on the selected panel's button.

There're also visual improvements on the button bar:

  • Removed the "eye" icon that used to indicate panels visibility status, to save horizontal space.
  • Changed the button coloring to indicate panels visibility status, showing a filled button for visible panels.
Actions #5

Updated by Lucas Di Pentima 17 days ago

  • Status changed from In Progress to Resolved
Actions

Also available in: Atom PDF