Property aware users that they can choose IDEs with onboarding dashboard

[mustard-mh]

Property aware users that they can choose IDEs with onboarding dashboard

Further opinion: Display recommended template project after they choose some IDE in this page (i.e Goland => template-golang-cli)

It's a IDE feature in our workshop

See draft Figma

Before	After (onboarding)	After 2(after onboarding)

[mustard-mh]

As a part of #6707

[mustard-mh]

We may need to discuss the UX and text content about IDE select (see Description Image After (onboarding))

cc @gtsiolis @loujaybee

[svenefftinge]

Wouldn't it be good to ask users what IDE they want to use per project? I'm thinking of asking them in the startup flow, before starting the workspace with an option to "never ask again for project xxx/yyy" which is enabled by default.
Then in the settings, we could provide means to manage this as well, in case you want to be asked again later.

[mustard-mh]

@svenefftinge If you want to choose different IDEs per repo, this PR may be helpful gitpod-io/browser-extension#59.

For projects, maybe we can provide a context menu with IDE list

[svenefftinge]

That one is IMHO not generic enough as it requires me to go through the browser extension and there are many other ways to create workspace for a repo/project.

[andreafalzetti]

@svenefftinge the concept of having a user-preferred IDE per project makes a lot of sense, we should put it on the roadmap IMHO 👍

At the same time it's still useful to have a default IDE for "everything" else not specified, I suppose.

I just want to highlight that with this issue we are trying to build a small analytics-driven experiment, very time-scoped, to see if we can increase awareness that Gitpod is not only VS Code in the browser, during the onboarding phase.

[loujaybee]

Wouldn't it be good to ask users what IDE they want to use per project? - @svenefftinge

IDE's per project settings is definitely something we want to experiment with (see #6874) there's been quite a lot of feedback from users that a per-project UX is needed on top of the global user preferences (CC: @andreafalzetti given your comment also about adding to the roadmap).

However, at this stage, I wouldn't want to mix/merge the two things: IDE visibility in onboard with per project IDE's. Let's raise a PR with a minimal first-pass experiment to add IDE visibility during onboarding, and before we ship we can adjust to make it more comprehensive/advanced, or ship as is and see the impact.

1. Per project IDE's - Gitpod "open in" should be set-able per project, not just per-user #6874
2. Opening ad-hoc IDE's from the dashboard - Open workspace in ad-hoc (per-workspace) editor or IDE #8573 (possibly also in the browser extension pull/59 as @mustard-mh shared above)
3. In workspace onboarding Collapsible global navigation within in-browser editing experience #9131

That one is IMHO not generic enough as it requires me to go through the browser extension and there are many other ways to create workspace for a repo/project - @svenefftinge

I agree. The browser extension is not assumed as a step of our current onboarding flow (see comment on the other PR [1]). The main two onboarding flows are: login > dashboard > workspace, and/or direct from a repo, or via a context URL. This experiment should ideally focus on impacting these two journeys as a priority.

[mustard-mh]

We can also provide a command open users are at Dashboard and going to open a workspace here after this PR #9467
When user is pressing cmd / opt etc, present IDEs for them to choose

• modal IDEs layers in template list
• put small icon IDEs layer above Project
• put small icon IDEs layer on right side of workspace

notice them by showing cmd ctrl etc tag in repo list right side / doc / what's new etc

Dashboard Template List	IDEs Layer (i.e)	notice (i.e from Alfred)

Present (when pressing) also	and here