Epic: Improve the experience of opening desktop IDE/editors

[loujaybee]

Context

As Gitpod moves to a situation where we have more desktop IDE's integrated like JetBrains and VSCode Desktop, we need to start to think about how we get desktop support into Gitpod as more of a first-class citizen rather than as a bolt-on which is accessed only via the browser experience (e.g command palette or selected on workspace start-up).

For VSCode, the user currently has to go to the browser, start a workspace and then use the command pallette to open VSCode desktop. For JetBrains, the user has to update their preferences, then restart a workspace.

Currently, we're prioritizing the browser-based flow, however, with more desktop support, we might want to revisit this decision, and make some changes to Gitpod where necessary to prioritize desktop IDE support.

This issue also affects:

• Onboarding Flows - As the current onboarding drops a user directly into a VSCode environment, and we have observed some difficulties when presenting this UX to a user that doesn't have VSCode experience (via usability testing).
• Marketing - As currently the Gitpod product is often perceived as browser-only product

An additional open question that we have to address is also whether:

1. Users want to open all workspaces using the same desktop IDE every time
2. Users want to configure IDE's on a per-project basis
3. Users want the choice of IDE on a per-project basis

Current Situation

Choosing Desktop JetBrains

If a user wants to use their desktop IDE, and not the web as default, they have to:

1. open the workspace in a browser
2. click through to open their local IDE.

Challenges with this flow:

• Forces the user to start from the browser (cannot start from desktop)
• Is a different flow to VS Code
• Not always transparent that a workspace restart is required to load another IDE (not the case for VSCode Desktop)
• User cannot initiate this flow from the dashboard (e.g. must wait for workspace to load first, i.e 2 clicks)
• There is no way to set a true "default" i.e "open in this IDE every time"
• It's not fully transparent to the user that browser + desktop can be used simultaneously

Choosing Desktop VSCode

Currently, the user has to open a workspace, then use the command pallette to open up their local VSCode, it would be better if we have a flow that allows the user to default to using VSCode desktop or some simpler, lower friction method of doing this.

Challenges with this flow:

• Forces the user to start from the browser (cannot start from desktop)
• Is a different flow to JetBrains
• A workspace restart is not required for this flow (unlike JetBrains)
• User cannot initiate this flow from the dashboard (e.g. must wait for workspace to load first, i.e 2 clicks)
• There is no way to set a true "default" i.e "open in this IDE every time"
• It's not fully transparent to the user that browser + desktop can be used simultaneously

Potential Solutions

We should investigate if this workflow could be simplified and remove the additional step so that an IDE can be opened directly from the dashboard, or from the local companion app.

CC: @svenefftinge, @jldec, @gtsiolis, @akosyakov

[corneliusludmann]

• If a user wants to use their desktop IDE, and not the web as default, they have to open the workspace in a browser and click through to open their local IDE, we should investigate if this workflow could be simplified and remove the additional step, so that an IDE can be opened directly from the dashboard, or from the local companion app.

As far as I know, the extra step is only necessary for the “Code with me” integration. Once we have a more direct way of opening JetBrains we will open the IDE directly. E.g. for the VS Code integration, we have a vscode://... link that opens the desktop IDE.

Nevertheless, opening an additional browser tab to follow the progress is still useful, IMHO. This page also shows errors when the workspace start fails. But that is certainly a matter of taste. I think it would also be useful to add a “Stop workspace” button there.

• The user is presented with browser AND desktop IDE preferences, but doing so means that the user is not strictly picking a default, but two defaults, which means that we still need to prompt the user on workspace start for which preference they would prefer.

Please correct me when I'm wrong but the reason that we have a browser and desktop IDE option is that there was the decision (before I joined the team) that we want to have a fallback when the connection from the desktop IDE to the workspace fails. In that case, the user should still have a path to access the files in the workspace without the need to stop and restart the workspace. That's why we went the extra mile and implemented the ability for a workspace to contain 2 IDE images: the browser and the desktop IDE image. If we don't need this fallback option at all, but only ever start 1 IDE in the workspace, then we wouldn't have had to go to all this trouble and could have simply implemented the desktop IDE images as “regular” images.

Thus, I think that the impression that the user is asked on workspace start for “which preference they would prefer” is actually not correct. The reason why at workspace start the 2 IDEs looks on the same level is because we are not able to start the JetBrains desktop IDE directly (yet) → see (1). The desktop IDE button is only meant as a fallback, not as an equivalent option.

I think it makes sense to communicate this consideration better.

• Users want to open all workspaces using the same desktop IDE every time
• Whether users would want to configure IDE's on a per-project basis
• Users want the choice on a per-project basis

That's actually is a very important point. Having the option to switch/configure IDE options per project would be very useful when you work in different languages, IMHO.

[loujaybee]

Dropping in an additional note/user-feedback from @gtsiolis (internal link)

Clicking on an active (running) workspace from the workspaces list in the dashboard that you opened while you’ve enabled desktop IDE in preferences, redirects again to the same workspace start page to select desktop or browser IDE regardless if you disabled desktop IDE in preferences. Known? Expected?

Also, link this Discord chat with a discussion regarding preferences for IDE's and projects.

[loujaybee]

Is there a way to always open in my local vs code? Currently I either go to GitHub and open Gitpod using the browser extension or I open it directly from Gitpod. But both those options opens in the browser first and then I have click open in VS Code. Is there a setting or a work flow that let's me open directly in vs code?

Noting an additional comment/feedback from the community [1] about enabling a better flow for opening VSCode desktop.

[loujaybee]

Thanks for the detailed response @corneliusludmann !

As far as I know, the extra step is only necessary for the “Code with me” integration. Once we have a more direct way of opening JetBrains we will open the IDE directly. E.g. for the VS Code integration, we have a vscode://... link that opens the desktop IDE.

Awesome 🙏

Nevertheless, opening an additional browser tab to follow the progress is still useful, IMHO. [...] This page also shows errors when the workspace start fails.

Agree. Some thoughts:

1. Should we only be allowing the user to start a desktop session from a browser? What about via companion app, or desktop initiated flows?
2. We need to investigate how transparent it is to users that they can use multiple IDE's to interact with a single workspace and whether the current UI/UX makes this clear.
3. Using the browser to view workspace errors is an interesting point. If the users moves their flow to desktop, they potentially might want a different browser experience for controlling their workspace (not necessarily just the browser IDE).

there was the decision (before I joined the team) that we want to have a fallback when the connection from the desktop IDE to the workspace fails. In that case, the user should still have a path to access the files in the workspace without the need to stop and restart the workspace [...] implemented the ability for a workspace to contain 2 IDE images: the browser and the desktop IDE image. If we don't need this fallback option at all, but only ever start 1 IDE in the workspace, then we wouldn't have had to go to all this trouble and could have simply implemented the desktop IDE images as “regular” images.

There's two thoughts I have on this topic:

1. Underneath this decision/architectural decision there's a sort-of implicit assumption that we can only have: 1 browser IDE (VS Code) and/or 1 desktop IDE (Choose a JetBrains one, currently) per running workspace (this isn't a 100% correct statement, as we can also start a JetBrains IDE, open the browser IDE, then open VS Code Desktop). We will for sure need to think about how we make a clearer distinction between the concept of the workspace and the concept of the IDE. It was somewhat "easier" before when Gitpod was more 1<>1 between workspaces and IDE's. But now with potentially multiple desktop IDE's... things are a little more complicated 🙃
2. The user is choosing IDE preferences "globally" and we might want to test/validate that assumption. i.e. do we want Gitpod to be a "happy-path configuration for a dev environment"? And should that happy path also include their IDE set up? Or... do we leave IDE configuration entirely to the user? Given that we allow per-project IDE extension configurations for VS Code [1] we have gone down the path of allowing per-project IDE configurations, so maybe we should add some way (probably in the .gitpod.yml) to set the IDE for a given project (issue created: Allow desktop IDE preferences (e.g. plugins) to be set via the .gitpod.yml #6706).

[svenefftinge]

My 2 cents:

• as long as we don't have a proper "start workspace" UI in the local IDEs or companion app, we will always start from web. In fact, starting from gitlab, github is still the primary flow. We can and should improve the start workspace logic and at some point bring this to all the uis we have but I think we can a few steps before without bothering too much about this future.
• the UI of a loading sequence is non trivial, so I'd prefer to keep focussing on the web-version of that. I.e. even when you start from local somehow and want to end up in a local IDE, the web based loading sequence should do for now.
• We should for sure auto open the local IDE when the workspace has started (redirect to special scheme), but I think keeping the browser open in order to get to the web ide if needed (e.g. starting local IDE didn't work)
• I don't think the configuration for what IDE I want to use is something that should be configured on the repo (gitpod.yml) but is rather a user preference.

[loujaybee]

Small piece of feedback [1] from a user in Discord, that they found it difficult to find the preferences, given that they were hidden under the checkbox.

Also some comments here: #6706 seem to overlap.

e.g.

So in an ideal world, you could select whether you want desktop or web based when the workspace was launching, a bit like when it gives you the selection for what desktop IDE you want to use, but adding the web options as well.

[loujaybee]

Referencing related internal conversation [1]

[Pothulapati]

I think, Just like how GitHub recently has been doing a lot of work focusing on workflows and power users. We should also be doing similar stuff at some point but this definitely may not be high priority now!

With us, starting to support many clients i.e Vs Code, Jet Brains, CLI (for Vim, etc. Great demo from @csweichel on this recently), etc. The importance for opening from the Browser, becomes more and more important as it's not at all easy to build and maintain clients for all the stuff mentioned above, and expect users to install before jumping to Gitpod. The web workflow will continue to be the most important, expected way to manage, use workspaces.

Having Client stubs, that make it easier to use/manage work-spaces would be something that the users would definitely want. These are important to enable power user workflows, where users would want to jump to work-spaces without having to use the web dashboard unless they want to do some additional tasks i.e admin settings, etc.

• Vs Code Client: Day after day, I see myself wanting to open a workspace for a repo without having to open the browser and this adds a additional hop! As VS Code desktop is the main way that I use gitpod. (My assumption is also this with others but happy to be proven wrong) This feels very important.
• CLI: Once we start adding support for ssh to enable all kinds of editors (yay), A CLI tool will become more and more important.

I think, In general CLI tools for dev tools i.e gh , etc have been getting a lot of developer love recently. We could have the CLI tool as the foundation for building the Extension stubs for editors i.e gitpod <repo> -ocode should open a vs code instance with that repo, etc. I think, if we have a CLI with great UX and integrations with editors, we might even skip building extension stubs for editors as CLI would be enough to enable power workflows.

[loujaybee]

Thanks @svenefftinge, @corneliusludmann, @Pothulapati for the insights. A lot of the original points raised / discussed are still relevant, but, this issue was also raised before product evolutions such as the more comprehensive JetBrains Gateway experience. Given that this was more of a discussion, and that it has now spawned some more specific, actionable issues I suggest we now close this issue, I'll link relevant discussions to other related issues where needed, e.g. 🙏

• Gitpod "open in" should be set-able per project, not just per-user #6874
• Epic: SSH access copy/paste via dashboard #7713
• Open Gitpod from JetBrains desktop IDE(s) (IDE plugin command) #7626
• Epic: Desktop Gitpod Experience (e.g. CLI or Trailer App) #7185
• Epic: Allow user to configure preferred IDE configurations as part of onboarding #6707