Make the selected initiative clearly distinguishable on the map

[matt-wallis]

We need to have a concept of "the selected initiative". There are various use cases where this is required:

• when a particular initiative has been selected from the list of search results #72
• when an initiative is selected on the map, by clicking on a marker e.g. #85

The selected initiative should be clearly distinguishable from others. It should not be within a 'cluster' (a number of the map instead of a marker), regardless of the map zoom level.

We need to consider also if more than one initiative can be selected. Some possible use cases in the future:

• select more than one initiative in order to declare that they are sameas one another. This would only become relevant whe we can update the triplestore (in particular the triples that declare sameas relations)

[matt-wallis]

There are comments in #72 that may be of use when implementing this feature.

[matt-wallis]

Consider: Have a marker that is used solely to represent the selected initiative. Call it selected initiative marker. It may have its own distinctive icon, which may be bigger than usual, or have a distinctive shadow. The selective initiative marker should:

• be on top of all others (z-index)
• not be a member of a cluster

When an initiative is selected, what should we do with its 'normal' marker? If we hide it, and it is clustered, will the cluster-count mysteriously (from the user's point of view) be decremented? Perhaps, if the selected initiative marker completely obscures the 'normal' marker, then we need do nothing.

How much 'baggage' would need to be transferred from the 'normal' marker to the selected initiative marker? e.g. popups and hover text?

Probably best if the selected initiative marker is created when an initiative is selected, and destroyed when it is de-selected. That also permits more than one marker to be selected.

An interesting use-case for selecting more than one marker is the case where the user wants to say that 2 markers represent the same initiative (i.e. a sameAs relationship exists). Typically, these will be co-located, so it is probably best if all selected initiative markers belong to a cluster.

[matt-wallis]

Something else to try out for selected markers: Permanently show the tooltip (i.e. the name of the initiative). See Leaflet ToolTip, option permanent.

[matt-wallis]

How does an initiative become selected/deselected?

By clicking on its Marker

• If the ctrlKey is pressed on click, then the initiative is added to the set of selected initiatives.
• Otherwise, current selections are de-selected.

N.B Muli-selection is desktop-only, but that should be fine for the 'advanced' feature of multiple selections.

Implementation note: Leaflet's MouseEvent provides access to the original DOM event, which has a ctrlKey property.

Note: When a marker is clicked, we do not want to automatically zoom and pan to the Marker.

By being chosen from Search Results

On clicking an item in the search results, the corresponding initiative becomes selected. All other selected initiatives are de-selected.

By being the only item in the Search results

This is equivalent to the sole search result item being clicked.

By being revisited in History

This assumes that

• On selection, initiative details are displayed in the sidebar
• and that this sidebar display is included in the same sequence of history as the search results.

The above is not yet implemented.

In this case, it is doubtful that we'd want the map to pan and zoom to the icon when the history item is revisited, because the user may have carefully set up the map pan/zoom only to find that is disturbed by using history navigation. However we do need to provide a mechanism for the user to pan/zoom to the selected iinitiative after its details have been displayed in the sidebar via history navigation. Maybe just click on the sidebar display? Or have a button?

This needs careful thought, particularly to bare in mind behaviour on small devices, where the map and sidebar are not displayed simultaneously.

When an initiative is selected via sidebar navigation, we would also need to de-select any initiatives that are selected prior to the action.

Conclusions

• Initiative selection does not necessarily mean zooming and panning to the initiative. Experimentation here is required, but this flexibility should be built into the design.
• We need to implement this logic in one place. That place needs to listen to several events that distinguish between the various (input) actions that can cause initiatives to be selected and de-selected. It can then perfom actions (e.g. by emitting events) that implement the appropriate action to be taken. Actions include:
  • managing the set of selected markers
  • changing icons (and the clusters they belong to)
  • displaying in the sidebar
  • zooming and panning the map
  • controlling whether the sidebar is displayed

[matt-wallis]

Implementation

The history is maintained and accessed by presenter/sidebar/search.js. This is the obvious place to handle all events relating to search results and initiative selections. But it needs to be renames to reflect this: presenter/sidebar/sse_initiatives.js.

Similarly, the module currently called view/sidebar/search.js should be renamed view/sidebar/sse_initiatives.js.

In both cases above, the modules contain functionality relating to the search box. This should be moved into a new module {presenter|view}/seachBox.js.

The presenter for sse_initiatives then deals with sets of initiatives:

• The sets may be the result of either searches of selections
• When there's exactly one initiative in the set, the presenter will instruct the view to show that initiatives' details.
• When there's more than one initiative in the set, the presenter will instruct the view to show a list of initiatives.
• Handling events that correspond to:
  • new search results are available
  • initiative marker clicked
  • history buttons
  • todo: complete this list
• Raising events when initiatives are selected or de-selected. There should be a separate event that triggers panning and zooming of the map, as this does not necessary follow when an initiative is selected.
• todo - complete this

[ColmMassey]

Looking good. Large Screen Feedback: The history is working nicely - quite powerful. It creates an expectation that the map should zoom to visualise those selected in the remembered search. This however may not be appropriate. What might a zoom to selected option look like? Mobile Feedback: When in the sidebar, can the icon to touch to return to map view be a map icon? See zoom to selected idea here

[ColmMassey]

This works. Closable?

[matt-wallis]

This works. Closable?

We still need to add the button to the sidebar that zooms/pans to the initiative(s) in the sidebar. Or is that a different issue?

[ColmMassey]

Ok, lets keep it open until that is there. Slighty related. On a mobile, the close sidebar button is very small. It requires care not to press the settings button beside it. So either, can we make it slightly larger, or move the other button away, to the other side, of the bar, perhaps?

[matt-wallis]

On a mobile, the close sidebar button is very small. It requires care not to press the settings button beside it. So either, can we make it slightly larger, or move the other button away, to the other side, of the bar, perhaps?

Can you raise a separate issue for this?

[ColmMassey]

I think this is no longer relevant with new designs for how the panel will work. @joebillings