Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time List auto-centering is problematic and should be removed #7449

Closed
1 of 7 tasks
charlesh88 opened this issue Jan 31, 2024 · 3 comments · Fixed by #7474
Closed
1 of 7 tasks

Time List auto-centering is problematic and should be removed #7449

charlesh88 opened this issue Jan 31, 2024 · 3 comments · Fixed by #7474
Assignees
Labels
notable_change A change which should be noted in the changelog severity:blocker type:bug verified Tested or intentionally closed
Milestone

Comments

@charlesh88
Copy link
Contributor

charlesh88 commented Jan 31, 2024

This is closely tied to and may be a dupe of #7167.

Summary

Automatically scrolling to "auto-center" current Activities in the Time List view (per #7167) is still not fixed. The centering feature doesn't work as requested, and the view still "fights" manual scrolling: when trying to manually scroll the view, the auto-centering will attempt to wrest the control away from the user.

Examples of problematic auto-centering

Desired: Note current Activity at top in view:

Screenshot 2024-01-31 at 2 49 08 PM

Not desired: When auto-scrolled, top current Activity is now hidden:

Screenshot 2024-01-31 at 2 49 15 PM

Expected vs Current Behavior

Given the recently added ability to apply the independent Time Conductor to this view, which allows the user to have better control over what's in view, the need for auto-centering is much less or nonexistent. Additionally, users now need to be able to easily manually scroll and select Activities to set status on them.

Given the above, I strongly recommend we entirely remove the auto-centering functionality, keep the current sorting methods and relying on the Time Conductor to control what's in view at a given time.

Steps to Reproduce

  1. View the Time List with plan data that has past, current and future activities and events.
  2. For auto-centering: size the view such that the vertical scroll bar appears. You may have to try different sizes, with the scrollbar almost disappearing if all activities can be brought into view (see image above).
  3. For scroll control "fighting": size the view so that 50% of activities are hidden beneath the scroll, then manually scroll the view. Observe that it will be sporadically hard to scroll, or after scrolling and attempting to select an Activity, the desired activity will be automatically scrolled out of view.

Environment

  • Open MCT Version: 3.3.0-next
  • Deployment Type: /testathon
  • OS:
  • Browser:

Impact Check List

  • Data loss or misrepresented data?
  • Regression? Did this used to work or has it always been broken?
  • Is there a workaround available?
  • Does this impact a critical component?
  • Is this just a visual bug with no functional impact?
  • Does this block the execution of e2e tests?
  • Does this have an impact on Performance?
@akhenry
Copy link
Contributor

akhenry commented Feb 3, 2024

Recategorizing as blocker, it's potential loss of situational awareness.

@unlikelyzero unlikelyzero added this to the Target:4.0.0 milestone Feb 5, 2024
@unlikelyzero unlikelyzero added the notable_change A change which should be noted in the changelog label Feb 6, 2024
@ozyx
Copy link
Contributor

ozyx commented Feb 27, 2024

Verified-- Testathon 2/27/24

No more auto scrolling in non edit, edit, compact, and expanded modes

@ozyx ozyx added the verified Tested or intentionally closed label Mar 5, 2024
@rukmini-bose
Copy link
Contributor

Verified Testathon 3/5/2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
notable_change A change which should be noted in the changelog severity:blocker type:bug verified Tested or intentionally closed
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants