[projects] Introduce "no setting", i.e. default to user's setting for workspace classes

[svenefftinge]

The workspace classes on the projects setting don't make a visual distinction between "no setting" and the set to the default class. But internally the difference is that an explicit project-level setting overrules any user settings.

We need a way in the project settings that communicates/allows setting to "default/ no setting".

[jldec]

Bumping priority on this because the feature is very difficult to use right now.

The setting shows one of options highlighted on the default value (e.g. based on your user preference) , as if selected, even though no preference has been stored in the project..

After clicking on the already-highlighted choice, it becomes selected and persisted, but there is no visual feedback at all.

cc: @svenefftinge @gtsiolis

[jldec]

@svenefftinge @gtsiolis

How about showing the "use default" (no setting) state in both personal and project settings?
This would allow for users to receive a different default when it is modified say at the org level 😉 .

[gtsiolis]

@jldec From UX perspective, a straightforward solution could be to automatically select and actually set a default (standard) class when someone adds a project. Does this sound like a good MVC forward?

❓ question: Do we want to ask users to go through all projects they add and set a workspace class?

💭 thought: Since we’re introducing the same setting on a user, project, and maybe later team and org level, maybe this is more about communicating clearly if a setting is inherited.

Some thoughts on the card component:

1. The selectable card component was designed to never have an unselected state. We could add an unselected state, but this would slightly decrease the effectiveness of this component.
2. The workspace class selection, just like the editor selection, will undergo a redesign so that it's more flexible and scalable, see Replace the editor selection cards with the new dropdown component used in the start with options new workspace modal #13116. In that case, having an unselected state sounds better and more viable.

[jldec]

@gtsiolis
This configuration on projects is optional and the selection UI needs an unselected state.

New and existing projects have no workspace class config and the UI should show that, because it means that the user's preference, or the installation default will be used. Simply showing that default as selected is confusing/wrong because it depends on who is looking at the setting and what their personal preference is at the time.

Going into project settings in order to change the setting is how project owners override the user or installation default.
In gitpod.io, they should see 3 choices and on first use, 1 will be highlighted.

1. Use default e.g. if configured in personal preferences
2. Standard
3. Large

[svenefftinge]

we don't need this for now, as we have removed the user settings for workspace classes. Maybe introduce it once we have policies for workspace classes on team and org level.

[gtsiolis]

Thanks @svenefftinge @jldec!