Route List tab on higher levels is not intuitive

[nicHoch]

The route list tab on a high level of an area/crag (not the last (sector) level) does not provide useful functions.

The sort order within the list is some merge join over all subsectors also with annotations in between. The user has no chance to use that list in order to "navigate on the crag" (outdoor) but also he can not use that list in order to navigate in the app to the route of desire. he can scan the entire list manually to find a route or use the route name or grade filter. If the user has found the route and goes to the route detail page he can not navigate to the parent (sector) of the route. With some luck the route has a topo (but the chance is less then 10%). so he might have found the route but have no clue how to get there as he need the parent detail page for that. now going back to the route list from route info the entire list is refreshed and jumped back to the top.

so i would propose the following.

• [ ] order the routes by sector (ordered by index) and then within the sector (order by index) support annotation at the right place.
• [ ] each sector (direct parents of the routes) should create a section header in the listview.
• [ ] tab on the section header should open the area page for that area
• [ ] in the route detail page (info) present a link to all parent nodes (areas) available
• [ ] if going back do not refresh/reload the routelist

[rouletout]

Agree, this is pretty low value like this - what of the above checklist can be done easily?

[bkucsera]

• if going back do not refresh/reload the routelist - this has been fixed

in the route detail page (info) present a link to all parent nodes (areas) available we are planning to do the following, please check the idea:

• we put a drop down icon to the right side of "Path" row. Clicking on this will drop down a list with all the parent nodes of the actual node, and all these texts will be a link to the node. This way the user easily navigate back with one click to any of the parent nodes.
• This clickable list will appear on Route detail page, to help navigation in the database

What do you think about this solution?

As this route list is not used for browsing a crag/sector, but to search for a certain route by name or available routes in a grade, we would not put here annotations and other items. In case of a big area with hundreds of routes, this would not serve easier navigation here. So we suggest to try with the above mentioned modifications. If we get many user concerns on the route list, we can make changes in the next release (v 1.2, with ticking, uploading and other functions).

[nicHoch]

i like the idea with the drop down parent node menu.

[rouletout]

Disuss what can be fixed for next release

[bkucsera]

Drop-down Path list will be added. There will be 4 tabs everywhere: Info / Areas / Routes / Search. In Routes tab we will show the child routes. In Search tab it will search in all routes of the node and child nodes.

[bkucsera]

Fixed (v151), please check and close if works properly.

[nicHoch]

i really like the path dropdown. this will by very helpful for the tree based navigation. i wounder if it would it more obvious if the drop down would be more emphasize by the UI besides the small triangular.

[nicHoch]

There will be 4 tabs everywhere: Info / Areas / Routes / Search. for me this is looking very good

[nicHoch]

In Routes tab we will show the child routes.: working well

[nicHoch]

In Search tab it will search in all routes of the node and child nodes: see here: https://github.com/theCrag/tca/issues/65#issuecomment-818993302

if the "local search" works well i think this issue improved the usability of the app quite a lot. thx for that

[killakalle]

The path dropdown in general is a good thing for navigation. However, I find it confusing that each part is shown both as

• end of an item
• beginning of an item

Since this is a path with all path elements shown, it's sufficient to show only the current element - without parent.

The last path entry in the list is also redundant with the title. Here I agree that showing the parent adds some value, because context might be missing. however, for the path drop down this is not the case.

[bkucsera]

i really like the path dropdown. this will by very helpful for the tree based navigation. i wounder if it would it more obvious if the drop down would be more emphasize by the UI besides the small triangular.

We gonna move the small triangle icon closer to the Path text, to show that the function belongs to the text. The triangle icon itself is a default android icon, this is why we use it. If we get more concerns from user, we can think about to modify it.

[bkucsera]

The path dropdown in general is a good thing for navigation. However, I find it confusing that each part is shown both as

• end of an item
• beginning of an item

Since this is a path with all path elements shown, it's sufficient to show only the current element - without parent.

The last path entry in the list is also redundant with the title. Here I agree that showing the parent adds some value, because context might be missing. however, for the path drop down this is not the case.

Questionable :) Lets see if we get more feedback on this topic from users, we can fix in the 2nd release.

[killakalle]

Some further thoughts. Maybe you don't need the Path in the bottom part at all. And you can just bring the dropdown into the title. Because at the moment you have the same information in two places. So why not consolidate this into one place only?

On Wed, 14 Apr 2021, 18:01 bkucsera @.***> wrote:

The path dropdown in general is a good thing for navigation. However, I find it confusing that each part is shown both as

• end of an item
• beginning of an item

[image: image] https://user-images.githubusercontent.com/30682796/114625827-1f1ceb00-9cb3-11eb-833a-ef5ca92031b7.png

Since this is a path with all path elements shown, it's sufficient to show only the current element - without parent.

The last path entry in the list is also redundant with the title. Here I agree that showing the parent adds some value, because context might be missing. however, for the path drop down this is not the case.

Questionable :) Lets see if we get more feedback on this topic from users, we can fix in the 2nd release.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/theCrag/tca/issues/69#issuecomment-819632079, or unsubscribe https://github.com/notifications/unsubscribe-auth/AHKC5LCXXGCEX7QXE2TND43TIW36RANCNFSM4ZR4UP2Q .

[bkucsera]

Thanks, it is an idea to think about. My first impression is that 2 different functions at the header can be confusing for the users. On the left part of the header there is a < arrow which goes back to the previous menu. If we put another arrow to the right of the cragname, it will open the dropdown path menu? We can do a list with these open UX questions and do a research with several testers.

[killakalle]

@bkucsera Here's an illustration of the current situation with path

What is comfortable to read is the pink line. What I currently need to read to use the path navigation is the orange line. The difference in how easy it is to navigate with my eyes is obvious.

So, I'm proposing to make the orange line the pink line by removing the parent from that display

[nicHoch]

i also think that the proposed format from @killakalle will be much better

[bkucsera]

We have changed the Path as you described. It will be out in v153 soon.

[rouletout]

@killakalle please check in 153 and let us kno if this is ok now

[killakalle]

Path looks good to me now!

[rouletout]

great, closing