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

Add keyboard shortcuts to navigate paginated lists #296

Open
cellio opened this issue Nov 17, 2020 · 3 comments
Open

Add keyboard shortcuts to navigate paginated lists #296

cellio opened this issue Nov 17, 2020 · 3 comments
Labels
area: frontend Changes to front-end code complexity: average Not particularly hard, not particularly trivial. priority: low type: change request New feature or request

Comments

@cellio
Copy link
Member

cellio commented Nov 17, 2020

https://meta.codidact.com/questions/279114

It would be nice if on pages with several subpages (like the posts page, with the previous/next and page number bar on bottom), there would be a shortcut to go to the previous/next page in the list.

I suggest the keys h and l for this (as they are what vi uses, and the j/k seems to also mimic vi, although their function is reversed). That is, pressing h would be equivalent to choosing the “previous” button, and pressing l would be equivalent to choosing the “next” button.

As a bonus, there could also be shortcuts for the individual pages. The obvious shortcut g p is already taken, but maybe g n for “goto page number”, so that g n 1 goes to page 1 etc.

Alternatively, the shortcuts could be relative. For example, g h 5 would go 5 pages back, and g l 3 would go 3 pages forward. g h 1 would be equivalent to h, g l 1 equivalent to l.

Since going back/forward zero pages makes no sense, the shortcut g h 0 could go to the very first page, and g l 0 to the very last page.

@cellio cellio added area: frontend Changes to front-end code type: change request New feature or request priority: low complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Nov 17, 2020
@Taeir Taeir added complexity: average Not particularly hard, not particularly trivial. and removed complexity: unassessed Needs further developer investigation before complexity/feasibility can be determined. labels Jul 21, 2023
@Taeir
Copy link
Contributor

Taeir commented Jul 21, 2023

Good to think about the impact on users that aren't expecting anything to happen when they press keys on their keyboard. Should this be a toggleable feature?

@cellio
Copy link
Member Author

cellio commented Jul 21, 2023

Good to think about the impact on users that aren't expecting anything to happen when they press keys on their keyboard. Should this be a toggleable feature?

If we do this only if the Keyboard Tools user preference is set, does that address the concern? Or do you think users might still be surprised by the expanded scope?

@Taeir
Copy link
Contributor

Taeir commented Jul 21, 2023

I think users won't know of the feature if it is not on by default. In general it is probably not an issue, but I've had some problems on e.g. gitlab, where I was just typing something and then it's actidentally not focussed on the textbox I was typing into but rather on the page, and then it just jumps to a random page (i => new issue, etc.).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: frontend Changes to front-end code complexity: average Not particularly hard, not particularly trivial. priority: low type: change request New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants