I’ve noticed a lot of top-level namespace pollution, and would like
everybody to know about the remarkable feature of Wiki sub-pages.
Basically, any top-level Wiki page can act as a self-contained Wiki
(to some extent). This has two benefits:
On this page there are many links to other pages that can be
considered to be “within” the cookbook, but they are all top-level.
It would be conceptually and practically nicer if, for example,
How easy is it to move a page to a different location? Since the Wiki allows
you to see which pages link to a given page, it’d be easy enough to track
down an update all the links, although this wouldn’t help for links outside
the Wiki. I guess you could just replace it with a little message saying
“Moved to FooBar/WhatEver” - this wouldn’t remove the namespace clutter,
though.
Tim Bates
···
On Sun, 12 Jan 2003 12:50 am, Gavin Sinclair wrote:
Hopefully one day, it will be easier to organise the Wiki thanks to
sub-pages.
No, but that would be a good start. I’d suggest putting the string
“@deprecated@” in there so someone can search for those and remove
them sometime down the track.
There’s no way I know of to move Wiki pages.
Gavin
···
On Sunday, January 12, 2003, 1:34:27 AM, Tim wrote:
On Sun, 12 Jan 2003 12:50 am, Gavin Sinclair wrote:
Hopefully one day, it will be easier to organise the Wiki thanks
to sub-pages.
How easy is it to move a page to a different location? Since the
Wiki allows you to see which pages link to a given page, it’d be
easy enough to track down an update all the links, although this
wouldn’t help for links outside the Wiki. I guess you could just
replace it with a little message saying “Moved to FooBar/WhatEver” -
this wouldn’t remove the namespace clutter, though.
As admin,[1] I can do that. However, I was wondering what problem we’re
trying to solve here. Wiki’s are not intrinsically hierarchical
structures: they are designed to be mostly flat. In fact, there’s
sometimes an interesting serendipity involved: you edit a page putting
in a WikiLink to some new fact you want to talk about, only to discover
that the page already exists.
On Saturday, Jan 11, 2003, at 08:41 US/Central, Gavin Sinclair wrote:
No, but that would be a good start. I’d suggest putting the string
“@deprecated@” in there so someone can search for those and remove
them sometime down the track.
No, but that would be a good start. I’d suggest putting the string
“@deprecated@” in there so someone can search for those and remove
them sometime down the track.
There’s no way I know of to move Wiki pages.
As admin,[1] I can do that. However, I was wondering what problem we’re
trying to solve here. Wiki’s are not intrinsically hierarchical
structures: they are designed to be mostly flat. In fact, there’s
sometimes an interesting serendipity involved: you edit a page putting
in a WikiLink to some new fact you want to talk about, only to discover
that the page already exists.
I totally agree, but there are pathological cases (like the one I made
an example of: LicenseIssues, which sounds general but pertains only
to the RubyOnlineCookbook). Over time, these patholical cases
increase in number, and the classic Wiki problem emerges: you can’t
see the wood for the trees. There’s a lot of good stuff in there, but
there’s also a lot of pollution.
That’s why I’m glad that subpages can go only one deep: the Wiki
stoutly refuses to be over-categorised, but allows refactored pages to
have a local frame of reference.
In short, sub-pages are a good feature that have their place. Also,
the Wiki is a good resource that needs a little administration now and
then.
Your point about serendipity is well made, though. I may have been
guilty of overusing them, but only slightly
As admin,[1] I can do that. However, I was wondering what problem we’re
trying to solve here. Wiki’s are not intrinsically hierarchical
structures: they are designed to be mostly flat. In fact, there’s
sometimes an interesting serendipity involved: you edit a page putting
in a WikiLink to some new fact you want to talk about, only to discover
that the page already exists.
FWIW, I went to the trouble of adding full hierarchy support in my
home-grown Ruby wiki I use on the job. Before I added it, I was using it to
manage stories for projects and started creating page names like
ProjectA_ModuleB_AddTheThingToTheOtherThing, the length of the names was
getting a little much. Plus, similar to Gavin’s comments, I wanted to have
pages like KnowledgeBase, for different apps: ProjectA/KnowledgeBase,
ProjectB/KnowledgeBase.
I’ve been using it for some months now – it’s a bit weird, and some uses of
the hierarchy come back to bite me, there’s a balance and such a thing as
too much hierarchy. Plus it’s easier to have duplicate pages living under
different parent dirs, thrwarting said serendipity. Anyway, just my $.01.
Yes, I think the more you look at it, the more it becomes clear
exactly when a given Wiki page should be a sub-page.
“A general-sounding title being applied to a very specific
area of knowledge or endeavour is a Wiki smell.”
– Gavin Sinclair, 2003-01-12
···
On Sunday, January 12, 2003, 4:16:31 PM, Chris wrote:
As admin,[1] I can do that. However, I was wondering what problem we’re
trying to solve here. Wiki’s are not intrinsically hierarchical
structures: they are designed to be mostly flat. In fact, there’s
sometimes an interesting serendipity involved: you edit a page putting
in a WikiLink to some new fact you want to talk about, only to discover
that the page already exists.
FWIW, I went to the trouble of adding full hierarchy support in my
home-grown Ruby wiki I use on the job. Before I added it, I was using it to
manage stories for projects and started creating page names like
ProjectA_ModuleB_AddTheThingToTheOtherThing, the length of the names was
getting a little much. Plus, similar to Gavin’s comments, I wanted to have
pages like KnowledgeBase, for different apps: ProjectA/KnowledgeBase,
ProjectB/KnowledgeBase.
I’ve been using it for some months now – it’s a bit weird, and some uses of
the hierarchy come back to bite me, there’s a balance and such a thing as
too much hierarchy. Plus it’s easier to have duplicate pages living under
different parent dirs, thrwarting said serendipity. Anyway, just my $.01.
