MR: Pending <!-- The first line of this issue description must be one of the following: 1. `MR: Pending` 2. `MR: <MR link with trailing +>`, 3. If there are multiple MRs: ``` MRs: - <MR 1 link with trailing +>` - <MR 2 link with trailing +>` - ... ``` 4. `MR: No MR` ...and the first description line of the MR should be `Issue: <Issue link with trailing +>` For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/index.html#relationship-of-issues-to-mrs --> <!-- The following sections should be filled out as part of the refinement process before the issue is prioritized. For more context, see: https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#2-pre-iteration-planning-meeting --> ## Description Users expect the Web IDE to behave the same with or without a workspace. Being able to add a runtime environment without leaving the Web IDE would improve the UX. If this isn't possible then we can at least improve the empty state of the terminal. ## Proposal The empty state of the Web IDE terminal refers to remote development documentation and provides a CTA that allows users to configure a remote environment. However, we could improve this by providing more guidance and streamlining launching a workspace without leaving the Web IDE. ## Notes From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531): "Maybe I could launch from the Web IDE?"  <!-- Replace with other type, e.g. bug or maintenance, if appropriate --> <!-- Replace with other subtype if appropriate --> <!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process --> <!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->