Skip to content

Collapsible global navigation within in-browser editing experience #9131

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

Closed
loujaybee opened this issue Apr 5, 2022 · 6 comments
Closed
Labels
editor: code (browser) meta: stale This issue/PR is stale and will be closed soon team: IDE

Comments

@loujaybee
Copy link
Member

loujaybee commented Apr 5, 2022

Proposal: Introduce a branded, collapsible navigation bar to in-browser editing experiences within Gitpod (Figure 1)

Why?

  1. Fewer clicks to editing experience - Currently when selecting a desktop IDE, the user is met with a splash page (Figure 2) where they could alternatively be brought direct into the editing experience.
  2. Application and navigation context - We have observed that onboarding users entering Gitpod are sometimes not aware that there is a whole dashboard experience which exists within Gitpod when they are put into a workspace. Having a navigation bar within the browser would allow us to give a "back" button and breadcrumb type experience.
  3. Dashboard experiences closer to editing experience - Currently within Gitpod there is a disjoint between the behaviours that are accessible in the dashboard and also within a workspace. Having a shared navigation would mean that some functionalities that are exposed into the dashboard could be moved closer to the in-editing experience.
  4. Branding - As Gitpod wraps a lot of existing tools, such as VS Code, Docker etc. Adding this navigation bar would give us an opportunity to add additional Gitpod branding into the in-workspace experience, and implement Gitpod specific features such as feedback polls [1].

Objections

  1. Why not use the command palette? The command palette experience is not a familiar UX for non VS Code users, so some users don't know that it exists, or the keyboard shortcuts to open it. The command palette cannot easily be branded to be obvious Gitpod, with the exception of the current prefixing gitpod: , etc.
  2. Will this not damage the "immersive" nature of the editing experience? The navigation bar should be considered collapsible, to return full screen real estate to the user.
Figure 1 Figure 2
image image
@loujaybee loujaybee changed the title Add collapsible global nav to in-browser editing experience Collapsible global navigation within in-browser editing experience Apr 5, 2022
@gtsiolis
Copy link
Contributor

gtsiolis commented Apr 8, 2022

@loujaybee This issue caught my attention and wanted to add some thoughts on this feature request.

FWIW, GitLab has tried in the past to replace their Web IDE with Theia[1][2][3] and OpenVSCode Server[4][5], while keeping a global navigation on the top of the screen and making it collapsible. See also relevant discussion (internal). 🦊

Having a global navigation toolbar seems interesting but it could be best instead to improve our workspace start page, offer a command palette option, and make the command more visible from the existing VS Code user interface. These are also improvements we should probably make regardless if we attempt to introduce this global navigation. 💭

The reasoning:

  1. The product offers a web based editor for coding and more complex IDE functionalities. Since the available viewport is already limited by the browser window, adding more elements could significantly decrease vertical or also horizontal active space and degrade overall user experience. Of course, a collapsible option could help with the vertical active space but this could easily negatively affect overall user experience of the product.
  2. We previously had Theia[6] as the default editor which included a global navigation at the top, see relevant screenshot. Besides better UX that comes without this global navigation at the top, VS Code prioritizes and orders menu options better vertically than horizontally which is something to also keep in mind if we delve into trying this feature request.
  3. Offering a vanilla-like distribution of the VS Code[1] sounds much more appealing to developers. Introducing more options in the user interface sounds interesting but could easily become a negative side effect and push away power users. Cross-posting from our internal design principles: Less choices, more control[1][2][3] (internal).
  4. We already have a branded section on the existing VS Code interface on the bottom left corner.
  5. Now that we're introducing more editor options, the browser version of the VS Code seems to serve as the default or fallback option. This means that the toolbar will not be available in all other options but only in the browser version of VS Code which creates less value to users.

Counter-proposal:

  1. Introduce a command palette action with two steps that allow users to first select workpace restart using a different editor and then select the editor before restarting the workspace.
  2. Make the command palette visible a) in the application menu, b) when clicking the branded status bar host, and c) by potentially introducing a new top-level menu item in the actions container above the status bar host, see screenshots A and B.
  3. Improve more actions button on the workspace start page, see Improve more actions button on the workspace start page when opening in desktop IDEs #6910 and screenshot C.
  4. Allow users to change editor option on the fly while workspace is loading and remember their preference.
  5. Allow users to change the editor after the workspace is loaded and restart the workspace with the new editor, see screenshot D and relevant discussion point (internal) in a past all hands.
A B C D
Frame 3722 Frame 372 144521420-ea95b3ff-92d2-4cc0-aadf-035e2b47f12b (1) Frame 376

@jldec
Copy link
Contributor

jldec commented Apr 11, 2022

@loujaybee are you proposing to embed the IDE frame so that it only occupies a part of the browser window area owned by gitpod.io instead of taking up the entire window, and then using the extra screen real-estate on the top or the side for dashboard navigation or other things (workspace or team status?)

@akosyakov
Copy link
Member

akosyakov commented Apr 15, 2022

  • I don't think it is easy to implement technically, since IDE is owning top-window and assume layouting. Putting an IDE in iframe is not an option.
  • I'm also very skeptical about putting alient elements over IDE. I think instead initial onboarding should be improved to get a user to a proper IDE and within IDE native elements should be used to surface Gitpod functionality.

@stale
Copy link

stale bot commented Aug 12, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Aug 12, 2022
@loujaybee loujaybee removed the meta: stale This issue/PR is stale and will be closed soon label Sep 24, 2022
@loujaybee
Copy link
Member Author

A similar experience in Codespaces now.

image

@stale
Copy link

stale bot commented Dec 23, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@stale stale bot added the meta: stale This issue/PR is stale and will be closed soon label Dec 23, 2022
@stale stale bot closed this as completed Jan 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editor: code (browser) meta: stale This issue/PR is stale and will be closed soon team: IDE
Projects
None yet
Development

No branches or pull requests

4 participants