Facet navigation and urls + filtering UI layout changes

[brendanheywood]

This won't be for the next release, but I'd like to discuss and get some direction on the facet pages. I'm really digging the new navigation that keeps context. So if I'm looking at a list of top contributors for a node, and I click on the crumb trail, or the side menu, then I'm still looking at the contributors page for where ever I clicked.

I think the facets should also work this way but this will have a few impacts:

• [x] all should be responsive
• [x] all should have pagination at the top
• [x] all should have facets in body
• [x] split in to consistent filter groups
• [x] all should have index menu on the left
• [x] crumb trail should retain filters
• [x] drop downs should retain filters
• [x] should have a 'sort by' drop down
• [x] shortby should be retained when navigate through crumb trail or dropdowns or side menu
• [ ] should group items by the sort by value
• [ ] audit missing facets - add to UI where missing
• [ ] turn common filters into always on, turn others into expando accordions eg 'show people filters'
• [ ] chrome gone when embedded on 3rd party site
• [ ] should use query params instead of paths?
• [ ] all should have a call to action in the header
• [x] First it means we've got to move the filters to somewhere else, and a few people have suggested the top, which also would work well for reflowing in smaller screens. That really becomes the catalyst for rethinking the layout of some of them, for instance in the route search it would probably be better to have most of the common filters just visible and not hidden behind the toggles. And maybe one big toggle for all the other stuff in an 'advanced filters'.
• [x] It means we're never going to filter the /at/ using more than one node. This is such an edge case I'm happy to drop this.
• [ ] because it will be much easier to navigate to, and around these pages, I'll remove the favourites stuff and the 'Area' facet completely.
• [x] make sure google doesn't index

• [x] This gives us the opportunity to make the url's even nicer. I don't really like any url's that aren't human readable, and the obvious culprits here are the /at/ filter and the tick types filters, and the user filter.

  http://dev.thecrag.com/ascents/by/7727431/at/11772109/ vs http://dev.thecrag.com/climbing/australia/gara-gorge/ascents/by/brendanheywood

  http://dev.thecrag.com/ascents/by/7727431/with-tick-type/7509994/ vs http://dev.thecrag.com/ascents/by/brendanheywood/with-tick-type/redpoint/

  I think moving the various facet pages to sit under their full url stubs will make a big difference when used in forums and elsewhere like on Qurank the other day.

There are a few minor things, like we need to make 'ascents' and 'routes' etc reserved words so they can't be used in the url stub of an area.

So, pros and cons?

Todo

• [x] make sort by a drop down, not column headers (too many non columns order by items)
• [ ] for route search, re-use same template as list view so we can also tick and edit from search results. Do we need extra backend stuff to show the tick icon if the user has ticked here? also need to make sure permissions work

[brendanheywood]

A very quick and rough mockup

[cgome]

A big +1 from me. Facet filters are more obvious and apply filter button is more accessible.

On Friday, 16 August 2013, Brendan Heywood wrote:

A very quick and rough mockup

[image: image]https://f.cloud.github.com/assets/187449/974670/c8ab323e-065d-11e3-84c7-c225ead042cd.png

— Reply to this email directly or view it on GitHubhttps://github.com/theCrag/website/issues/1179#issuecomment-22758527 .

Campbell

[scd]

let's separate this into two issues. a) change the filters and b) update the urls.

I don't mind if we change our strategy with urls, that is just the nature of development. However the url issue is across all the facets, so I want to align photos so that they are all consistent. Then change them all at once.

[scd]

I think we could keep the facet url pretty much the same and just allow the front part of the url before (photos/routes/ascents/etc) to be interpreted as an 'at'. The old way of referencing the facets could still be allowed, in particular if we ever need multiple at's then we could use the old method.

[brendanheywood]

yeah I really like that, best of both worlds

[scd]

Now that the last facet (photos) is standardised the next step to get the facet to work after a standard index url was simple - especially given we have decided to keep the old facet url in parallel.

In repo. Try:

http://dev.thecrag.com/climbing/australia/arapiles/ascents

The '/climbing/australia/arapiles' is interpreted as an 'at' parameter.

Should work for all facets.

[scd]

@brendanheywood I have made changes to the template so that facets use index url context. They still work with the old urls as well.

I think this now makes your context primary navigation work with facets.

Do we need to do something similar for the climbers so that '/climber/scd/ascents' works in the same way?

[brendanheywood]

No, the primary driver is that we're conceptually splitting the filtering into filtering via node on the left hand menu, and via all the other filters in new controls along the top. So in a way /climber/scd/ascents is actually really /climbing/world/ascents?by=scd

[brendanheywood]

See also #916

[brendanheywood]

Add a to do related to Lee McDougal's request to tick from a search page

[brendanheywood]

@scd I've made some pretty good progress here with all 9 facets but I need a bit more template date to build the side menu, same data structure as we get in the listview template for children and ancestors with siblings data. There is some data already in the 'at' data and also 'referenceArea' don't care with we use. Also I if there is no 'at' node I expect it to populated with the world data, and while technically there could be multiple 'at' filters I want to just ignore that completely so only ever return one please.

[scd]

Please ignore my last comment about standardising for full width. I imagine you want to add child nodes to the left hand column.

If there are multiple at areas, should I return the lowest common parent?

[brendanheywood]

Multiple isn't really a use case I care about much and it will be hard to achieve using the ui anyway. Happy to deprecate it entirely. So just return the first one

Sent from my iPhone

On 12/10/2014, at 5:25 PM, Simon Dale notifications@github.com wrote:

Please ignore my last comment about standardising for full width. I imagine you want to add child nodes to the left hand column.

If there are multiple at areas, should I return the lowest common parent?

— Reply to this email directly or view it on GitHub https://github.com/theCrag/website/issues/1179#issuecomment-58775120.

[scd]

All the facets now have a referenceArea (in repo) which includes ancestors and children. If there is no at in the search then this will default to world. If there are mulitple at's then this will default to the first at.

This means multiple at's will still work, but we will only display it as if it is one at. The UI cannot generate multiple at's so it should never occur unless some advanced user explicitely wants information from multiples at's and manipulates the url. I recon we can just not worry about multiple at's but there is no need to actually deprecate it.

BTW, I think that the facet search parameters should not be included in an embed by default. If somebody is using oembed for a particular URL I think the implication is they just want the result.

[brendanheywood]

This is all added in to the UI now, I'm pretty happy with this now, so closing