Proposed alternative to trash can in radial menu (make "delete" harder to hit).

[brycenesbitt]

This is a proposal to make deleting a feature harder with iD. Or, put another way, to make delete prominent at the "right level" compared to expected editing patterns. First the proposal:

1. Remove the Trash Can from the radial menu. This means when clicking on a POI no radial menu will come up at all. iD would become a bit more opinionated : encouraging the user to first scan the feature's associated tags. Thus the feature removal trash can moves to the bottom of the "Edit feature" pane.
2. Remove the shortcut binding to Backspace. Just because P2 and JOSM have this, does not make it right for iD.
3. Retain the Trash Can in the radial menu, but only for nodes that are part of a way. The trash can removes only the node. When you hover over a way node with tags, it would say "This node has (X) tags, and is part of a larger feature with (X) tags, and (Y) relations". This will help keep people from deleting barrier=toll_both or highway=turnnig_circle, if all they really wanted to do was adjust the geometry of the way. And help new users understand that every node can have tags, even if it is part of something larger.

---

In general this will allow the radial menu to control only geometry, rather than geometry plus existence.

One downside is on features with a lot of tags, since you'll often need to scroll to find the trash can. But I think this is good: if someone took the trouble to add that many tags, perhaps it is only courtesy to force the user to read the tags prior to deleting the entire thing ;-).

[jfirebaugh]

There are editing patterns for which deleting features is legitimate and common. TIGER fixup often involves deleting ways that do not exist on the ground. Deleting stray untagged nodes is another. Removing the shortcut key and burying the delete action at the bottom of a scrolling list would make these tasks tedious.

With regards to #3, iD already displays a feature's tags and relation memberships on hover, in the sidebar.

To be honest, I think the concern about accidental deletion is overblown. I contend that it's much rarer than it's made out to be, and easy to correct when it does happen. That said, I'm open to suggestions of how to gently guide users away from unintentional deletions -- but they have to be weighed against the costs of discouraging legitimate edits.

If you find examples of accidental deletions, please bring the changelists to my attention -- concrete examples will help us understand what mistakes users actually make. I've made this request before, but never gotten a response -- that's part of why I'm skeptical about their prevalence.

[brycenesbitt]

I hope that deleting a pile of ways, without looking at their tags, is the rare case. Deleting an untagged node requires clicking on the node, looking at the tags, then selecting delete. I think that's arguably faster if the trash can is next to the (empty) list of tags!

As for prevalence of editing mistakes: some more data would be needed. A start could be putting on the changeset (not the node!) a editor=P2, editor=iD tag.

[tmcw]

A start could be putting on the changeset (not the node!) a editor=P2, editor=iD tag.

This has always been done by iD, P2, and JOSM.

[brycenesbitt]

Right, @tmcw created_by=iD 1.1.4. Got it.

@jfirebaugh to find 'examples of accidental deletions' is a tall order. To prove one editor or the other has more accidental deletions, and the cause, is an even fuzzier hoop to jump through. iD would have to be out for much longer to even have a shot at deducing any relationship. I don't think you'll get a response to the question as posed. If a shop or toilet is missing from OSM, how would the next editor even notice? If JOSM editors were 23% more likely to delete a node accidentally, what would that mean in terms of software design?

---

But I don't think you have to make the assumption there is a "deletion problem" to want to explore improving iD's deletion behavior. Click on a POI such as a store, and immediately your eye is drawn to the motion on the screen: a largish trash can shows up. It's kind of weird how emphasized deletion is. The UX seems to scream that deletion is the most important action one can take.

A really good workflow for deletion is to select the item, examine it (including tags), and try to fix it. Only if it can't be fixed then consider deletion.

---

In response to 'editing patterns' above:

TIGER editing most emphatically does not involve quickly deleting a bunch of ways. TIGER data may be misplaced, or mis-interpreted, but rarely did the Census workers make up stuff out of thin air. TIGER editing often involves clicking on things, looking at them, and usually moving or reattaching them to more sensible places.

Deleting stray nodes is another case where your visual focus is not on the radial menu in the editing area. You have to glance over and ensure the node is really untagged, not just misspelled (e.g. ammenity=toilets).

Only when changing the shape of a way (by adding and deleting nodes) is your visual focus purely spatial. And above I propose leaving that trash can in the map area in that case.

I think you can achieve great workflow in iD, including delete workflows, with a different solution than presently employed. Make it better for everyone.

[tmcw]

iD would have to be out for much longer to even have a shot at deducing any relationship

There are over 197,000 changesets already created with iD. If this is a systemic problem, you should be able to find one that exhibits it.

Without that, this and other bugs boil down to 'someone we don't know is doing who knows what, and we need to handicap their tools because of our fear'

[brycenesbitt]

No handicap should be implied: this is about making delete workflow appropriately prominent.

Finding an example should not change the debate: a mistake can be made with the most robust of tools. Doing the work to find the example is time not spent mapping, developing, or improving. Seeking such examples smacks of work to prove a point, seeking to prove a pre-held conviction, not really working to make the best overall result.

[jfirebaugh]

to find 'examples of accidental deletions' is a tall order.

That is exactly my point -- that "accidental deletions" and "broken relations" are more a product of fear, uncertainty, and doubt than serious problems that are so widespread that they require significant design and implementation resources to address.

[jfirebaugh]

Sorry for drifting off topic there. To bring it back: I'm not sold on splitting the actions into some that appear in one place and some that appear in another. "Change geometry" vs "change existence" doesn't seem like a distinction that's likely to be part of a new user's mental model.

I'm fine with changing the shortcut to Ctrl-Backspace/⌘-Delete to ensure it doesn't get hit accidentally. I'm also open to reducing the size of the delete button in the radial menu, and bringing back the "Move" operation for POIs, just so delete is not the only item. We'll probably eventually have some form of "Copy Feature" or "Copy Tags" there as well.

That said, I don't think any of these changes should block iD becoming the default. The evidence we have points to accidental deletion not being any worse of an issue than with P2, and possibly better.

[Janjko]

Maybe if you had to click delete two times for distinct features with tags. First you click the trash can on the radial menu (or Backspace), and then a big "Are you sure" comes up on the left side, with a description of what you are actually doing, and a big "Delete" button.

Like how you have to click "Save" two times.

[brycenesbitt]

@jfirebaugh thanks for the CTRL-BACKSPACE patch.

As for the user's eyeballs: what can we do to make the user's eyeballs go to the tags? The question is not "are you sure?" it is "did you even bother to examine this thing you're about to delete?"

Perhaps deleting your own work in this session should remain as it is today, quick and hassle free.

But deleting another mapper's work? That's a pretty serious action, especially given the relatively poor revert capability and associated history loss. That's really the point to educate about "disused", and other topics of map maintenance. JOSM and P2 might not, but iD is taking things to a new level...

[bhousel]

I think this issue can finally be closed

[pmailkeey]

I'm in favour of keeping it as it is - there's always the 'undo' function for erroneous deletions.

Unfortunately, iD is difficult to use with complex objects and deleting and starting again is an easier solution despite some data loss.