User Preference Specifications

[fjacon]

• Filtering preferences interface only (email, password etc. kept separated in the existing account page)
• Create new account menu entry + new “filters settings” page with activities and regions switches (icons - all ON by default) + region switches:
  • Activities: all ON by default ? or all OFF by default to show there is no activity filter activated yet (would be more consistent with regions)
  • Regions: a map with a vector layer showing the regions, hovering a feature would make the region name appear, clicking a feature would toggle on/off the filtering on this region.
  • Toggling on/off an activity or a region would make a request to the API feed filters service.
  • When loading the page a request to the API feed filters service would retrieve the list of filters of the current user.

Todo:

• [x] Add a route/view/template/menu entry for the filters settings page
• [x] Create a directive for the activity switches (with read/write access the API service)
• [ ] Update the map directive to enable and show a region vector layer with hovering and click interactions + read/write access to the API service.

Relies on https://github.com/c2corg/v6_api/issues/402

[asaunier]

@tsauerwein made me realize that v5 region filters also include countries and administrative areas (FR departements or CH cantons) in addition to ranges. I think ranges are most of the time enough, but yes there are cases where the other region types are useful. For instance if you leave in a place where no range has been defined yet (but then it probably means there are not much activity in this area). Or if you only want to see the outings in Valais.

It's not that easy to display all 3 types of regions at the same time in a map (or maybe by displaying each type in a distinct layer? but then you might not see that a region is selected if the layer is not activated). On the other hand it's more intuitive (you figure out easily what regions are interesting for you even though you don't know the name on c2c and see the exact limits of the regions).

A problem of a region text selector is that it might take quite a lot of space in the page since there are many regions: 678 according to http://www.camptocamp.org/areas (among them 90 ranges http://www.camptocamp.org/areas/list/atyp/1). We could use tabs and scrollbared sections but then again you might not see that some region is selected?

If using a map selector, it's probably a good idea to only retrieved simplified geometries of the areas!

Since there is quite a lot of regions, I wonder if this preferences page should not be redis-cached on the UI-side with the list of areas retrieved by a UI-server-side request to the API (one for all). Then the client-side would only make API requests to get/update the user-related list of prefed regions.

[tsauerwein]

It's not that easy to display all 3 types of regions at the same time in a map (or maybe by displaying each type in a distinct layer? but then you might not see that a region is selected if the layer is not activated).

These are the main problems I see with the map.

We could use tabs and scrollbared sections but then again you might not see that some region is selected?

We could display the selected areas in a separate select box, so that it is easy to see which areas are selected. You could then also unselect areas in this box.

[asaunier]

Arf, this regions selector looks way more tricky and complicated to build than I expected!

Existing solution in v5

• Regions are listed in multi-select lists
• Region types are splitted into 3 dedicated tabs
• Each tab is fed by a dedicated Ajax request
• When switching to another tab, unsaved selections in the source tab are lost.
• It seems not possible to select regions from different types at the same time.
• Within every list, regions are grouped in bigger regions (eg. continents etc.). Those groups are built using a config file, see https://github.com/c2corg/camptocamp.org/blob/1e60b94803765ca09fba533755dad0ecd4cad262/apps/frontend/config/app.yml.in#L761-L1530
  • The region names are probably retrieved from the DB but the list building is done using this config (which mean that if a new region is created - not possible in the UI - it must be added to the config as well).

A few remarks:

• I guess most of those regions are not actually used in user prefs, perhaps only a small subset is useful
• It's not very easy to understand what are the limits and locations of some regions (especially ranges, since they are not really official, their bounds have sometimes be defined by C2C).
• It's not very user-friendly to use multi-select lists because some user don't know how to select several item at the same time, especially with a mobile phone screen (checkboxes are more intuitive).
• not possible to select several region types at the same time (but no one has ever complained, perhaps no one need to do so).
• using a massive and not convenient config is required to build the groups

For v6

• we need an easy way to select regions: checkboxes or graphical selection on a map
• we need to make the selected regions obvious => recap somewhere the selected regions?
• if using a map: should be fairly easy to use on a mobile phone => full screen map (same problem actually than for the advanced search, see https://github.com/c2corg/v6_ui/issues/657)
• if using region lists:
  • as suggested by @tsauerwein we probably need a kind of tree with folded/unfolded branches
  • what about mixing all region types in the same tree? The first nodes would be "ranges", "countries", "admin".
  • how can we build a tree with dozens of branches and ~700 leaves? Is it OK to have all the items loaded at once or only when unfolding a branch?
  • could we use some solution as in geospatial tool (eg. GeoMapFish, https://map.geo.admin.ch/ or others?)
• should we use some kind of search tool like the association tool? Or a kind of advanced-search tool where users could see the geometry of the regions and apply search filters?

[tsauerwein]

I think the component should consist of three elements:

• A tree or a component like in v5 where you have three tabs with groups.
• A search to directly choose an area using its name.
• A box where you see the selected areas, and where you can unselect areas.

This would allow to select an area by searching for the name but also to explore areas if you are not sure about the name. And with the box showing the selected areas you know exactly what you have chosen.

[asaunier]

Not bad indeed :)

[asaunier]

• A tree or a component like in v5 where you have three tabs with groups.
• A search to directly choose an area using its name.
• A box where you see the selected areas, and where you can unselect areas.

This proposal makes sense indeed.

But I have several concerns:

• it's quite complicated to implement (and we have not much time to do it)
• it's a bunch of data to get (678 areas!)
• so that it's user-friendly enough, we would need to group the areas within "bigger areas" like in v5, BUT those bigger data do not exist in the DB (in v5 a verbose YAML config is used, see https://github.com/c2corg/camptocamp.org/blob/master/apps/frontend/config/app.yml.in#L761) or use a graphical UI (map, tree, etc.)

I wonder if a good compromise (could be improved later) would not be to:

• skip the areas lists
• only provide a search tool (based upon the simple search / association tool already existing but filtered on areas)
• we would have a list of cards listing the selected areas (as for associated routes for instance) => a bit like associating areas to a user => it would be possible to "associate" or "deassociate" an area as usual.
• would need some changes described at https://github.com/c2corg/v6_api/issues/419

Sounds reasonable?

[tsauerwein]

For me, yes. We can still improve it later.