redesign the stopped loading screen

[akosyakov]

I’m missing go to workspaces and GitHub (context) links.

[corneliusludmann]

Some thoughts on this:

I would love …

• to have a “go to workspaces” link (as Anton mentioned already)
• to have a context link (as Anton mentioned already) → link to GitHub / GitLab / Butbucket context
• to have the info if the workspace has uncommitted / unpushed changes (as we have in the workspace list), probably also other info from the workspace list like workspace start time, stopped time, etc.
• to have a second “start workspace” button that does not restart the existing workspace but opens a new workspace with the same context. (This button should be the primary one if the workspace has no uncommitted / unpushed changes, IMHO.) This should encourage users to create new workspaces instead of reusing old ones.

[svenefftinge]

to have a second “start workspace” button that does not restart the existing workspace but opens a new workspace with the same context. (This button should be the primary one if the workspace has no uncommitted / unpushed changes, IMHO.) This should encourage users to create new workspaces instead of reusing old ones.

I'm generally in favor of educating people to start fresh workspaces, but I think in this context it doesn't generally make sense and would potentially confuse users. Especially when the primary button changes depending on state.

[svenefftinge]

Also, why do you want to go to the list of workspaces? I think it is more like a history of your past actions.
Could it be that you are only missing the go back to GitHub/GitLab?

How about showing the workspace entry? It contains all the info including possibility to start and even delete?

[svenefftinge]

[corneliusludmann]

Sound like a good idea to re-use the same widget here. Also from a maintaining perspective.

In the long term, we could think about whether this widget could be improved in general.

[gtsiolis]

Going through the comments and trying to jot down some points that could help reaching consensus here as well as move into the right direction.

Question: I understand that a user can reach this screen by a) reaching the timeout for a workspace or b) manually stopping the workspace via the dashboard, right?

I think @corneliusludmann described concretely in #2084 (comment) most of the key points this page should contain. All points are valid, the only missing here is a clear state which can be confusing since a very similar page is used for indicating STARTING and STOPPING lifecycle stages.

Problem

One of the core issues with the stopped loading screen is that we are using almost the same layout for stopping, stopped, and starting lifecycle stages of the workspace. This makes it hard to quickly differentiate the current state.

WS STARTING	WS STOPPED

There are also some issues that could be considered out of the scope of this issue:

1. In this state, where the user sees the loading screen for a stopped workspace, the user can either refresh the page using the browser to restart the workspace or close the tab.
2. There's an in-between state when the workspace is STOPPING where the user can only close the tab as refreshing the page will try to restart the workspace according to the user interface elements but will fall back to STOPPING and eventually stop the workspace.
3. In the STOPPED loading screen, the stopped loading indicator (G) is moved on mouse down which can be confusing on whether this action is trying to do something in the background or not.
4. The primary action button is quite clear that restarts the workspace but it's not clear whether user edits (new files, edited files, new commits, and more) have been persisted or lost after the workspace stopped.
5. Also, if the user tries to restart the stopped workspace via the dashboard without closing the tab with the stopped workspace first, you end up with two tabs running the same workspace.

Reusing the WS component: Regarding reusing the same component, although it is certainly efficient, in the long run a completely different design could be better for the user to be able to think fast and realize this is the stopped screen and not part of the dashboard or a broken feature, without looking in the layout details. /cc @svenefftinge

WS List	WS STOPPED (Proposal A)

Proposal

In addition, I'd say that the key points that need to be more visible and clear to the user here are the following:

1. Make sure it's clear this (STOPPED) is the last lifecycle stage of the workspace lifecycle and not the first one (INITIALIZING). A status label could help here.
2. Remove any click events that interact with static elements in this screen like the stopped, previously animated, logo.
3. Clarify what happened to your work as you may have been working for a couple of hours in this workspace and after a small break away from keyboard you have no clear view whether your work is lost or persisted temporarily until restarting the workspace.
4. Provide clear action buttons for going back to the dashboard and restarting the workspace in a sense of continuing work.

WS STOPPED (Proposal B) - Low Fidelity (LoFi)	WS STOPPED (Proposal B) - High Fidelity (HiFi)

Using a workspace component like the proposal in #2084 (comment) could also be interesting.

WS STOPPED (Proposal C) - Low Fidelity (LoFi)	WS STOPPED (Proposal C) - High Fidelity (HiFi)

Question: Also, what do you think of rephrasing RESTART to REOPEN? 💭

---

Follow-up issues I run into while investigating this:

Authorization

Here're some possible edge cases for this scenario:

1. Issue: The shared running workspace could be based on a GitHub repository while the user opening the shared link could have authorized only with GitLab and eventually run into an error page. We could use the same authorization page we use when opening a GitHub repository without a GitHub authorization in place. See follow-up issue in Opening a snapshot for a repository from unauthorized providers fails #2408.
2. Issue: Even if both users sharing a running workspace have authorized with GitHub, the user opening the shared link will also run into an error page. The same happens for workspace snapshots.

#### Navigation

Thinking of dev environments as disposable dev environments is a solid idea. However, opening a new workspace in a new tab every time creates disposable tabs along with workspaces which can lead to redundant tabs, create user confusion and more. Curious how many stopped workspaces (tabs) everyone is closing every day while using Gitpod?

Proposal: What do you think of not start workspaces in a new tab but using the same tab to render the IDE and allow the user to navigate back to the dashboard from within the same tab.

1. This will allow the user to use browser shortcuts like CMD+Click to open a new tab if needed.
1. This will make adding any action buttons more useful and effective. Adding in the current state buttons to go back to the workspace could create more tab noise since there's a high chance I've already have a dashboard open when I started the workspace in the first place.

See follow-up issue in #2516.

---

Again, hope you find all these points helpful. Let me know what you think. ❤️

[svenefftinge]

Thanks George, I like

👍
For all the appendix stuff, I think it would be good to track / open up discussions elsewhere. As it is unrelated to this topic and therefore a bit distracting.

[svenefftinge]

I propose to leave out the "Workspace" heading for now and also don't change the style of the status.

[gtsiolis]

Thanks @svenefftinge! 🙌

For all the appendix stuff ...

Definitely, I'll try to open follow up issues for these.

I propose to leave out the ...

Agree, title seems redundant at the moment. We can also aim for a minimum viable change (MVC) and use the existing style (buttons, etc) and match the layout and structure with the new design elements.

Some key points of this proposal include:

1. Using the gray variant of the logo to indicate a stopped workspace following the pattern used in the favicon.
2. Using a text status label since color is not a strong indicator here, especially for color blind users.
3. Linking to relevant documentation for more context.
4. Highlighting workspace edits.
5. Providing clear actions for the user.