Map interact-ability isn't consistent while editing a feature about data-collection-dotnet HOT 7 CLOSED

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.

from data-collection-dotnet.

^ 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!

from data-collection-dotnet.

@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?

from data-collection-dotnet.

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?

from data-collection-dotnet.

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.

from data-collection-dotnet.

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)?

from data-collection-dotnet.

@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.

from data-collection-dotnet.