Make all features fully interactive

[kelvinabrokwa]

/cc @peterqliu

The way its going to work is you call

var id = Draw.set({ type: 'Point', coordinates: [0, 0] }, true);

initially to set the point (the second argument sets the feature to interactive so that it is always in edit mode). id is the way to unique identify features in gl-draw. When you drag the point around it will fire an event so on your side just something along the lines of:

map.on('edit.new', function(e) {
    if (e.id === id) {
        var location = e.geojson;
        // route to new location
    }
});

[kelvinabrokwa]

The use case for an interactive mode is something I hadn't considered before talking to @peterqliu today but its very common. In a nutshell, a developer using gl-draw can simply set one or many features (say markers) and the user will be able to manipulate these features, perhaps without the ability to draw new ones. Think start and end markers on a routing app.

Working on interactive mode is making me question whether there is a need for different modes at all. Why isn't everything just always edittable? A user is always free to drag features around, resize, and reshape without have to click on it to enter a special mode (the only UI downside to this I see will be in deleting features, but that is surmountable).

Making everything always edittable would kill two birds with one stone by simplifying the codebase a great deal and also making the UI more intuitive.

UI-wise, a feature is simply styled differently on hover and then you can edit as necessary. This will also eliminate most of the functionality of the stores and individual geometry Objects will be responsible for rendering themselves.

As a bonus, this will also come with a nice performance improvement because we'll be switching between gl-js layers a lot less.

I know it isn't the Leaflet draw paradigm we have all come to know and love but I think this is definitely the way to go.

@tristen @tmcw @peterqliu thoughts?

[tristen]

Working on interactive mode is making me question whether there is a need for different modes at all. Why isn't everything just always edittable?

Having not looked at the codebase for some time I'll throw in a rash agreement and say yes! All features should be editable with editing indicators defined in the UI (i.e. hover).

[peterqliu]

Why isn't everything just always edittable?

As a user, I'd enthusiastically want this. But the real question is, what's the performance overhead of keeping all these elements editable?

This is analogous to the discussion about whether GL layers should be interactive by default: either if the performance sacrifice is small enough to be worthwhile, or so negligible that we can make things interactive all the time, and removing the concept of interactivity outright.

[tmcw]

Always-editable interfaces introduce UX issues beyond deletion:

• Tightly-clustered draggable points spread out on a map will prevent the map itself from being dragged and users wanting to drag the map will accidentally move points. This often happens with iD & P2, to the point that we have custom drag handlers that require a minimum drag distance over time, and this is a fuzzy measure that still fails often.
• Draggable polygons that can potentially occupy the entire viewport lead you into a situation where the entire map can be covered by a polygon, and similar to clustered points, you can't un-try-to-drag the polygon to try to drag the map.

Like other cases of thinking about performance before seeing numbers, I'm going to reiterate that that's the incorrect order. But from a UX perspective, we know about some of the potential paths:

• @tristen and @samanpwbb built a /editor that didn't have an "editing" mode that introduced these problems, and we iterated away from it.
• Large polygons in iD have led us to a relatively complex system that allows for feature filtering Polygons beyond the edge of the screen cause confusing radial menu openstreetmap/iD#542 should area fill support pointer events? openstreetmap/iD#324

I'm -1 on this. Route planning is the simplest case: two draggable markers that are naturally placed away from each other. gl-draw's eventual role is as the editor for the dataset api, which has to deal with any kind of data - different shapes, different densities, many shapes stacked on each other - and for these cases removing the modality costs more clarity than it wins in ease.

[samanpwbb]

The best solution would be to give developers control over how features are can be edited. Spend some time with iD (or any vector editing program) and you'll see a lot of different approaches, most of them a hybrid of always editable and focused edit modes. In iD, some features need to be selected first before editing, like polygons, and in other cases (with points and lines) we display nodes and allow direct editing.

If we had to pick between always editable, and always select -> edit, I'd lean towards requiring user to make a selection first. It's the safer approach that has less usability issues, the downside is that it's going to slow users down or feel weird for certain types of interactions.

It would be great if this library made it possible for developers to make those kinds of choices on their own, there is no best UX approach.

[kelvinabrokwa]

@tmcw @samanpwbb @tristen @peterqliu perhaps a compromise can be the ability to toggle between everything being edittable and nothing being editabble (giving the developer the option to disable either of those modes for their app).

[kelvinabrokwa]

I'm going to go ahead and merge this. When a user instantiates draw, they now have the option to keep everything in edit mode always of toggle between drawn and edit (default).

So,

var Draw = mapboxgl.Draw({ interactive: true, drawing: false });
map.addControl(Draw);

will enable the developer to set features than can be dragged, manipulated, etc. but the user can't draw any new features and the set features are always in edit mode.