----- Original Message -----
From: "Daniel Barrett"
<danb(a)VistaPrint.com>
1. A desire for a department to have "their own
space" on the wiki.
I'm not talking about access control, but (1) customized look & feel,
and (2) ability to narrow searches to find articles only within that
space. The closest related concept in MediaWiki is the namespace,
which can have its own CSS styling, and you can search within a
namespace using Lucene with the syntax "NamespaceName:SearchString".
However, this is not a pleasant solution, because it's cumbersome to
precede every article title with "NamespaceName: " when you create,
link, and search.
If the *concept* of namespaces could be decoupled from its title
syntax, this would be a big win for us. So a namespace would be a
first-class property of an article (like it is in the database), and
not a prefix of the article title (at the UI level). I've been
thinking about writing an extension that provides this kind of UI when
creating articles, searching for them, linking, etc.
Some way to search within categories reliably would also be a huge
win. Lucene provides "incategory:" but it misses all articles with
transcluded category tags.
2. Hierarchy. Departments want not only "their own space," they want
"subspaces" beneath it. For example, "Human Resources" wiki area
with
sub-areas of Payroll, Benefits, and Recruiting. I realize Confluence
supports this... but we decided against Confluence because you have to
choose an article's area when you create it (at least when we
evaluated Confluence years ago). This is a mental barrier to creating
an article, if you don't know where you want to put it yet. MediaWiki
is so much better in this regard -- if you want an article, just make
it, and don't worry where it "goes" since the main namespace is flat.
I've been thinking about writing an extension that superimposes a
hierarchy on existing namespaces, and what the implications would be
for the rest of the MediaWiki UI. It's an interesting problem. Anyone
tried it?
What you want, I think, is what Zope2 called "acquisition". It's like
OO subclass inheritance, but it's *geographic* depending on where you
were in the tree; the old Mac Frontier system did something like it
too.
You want links to have a Search Path, that starts with whatever part/
subpart of the tree the current page is in, and then climbs the tree,
ending in the unadorned Main namespace, whenever a user clicks them.
That breaks the semantics of wikilinks some, but that's probably ok
for your use. It *might* be generally useful; I'm trying to figure out
if there are any obvious common use cases that it breaks, and how you
tell where in the tree a page lives when it's created (and how you
would show that to users).
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates
http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA #natog +1 727 647 1274