<< back to Maps in Openplans

Keeping things item modal (and some notes on saving workflow)

One ambiguity in the design specs so far concerns the idea of modality in the UI.  When is the user allowed to edit features?  Add comments?  Move them?  Some parts of the spec, like the descriptions of the different popup options in the "Note tags details and options" section of maps-part-1 , implicitly set up item-specific edit and view modes.  In other places, like in some parts of google-maps-in-openplans , there seems to be a reference to a map-wide edit mode.

Geoserver/Design Team Dictionary
Geoserver	Design
"feature"	"item"

There are a small number of different map operations that we are considering at this point:

1. Adding a note
2. Editing a note's content (or title, or other non-comment properties)
3. Adding a comment
4. Editing a comment
5. Moving a point
6. ***Deleting a point*** (not discussed originally, but may need some thought)
   

In a conversation today, Nick expressed the following preferences:

• Having different modes is not good
• To the extent that item specific modes are possible, they are better than global modes

The question we asked was: How can we divide up the different map operations to conform as well as possible to Nick's preferences?  Here were our conclusions:

(2) can naturally be done in an item-specific feature mode within a popup, a la Google Maps and the UI spec that's already been given.

(3) and (4) can be done in an item specific way within the sidebar (with some sort of link for opening the sidebar from a popup)

(1) has been speced out in maps-part-1 with an "add note" button.  It doesn't make sense for this to be item specific, so this needs to be a global, but obvious, mode/tool.

The difficult decision was concerning (5)--moving a point.  On the one hand, modes are bad, and we don't want the UI to get in the user's way.  On the other hand, a simple click/drag interface for moving notes could lead to something like accidental moves.  This becomes an especially difficult issue when we talk about when an action on the map is permanent, as opposed to buffered.

Tangent: Saving workflow

Question here.  We haven't talked about the case when several users are editing a single note at the same time.  On the one hand, this possibility might be precluded by allowing users to edit only those notes that they "own."  But it may be that this constraint is too strong.  Do I edit a map as an individual, or as a representative of my project?  Doesn't it makes sense for anyone in a particular project to edit notes on a map, in some cases?  Or is that going too far into wiki-land for the earlier releases?

One of the open questions left by the original spec is when and how transactions should be sent to geoserver.  There are several UI implications and constraints surrounding this technical question, the most important of which probably being the ease with which a change is "undone."  Because multiple users may be editing the same map (and note!)­, the naive undo solution, reverting back to the immediately previous version of the map, may have unexpected consequences.

Nick and I (Seb) talked about this today as well, and Nick's recommendation was that transactions would neither be done automatically without user input or with a global "Save" button (as Google MyMaps uses).  Rather, "Saving" should happen when a feature-specific action is taken by the user.  In the content editing operation (2), that means having a save/OK/form-submit button in the popup itself.  And so on for (3) and (4).  For adding a point, (1), the solution is slightly less clear, but since upon placing a point a popup should emerge from the note, the opportunity to save or cancel in a feature-specific way can easily occur then.

Once again, moving points (5) is the challenging case, since moving has so far been conceived of as an operation that takes place in the global map context, as opposed to "within" a feature.

Proposed solution: item-specific move mode

During our conversation, we came up with the following option.  Rather than having the feature moving operation contiguous with the global map viewing "mode," we could have an item-specific move "mode" accessible through a feature's popup.  A popup could have a "move this note" link on it, which shrinks the popup down to a tiny size (perhaps with a button or two for "Done" and "Cancel") and then allows the user to move the note.  It could be moved either with a click-drag-release workflow, or the feature could "become" the cursor, as when one adds a pointer in MyMaps.

Since this item-specific move "mode" comes with a button to trigger the item-specific geoserver transaction, this kills two birds with one stone.

A much better solution for this is to not have the user ever enter an item-specific mode, but rather just ask them to go through an item-specific (within a popup) OK/CANCEL decision dialogy upon dragging.  This prevents accidental edits (the same way as the delete dialog prevents accidental deletes) while requiring only a single click of extra workflow and minimizing funky new widgits.  Unless there are any objections, I think we should go with this.  Nick has rubber stamped it.  -- Seb