Toggldesktop: Editing a time entry is destructive

[donquixote]

💻 Environment

Platform: Linux
OS Version: Ubuntu MATE 18.04
Toggl Version: 7.4.528

🐞 Actual behavior

Using the scroll wheel changes the focused element, e.g. date, start/end time.
Changes are saved immediately, with no option to undo.
This is highly destructive.

💯 Expected behavior

Scroll wheel should not have any effect (it is too likely that people just fiddle around with it).
There should be "save", "cancel", "reset" options, instead of saving immediately.
Modified fields should be visually highlighted in some way.
There should be an undo function, perhaps even some kind of versioning / revisions.

🔨 Steps to reproduce

Click on a time entry to edit.
Use tab to navigate around between the input elements.
Use the mouse scrollwheel.

📦 Additional info

This has always been a problem in the Linux desktop app.

It is one of the basic principles of interaction design to not destroy or jeopardize the user's work and data. And in this case, the numbers can equate to real money!

[Leland]

2695 was supposed to have introduced undo functionality with eg Cmd-Z

[donquixote]

2695 was supposed to have introduced undo functionality with eg Cmd-Z

I confirm that Ctrl-Z (on Linux) undoes changes in the textfield.
But not in the other input elements.

Also the main problem here is you can do accidental changes and then don't even know what you want to undo..

[Leland]

I'll note that I proposed moving away from an automatic updating model in #2470, but it was closed. I'd prefer, like you've proposed, an interface that requires a button press or an Enter key to commit changes.

I suppose that's up to Toggl's discretion, however.

If they intend to keep that approach, it seems like at the bare minimum supporting undoing all changes with Ctrl/Cmd-Z is a must.

[donquixote]

It is too easy to send a time entry into the previous year, and then never find it again..

[donquixote]

Interestingly, I had an email exchange once in the past with the support, and someone there agreed with me ..

[donquixote]

Also found some QAs on stackexchange, but not sure if they are helpful. Perhaps they are mostly about settings forms.
https://stackoverflow.com/questions/3066108/usability-save-changes-using-apply-button-or-after-every-single-change#3066181
https://ux.stackexchange.com/questions/12289/guidelines-for-when-to-auto-save-settings-vs-save-button?noredirect=1&lq=1
https://ux.stackexchange.com/questions/37602/saving-global-save-vs-sectional-save-vs-item-save-vs-instant-save

I would say the main criterion for whether "instant save" is a good idea is whether the controls are operated with intent and awareness, and the before/after is fully transparent to the user. Another criterion is the possible damage and recovery options.

Toggl time entries are especially problematic, because

• changing the date can move a time entry into a place where you cannot find it easily afterwards.
• the same UI is used to inspect a time entry and to modify it.
• various kinds of input can modify the time entry.
• there is a risk of _delayed mode changes_ which change the effect of input events.

To the last point:
While looking at the list, scroll wheel means to scroll up and down, which is a zero-risk operation.
In the edit view, the scroll wheel can modify data.
Mouse clicks also have different effect in the list view vs the edit view.
Changing between the list view and the edit view can be delayed due to a sluggish network. This means a click or scroll event intended for mode A can then actually fire in mode B, causing an unintended effect.

This has happened to me more than once: In edit mode, I clicked "Done", nothing happened, I was impatient and wanted to click "Done" again, but while I was clicking it went into list mode, so the click opened another time entry for editing.

I doubt that the "instant save is better" principle applies in this scenario.

[IndrekV]

Thank you for the detailed feedback. We'll take another look at the editing and reverting logic. I think that instant save is a great logic, but there should also be a way to discard changes when user has not stopped editing an entry ( has not closed edit popup for the entry )

[donquixote]

For my taste you could simply get rid of the instant edit in the desktop client edit dialog.
Then:

• if nothing was modified, simply provide a "Cancel" button.
• if something was modified, show "Save", "Cancel" and "Discard changes".

a way to discard changes when user has not stopped editing an entry ( has not closed edit popup for the entry )
with or without the instant edit, it could be useful to have a global "changelog" where you see a log of manual changes on all time entries.

The discard option in the dialog itself can be useful, but I think there may be cases where a user does not notice they modified anything.