Add keyboard shortcuts for navigating lists (issues, files, MRs, etc.)

Description

Currently it is not possible to navigate lists (e.g. files list or issues list) with keyboard.

Proposal

1. Identify situations where lists could be navigated by keyboard (e.g. files list, issues list, MR list etc.). This can of course be done incrementally, though the initial design robustness might benefit from considering more than one situation.
2. Add keyboard shortcuts "j" and "k" for moving selection down and up the list, respectively
3. Add keyboard shortcuts "o" or "enter" to open the selected item

Note: in file browser, going a level up is achieved by selecting the ".." item and opening it.

This is how it behaves on GitHub. Also it behaves this way on GMail (list of emails) and Google Groups (list of topits).

Links / references

feature proposal

@dimitrieh What do you think from a UX perspective?

Added feature proposal label

I think this is a great functionality we should add for power users.

And would be pretty easy to add to our lists in the same way as it is done in "Inbox" by google.

They operate btw with left arrow right arrow and enter escape which sound a bit more logical to me.

Btw note that if the row is clicked focussed it also has the left border color

In gitlab that could look like this for example:

@awhildy what do you think?

slightly related perhaps: https://gitlab.com/gitlab-org/gitlab-ce/issues/21958

I was also talking about keyboard shortcuts here: https://gitlab.com/gitlab-org/gitlab-ce/issues/22069#note_15207136

Good thoughts! Both Gmail and Inbox actually have both arrow keys and j and k. I assume j and k are because of how programs like Vim navigate lines, etc. Which would definitely be familiar to a lot of our users.

Looking at the current keyboard shortcut list for GitLab (using Shift+?), it seems like our File list is a lot more navigable by shortcuts than our issue list. I'd propose:

Step 1: Make all our table views consistent with keyboard shortcuts (basing on how things currently work with the Files page)

• Up/Down arrows to navigate, enter to open
• Should determine what table views this needs to be added to (Issues, MRs, etc.?)

Step 2: Add common alternatives to existing shortcuts.

• Add j/k, and o

Up/Down arrows to navigate

These are already assigned by the browser to scrolling the page.

Up/Down arrows to navigate

These are already assigned by the browser to scrolling the page.

Maybe that is not that big problem if the page would consist only of the table (e.g. a file list without a readme content displayed below it), as (since) moving the selection to a row of table below lower edge of viewport would (should) lead to scrolling.

Added frontend label

Agreed @dusek! If you play around with the arrow keys here: https://gitlab.com/gitlab-org/gitlab-ce/tree/master, I think it works out. The selected row is actually kept in a consistent place on the screen, so it is easy to scroll the page. Thanks!

The selected row is actually kept in a consistent place on the screen

I think that is inconsistent with how selection works in native UIs. I think there scrolling happens really only when the selection gets near the top/bottom of the screen. (At least on macOS it does, I think other platforms too, but frankly not sure as I don't use them).

I noticed GitHub at least behaves like what I described, scrolling by one row when top/bottom edge is reached. GMail too, just instead of scrolling by one row when hitting the bottom of viewport, it scrolls about half the table. I found both these behaviors on macOS: Mail.app messages list scrolls by half screen, Finder.app in column mode by one row.

Yep, I agree what you describe is the more common behavior. I'm not sure why it was decided the way it was for the files page. The one thing I could think of was that it meant you didn't have to move the selected row highlight all of the way to the bottom to start scrolling the page, and seeing more content. But not sure if that was the rationale.

Unless I can track down the original opinions that lead to that design, I'm happy to make the switch to the more consistent model. This issue probably needs a few more UX details worked out (what pages will be impacted, a list of exactly what commands to support), and then we can get this work scheduled. Thanks!

Added ~19492 label

Milestone changed to %Backlog

Mentioned in issue #24479 (closed)

Added shortcuts label

Mentioned in issue #24821 (moved)

mentioned in issue #27652 (moved)

mentioned in issue #32311 (moved)

mentioned in issue #32310 (moved)

mentioned in issue #32309 (moved)

This would be extremely useful for our team. Being able to quickly move from one issue to the next with a button and keyboard shortcut is the only thing I miss from Jira. I can't believe I'm even saying that...

Will wait for @victorwu to schedule. Or @mydigitalself

removed frontend label

added Discussion Platform frontend labels

@mydigitalself can you leave the FE label off of issues I removed us from for now, until it is scheduled. That way our backlog isn't completely filled with stuff we will never do or won't do for a long time. We had 152 things in our backlog and that's just a pile of stuff vs the stuff I have in there right now (42) is actually a useful list of things we intend to do shortly. If it's important we'll know it's FE as that's a pretty easy thing to label.

removed frontend label

moved to gitlab#6654

Hey! 👋

GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current gitlab-ce repository will become a read-only mirror, without any proprietary code. All development is moved to the current gitlab-ee repository, which we will rename to just gitlab in the coming weeks. As part of this migration, issues will be moved to the current gitlab-ee project.

If you have any questions about all of this, please ask them in our dedicated FAQ issue.

https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

You can also find more information here:

• https://gitlab.com/gitlab-org/gitlab-ee/issues/13304
• https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/

Frequently Asked Questions

For an up to date list of questions and answers, please take a look at https://gitlab.com/gitlab-org/gitlab-ee/issues/13855

What will we do with the repository names?

https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.

Why rename gitlab-ce to gitlab-foss?

Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear

I created a merge requests for CE, and this got closed. What do I need to do?

You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.

How does the licensing work in this new setup?

Everything in the ee/ directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in the ee/ directory, the process of contributing changes is the same as when using the gitlab-ce repository.

Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?

No. Merge requests submitted to this project will be closed automatically.

Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?

Yes.

How will this affect users of GitLab CE using Omnibus?

No changes will be necessary, as the packages built remain the same.

How will this affect users of GitLab CE that build from source?

Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.

Where can I see a timeline of the remaining steps?

https://gitlab.com/gitlab-org/gitlab-ee/issues/13304

Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?

Yes, these changes will be synced to gitlab-foss automatically, several times per day.

locked this issue