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).