18 Mar
2007
18 Mar
'07
11:17 a.m.
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
19 Mar
19 Mar
10:55 a.m.
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
12:23 p.m.
On Mon 19 Mar 2007, Nick Burch <openguides(a)gagravarr.org> wrote:
Bob (um, or was it doop? One of them, anyway) suggested that we could
move to using YAML instead of Config::Tiny.
Kake
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?
12:44 p.m.
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
12:59 p.m.
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.
--
Bob Walker
http://www.randomness.org.uk/
Stress Kittens: Squeeze them till they cry!
The latest tech in homicidal tendency relief.
1:15 p.m.
On Mon, 19 Mar 2007, Bob Walker wrote:
--
Bob Walker
http://www.randomness.org.uk/
Stress Kittens: Squeeze them till they cry!
The latest tech in homicidal tendency relief.
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.
1 p.m.
On Mon 19 Mar 2007, Nick Burch <openguides(a)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
24 Mar
24 Mar
10:18 p.m.
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
10:31 p.m.
On Sat 24 Mar 2007, Nick Burch <openguides(a)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
11:02 p.m.
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
26 Mar
26 Mar
12:30 p.m.
On Sat, Mar 24, 2007 at 11:02:01PM +0000, Nick Burch wrote:
On Sat, 24 Mar 2007, Kake L Pugh 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?
Dominic.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
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!
12:52 p.m.
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
1:28 p.m.
On Mon, 26 Mar 2007, Nick Burch wrote:
On Mon, 26 Mar 2007, Dominic Hargreaves wrote:
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
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
19 Mar
19 Mar
4:52 p.m.
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
9:12 p.m.
On Mon 19 Mar 2007, Kake L Pugh <kake(a)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
5:25 p.m.
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.
--
Dominic Hargreaves | http://www.larted.org.uk/~dom/
PGP key 5178E2A5 from the.earth.li (keyserver,web,email)
6025
days inactive
6033
days old
openguides-dev@lists.openguides.org
16 comments
4 participants
participants (4)
-
Bob Walker -
Dominic Hargreaves -
Kake L Pugh -
Nick Burch