seperation of child areas into type is confusing

[nicHoch]

example: https://thecrag.topoguru.com/info/992641662

the separation from all child areas into its area type (area, region, crag) is very confusing and will not help to find a certain area.
The usage and definition of area type is very subtle and differs in various regions.
The user can not tell for sure if the area he is looking for marked as a crag/area/region/sector ...

what to expect:

Combine all of them (not routes) into a single child list view.

[bkucsera]

This is an important issue, as theCrag has huge amount of data in every country. We are open to any kind of solution what makes the user experience better and easier.
I think this issue maybe worth a common call (we already had before with Ulf).
In case of the linked example (Austria): we can hide the type of area when it is a country. Is that what you mean here? I mean, not to show Austria as a region, however it has a "region" label in the database.
If you mean to show every database level in a hamburger menu what the website has now, it would cause a bad UX in the app.

Can i ask you to explain a bit more detailed, what you would like to see (" single child list view")?

[nicHoch]

https://thecrag.topoguru.com/info/992641662

Has many subarea that looks on theCrag so:

in the app the list view of the child areas is separated into:

Area:

Region:

Crags:

with this separation by area type the user has to know a priory the type of the area he is looking for to stitch to that tab - but he can not know it (due to local favors, errors ...).
so i would suggest to combine all area (regardless of type) into a single list view.
(only exception i could imagine might by gyms - but gyms are a topic on its own)

[nicHoch]

this example is a very simple one as there are only one Region and one Area, all the rest are Crags imagine in area with many subareas in each tab. The user has to scroll and swipe a lot.

[bkucsera]

@rouletout This suggestion is a bit deeper simplification in the menu system, what we discussed on the weekend.

What do you think guys, if we try with these levels:

• Country
• Region: every "admin edited" region. In case of the attached example, you would handle every swiss region under one tab? For example in Switzerand the 3 main regions (Jura, Mittelland, Alpen) would be on the same list, as their child-regions, such as Appenzeller Alpen or Graübünden?
• Area: everything under Region level, and above TLC level?
• Crag: the same list would contain all TLCs, simple crags -and as we discussed with Ulf, we would handle Cliffs and other smaller items in the Crags list

Or you mean something different? @nicHoch

[nicHoch]

@bkucsera i do not understand why you need any separation of area types.
i would propose one single list for all areas in the parent area but only direct children.
we have some very massive Crags with each more then 1000 (recursive) subareas like:

https://www.thecrag.com/en/climbing/germany/sachsische-schweiz/areas
https://www.thecrag.com/en/climbing/germany/frankenjura-nord/areas

any simplification (flattening) of the tree structure based on implicit rules will most likely produce errors or not work on other area in other countries. Or maybe even create app freeze to the large total amount of children in the list view.
Flatten all area will alsoproduce name "conflicts": there are several "main walls" "south face" ... in the same crag

sticking to the tree approach will most likely also solve the issues: #21

[bkucsera]

In general:
Im not sure if we will succeed in this topic, but we try to find some kind of simplification because of the different typical user need in an app. Most of the users get used to easy-to-use applications, where they can find the important information within a few clicks or seconds. This is the reason why we are thinking about a solution to flatten theCrag's database somehow.
In our case i think the most important user case is to 1.) find topos and 2.) read infos about crags. But it can happen that simplification would cause more trouble then gain, so this is an important discussion.

Im not sure if i understand your suggestion :)
Can i ask you to write an example of your suggested app-menu? With this region for example: https://www.thecrag.com/en/climbing/switzerland/alpen/graubunden/engadin

• So the first level what we see is Alpen, where we have Info and Regions tabs?
• in case of Graubünden, we would have only an Info and Regions tab? We would put the crags also to the Regions tab? And rename the Regions tab to Areas?

[nicHoch]

in case of Graubünden, we would have only an Info and Regions tab? We would put the crags also to the Regions tab? And rename the Regions tab to Areas?

yes exactly just one "Info" and one "Areas" tab (with all Crag, Region, and Area in one list - but not recursive area levels).

The order in the list is defined by the API call.

Navigating in a tree structure is not easy in a APP that is why we need good entry points into the tree for example

• map
• name search
• favorites

[bkucsera]

Back to this logical problem.
In my opinion is ok to use more simple menu structure, as you suggested.
If we simplify, we have to set up the simplification rules:

• Which levels can be renamed for 'areas"?
• Ulf mentioned before that region is fix item in the menu, as it can be created only by admins. Is it true for all regions? Or just main regions? In the example above: Graubünden is an admin edited region, but it's sub-region (eg. Engadin-Poschiavo) is not?

What if we do like this?
-> rename to "Areas" every sub-item under a main Region. - If we have main regions in TC database
-> rename everything to "Crags", until that point where there are no sub-crags

This way we can have:

• Regions with Info and Areas tabs
• Areas with Info and Crags tabs
• Crags with Info, Sector and Rotues tabs (and maybe here we will need an Area tab as well to handle the problem of top-level crags and simple crags)

[nicHoch]

Unfortunately there is no forced rule on how subareas are evolving from Country to route level. And it is easy to find many different cases that will break all "simplification rules". There are large crags without any sectors and sometimes even routes and areas are on a same level.

So i would still propose to ovoid any confusions with the currend index not to rename any area to a forced schema.

Put all (direct child ) areas a a "area" tab (add a area type label to the list entry) and all (direct child) routes in a route tab.

Also it is not really helpful to show all routes and all topos to early (i would suggest only to show direct child routes and topos). If you look on large crags like Grampians: https://thecrag.topoguru.com/info/11740939 you will see 8000 routes and 650 topos in the same list. this does not help with any navigation.

[rouletout]

After another discussion we propose to ask for user input on this topic. What is better, multiple tabs with shorter lists or 2 tabs with longer list? Can we use a concept of top level region?

[nicHoch]

any progress here?
i still do not see any usability advantage of the split into tabs.
the user can not know as what type the area is. and have to randomly switch between tabs.
sometimes the tabs are so many that it starts to look strange. of course in this example: (https://thecrag.topoguru.com/info/188179026) the real types of the area should be more consistent. but with our very large community driven content we will never be able to control that so we have to find an UX that supports this imperfection.

[rouletout]

Based on more testing and the little feedback we received we should probably fix that asap. The value of splitting this in tabs for area typoes is close to zero but has lots of disadvantages as it creates unnecessary searching / switching between tabs.

[bkucsera]

This is a compex problem, and as i see now every solution has pros and cons.

• If we merge some of the data, we should define merging rules
• If we decide to merge, that will clutter the existing database. I think active users are get used to this, so for them probably not a big deal if we use several tabs.
• the strange look happens in a very few cases comparing to the whole amount of nodes in the database. However probably happens in case of the bigger areas, which used by more users.

Do you have a UX suggestion to handle this issue?
2nd option is that we wait until the first user feedbacks from the live app and see what users would like to see here.

[nicHoch]

i wonder what do you think is the pro of the current solution?
if i am browsing around i almost see only cases where this current solution does not work. and the other cases both solution will work.

https://thecrag.topoguru.com/info/11740915 Arapiles: here we have one area and many crags. all areas of type "cliff" are not shown and will end up in a separate tab. for me this is very confusing.

a user can not know as what type an area will be marked he can only guess.

i do not see why we need any merge rules. there is no merge needed. the original order in the index is side by side regardless of type. you introduced a split rule - from a theCrag user perspective this is not "clutter" this is the actual data.

[bkucsera]

Merging just a suggestion/question from the previous comments, im not sure if we need it.
The Cliff issue is under process.

Okey, we try a new method, what you suggested earlier: "Put all (direct child ) areas a a "area" tab (add a area type label to the list entry) and all (direct child) routes in a route tab.
Also it is not really helpful to show all routes and all topos to early (i would suggest only to show direct child routes and topos)."
@rouletout is ok for you as well?

[bkucsera]

Questions:

Tabs

• so we will use only Area tab at nodes, and put every types of nodes under Areas. Marking on the tile the type of the node, as Nicky suggested here: seperation of child areas into type is confusing #26 (comment)
• I think it would be good to have a separate "Sectors" tab, in case of Crags. On user side, i think many of the users are thinking in the "guide-book scheme", where there are strictly crags/sectors/routes order. So i suggest to put a separate "Sector" tab in those Crags, which do not have any other Crags or Areas as a child node, just sectors and smaller level nodes (such as Cliff, Boulder, etc). What do you think about this?

Search
In this case with fewer tabs, we can have a separate Search tab on the node page. So the tab bar will be like this: Info / Areas / Sectors / Routes / Topos / Search
What do you think about this?
this also solves #65

Route list
Route list issue: im not sure if showing only direct child routes is a good idea. As a user when im browsing crags or areas, im interested in certain grade of routes. Eg. i would like to see how many 7a-7b routes are in that area. If we show only direct child routes, the route list will be empty, until i dont go into a crag/sector.
So i suggest to keep the route list as it is now, to be able to search in a wide range of routes.

Please share your thoughts/modifications and confirm those points which are acceptable for you as well. Thanks!

[nicHoch]

to add a search tab is good.

area/sector i get your point. what about just having one tab. and just change the label from "area" to "sector" if only sector like area types are around? but the other aproach might also work . i guess if the area tab would be empty it is not shown at all. right?

[lordyavin]

Regarding the list of all routes in the area: How do you want to guide the user that he/she knows that the list is an aggregate of all routes in child areas? The use case you describe is valid but why not providing a "search/filter all routes" function explicitly? That would solve most issues. If the user traverses through the tree he/she sees the real index structure. If needed he/she can switch to the "show me all routes" tab and apply whatever filter is available. And BTW there are a lot more useful filters than the grade: stars, gear style, route style,...

[birgander2]

To have all sub-areas together in one tab, independent of their type, is certainly better and more intuitive. The problem I see is that there are various ways of organizing an area and even a crag. I would bet, that there are even sectors that have sectors as child. And I remember for sure some (not well maintained) crags that have sectors as well as routes as direct child.

[bkucsera]

We will go further only with Areas tab, and list every child node under it.
The type of the node will be shown on the tile, as you suggested above.

As we will have a Search tab, we can improve the filtering systems in a later release, described above by @lordyavin

[rouletout]

looks great, closing