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 Recommendation originating from [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2445) ## Problem 1 Users have trouble understanding workspaces and how they relate to GitLab projects. The side nav is one of the first places they look. Combined with how the `Workspace` brand means something different to different people it can lead to the interpretation that a workspace spans multiple projects. From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531) : - _“If I had just clicked Edit and seen workspaces I would not have been particularly drawn to use it just because I’m entirely unfamiliar with it”_ - _"Initially, I imagined ... that it will be just a general thing accessible through GitLab somewhere where I would click a button and it wouldn’t be directly attached to a project. I think it makes a lot of sense to attach it to a project. It's just not what I expected.”_ - _"I think just the name Workspace suggests to me, this is where I work, and when I personally work, I work on everything (not just one project) at the same time. That’s just where the name led me.“_ ## Problem 2 Launching from the `Edit` button in a project is not as engaging as it could be. From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531) : - _“If I had just clicked Edit and seen workspaces I would not have been particularly drawn to use it just because I’m entirely unfamiliar with it”_ ## Problem 3 Clicking `Create workspace` from the `Edit` button in a project direct the user to `Your work > Workspaces > Create workspace page`. This is unexpected at best and confusing at worst. Users who are new to GitLab and don't fully understand the difference between `Your work` and `Project` in the navigation are especially confused. From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531) : - _“Oh this tab wasn’t here before”_ (`Viewing Your Work > Create Workspace page` after clicking New Workspace in `Edit` button) ## Problem 4 Could we improve workspaces usefulness by allowing users to see all members workspaces in a project? Needs more investigation but this could be a useful collaboration feature. From [UX Scorecard](https://gitlab.com/gitlab-org/gitlab-design/-/issues/2531) : - _“It would be cool to see other people’s instances”_ - _"We had something like this (collaborative dev environments) at my last job. It was really useful"_ ## Acceptance Criteria TODO: Fill out (required) - [ ] Alignment on proposed solution - [ ] Split into individual issues ## Proposed solution <!-- 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 -->