Hello! Here's an update on what I'm doing, and a request for input.
At the moment, I'm concentrating on making it easier for people to customise their Guides without having to fork. I've added a config option to let you suppress the recent changes on the home page, and I've split out the "guts" of the navbar into smaller sub-templates, so navbar.tt is now incredibly simple:
<div id="navbar"> [% INCLUDE navbar_home_link.tt %] [% INCLUDE navbar_tools.tt %] [% INCLUDE navbar_help.tt %] [% INCLUDE navbar_options.tt %] [% INCLUDE navbar_search.tt %] [% INCLUDE navbar_this_page.tt %] [% INCLUDE navbar_revision_info.tt %] </div>
(I noticed some people had rearranged the order of things in their navbar; this allows you to do that without potentially locking yourself out of upgrades if we have to make code changes in the navbar templatey bits. And it makes it a lot clearer what's going on, which is good.)
Anyway, while I was doing this I came across the question of these common categories/locales. When Nick put them in, Clair asked if they could be moved into the navbar, and Nick said he didn't want to do this, but didn't really explain why. I think they should be in the navbar. Semantically, they belong there; they're means of navigation, entry points into the Guide. Also, I see only three guides that actually have them turned on; RGL has a hacked template that puts them in the navbar anyway, and the other two (can't remember which, sorry) seem not to have noticed them, since they're just stuck awkwardly at the bottom of the page. Nick, can you explain why you think they don't belong in the navbar?
The other thing is that they should really be specified in wiki.conf, since (a) they should be configurable, and (b) they need to be run through the node_name_to_node_param method of the formatter before being plonked on the page. I'm not sure of the best way of doing this, since Config::Tiny doesn't let you specify more than one value for a key. Can we assume that nobody will ever want to use a category/locale with a comma in for this purpose, and just use a comma-separated list? Or can someone come up with a better idea? I don't want to rush in with a half-baked solution that will need to be done over again in a few months.
Kake
On Sun, 18 Mar 2007, Kake L Pugh wrote:
Anyway, while I was doing this I came across the question of these common categories/locales. When Nick put them in, Clair asked if they could be moved into the navbar, and Nick said he didn't want to do this, but didn't really explain why. I think they should be in the navbar. Semantically, they belong there; they're means of navigation, entry points into the Guide.
They weren't placed into the navbar for reasons of css control. If they were within a div with id=navbar, it became significantly harder to give different styling to these than the rest of the navbar.
One workaround might be to do (id names probably want to be better): <div id="navbar"> <div id="main-navbar"> .... </div> <div id="common-links"> .... </div> </div>
That way, you could choose to do all your styling on navbar (so they go together), or do no styling on navbar, and style main-navbar and common-links independently.
The other thing is that they should really be specified in wiki.conf, since (a) they should be configurable, and (b) they need to be run through the node_name_to_node_param method of the formatter before being plonked on the page.
Dom had a think about this, and I think decided we'd need to extend Config::Tiny, or use something else, to be able to do it properly. Dom - am I remembering you comments correctly?
Nick
On Mon 19 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
They weren't placed into the navbar for reasons of css control. If they were within a div with id=navbar, it became significantly harder to give different styling to these than the rest of the navbar.
One workaround might be to do (id names probably want to be better):
<div id="navbar"> [...] <div id="common-links">
I wouldn't say that's a workaround - I'd say that's the correct way to do it! Well, modulo the "main-navbar" thing; it would be better to give each navbar "module" its own id. I don't understand why you're special-casing the categories/locales - surely people are just as likely to want to style other elements of the navbar as they are to want to style these particular elements. But anyway, yes, I'll move them into the navbar, if this is the only reason you left them out.
The other thing is that they should really be specified in wiki.conf, since (a) they should be configurable, and (b) they need to be run through the node_name_to_node_param method of the formatter before being plonked on the page.
Dom had a think about this, and I think decided we'd need to extend Config::Tiny, or use something else, to be able to do it properly. Dom - am I remembering you comments correctly?
Bob (um, or was it doop? One of them, anyway) suggested that we could move to using YAML instead of Config::Tiny.
Kake
On Mon, 19 Mar 2007, Kake L Pugh wrote:
I wouldn't say that's a workaround - I'd say that's the correct way to do it! Well, modulo the "main-navbar" thing; it would be better to give each navbar "module" its own id. I don't understand why you're special-casing the categories/locales - surely people are just as likely to want to style other elements of the navbar as they are to want to style these particular elements.
The reason to special case them is so it's easy to put them somewhere else, leaving the rest of the navbar as it currently is. I'm told that if you can't have them in different parent div's, it's really hard to do something like: http://ogtest.torchboxapps.com/wiki/wiki.cgi?Evenlode_Books%2C_Charlbury
Nick
On Mon, 19 Mar 2007, Nick Burch wrote:
The reason to special case them is so it's easy to put them somewhere else, leaving the rest of the navbar as it currently is. I'm told that if you can't have them in different parent div's, it's really hard to do something like: http://ogtest.torchboxapps.com/wiki/wiki.cgi?Evenlode_Books%2C_Charlbury
the problem at the moment is that they end up being splurged on the page with no rhyme or reason so if nothing else they need a sensible default style. the other problem is that they get turned on by default if not mentioned in the config file. this is bad behaviour imho.
On Mon, 19 Mar 2007, Bob Walker wrote:
On Mon, 19 Mar 2007, Nick Burch wrote: the other problem is that they get turned on by default if not
mentioned
in the config file. this is bad behaviour imho.
or perhaps not. just ignore me. i keep on seeing strange things. i blame the mind control rays.
On Mon 19 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
The reason to special case them is so it's easy to put them somewhere else, leaving the rest of the navbar as it currently is.
Sorry, I didn't explain myself very well. What I mean is: why do you care about people who want to put the categories/locales somewhere else, but not about people who want to put the help links somewhere else, or people who want to put the Tools somewhere else, or etc etc?
I'm told that if you can't have them in different parent div's, it's really hard to do something like: http://ogtest.torchboxapps.com/wiki/wiki.cgi?Evenlode_Books%2C_Charlbury
Even if that is the case (I don't know enough CSS to tell), judging by existing Guides, nobody seems to want to do this anyway. Who was it that asked for it?
Kake
On Mon, 19 Mar 2007, Kake L Pugh wrote:
Sorry, I didn't explain myself very well. What I mean is: why do you care about people who want to put the categories/locales somewhere else, but not about people who want to put the help links somewhere else, or people who want to put the Tools somewhere else, or etc etc?
If you want to put categories AND locales somewhere else BUT the same somewhere else, life is significantly easier if they share the same parent, and nothing else does.
So, Dom and I have added a div with a special id around the pair of them, but still leaving them within navbar. That way, they will sit in the navbar by default, but if you wanted to put them elsewhere (but together), it's very easy to do.
Even if that is the case (I don't know enough CSS to tell), judging by existing Guides, nobody seems to want to do this anyway.
I want to do it for the cotswolds openguide. I just need to find 5 minutes to tweak the css I've got that does that (now a few of the ids and classes have changed), then I can put it live.
Who was it that asked for it?
We did some useability testing on the cotswolds guide, and the lack of an easy way to get from a node page to the most commonly used locales and categories was identified as a failing. When we tried a few designs for where to put those lists, we found that having them next to the navbar, in a 3rd column, worked well for a lot of designs.
Nick
On Sat 24 Mar 2007, Nick Burch openguides@gagravarr.org wrote:
If you want to put categories AND locales somewhere else BUT the same somewhere else, life is significantly easier if they share the same parent, and nothing else does.
Ah-ha, I see what you mean now. You just want a way to group these two <div>s together.
So, Dom and I have added a div with a special id around the pair of them, but still leaving them within navbar. That way, they will sit in the navbar by default, but if you wanted to put them elsewhere (but together), it's very easy to do.
Works for me! I'm not sure "navbar_common_navigation" is the best name for the containing <div>, though - it doesn't really convey what you mean. How about "navbar_categories_locales" or maybe something like "navbar_popular_starting_points" (which would allow adding other related things in the future)? (Or "navbar_starting_points" or something like that? Just spitting out ideas in the hope that someone will have a better one before release.)
Kake
On Sat, 24 Mar 2007, Kake L Pugh wrote:
Works for me! I'm not sure "navbar_common_navigation" is the best name for the containing <div>, though - it doesn't really convey what you mean. How about "navbar_categories_locales" or maybe something like "navbar_popular_starting_points" (which would allow adding other related things in the future)? (Or "navbar_starting_points" or something like that?
navbar_starting_points works for me. Dom and I were feeling uninspired when we came to name it!
Nick
On Sat, Mar 24, 2007 at 11:02:01PM +0000, Nick Burch wrote:
On Sat, 24 Mar 2007, Kake L Pugh wrote:
Works for me! I'm not sure "navbar_common_navigation" is the best name for the containing <div>, though - it doesn't really convey what you mean. How about "navbar_categories_locales" or maybe something like "navbar_popular_starting_points" (which would allow adding other related things in the future)? (Or "navbar_starting_points" or something like that?
navbar_starting_points works for me. Dom and I were feeling uninspired when we came to name it!
Ah, it looks like noone committed this change, so navbar_common_navigation is now in the release. Whoops - but not the end of the world. Nick, you could commit the correct name, updating README.CSS as appropriate, if you like?
Dominic.
On Mon, 26 Mar 2007, Dominic Hargreaves wrote:
Ah, it looks like noone committed this change, so navbar_common_navigation is now in the release. Whoops - but not the end of the world. Nick, you could commit the correct name, updating README.CSS as appropriate, if you like?
OK, done
Nick
On Mon, 26 Mar 2007, Nick Burch wrote:
On Mon, 26 Mar 2007, Dominic Hargreaves wrote:
Ah, it looks like noone committed this change, so navbar_common_navigation is now in the release. Whoops - but not the end of the world. Nick, you could commit the correct name, updating README.CSS as appropriate, if you like?
OK, done
I've also had to add another parent to navbar (id=navbar_parent), hope that's ok. This allows you to pull bits of the navbar over into another column (or more than two, if you want), and still have the rest of the guide positioned properly.
You can see it in two different styles on: http://cotswolds.openguides.org/wiki/wiki.cgi?The_Bird_In_Hand%2C_Hailey http://ogtest.torchboxapps.com/wiki/wiki.cgi?Evenlode_Books%2C_Charlbury
(The trick is to size the parent however big you want both to be, then add a left margin on the navbar itself to shift it out of the way, then position:absolute to put any other things in the required place)
Nick
Here's another little script that people might be interested in. It lists all the pubs in Category Good Beer Guide that don't have a node image set. It includes a drop-down list to let people restrict the results to a single locale. It'd be easy to modify it to search a different category - just change "good beer guide" in the SQL to whatever category you like (make sure to lowercase it).
See it in action at: http://london.randomness.org.uk/scripts/gbg-no-image.cgi
Kake
On Mon 19 Mar 2007, Kake L Pugh kake@earth.li wrote:
Here's another little script that people might be interested in.
Sorry, that shouldn't have been in this thread.
Kake
On Mon 19 Mar 2007, Kake L Pugh kake@earth.li wrote:
I wouldn't say that's a workaround - I'd say that's the correct way to do it! Well, modulo the "main-navbar" thing; it would be better to give each navbar "module" its own id. I don't understand why you're special-casing the categories/locales - surely people are just as likely to want to style other elements of the navbar as they are to want to style these particular elements. But anyway, yes, I'll move them into the navbar, if this is the only reason you left them out.
OK, this is now done. The common categories and locales are in navbar_categories.tt and navbar_locales.tt, which are INCLUDEd in navbar.tt as described in the mail I started this thread with.
Also, every navbar "module" now has a CSS id (apart from "site name" and "revision", which instead have classes for historical reasons - I'd like to change this if people don't mind), so you can style as much as you wish.
Before I made these changes, there was quite a lot of very specific CSS stuff for things like common_categories_title, common_category_link, etc - you don't need to do this since you can access those elements with e.g.
div#navbar_categories div.navbar_group_title { color: green; }
div#navbar_locales ul a { color: red; }
(For the interested, CSS changes are documented in README.CSS)
Kake
On Mon, Mar 19, 2007 at 10:55:32AM +0000, Nick Burch wrote:
Dom had a think about this, and I think decided we'd need to extend Config::Tiny, or use something else, to be able to do it properly. Dom - am I remembering you comments correctly?
I'm fairly sure I never suggested extending Config::Tiny, but we would have to use something else, yes. There's been discussion about what on the #openguides IRC channel this afternoon.
Dominic.
openguides-dev@lists.openguides.org
-
Bob Walker -
Dominic Hargreaves -
Kake L Pugh -
Nick Burch