retain nav context for some pages like help

[brendanheywood]

I'm really loving the new nav structure and climbers pages etc. I thought I'd brought this up earlier but couldn't find an issue: if I am on say the gara node and click on help, and then click back to the the 'index' tab I'd expect it to go back to gara. That's how every other tab works (or shortly will) and it is very natural. So what I want to do is every time a person visits a page of any time, we just remember what node ID it was, and if they are on a help page or other page which isn't node related (dashboard, settings etc) then we still know where to send them. I can do this in pure JS but I think it's best to do it further up the food chain and just pass this back into the template as 'lastnode' or similar. This data never needs to actually be stored or process by the server, other that maybe a node lookup so we only store just the nodeid in the cookie.

• [x] on node serve, save the current node id with the cookies 'nodeid=12345'
• [x] if no node context when service the page, see if there is a cookie and if so grab it's id and look it up, send that to the template as $data->{lastnode}
• [x] Brendan's fixed up the templates to make it work

[scd]

Rather than create an extra cookie and take up network bandwidth, what about just storing the last nodenode in the session?

[brendanheywood]

Yeah I don't care much about the internals, I just want the menu to work the way I want. But if we go with session data doesn't that mean that for anon users the template will be different which means we can't cache it anymore?

[scd]

Good point, but I may be able to fix the anon users so it is ok.

[brendanheywood]

Ok, but how?

[scd]

create an anon session id

[brendanheywood]

I was thinking that this was very similar to the recent nodes #1467 internally, and also related to the primary nav stuff your working on, should we bring it in?

[scd]

Actually, given that the context of primary nav is also on the climber, we need to store one of:

• [x] '/world' # default world node
• [x] '/climbing/australia/arapiles' # area/route url stub
• [x] '/climber/scd'

[scd]

OK I have done this one.

There is an issue with anonymous sessions so I have implemented in it's own cookie NavCtx

This is available in the template as a global variable $app->{NavCtx}

[brendanheywood]

God damn this is awesome!

However I'm not sure about the climber context. If I click on a say araps, then photos, then index I go to arap, then drill down into a climber page, and then click back to index, previously it would take me to the araps page but now it takes me to world. I see that photos and logbook go to the climbers photos and logbook, but I think this is a bit confusing.

I see two solutions: 1) either we keep a climber context, but make that do something useful for all of the tabs. For the maps tab it could be showing the ascents for that climber on a map, for index it could mean show all their edits or something. This feels a bit contrived and for some tabs or sub pages it will just never have a valid meaning

2) we keep it as purely a node context, so you click into a climber page, and then back to the node page in the other tabs. This will mean that to get to photos and logbooks for a climber will be done through means other than the tabs but I'm ok with that. There is a clear navigation path from a profile to these pages and in future I have ideas to make this even simpler (more like twitter / github profiles)

I much prefer 2), and it also follows the general trend with all the facets and other pages where we are treating 'node' as a much more important facet than any other facet like 'who' or 'grade' or whatever. I think also when we add back in the side menu node navigation to all the facets pages this will tie in really well.

[brendanheywood]

There is another hybrid option where in the scenario above, the index page would take me to the last node context, ie araps, but the photo and logbook pages would take me to the last climber context. But I think this is more convoluted and will also confuse people even more.

[scd]

My thoughts on this.

When I am on my dashboard, the 'Logbook' primary link implies that it will be my logbook. Clicking that and getting the worldwide logbook seems wrong from the context of my dashboard. I would suggest that we could change this name to 'Ascents' and the problem goes away, but I also happen to like the branding of a community Logbook when we are at an area level.

Having a climber context means we can get rid of three lower level tabs on the dashboard page. This is something which we have been trying to do for a long time, so is a bonus.

I think Maps tab will eventually go away when we nail it in the index.

From the context of one's dashboard the Climbers tab could actually be you or your friends.

I am ok with the Index page just going to the world and switching contexts.

In summary I am in favor of a hybrid model. Tabs on the left are index context and tabs on the right can have a secondary climber context.

Another model could be climber context is only available from as a personal context from the dashboard. This would give us the wins without the confusion.

[brendanheywood]

When I am on my dashboard, the 'Logbook' primary link implies that it will be my logbook. Clicking that and getting the worldwide logbook seems wrong from the context of my dashboard. I would suggest that we could change this name to 'Ascents' and the problem goes away, but I also happen to like the branding of a community Logbook when we are at an area level.

I agree with the problem but think there are better solutions that allow us to stick with node only context. Your own logbook is universal, you should be able to get to it from anywhere (and not just when you were previously on your dashboard / own profile page), it is special by virtue of it being yours. Because it is special, and because you should be able to get to it quickly from anywhere, that is more of an argument that it shouldn't affect the nav context at all. You can already get to it from your account dropdown but agree that also associating it strongly with the logbook tab makes sense.

So how about this instead (committed):

This also sets the scene for other similar stuff, like putting the help index under that tab, or under maps have 'Map of your ascents' etc etc

Having a climber context means we can get rid of three lower level tabs on the dashboard page. This is something which we have been trying to do for a long time, so is a bonus.

Yes and no. I have a few issues with the second level tabs: 1) the often were a duplicate of top level tabs, we've mostly fixed this 2) they were conceptually top level concepts and not restricted purely to under a person (eg photos / ascents)mostly fixed now 3) Pure UX / design issues, like the second level tabs are part of the sticky header but the top level ones aren't, still on todo

I'm not completely against the idea of second level nav itself and if done right would be good: where there is a clear semantic relationship with a user that can't be viewed in in other context (eg photos, ascents, do make sense outside of a person). The biggest examples that jump to mind is what roles a person has in various crags, the new todo list concept, and possibly trips if we get them working well might be in the same bucket. So far my thinking long term on the profile is inspired a lot by the github profiles and the twitter profiles which both have person specifics tabs but just done better.

I think Maps tab will eventually go away when we nail it in the index.

No, I think maps is vitally important. I definitely do want the two maps, ie small map inside list view, and what is shown inside the maps tab, to converge into the same display and codebase - but they both have value in themselves. When you look in GA, maps is the second most popular tab, it is even higher than /climber/* and /ascents/*. It also gets more traffic for new users to the site which is expected, it is much better to explore using a map for a new area when region names and the org structure are new and don't make any sense yet. In future I see the maps tab as simply the 'fullscreen' mode of the embedded maps (and from a code point of view that is exactly what I want it to be)

[scd]

I am very happy with the logbook drop down. Also photos and forum drop down. With those changes I would be comfortable committing to no climber context.

My only concern is that if these dropdowns become become a critical part of the site, how do they work for mobiles?

Good point about the GA with the maps. I'm not that visual so I should be careful not to project my biases onto the project.

FYI I will release as soon as we are happy with this bit of work. I have done all the unrelated critical stuff I have wanted to do and the wash up of fixing all these follow-up primary navigation issues will pretty much fix all the other forums stuff I wanted to fix in the short term.

I would be happy for us both to focus on getting this done. I don't think I want to do any topo work for this release because it will risk delaying the release. There is a personal issue that I may have to take some time off for very soon, so it would be good to get the release done before this happens.

[brendanheywood]

I've got thoughts on the top level nav for mobile but right now they don't work, but then they never have for the favourites either. I have something like this in mind:

http://jasonweaver.name/lab/flexiblenavigation/

The whole primary nav + header is all showing it's age and I'd like to rebuild it from the ground up, even if the design barely changes to better support mobile nav. I'll make an issue but don't want to think too much about it for at least a couple releases.

[brendanheywood]

This one is solid from 2 releases ago so closing