Improving new user flow (with a focus on Quarkus)

[l0rd]

Is your enhancement related to a problem? Please describe.

If someone looks for Che on Google these are some of the UX problems that will be found:

che.eclipse.org issues:

• "Start working with Che" section in the website is not clear #17964
• Replace Thorntail stack with Quarkus on Eclipse Che website #17961

Hosted Che issues:

• Hosted Che sso redirect page has a bad CSS #17965
• Switching to persistent storage on che.osio we should warn about the filesystem issues Switching to persistent storage on che.osio we should warn about the filesystem issues #17990
• When switching from ephemeral to persistent storage I am not expecting to lose my files When switching from ephemeral to persistent storage I am not expecting to lose my files #17991

Devfile Registry issues:

• What's "Quarkus command mode" stack? #17966

Quarkus Plugin issues:

• Extension welcome page gets shown again and again Quarkus welcome page gets shown again and again #17994
• Quarkus getting started page is not written for Che "Quarkus Tools for Eclipse Che" welcome page is not for Che #18005

Che Theia issues:

• File Explorer should be opened at workspace startup #17969
• Theia "Debug" menu item should be "Run" menu item #17967
• Disable tasks output scanning message #17970
• Port redirect option "No" is missing #17972
• Hide port redirect message for non public endpoints Hide port redirect message for non public endpoints #17993
• When clicking on Run nothing happens [UX] When clicking "Run" nothing happens unless a java file is open / extension is loaded #18004
• Default path is / and not /projects/ Default path is / and not /projects/ in "Create Quarkus project" wizard #18006
• My workspace view should be opened at workspace startup

[sunix]

I added My workspace view should be opened at workspace startup WDYT ? @l0rd
Most of the new users are quite lost in a Che workspace. It is important that these users visually see the containers and the ability to open a terminal or run a task visually at start up. So it is straight forward to start a build, or run the app, etc ...

[l0rd]

I added My workspace view should be opened at workspace startup WDYT ? @l0rd
Most of the new users are quite lost in a Che workspace. It is important that these users visually see the containers and the ability to open a terminal or run a task visually at start up. So it is straight forward to start a build, or run the app, etc ...

No I don't think that My workspace view is something that makes things clearer for a new user.

I understand that for those that are not used to VS Code and the command palette it may be hard to find the list of tasks. But we should spend our energies to help users getting into the command palette instead of implementing an "old style" alternative to it.

The same applies to the terminal: when a user starts a quarkus stack he will expect that running maven is as simple as selecting an existing task or opening a terminal and type mvn. If we give the user the choice of multiple containers we will lose him.

I am also against providing the details of the IDE services (plugins). Except for advanced users, accessing directly those containers is source of confusions and should be avoided.

The endpoints links are the only thing that I would keep. But current UX should be reviewed: the endpoints status is not shown and, if the application isn't running (at workspace startup for example), clicking on an endpoint shows some error pages.

[tsmaeder]

The same applies to the terminal: when a user starts a quarkus stack he will expect that running maven is as simple as selecting an existing task or opening a terminal and type mvn. If we give the user the choice of multiple containers we will lose him.

I disagree here: we can try and make the different containers disappear in the UI, but this will be a leaky abstraction: eventually, the user will have to deal with the fact that the workspace consists of multiple different containers and will be even more confused. It's better to be explicit with non-reducible complexity.

[l0rd]

the user will have to deal with the fact that the workspace consists of multiple different containers

Maybe. I am probably missing some advanced use case. But the new user that opens a Che workspace for the first time, selecting one of our getting started, should NOT deal with the fact that the workspace consists of multiple different containers.

[tsmaeder]

@l0rd this "remote commands" and "hide the containers" stuff seems to be part of a bigger effort: is there an Epic (or could you open one) so that we know what's coming down the line and can discuss it?

[l0rd]

@tsmaeder I agree. We currently have #17209

[sunix]

Discovering Che, new users have to see the difference from a traditional IDE (or even other existing Cloud IDEs).
There is one thing that user may use the command palette and not the my workspace view. This is the choice of the developer. AFAIC, i prefer not to use the command palette, and I prefer to use the terminal, not the gui. This are personal choices and you shouldn't try to convince me to use the command palette. My workspace view has the advantage that it is visually accessible. Knowing that you have available predefined tasks to run a build not something that you can guess right away.
My point is that knowing that you have predefined Che task that you can run from the command palette is an advanced usage. We have to show at the very beginning to the users that these tasks exist, that these containers exist. Without that, new user will finally open a terminal (and choose the container?) and try to type his the commands ... fail ... and give up ...
IMHO, If we want the user to start the build and run the app 20 seconds after having started the workspace, we have to show the my workspace view.

[che-bot]

Issues go stale after 180 days of inactivity. lifecycle/stale issues rot after an additional 7 days of inactivity and eventually close.

Mark the issue as fresh with /remove-lifecycle stale in a new comment.

If this issue is safe to close now please do so.

Moderators: Add lifecycle/frozen label to avoid stale mode.