Improve prebuild-in-progress page layout and actions as well as make workspace start sequence clearer

[gtsiolis]

Problem to solve

Following up from #9904 (comment), the prebuild-in-progress phase:

1. Happens before the workspace loading phases (Checking, Creating, & Starting), however, it's not clear if it takes place before or after the rest of the workspace start phases.
2. Does not re-use the prebuild log output component from the prebuild page, see Use the same prebuild view for Workspace start as for Prebuild Details #9132.
3. Currently hijacks the title element from the existing loading phases of the workspace start page to indicate it's about the prebuild-in-progress phase.
4. Does not feel connected with the rest of the workspace start phases.

Proposal

Since the existing loading phases of the workspace start page aim to abstract the sub-states of the loading cycle to make the loading friendlier to the user, we could consider 🅰️ reusing the same element from the prebuilds pages (see #9132) where we could surface these sub-states of the prebuild phase and 🅱️ provide better visibility of the step sequence.

BEFORE	AFTER

In short, to break things down into smaller minimum viable changes (MVC) if needed:

1. Introduce a Preparing loading phase for the prebuild-in-progress phase
2. Additionally, consider re-using the prebuild log output element for better associating prebuilds across the product as well as surface potential sub-states of the prebuild-in-progress phase as well as improve the UX of the actions available to users, see Use the same prebuild view for Workspace start as for Prebuild Details #9132.

[gtsiolis]

@jankeromnes I'd love any feedback or thoughts on this since you were involved in adding these workspace start pages in #3301 and #3415. Cc @jldec

[atduarte]

Just sharing my 2 cents as I saw this being shared: I like the additional info 🙌 although I'm concerned about reducing the width of the window with logs.

[gtsiolis]

Thanks for the feedback, @atduarte! The width aspect has been brought up before in #9132 (comment). Keeping the existing width can be also a good way forward and will be possible without further design specs as the component is flexible to change its width. 🤝

Re-posting from #9132 (comment) for visibility:

No strong feelings on the width of this element, we can safely move forward with the same width for this iteration. 🛹

To provide some context, the idea of the smaller element width was based on the intent to provide a fun and futuristic aspect in the product (see relevant comments[1][2][3]) while assuming that watching the prebuild logs is not much helpful most of the times during workspace start as there's nothing users can do besides continuing with the default image. Cc @jankeromnes because #3560.

This idea comes with the intent to have a horizontal scrollable container or keeping the text wrapping of the logs as is, see example prebuild in gitpod-io/gitpod project, while focusing on the visibility of the prebuild task completion output.

To support this idea, there was an early design draft we made for the onboarding flow which allowed users to expand the logs output element in width and height while using a narrower width by default which could be re-used here, see arrow on the top right corner in the exports below.

Logs collapsed	Logs expanded	Prebuild task

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.