Handle WP hierarchy in detail view pages

[asaunier]

_This issue is already mentioned in https://github.com/c2corg/v6_ui/issues/191 but this is a quite important one that deserves a dedicated issue page._

v5 uses some hierarchy amongs some waypoint types (for instance the summits or the climbing_outdoor sites or accesses): http://www.camptocamp.org/summits/42284/fr/aiguilles-de-chamonix-et-envers-des-aiguilles

=> at least 3 levels of parent/child relationships are possible.

Parent/child associations are already supported by the API but in the UI all associated documents are listed linearly. A kind of tree rendering would be useful but not that easy with the card layout. Can we think of an alternate rendering suited for cards?

[asaunier]

at least 3 levels of parent/child relationships are possible.

Actually 3 levels is the maximum. http://www.camptocamp.org/articles/426084/fr/regles-du-topoguide#summit-link-rules

[tsauerwein]

This limit is currently not enforced by the API.

[asaunier]

This limit in v5 is rather a technical limit rather than an organisational choice.

According to @lbesson

il y a deux requêtes dans la base trouve les sommets associés à mon sommet, et trouvent ceux associés à ceux-ci, ce qui permet de construire une hiérarchie à 3 niveaux. Pour des raisons pratiques et de perf, il n'est pas vraiment envisageable d'avoir quelque chose de générique à ce niveau, avec un nombre de requêtes au fur et à mesure

I don't think we need to implement such a limit in the API if it allows to have more levels. But then of course we need to address the hierarchy rendering and the possible performance issues.

[tsauerwein]

Yes, I also think it would make things easier if we only allow three levels. I opened a ticket on the API side: https://github.com/c2corg/v6_api/issues/272

[tsauerwein]

Depends on https://github.com/c2corg/v6_api/issues/132

[tsauerwein]

Can we think of an alternate rendering suited for cards?

In card layouts, if you want to represent some sort of hierarchy, you can make the more important cards bigger (see Material Design Guide - Cards). But I think it will be difficult to represent a hierarchy structure like this one with cards.

Which waypoint types should be shown in a hierarchy? Only summit, climbing_outdoor and access? Or also others?

Should we show a hierarchy like in v5 for these waypoint types, and use a card layout for the other types?

[asaunier]

Which waypoint types should be shown in a hierarchy? Only summit, climbing_outdoor and access? Or also others?

In v5, hierarchy is indeed useful for "summits" (as in v5, ie. also passes, lakes, valleys, etc.), accesses and climbing_outdoors (I think). But in v6, I don't think we'll make special rules depending on the waypoint type, will we? That would make things even more complicated. Then I think we can assume that in v6 any kind of WP can be hierarchically associated. Actually there is no flat associations between WP (unlike for routes), and all WP assocations have a parent-child relationship.

Should we show a hierarchy like in v5 for these waypoint types, and use a card layout for the other types?

As I said above I don't think it is really possible to distinguish WP depending on the types. In addition that would not be consistent to show some associated documents using the usual card layout, and other with some other layout (for instance the tree of links as in v5). Finally, using raw links for instance is not really convenient for using with a mobile device (which is the reason for using cards).

I think we need to stick to the card layout for associated documents.

Your link https://www.google.com/design/spec/components/cards.html# is interesting and could give us ideas about a solution.

First question is: do we really need to show all those 2nd-level associated documents (ie. the siblings)? Perhaps we can simply display only the 1st-level associations:

• all the child-waypoints
• all the parent-waypoints By the way rendering the full tree of associations as in http://www.camptocamp.org/summits/42084/fr/chaine-des-gastlosen might cause performance issues or even not be possible with the current state of the API (do we really get the siblings?).

Second question: if we need the whole tree of associations, do we need to get every branch and leaf in a single API call? What about only showing the 1st-level associations (only parents-children) and make and additional AJAX request to get the other associated documents? Performance is critical when rendering a detail view page, it's probably not relevant to spend time gathering all the associated docs if it delays too much the rendering of the page. The AJAX request could even be triggered only "on demand" by the user?

Concerning the rendering of the associated documents with their hierarchy, here are a few tips:

• for a given document, display its parent(s) and its children in 2 distincts blocks (with a linear listing)
• stack the cards vertically to show the levels ("parent"/"grand parent"). For instance in http://www.camptocamp.org/summits/531111/fr/motteux-peteux we would have first a card for "Chaîne des Gastlosen", then a card for "Dent de Ruth" right below. Do we need to have a kind of card (maybe not clickable and simplified?) for the current document "Motteux Péteux"? In the "middle" summit detail view page "Dent de Ruth" (http://www.camptocamp.org/summits/37509/fr/dent-de-ruth) we would have a card for "Chaîne des Gastlosen" first, then the "fake" card for "Dent de Ruth" right below and a card for "Motteux Péteux" on the next level (right below).
• Perhaps we could find inspiration looking at the way github renders the comments in an issue or pull request => you have the standard comments that are displayed linearly and the comments on a piece of code that are shown as a kind of branch?
• same-level documents (siblings? children?) could be rendered without having a gap between the cards as in the "list" layout on the left side of this example found at https://www.google.com/design/spec/components/cards.html#cards-usage This kind of layout could be used for instance to fold/unfold the list of waypoint-children of the current waypoint? Or the siblings? For instance we would have only the direct parent and children WP shown first. And if you would like to see the other children of the parent (siblings) you could click on some button in the parent card that would embed the siblings inside the parent card.

[asaunier]

A somehow related issue: in v5 the detail view page of a summit lists all the routes directly associated to the summit itself AND ALSO all the routes associated to the children summits... The "2nd-level" associated routes are then prefixed with the name of the child summit. See for instance http://www.camptocamp.org/summits/37737/fr/mont-de-grange#routes http://www.camptocamp.org/summits/42084/fr/chaine-des-gastlosen#routes

I think those "2nd-level" routes are not returned by the API currently (as a result not displayed in the parent-WP either).

We probably have to figure out if we really want to do that in v6.

[fjacon]

Ticket à discuter

[stef74]

For the moment we decide to not show the complete hierarchy.