Improve crag summary

[birgander2]

Some observations:

• The histogram of route grades is very coarse (only 4-5 bars)
• The season graph appears very prominently before the route stats, should be lower down or even hidden behind a button.
• Only few tags are shown, took me a while to find out that you can scroll them. This makes no sense. Better show all tags, but without the text (with popup text instead maybe)
• Tags are also not associated to the respective section (description, approach, etc.).

[bkucsera]

Thanks for the comments! We are also still thinking on this screen, how to make it more user friendly. Our idea is this:

• we can change the Route stats and Season graph diagrams, so Route stat will be higher, just under the Description texts.
• we will put an "i" icon or a "?" icon next to the Route stats and Season graph diagrams. If the user clicks on it, a pop-up comes up, where we can tell them how these diagrams are made (eg. "Season graph is aggregated from the number of monthly ascents" or something like this).

Tags:

• I would recommend not to show every tag on the screen at the same time, because some bigger crags can have 10+ different tags. We should decide what to show first.
• What if we show the tags in 2 lines, but still with the existing swipeable solution? This way we can show more of the most important tags, but the screen still doesnt look like a big tag-cloud :)
• we decide to leave some of the information, for example at "Steepness" we dont write "Ramp" or"Vertical", just show the icons.

Route diagram cannot be more detailed with more bars (as it looks like on the website), because the API sends only these data.

[rouletout]

@scd can we make the API spit out more fine grained data for the grade distribution graph?

[bkucsera]

Btw im not sure if it would be better to have the same, really detailed diagram in the mobile app, what you have on the website. On mobile screens, the diagram with 30 columns would be too much in my opinion. What do you think?

[scd]

We can make the api spit our more but it is a large amount of data. At the moment the 5 band levels are used for all countries and all gear styles so it is one graph for all. If we go to grading systems then this changes for each area and gear type.

If the grading system was always known then you could use a particular grading system, but this would have to be consistent for a single api call. So if we were getting a grading system for the whole world this is the grading system we are stuck with.

Really if we want to do this properly and model in a similar way to the the back end we need to transfer the internal grade. So we now go from 5 data points per area to 500. But actually we probably want this graph for each gear style so it is 500 x number of gear styles.

If it is marginal UX improvement only then I suggest we do not expand the graph until we master other parts of the app first.

[bkucsera]

Okey, lets get back to this issue when we have the first version apps ready.

[rouletout]

@bkucsera agree for this point (granularity of grade band), I think the other 3 points by @birgander2 are worth considering

[bkucsera]

Yes, we don't close this issue until not fixing the other questions. What are your thoughts on my recommendations above? (changing the diagrams and tags) We can collect these UX/UI issues and have a call in a few days time.

[rouletout]

This is done, closing