Che: Dashboard: While editing a devfile of a workspace, user is constantly interrupted by the auto save

[sunix]

Describe the bug

Editing the devfile of an existing workspace from the dashboard is a nightmare.
It is not possible to edit a command and being interrupted by the auto save which is not doing it silently: while the user is typing it is saving, reformatting, scrolling and undoing what the user had typed few millisecond before.

Che version

• [ ] latest
• [x] 7.0.0-next
• [ ] other: please specify

Runtime

• [ ] kubernetes (include output of kubectl version)
• [ ] Openshift (include output of oc version)
• [x] minikube (include output of minikube version and kubectl version)
• [ ] minishift (include output of minishift version and oc version)
• [ ] docker-desktop + K8S (include output of docker version and kubectl version)
• [ ] other: (please specify)

Screenshots

Installation method

• [x] chectl
• [ ] che-operator
• [ ] minishift-addon
• [ ] I don't know

Environment

• [ ] my computer
  
  
  
  • [ ] Windows
  
  
  • [x] Linux
  
  
  • [ ] macOS
  
  
• [ ] Cloud
  
  
  
  • [ ] Amazon
  
  
  • [ ] Azure
  
  
  • [ ] GCE
  
  
  • [ ] other (please specify)
  
  
• [ ] other: please specify

[vitaliy-guliy]

Agree with @sunix. I really hate autosave in this case. Probably it's a good feature but I have to edit the devfile outside the dashboard and then to replace the whole devfile content.
Save button is really what we need.

[sunix]

autosave is a good feature but it should not interrupt the user currently editing. In Theia, autosave works great.

[vitaliy-guliy]

Fine, but the dashboard should not re-read the devfile on every save.

[nickboldt]

Thoughts:

a) autosave could be slowed down to only apply if the user stops typing for 5 seconds

b) add a checkbox to disable autosave

c) why not ALWAYS have a save button anyway, even when autosave is enabled? Sure, it'd be greyed out but it's not like there's a shortage of screen space.

d) maybe it would be easier/better for extensive editing to be done in another browser (eg., in Che editor) and then have a way to upload the file easily to the dashboard

e) why make this complicated? follow the UI experience of editing a file/comment/gist in Github or JIRA UI. One green button to rule them all, no autosave needed.

[sunix]

To me the problem is not autosave itself but the fact that it is reformatting/changing your file and the cursor doesn't follow. Is it necessary to reformat the file ? could we reformat after 10 secs of inactivity ? could we set the cursor back to where it was after reformatting ?

[amisevsk]

Another frustration here is if you e.g. delete a single character from one of the fields, the automatic reformat will

1. Delete the whole subtree for that field (deleting the s from components) will remove all components from your devfile.
2. Immediately save the now-broken devfile.

[nickboldt]

Removing triage label as we seem to agree this needs doing, and no one has objected to the 7.2 target milestone.

[akurinnoy]

@nickboldt

Originally, similar page with workspace config editor had separate SAVE button. But back then there was the problem that people forgot to hit the button, went to another page of UD and lost all changes in editor.
Actually, the SAVE button is still there but it's disabled and hidden on the editor tab.

@sunix @amisevsk

AFAIK reformatting and changing of devfile happens because we don't store a raw content of devfile. Each request to save changes of a devfile ends with re-rendering of editor content with serialized server side response.

With this in mind I see two options:

1. Disable autosave on editor page and prevent user to leave editor tab until user explicitly saves or discards changes. This will make also all tabs on Workspace Details page behaves consistently.

2. Avoid re-rendering the editor content if server side responds with status 200. But this may lead to that devfile in editor may differ from what was saved (see comment).

Does anyone has other ideas how this can be done?

[amisevsk]

@akurinnoy My main issues with the way the editor is implemented are

1. The autosave can happen often, which interrupts text input.
2. The editor auto-reformats the devfile on every save, which can totally break it.

The first point above could maybe be fixed by increasing the autosave interval (user stops typing for 3 seconds or something). I'm not sure on the best approach for the second part, though.

What I'd imagine for the devfile editor is

• Shows the progress bar at the top of the panel when user is "editing" devfile (i.e. as soon as any change is made). The bar signifies to the user than not all changes are saved yet.
• If user stops typing for 3 seconds (or whatever is appropriate), then autosave happens. Only after all changes are saved does the progress bar disappear. There's some UX work in figuring out an appropriate save delay.

[amisevsk]

Example of the second issue:

[akurinnoy]

@amisevsk

1. The autosave can happen often, which interrupts text input.
2. The editor auto-reformats the devfile on every save, which can totally break it.

You exactly pointed main issues. But increasing the autosave interval will make them happen less often while you're typing but they will always happen on devfile save. Also, you'll have to wait longer for autosave when stop typing.

That's why my first proposal above was to disable autosave and enable 'Save' button.

What I'd imagine for the devfile editor is

• Shows the progress bar at the top of the panel when user is "editing" devfile (i.e. as soon as any change is made). The bar signifies to the user than not all changes are saved yet.

I'm not sure it's a good choise because currently a progress bar in Dashboard indicates that UD has already started an API request.

• If user stops typing for 3 seconds (or whatever is appropriate), then autosave happens. Only after all changes are saved does the progress bar disappear.

Users may be confused what kind of request has been started on keypress in editor and why it lasts for e.g. 3+ seconds.

[akurinnoy]

@amisevsk

Example of the second issue:

AFAIK this issue is already in progress.

[akurinnoy]

@slemeur hello,

I'd like to know your thought on this issue.

[amisevsk]

@akurinnoy You make a good point; the more I think about it the more I think disabling autosave and instead showing a save button is better UX.

[akurinnoy]

@sunix @slemeur

Do you have any objection to disable autosave in favor of save button?

[AndrienkoAleksandr]

+1 to disable, but it would be nice to have hotkey, f.e. Ctrl +S to save defile.