Too easy to switch away from save side-dialog without saving

[risicle]

Hi,

The other night at a mapathon I had a new user faithfully regularly hitting save all evening, but each time not noticing the side dialog and thus never hitting the actual save button, assuming the top "save" button did what it said. This resulted in a full evening's work being lost.

Could be solved by something as simple as a dialog warning them if they switch away from the save-mode without saving. Preferably with a "don't warn me again" option.

[jfirebaugh]

I think this is a legitimate usability issue, but I'd like to hear some suggestions about how to address it other than adding a warning dialog. My guess is users who don't read the save dialog are likely not to read a warning dialog either, and such a dialog would penalize the legitimate workflow of correcting validation errors or making other last minute changes. (I have a heuristic that says any time you think "let's add a dialog with a 'don't show again' checkbox", you should keep thinking until you come up with a better solution.)

[KathleenLD]

Another way to address this would be by notifying users who have a "large" number of unsaved changes, either with an alert (something not too intrusive, that doesn't have to be dismissed to keep editing) or even just a color-change in the unsaved change counter.

Since selecting the number of changes that should trigger the alert might be rather difficult, "time since last save" might be another metric to consider?

[Eitz]

Why not open up a modal asking for the description of the edits when the button is pressed?

Right in the middle of the screen.

And if you keep the modal without a shady background, the info in the dialog to the left could still be there. Also, if there's warnings/errors don't let people click the save button again, or add a check-box saying "I understand that there's errors" or something like that.

[bhousel]

Why not open up a modal asking for the description of the edits when the button is pressed? Right in the middle of the screen.

I agree that moving everything from the save pane into a lightbox would be an improvement..

[jfirebaugh]

Saving was originally done via a modal dialog; we moved away from it by design. See #1526, #564, #1562.

I think we can fix the usability issue here without the disadvantages of a modal interface.

[risicle]

Had the same event again last night and this time two people lost their entire evening's work and three more very nearly did (luckily no conflicts in these cases) because they made the same mistake.

[KathleenLD]

Any opinions (good or bad) on my suggestions regarding addressing this issue prior to reaching the Save dialog? That way if someone hasn't successfully saved they will still see some UI indicator that tells them that.

[danstowell]

@KathleenLD personally I agree that it would help a bit if the number-of-changes box could do something like go bold+red after 30, or something like that, with a tooltip available to explain that it's because it thinks you should save now...

[risicle]

Had another HOT mapathon the other night. This time there were about 4 people who lost a large amount of work because they didn't notice the relevance of the side-dialog. This problem isn't going away. Work must be being lost every day.

[danstowell]

Thinking about it, it is actually quite odd for the save dialog to be non-modal - compare it against the workflow in most desktop apps, where you press "Save" and you have a modal interface forcing you to complete or cancel the save action. These are the interfaces that our users will already be familiar with. It seems from @jfirebaugh 's comment above that the non-modal version was chosen because it allows review of changes, copy-paste of names, etc. However it fails to do what modal dialogs are intended to do, namely force the user to complete (or cancel) the action.

One possibility might be: do not allow the user to EDIT (or maybe just CREATE) any objects while the save panel is active?

@jfirebaugh: it might be helpful to understand what you see as "the disadvantages of a modal interface" in this specific instance? I do understand the usability arguments for non-modal interfaces in general, but here we may be able to keep some of the benefits of nonmodality (e.g. let the user copy-paste) and of modality (prevent Task Completion Error).

[jase88]

@danstowell As far as I understand this issue, it is not about how the saving interface is presented, but about the user-awareness that you need to hit a button to save your changes. This is what all OSM editors are doing: you need to hit a button to save after you made changes. The difference between iD and other editors is that the users are warned that their changes haven't been saved until now. This is about loosing data as well as conflicts that might raise if your editing a lot over a long period. Ideas, proposals or discussions about a different saving dialog might better fit in a new issue (or a existing one).

[danstowell]

@kerosin - I disagree. This github issue is about users pressing Save in iD but not realising they need to press the second Save button (see original message) - this issue is not about users failing to realise they need to save.

Editors such as JOSM and Potlatch2 show a modal dialog when you press Save (and this is a pattern that users will be familiar with from standard apps, even though the role of it is a bit different) - this modal dialog is the mechanism that prevents the current issue from arising, i.e. prevents the two-stage saving process from being abandoned half-way through by accident. It's not necessarily the only solution, but I've argued that it's a good choice.

[jase88]

Oh yeah, sorry my fault misunderstood this and had a closer look at iD. Imho a sidebar doesn't differ to much to a modal/dialog box expect the position on the screen. The bad thing is that your able to continue mapping in this context. Like already said at this point it makes sense to force the user to finish his action. I would blur the map and disable all controls. Of course a color change could improve this too. At the moment the only thing happening: focus on changeset description and a big save button. And if you're continuing the only thing that is making you attentive is that there is count of changes next to the save button.

[bhousel]

I've replaced the close 'X' with an actual Cancel button, which should be clearer to new users. We don't have any keys bound here (like escape) so as far as I know the only way out of this panel is to click the Save or Cancel button.

Before	After

[danstowell]

There's a third way "out" of the panel, which is to ignore the panel and carry on editing. That's the problem we saw recurring, and your change doesn't seem to address that. It looks to me like an improvement in itself, but I don't see how this prevents the error described in this issue?

[danstowell]

@bhousel no wait, I spoke too soon. I've poked around in iD and I see how it makes it clearer. When the user tries to "make their next edit" without having completed the save action, they are then confronted with the idea of cancelling rather than just "pressing x". Thanks.

[bhousel]

@bhousel no wait, I spoke too soon. I've poked around in iD and I see how it makes it clearer. When the user tries to "make their next edit" without having completed the save action, they are then confronted with the idea of cancelling rather than just "pressing x". Thanks.

Yes that's a relatively recent change, I removed a bunch of behaviors from save mode with 80f5f65, so users can't make changes or quit save mode while the conflict resolution is happening.