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

Request: UX enhancement for service tabs #43

Closed
rsyring opened this issue Feb 3, 2025 · 4 comments
Closed

Request: UX enhancement for service tabs #43

rsyring opened this issue Feb 3, 2025 · 4 comments

Comments

@rsyring
Copy link

rsyring commented Feb 3, 2025

Problem statement: when I'm trying to troubleshoot a failed service, I want to quickly move between the service's tabs and then scroll up/down through the tab's content. However, I currently have to tab into the tab's content to scroll and then back out to move between tabs.

Image

Referencing the above image, the current "focus" is the tab bar that contains Status, Journal, etc:

  • I can use the left & right arrow keys to move right and left between tabs.
  • Up/down arrow keys and page-up/page-down do nothing (as far as I can tell)

In order to scroll the journal (or anything else in the lower pane), I have to TAB to get from the Journal tab to the journal display area, then I can use arrow or page keys to scroll up & down.

I propose changing the functionality of the up/down/pg-up/pg-down arrow keys such that:

  • when used in the tab bar, they apply to the content pain of that tab
  • using them does NOT change the focus to the content pain (so that left/right arrow keys still change the tab)

This should facilitate a more fluid approach to quickly "scrolling" through tabs and their content as one tries to get their bearings on what the various panes are showing.

Copy link

welcome bot commented Feb 3, 2025

Thanks for opening your first issue here! 💖

@isd-project
Copy link
Owner

Hmmm. I see your point.
But I have removed a similar "feature" because I felt like it was adding an "unintuitive overload" if that makes any sense.
If you focus on the tab header, it isn't really obvious that you can move up and down but not left and right, as this would switch to the next tab.

However, while thinking about different solutions, maybe the most intuitive one would be to simply use Tab to tab through the tabs? So instead of overloading the "tab header", if you jump "into" the Journal tab, navigate the output with your normal left,right,up,down and if you want to "jump" to the next tab, you would press Tab again.

And then maybe there could be a strategy to quickly jump to the first/last tab header just so that the next tab moves the focus to the next element.

What do you think?

@rsyring
Copy link
Author

rsyring commented Feb 4, 2025

Hard to answer these questions without user studies but here are my guesses for what they are worth:

If you focus on the tab header, it isn't really obvious that you can move up and down but not left and right, as this would switch to the next tab.

At least in my case, the feature request comes from wanting to get my bearings quickly. So moving left/right between tabs and up/down with just the arrow keys accomplishes that goal. Not being able to scroll the content left/right without tabbing into the interface seems like an OK tradeoff to me.

However, while thinking about different solutions, maybe the most intuitive one would be to simply use Tab to tab through the tabs? So instead of overloading the "tab header", if you jump "into" the Journal tab, navigate the output with your normal left,right,up,down and if you want to "jump" to the next tab, you would press Tab again....

Tab is how you get from the tab group to the tab's content pane. That would also, presumably, require shift+tab to go back a tab. Workable but less intuitive than arrow keys IMO.

Some additional thoughts:

  • page up / down could scroll up/down a page regardless of what is done with arrow keys?
  • Use shift as a modifier for the arrow keys:
    • Option 1: up/down always scroll content, hold shift while using arrow keys to scroll content left/right. Has the benefit of being faster/easier for the more common operation (vertical scrolling) and only needing a modifier key for the less common (horizontal scrolling). Probably requires note at bottom: "shift+lt/rt to scroll"
    • Option 2: shift always required with arrow keys to scroll content. Has the benefit of symmetrical operation for vertical/horizontal scroll. Not as easily discoverable. Probably requires note at bottom: "shift+up/dn/lt/rt to scroll"

Neither of those notes discuss pg up/dn b/c I was trying to save space. If you go with option 1, the primary use cases are covered and the note is supplemental not primary IMO. Could add an option at the bottom "^u usage notes" or "^h help" or "^s shortcuts" and then bring up an info pain in the lower right like where the error messages show up, or maybe better in a centered modal like "systemctl actions", that explains usage including whatever scrolling options exist. The benefit being that if other usage options become available, there is already a way to note them and the shortcut key documentation in the footer doesn't become cluttered or restricting.

The above made me think of something. Outside of scrolling, is there a reason to have the focus shift from the tab into the content pane? If not, could remove that as a focus area. Then tabs only move between search, results, and tabs, which seems a bit cleaner to me and, if adding the usage notes, it's also easy to discover how to use the not-as-obvious features of the tab group and panes.

HTH.

@isd-project
Copy link
Owner

Hey, thank you for raising the issue. 👍
I have improved the UX for the service tabs.

From the commit:

Now the next/previous_preview_tab actions keep the focus within the
log preview output if the preview output was focused before triggering
the action. This avoids having to tab around to quickly move between
tabs and navigating the output.

If you check out the application from the main branch, the tab navigation actions (by default . and ,) now check if you are already focusing the preview output. If you do, it will auto-focus the new preview output. This means that you can navigate the output as you normally would (j,l or up,right etc) press . and continue navigating the output with j,l or up,right etc.

So moving left/right between tabs and up/down with just the arrow keys accomplishes that goal.

This issue is resolved now.

Not being able to scroll the content left/right without tabbing into the interface seems like an OK tradeoff to me.

Not for me ;)

The other points are similar to those mentioned in #50. I prefer to enforce an additional tab press to focus the preview output and separate the tab header with the preview output from one another, enforcing more "explicit" navigation, hoping that it is more intuitive.

info pain in the lower right like where the error messages show up

There already exists such a page. You can open the command prompt ^p and then search for help.
I know that it is "hidden" but I might make larger changes to it. After I am happy with those changes, I would add it to the footer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants