Map interact-ability isn't consistent while editing a feature

Esri / data-collection-dotnet

Data collection application built using the .NET Runtime SDK.

https://developers.arcgis.com/

Apache License 2.0

23 stars 30 forks source link

Map interact-ability isn't consistent while editing a feature #81

Closed mikewilburn closed 5 years ago

mikewilburn commented 5 years ago

This occurs on both WPF and UWP.

Repro steps:

Click a map feature to select it
In the detail view, click the 'Edit Feature' or 'Add Attachment' button to begin an edit session
Notice that you can still interact with the map (both panning & zooming is permitted)
Notice that you cannot update the feature selection on the map:
- Either click a different feature to attempt to select it, or
- Click off the currently-selected feature to attempt to de-select it

While toggling a feature selection probably doesn't make sense while editing, it feels a little odd to permit some map interact-ability (pan & zoom), but not others (selection). As well, while you're in the 'Edit Attachments' detail view, it's not overly obvious that you are actively editing other than the fact that the 'Edit' & 'Delete' buttons change to 'Save' & 'Cancel'.

mikewilburn commented 5 years ago

^ It occurred to me that the previous issue title wasn't an accurate statement of what needs to be resolved. @nCastle1 let's work together to conceive of an appropriate solution to this, or confirm that the current behavior is permissible!

nCastle1 commented 5 years ago

@mikewilburn I think this is part of the design of the app and not a bug. Maybe the design should be changed but I wouldn't hold back the release on that.

Maybe adding an overlay on top of the map view would make it clearer that editing is in progress? Is it OK to obscure the map while editing a feature? Native iOS uses navigation so you can't interact with the map while editing, but I don't know if that makes sense on desktop/tablet.

@esreli Thoughts?

mikewilburn commented 5 years ago

You're right, probably doesn't make sense on desktop to entirely obscure the map. Is there a platform paradigm you can think of that we can follow to prevent the map from appearing unresponsive as it concerns selecting/de-selecting when in this mode?

nCastle1 commented 5 years ago

We can change the cursor, that probably gets the point across on desktop. A light blur or greying out the map is probably the best option on tablet but is also totally reasonable on desktop.

Alternatively, we can prompt the user to either save or cancel edits, then proceed with the identify.

mikewilburn commented 5 years ago

we can prompt the user to either save or cancel edits, then proceed with the identify.

I thought about this too, but are we able to discern a map click where the user is attempting to identify vs. pan or zoom? I suppose it's a single-click (identify) vs. a click-and-hold (pan) or double-click (zoom)?

esreli commented 5 years ago

I believe this is as designed. A perk of a desktop design is more screen real estate. With this in mind, I think it's absolutely appropriate to allow interactions with that map that are not selection. I would suggest the app is fine as-is.

mikewilburn commented 5 years ago

@nCastle1 and I met to discuss this today and we agree that while there's others ways we could present this behavior, this isn't necessarily incorrect the way it's presented today. Closing this as designed.