Extend user interface and interaction patterns more consistently

[tordans]

Hi, I just watched your presentation at https://www.youtube.com/watch?v=GUii8jWH_so. Great stuff.

One thing I notices is a conflict in the information hierarchy and interaction design.

Current iD Pattern:

• The color of the shape represents the type. Buildings are red. (Border Color + Fill Color)
• The "is selected" state is represented by a different color variation and a blinking border.
• The map panel is used to select and edit a shape
• The context menu on a shape is used to modify the shape
• The left edit-object-panel is used to edit tags

(Source)

You introduce new interaction patterns that are in conflict:

• You use the color of the shape to represent the approval status, which is something very different.
• You add button to the edit-object-panel to approve / reject the shape and show the approval state.

(Source)

What I thing would help …

Your additions to the user interface should try to change the existing patterns as little as possible.
I don't have a solution from the top of my head, but I think this should be considered more closely before adding it.

Some thoughts …
Don't use border color and fill color to show the state (currently yellow, green (and red?)). Instead maybe …

• use a box-shadow?
• add an icon to the shape on the map?
• add action buttons "add", "discard" to the shape on the map?
• add a separate list of shapes with their approval status, but keep the shapes themselves untouched (regular building shapes)
• add a hatching pattern (Example) on top of the existing color pattern (but that does not work for lines)

What is the best place for the "approve" button?
There is nothing like this in iD yet.

• Maybe put them on the shape themselves? Like a on-mouse-over-context-menu? (They should not be part of the context menu, that is too hidden.)
• Maybe go for the list-approach (see above) and have the button there?

What does the "approve" and "reject" button actually do?
The more I think about it the less I understand the general mental model.
The model of iD Edit is, everything on the map is submitted. Your model introduces a in-between-state. Is this really needed? Why not work with a "do" / "undo" pattern – just add the changes to my working space and give me an option to review and undo them (undo also means deleting)

The way I understand it ATM, "approve" actually means "add this shape with those tags to the map for me to submit". So "reject" probably means "delete shape without a trace".

Thats basically why its so hard to find the logical place for the button, it does two things that are separate in ID ATM. Again a +1 for a separate list IMO.

(Further thoughts are required :))

[jgravois]

thanks for the detailed feedback and ideas to improve the design of the feature we're proposing!

openstreetmap#4633

cc/ @briandaviddavidson