Re-order default list by location

[acka47]

Currently, people are quite confused by the order of the result list on http://lobid.org/organisations/search. It would be great if people were asked for their location and the results were sorted with nearby organisations first.

[fsteeg]

Deployed to staging.

Reliability seems to depend on different aspects like OS, browser, network, HTTPS.

1. Open Javascript console: Shift + Ctrl + I
2. Go to https://test.lobid.org/organisations
3. Confirm to share your location
4. Search anything

Results should be sorted by distance to current location. Errors should be logged to the console.

Location data is stored in the session, so restart browser for a clean test.

[acka47]

I get errors in the console ("PositionError {code: 2, message: "Network location provider at 'https://www.googleapis.com/' : Returned error code 403."}"). I thought that the problem might be not being logged into google. But logging in didn't change anything. This problem has been occuring for some years in different browsers as a quick Google search suggests. There are other options to retrieve the position, see e.g. http://stackoverflow.com/a/32338735.

[acka47]

When we have this problem sorted out, I would be happy if the map could reflect the currently shown – not returned – search results so that it zooms in to show the 20 institutions nearest to the searcher.

[fsteeg]

Deployed to staging: http://test.lobid.org/organisations

The free http://ipinfo.io fallback support only non-HTTPS calls.

So with general HTTPS redirects (see #263), this fallback would never be used.

[acka47]

I am not yet satisfied with this. It is a bit confusing that the facets refer to the result list as a whole while the small map view doesn't. A solution might be implemented by a map zoom on the viewers position, loading only the organisations to be seen inside this part of the map and loading the other places in the background while the user can already interact with the page.

Thinking a bit more about it, here is a proposal for a different approach:

• We remove the distinction between search vs. browse.
• On the home page, we have the search interface without the small map in the upper left corner. This enables quick loading of the result list with nearest institutions first shown.
• We enable switching between list and map views of the search result via tabs inside the homepage. (probably on the upper left of the result list) while facet and search bar stay untouched at their place.
• The map can load in the background and people can start looking/interacting with the result list. When they switch to the map they see a zoom with 5 km radius or so from their position.

IMO, this approach has at least two advantages:

1. The UI gets simpler.
2. People have the possibility to view and interact a much bigger map.

I can not really see any disadvantages besides the fact, that the map may still be loading when people switch the tabs. For speeding up loading of the map, @literarymachine recommended gzip compression, see hbz/oerworldmap@a5634d1.

[fsteeg]

This is a major change in the UI that brings up different issues (where does the current starting page content go, page structure would change, the map would become totally different in size etc.), so this should be a separate issue, and we'll have to see if we can build a good solution until Thursday.

For this issue, the question then is: do we deploy this with all markers or for the current page only?

About the compression: the data transfer is not the issue, it's the client side rendering of all the pins.

[fsteeg]

Will deploy a variant later that loads the pins for the current page first, and the others in the background.

[fsteeg]

Initially load pins for current page only, load remaining pins in the background, keep map zoomed in.

Deployed to staging, see: http://test.lobid.org/organisations

[fsteeg]

Tweaked behvior on staging: load not only pins for the current page initially, but up to the current page.

This avoids initially disappeared pins when paging throught the results.

http://test.lobid.org/organisations

[acka47]

Loading https://test.lobid.org/organisations/search still takes ~2s which is too long IMO. Nonetheless, the sorting is implemented and it loads fastert than now on production. Thus, +1.