Deleting features accidentally is too easy

[m-kuhn]

Right now there's a trashcan button that will delete features immediately. The impact can be too heavy to make it the user that easy to mess up things.

Possibilities:

• An undo option would be great because in the 90% where you DO want to delete something it's just one single click.
  E.g., show a message "feature deleted. click here to undo" for 5 seconds. The "problem" is, we try to push changes to the dataprovider as soon as possible and there may be triggers etc. attached, so once deleted it depends a lot on the dataprovider how a proper "undo" should be handled.
• A confirmation dialog. It's always an extra click. So for this, it needs to be easier to delete several features at once (imagine deleting 20 features and confirm every time, that's not a good UX). Maybe a selection could be done and then operations performed on the selection (very common in Android apps).

[nsm91]

What if there was an edit history button. Then one can undo deletes way after the fact but also erroneous attribute edits and such. Simple and fast but also provides for greater functionality overall

[m-kuhn]

That has the same caveats like undo:

• we could use a local edit buffer

  + undo is easy
  - changes wouldn't be saved immediately
  - risk of dataloss
  - extra "save button" click after an edit session

• we could save crud operations.I.e. when a feature is "deleted" it can be "inserted" to undo

  + Undo would work while keeping a commit-fast approach
  - generate new serial primary keys and other default values
  - triggers executed on delete will not easily be undone

• we could maybe integrate some sort of transactions with savepoints etc. Undo would happen on the database

  + Commit immediately possible
  - Unsure if changes would persist in an open transaction on connection loss/crash
  - Will need to be implemented individually per datasource
  o Larger project

[ivankautter]

The problem with the current implementation is that it breaks the essential contract between edit mode with its UI wherein you select a layer to edit or at least digitize features and the user expectations. Digitize mode is for editing. Browse mode is for browsing.

Long pressing in browse mode appears to implement a selection mode for identifying features; however, there appears to be no way to clear this selection set. One literally must quit the app to clear the selection set. A user might believe as I did that hitting the trashcan button would remove a feature from the selection set. Unfortunately, hitting that button deletes the highlighted feature despite there being no declared editing session.

The solution is simple. Long press in browse mode should strictly create a selection set for feature identification purposes. This is an essential GIS function, feature identification. Past this, a button should be implemented either to clear the selection set entirely for all features or remove individual features from the selection set.

Digitize mode should be edit mode. Features should only be permitted to be added and deleted in this mode and only for the feature set that has been chosen from the drop down currently existing in digitize mode. This is the expected behavior in any GIS environment. Only the feature set that one has designated for editing should be alterable and only within an explicit editing mode. In this mode, a long press would select features within a tolerance from the feature set that has been explicitly chosen for editing. From the existing sidebar dialog that has been implemented, features could be deleted but again there should be a specific button that implements a means of clearing this set of selected features.

[m-kuhn]

Thank you for the feedback Ivan. We are actually evaluating to move editing strict to the digitizing mode. I think however, that this will not solve all the problems. Even in a more strict digitizing mode, it is too easy to delete features with just this single button. Something like having to select a feature from the list (long press on the item, maybe possibility to select multiple) and then deleting with a button in the header (possibly with a confirmation dialog) will still be required. I think this is of higher priority than a strict edit mode and that once this is in place, the strict edit mode will need to be re-evaluated. #47 proposes a solution to clear the selection, let's discuss topics individually.

[nsm91]

I agree with Ivan that the delete feature option should not even be visible unless in digitize mode. Also, I feel that since this is a mobile extension of a desktop program, its main function will be data collection, and that editing/deleting data will be a more remote need. As such, within the digitize mode it should still require a confirmation since bulk deletions will most likely be rare operations and not a common concern.

[m-kuhn]

We have use cases where it's only about reviewing features and no features need to be added. For these, it is nicer if the buttons to create new features are not visible.

I haven't seen anything similar concerning delete, but never say never :)

The nicest solution would probably be to define capabilities for each layer individually on the desktop beforehand (add, change, delete).
Unfortunately that is not there yet and we don't have a project with this requirement yet.

I don't have big concerns with moving the delete functionality to digitize only but as you say, also in that case some kind of confirmation will need to be available.

[etiennethomassen]

I also agree that deleting is far to easy. I did exactly what ivankautter described. Expecting that I would not be able to delete anything in browse mode I touched the trash can expecting the feature to be unselected. But it disappeared completely.

I can imagine deleting can come in handy when working in the browse mode. The browse mode is more of an edit feature mode I think. Editting a feature requires I go into edit mode. Deleting does not. Perhaps requiring that plus an are you sure dialog would work?

[m-kuhn]

A confirmation method is in the pipeline. In its first incarnation this will be an "are you sure" dialog.

Moving it to only digitizing is probable to happen too. But this requirement may change based on usability studies and feedback from real life workflows.