Closed scd closed 10 years ago
In fixing /climber/scd/ascents I created a problem with the filter having the wrong base url. Must fix this before release.
Simple solution for conflicts between standard facet search parameters and url prefix parameters, for example:
/climber/scd/ascents/by/cgome/
standard parameters take precident, so the above query gives the same results as:
/ascents/by/cgome/
I must confess, now that I have been playing with the updated primary nav, it is somewhat better than I expected. It feels as though it is predicting what I want to do next and draws me in to continuing searching. If other people have the same reaction then this will be good for us. My prediction is that we will get a whole lot of issues raised as people see more of the site. It is also really motivating me to get the responsive stuff done for the first clicks on all the primary nav pages.
Thanks Brendan for being firm on your vision with this, which was exactly the opposite of my vision, which was a primary navigation which always took you to the same place. In general neither visions are wrong or right, it is just that for our site Brendan's works better for our site.
Thanks me for letting go and trusting Brendan.
hahaha - that made my day :)
and yes totally agree re responsive, it's really noticeable that all the tabs are different widths and bounce around a lot. Photos will be the easiest to fix but we should aim to also get these fixed this release
I have started on making dashboard responsive while doing the mark all as read enhancement. To do this properly means I have got to jump into message css stuff. I plan to be brave and give it a go. If I get it done then it means I will have jumped up on the learning curve and be much more effective on the front end.
If you wanted to work on quick wins with the photos then that would be great.
Something I really don't want to do is move the facet fields from the left hand side menu to the top. That does not have to be in this release, and I certainly won't make this change for the release.
Cool. A good model to emulate is the list view. Use the > selector lots to stop over selecting I find helps heaps
Sent from my iPhone
On 31/05/2014, at 1:42 PM, Simon Dale notifications@github.com wrote:
I have started on making dashboard responsive while doing the mark all as read enhancement. To do this properly means I have got to jump into message css stuff. I plan to be brave and give it a go. If I get it done then it means I will have jumped up on the learning curve and be much more effective on the front end.
If you wanted to work on quick wins with the photos then that would be great.
Something I really don't want to do is move the facet fields from the left hand side menu to the top. That does not have to be in this release, and I certainly won't make this change for the release.
— Reply to this email directly or view it on GitHub https://github.com/theCrag/website/issues/1474#issuecomment-44716994.
What's the story with the '/climbing/australia/arapiles/maps' in the todo list at the top? That url shouldn't ever work, are we accidentally generating that as a link somewhere?
And just checked, photos is already responsive, it is ascents tab which isn't. I've just flicked on the responsive flag for the template and it work reasonably well straight off the bat. Even on my iphone while not fantastic is still quite usable. It definitely needs more work but that can come later with #1179
So now it's just dashboard and forum which is left
If we got ''/climbing/australia/arapiles/maps'' to work then we would have completely standardised the primary nav urls. However if there is other more important business logic then we don't have to do this.
Ah, yes see your point - I just realised in GA I need to filter on url suffix instead of prefix, so those stats I gave before will be wrong because we are half way through that cutover (but under represented so the real stats would be higher). It makes the GA drill down's a little bit more fiddly, I'll have to play to extract these as traffic slices somehow.
So yes I think we should change them, also remember to fix the dynamic url generation in the maps.js file.
There is also a bunch of other url stuff I've just realised we should fix now as part of this for better GA reporting, it's all easy stuff but will document in a new card.
I've just rerun the stats with some new GA segments to filter on url contains instead of url prefix and the tab order comes out different. Photos comes in a clear first, ascents and maps roughly the same. Forums last. Forums is a little misleading as this doesn't include messages done via the dashboard, nor messages themselves only the summary pages.
It's a little bit of a pain to use segments as now I can't easily report on tabs + user segments (like new vs returning) at the same time with the new url format.
I have removed the climber context and added some more menu items under Forums and Photos. I am happy with this approach.
Until we sort out the primary nav on mobiles I am leaving the secondary dashboard tabs in.
closing
Did you want to straighten the maps url now?
are any issues with your javascript generating the breadcrumb urls. If not then I think we should just go for it.
On Thu, Jun 5, 2014 at 4:34 PM, Brendan Heywood notifications@github.com wrote:
Did you want to straighten the maps url now?
— Reply to this email directly or view it on GitHub https://github.com/theCrag/website/issues/1474#issuecomment-45185407.
It's 5 minutes work for me to fix the JS, so I reckon we sort it now
The js is sorted in dev, just need you to sort back end route to work. Also need to leave legacy route in place
Sorted on the backend. Please pull from repo and let me know if it is ok.
Two questions come to mind.
All tested and good
Our canonical url, in the sense of what we should internally link to is this new urls eg:
http://dev.thecrag.com/climbing/australia/new-south-wales-and-act/northwest-slopes-and-plains/maps
Both the old as well the new url format are blocked by robot.txt (just tested this in webmaster tools with new url). I think this is fine as is. Part of me thinks it would be nice if google did index just the very top level map page but not any of the ones under it, but leaving that for another day.
The canonical url in the page metadata is currently wrong and just points to "/maps", but this page is never indexed by google so it currently doesn't matter. If we ever do let google index it, it probably makes sense to leave it pointing at the top level page, but possibly change to /climbing/world/map
There is extra unnecessary logic in generating primary nav urls because they are not all standardised: