Minimal set of dashboard improvements for Che 7

[l0rd]

Description

Here is a small list of desiderata for Che 7 regarding the dashboard:

• Plugins list should be visible only if a Che 7 stack has been selected
• A user should be able to set less than 500 MB for a runtime memory limit
• Che 7 stacks should not appear when running on Docker infrastructure
• Configuration should be saved automatically (remove SAVE button) -> moving to separate issue Workspace configuration should be saved automatically (remove SAVE button) #12136
• When a user select create workspace it should also start by default

cc @slemeur @evidolob @ashumilova

[mmorhun]

@l0rd I disagree with the point that we should start workspace after creation. It might be useful to change some configuration and only then start it. At least we should leave the ability to not to start it.
Also we have limitation for number of workspaces which run simultaneously and if a user creates a new workspace it might not start due to the settings which will look not so good, like error on creation.

[l0rd]

@mmorhun I agree we should leave the ability not to start it right away. But the default should be to start it!

[mmorhun]

@l0rd as about saving of workspace config: we cannot save invalid one, AFAIK. And if a user is in process of editing it might cause problems. To me we shouldn't show errors/success on editing (it is obvious, IMO), but on attempt to save. The problem is that we cannot predict when user finish the editing. And we should notify a user if config is invalid and what is wrong when editing is done.
So far, I see the save button the most clear way of doing it. But what we can improve, that preventing of leaving tab with unsaved configuration (the problem I run into from time to time).

[l0rd]

@mmorhun what you are saying doesn't make and it looks like you haven't tried to edit a workspace since a long time :-) Try to edit the json config of a workspace, and tell me if the syntax checking is done when you are typing or when you press Save:

[mmorhun]

@l0rd no, I have used the editor during last few days a lot :) . I more talking about ways to improve and not about how current config editor works.
As about the error message, well, for some cases it might be useful, for example in case of copy/pasting config parts, I missed it, but while a user types it might be annoying (I do know that when I type parameter name I miss the value for now). But ok, it is easier to ignore than not to have it at all, may be we should keep it.
The thing which to me should be fixed is formatting on fly, because it may change input point on type pause (or keep caret in the position (i.e. move according to formatting)).

[mmorhun]

@l0rd and yes, thanks for feedbacks ;)

[l0rd]

@mmorhun I agree that current syntax checking/formatting can be annoying but I consider of higher priority the removal of the "SAVE" button. Then we will fix the rest too. Step by step ;-)

[ashumilova]

I have few questions:

1. "Che 7 stack" - how we differ it from others? can we check attributes (editor or plugins) are set as indicator?

2. When workspace is created not from Che7 stack and we edit it - can we still leave "plugins" , cause it's made in a way to allow to switch to Che7 model without errors (installers will be removed and user notified about that). Here the idea was to promote switching to Che7 model from Che6 one.

3. About starting by default workspace on creation-> here it's meant when user clicks "Edit" or "Open in IDE"(in this case workspace is started)?

[ashumilova]

About removing "SAVE". I understand about the point to autosave, but with current layouts do not really have idea how to make it consistent. Let me explain. This layout appears each time we do any edits with any object:

but in case of workspace it has additional option - to Apply the changes, which means workspace will be restarted.
In case of autosave - first - no way to provide that and may cause misunderstandings, second - based on UX of editing other objects from dashboard or other parts of workspace - may be confusing as well - in which case config is saved automatically, in which case - need to click Save. Maybe we should think how to improve overall flow of editing the workspace details.

[ashumilova]

BTW, what button on workspace creation you meant:

• in right upper corner
  or
• at the bottom on the page
  

Based on your idea to start workspace by default but still have way to change it, and avoid popup (as I understood):

we could add smth like checkbox - by default unchecked saying smth:
"I want to proceed editing the workspace"

[benoitf]

about

• Che 7 stacks should not appear when running on Docker infrastructure

maybe it could be more generic. Testing on Kubernetes we see some stacks that are not working as well due to openshift recipe, etc. So it should display only compliant stacks

[l0rd]

@ashumilova

"Che 7 stack" - how we differ it from others? can we check attributes (editor or plugins) are set as indicator?

That's an excellent question and I was wondering the same thing. Checking editor attribute is a good idea but I don't have a strong opinion: that's an implementation detail.

When workspace is created not from Che7 stack and we edit it - can we still leave "plugins" , cause it's made in a way to allow to switch to Che7 model without errors (installers will be removed and user notified about that). Here the idea was to promote switching to Che7 model from Che6 one.

That's fine.

About starting by default workspace on creation-> here it's meant when user clicks "Edit" or "Open in IDE"(in this case workspace is started)?

I mean Open in IDE. I think that's what users want to do 99% of the times: select the stack, select the project and Open in IDE (not editing).

About removing "SAVE"...

I don't want to go through a full refactoring/review of the dashboard with this issue. It's just a list of quick fixes to improve the UX. I still think that enabling autosave, removing the SAVE button (and and maybe just renaming APPLY to RESTART) can be done as a quick fix. But you know the details better than I do and if you think it's more complicated than that let's descope it from this list and make it a separate issue. I am fine with it.

what button on workspace creation you meant?

Both. Transforming both into "Open in IDE" button.

we could add smth like checkbox - by default unchecked saying smth:
"I want to proceed editing the workspace"

I would just invert Create (currently the default) and Open in IDE (should be the default instead):

[l0rd]

Testing on Kubernetes we see some stacks that are not working as well due to openshift recipe, etc.

@benoitf I think that's already the case no?

[benoitf]

@l0rd ok maybe it's the Che7 stack then that is not working as expected due to the broker adding openshift recipes dynamically when we're on K8s

[l0rd]

@benoitf that's weird. I have tested Che 7 stacks (merged yesterday in master) and they worked perfectly on kubernetes for me.

[benoitf]

@l0rd I used 6.13.0 it might explain