Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
4 of 23 tasks
sunix opened this issue Jul 23, 2019 · 16 comments · Fixed by #14913
Closed
4 of 23 tasks
Assignees
Labels
kind/bug Outline of a bug - must adhere to the bug report template. status/in-progress This issue has been taken by an engineer and is under active development.
Milestone

Comments

@sunix
Copy link
Contributor

sunix commented Jul 23, 2019

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
  • 7.0.0-next
  • other: please specify

Runtime

  • kubernetes (include output of kubectl version)
  • Openshift (include output of oc version)
  • 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

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

Environment

  • my computer
    • Windows
    • Linux
    • macOS
  • Cloud
    • Amazon
    • Azure
    • GCE
    • other (please specify)
  • other: please specify
@sunix sunix changed the title Dashboard: Editing a devfile of a workspace is constantly interrupted by the auto saving Dashboard: While editing a devfile of a workspace, user is constantly interrupted by the auto save Jul 23, 2019
@sunix sunix added the kind/bug Outline of a bug - must adhere to the bug report template. label Jul 23, 2019
@vitaliy-guliy
Copy link
Contributor

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
Copy link
Contributor Author

sunix commented Jul 24, 2019

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

@sunix sunix added the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Jul 24, 2019
@vitaliy-guliy
Copy link
Contributor

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

@nickboldt
Copy link
Contributor

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
Copy link
Contributor Author

sunix commented Jul 25, 2019

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
Copy link
Contributor

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 nickboldt removed the status/need-triage An issue that needs to be prioritized by the curator responsible for the triage. See https://github. label Jul 31, 2019
@nickboldt
Copy link
Contributor

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

@akurinnoy
Copy link
Contributor

@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?

@akurinnoy akurinnoy self-assigned this Sep 27, 2019
@akurinnoy akurinnoy added the status/in-progress This issue has been taken by an engineer and is under active development. label Sep 27, 2019
@amisevsk
Copy link
Contributor

@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
Copy link
Contributor

Example of the second issue:

devfile-editor-2019-09-27_11 06 27

@akurinnoy
Copy link
Contributor

@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
Copy link
Contributor

@amisevsk

Example of the second issue:

AFAIK this issue is already in progress.

@akurinnoy
Copy link
Contributor

@slemeur hello,

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

@amisevsk
Copy link
Contributor

@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
Copy link
Contributor

@sunix @slemeur

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

@AndrienkoAleksandr
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/bug Outline of a bug - must adhere to the bug report template. status/in-progress This issue has been taken by an engineer and is under active development.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants