A recent thread on the Drupal documentation list has brought up once again the "why don't we have a wiki on Drupal.org?" question. It comes up regularly; you can set your watch by it.
What I've never understood is why anyone would want to take a step backwards from Drupal's handbooks to a simple wiki. How would removing features and capabilities help Drupal's huge pool of documentation?
What exactly makes something "a wiki"? Let's examine:
- Any user (or some large pool of users) can add content.
- Any user (or some large pool of users) can edit content.
- New pages can be created ad hoc as needed.
Optional attributes include:
- There is an "editor" person or team that can police additions and edits.
- There is a custom, usually proprietary, syntax for writing HTML without HTML.
So now let's examine Drupal's current documentation situation:
- Any user with an account can add a book page.
- Any user with an account can add a comment to a book page.
- New book pages may be created as children of virtually any other book page.
- There is a Docs Team that folds comments back into pages as appropriate, can roll back changes, and delete spam pages.
- You can enter a subset of real HTML, plus project issue numbers auto-link.
Guess what? Drupal already has a wiki; it's called the handbooks. So it runs Drupal rather than MediaWiki, and doesn't invent yet another new proprietary syntax that you have to learn. That's a good thing!
What's unique about the "book-as-wiki" configuration that Drupal already runs and has run for years is that it is structured rather than a disorganized blob. A "disorganized blob" wiki is useful in precisely one circumstance: When all entries are simple nouns. That works for Wikipedia. Drupal book pages are not all simple nouns, and therefore a disorganized blob is inferior to a structured setup you can read through linearly where appropriate.
The book module structure supports both structured organization (hierarchy) and limited cross-cutting organization (tags, currently just for Drupal version). That is superior to a "blob" wiki which provides no organization or just limited categories. Perhaps the handbooks could benefit from more robust tagging options, but that has nothing to do with a wiki. Drupal's own taxonomy/tagging options, if used well, are second to none.
Is there a problem with the "parent" selector getting too big on Drupal.org? Certainly! What does that have to do with a wiki? Throwing out the idea of a hierarchy just because the hierarchy is big is, quite simply, moronic. However, in Drupal 6 the book module underwent a major (and somewhat painful) rewrite to modernize it and allow it to better handle huge book hierarchies. That was done very deliberately with an eye toward making life easier for the Drupal.org handbooks. Progress takes time, but it is happening.
So what "wiki" features is Drupal.org missing that are so desperately important?
Having 5 people discussing a feature right in the body of a page? That's misleading and distracting, and can happen right now in the comments available on every single page.
Letting anyone post corrections? That happens right now in the comments on every single page, and anyone can file a documentation issue to fold a comment with a correction back into the body. (The Docs team is very fast about those, in my experience.
Linking across arbitrary pages? If you can use an <a> tag, you can do that right now.
A non-HTML syntax? Great, because learning self-documenting HTML wasn't hard enough, we invent a new less self-documenting syntax instead. Thanks but no thanks.
No, Drupal.org doesn't need a wiki. It already has one; one that has more features than any other wiki software I've ever seen. It's called book.module, and it is doing its job quite well.
The challenge for the handbooks is to improve the structure and organization of the page hierarchy so that they make sense (something a "blob" wiki is fundamentally incapable of doing). That takes a great deal of time, thought, and effort, especially when dealing with over 100,000 pages. But guess what? At the DrupalCon Boston code sprint, I was seated not far from several of the Docs team leads who were working on doing exactly that, having flown across the country to meet so that they could do exactly that.
Throwing away data solves nothing, which is exactly why a wiki is not what Drupal.org needs.
Good Points
Good points. Maybe I just need to learn more about this point: "New book pages may be created as children of virtually any other book page" in order to stop doing battle with documentation entry. Ahah! This "moronic" soul never noticed "add child pages." (Actually I think it's partly that the URL I was directed to on the IRC was the page with the big humongous drop-down; That's the page I keep wrinkling my nose at.)
Maybe once we get a good new structure, someone could do a brief screencast, to make the obvious stand out even more. :)
I wonder if the drop-down problem could be handled with some ajaxy search-type approach. I noticed that civicrm lets you use %search term% to find any item that matches a term in their search block, even if the word isn't at the beginning of the result.
sorry...
...didn't mean to be anonymous on the post above.
Links do get missed
Yeah, I have found that the Add child page gets missed a lot. I look forward to a redesign where we can generally make it clearer to folks how to interact with the handbook. 3 things I'd like to see clearer:
1) Adding a new page
2) What comments are for (not support)
3) How to report a problem/edit
And also, you just said the magic word with screencast! /me thunks head. I shoulda thought of that. I'll add docs/using drupal.org to my list of videos to get made. Perfect!
Ajaxy
In D6, the drop down is book-specific rather than global. You pick the "book" in one drop-down and then a second drop-down is AHAH-populated for just that book. It's still going to be big on Drupal.org, but on the order of hundreds not thousands. That's a big improvement on its own. :-)
I don't think a complete text-lookup is good for what is really hierarchical, not flat data (which is the whole point). However, chx was working on a multi-select control that barely missed the cut-off point for Drupal 6; select one level, a second select box appears to select the next level, and then a third appears, etc. I think Wim Leers did something similar in contrib recently. Whether or not that will ever make it onto drupal.org I don't know, but perhaps someone should look into reviving that patch for book module in Drupal 7.
Hierarchical Select 2
Wim Leers' module is Hierarchical Select 2 and its very nice (although I haven't checked to see how it degrades without JS.)
Demo site: http://wimleers.com/demo/hierarchical-select
Hierarchical Select 3 will be more scalable
Hierarchical Select has always degraded, but not very elegantly: it degrades to a normal select. That means that JS-enabled Hierarchical Select (well, without JS you can't really call it a hierarchical select) simply works *on top of* a normal select. That immediately explains its scalability issue: what if you've got 80k+ items in your hierarchy? Then the HTML will be *huge*. This is of lesser importance for drupal.org, but still relevant.
So, for Hierarchical Select 3, I will be removing the current normal select and using the system chx proposed. The only difference: I will be writing it for Drupal 5 first. Too many clients are still on Drupal 5 to only do this for Drupal 6. I'm sure it'll be challenging, but it has to be that way.
When Hierarchical Select 3 is ready and ported to Drupal 6, I'll start an issue for inclusion on Drupal.org. It works well in all browsers, except for Opera: the CSS seems to be problematic there. If you're good at CSS and want to help, please contact me :)
Comments vs "Discussion" page
One thing I find is that the "Discussion" tab on mediawiki and its associated page are IMHO cleaner and more efficient that the current threaded comments system:
Maybe, if others shared that opinion, it would be possible to keep the drupal commenting model but with such a resulting UI for page readers. We would have the best of both worlds.
Agree with your oppinion in
Agree with your oppinion in most, but ...
In Drupal (core, without third party modules), there is no option to automatically create "non-existing" pages (as in most wikies, create link in come content, and if target doesn't exist, link leads to "create new page" or something like this)
freelinking
There's a freelinking module if you wanted to go that way. Again, though, that leads to disorganized content. I'd much rather people use the "add child page" link, which provides clean separation and document structure. You can then link directly to such a page with an
<a>tag. Again, not a "pure wiki" I suppose but still has most of the benefits of a wiki without most of the problems.Actually NO, Drupal isn't a Wiki
There are 2 main things that define something as a Wiki and that is:
1. Anyone (with or without an account) can edit the page directly
2. Admins can roll the page back to a previous version which makes it vandal/idiot proof, and more importantly point 1 viable.
3. (optionally) Anyone can see any of the revision at any time.
There are a few problems with your argument here. The idea of a "Team that folds comments back into pages as appropriate" seems to ignore the fact that this _is_ an extra step which equals extra work. You seem to ba ignoring the simple principal: "Humans are lazy". Wikis eliminate this extra step/control and hence they are very popular because they give people the feeling of empower and make the labour of documentation faster than a Drupal alternative. Since Drupal doesn't support point 2 rollback, it needs:
1. User accounts
2. An extra team to monitor comments
3. Slower documentation process which in large organisations could result in bureaucratic nightmares (in my experience).
Drupal could have a Wiki module, I don't know why it doesn't. It would pick up more business if it did. I find the "handbooks" to be quite a crude in comparison to a Wiki: "Lacking in detail".
Narrow view
If you split hairs between the body and comments on a page, then yes book.module is not a "pure wiki". At one point a few years ago the Docs team tried opening up the entire handbooks to global editing like a "pure wiki". The amount of work required to undo all of the vandalism and flat out wrong information that ended up intermingled in handbook pages was far more than the work required to fold comments back into the body manually.
Just having versioning ability does not make a site "vandal/idiot proof", it makes it "recoverable from vandals and idiots", assuming the Docs team has the bandwidth to police it. Given the problems Wikipedia has had with factually wrong articles persisting for months before being corrected, I don't think that is a solvable problem. I'd much rather have low-barrier gatekeepers like we do now.
Drupal has at least two, probably more ways to set up a "pure wiki" in under 10 minutes. That doesn't mean drupal.org should do so. I find a "pure wiki" to be quite crude in comparison to the Drupal handbooks: "Lacking in organization".
Re: documentation issue
Some really thought provoking points--thank you for taking the time to respond to my issue.
When I made the original post what I was most interested in seeing feedback on was whether or not there is a way to present the documentation that is out there in a more coherent fashion. Wiki or not, the documentation remains to be organized in a useful way. I think this is more of a marketing issue than it is a technical one, though of course, there are significant technical questions that come up.
Blob vs Network
I have installed and used Drupal books and Wikimedia. A wiki is a network of links, not a blob. Wikis have the ability to be organized in interesting and complex ways. Hierarchies work well for some purposes and networks work well for other purposes. The informed user knows when to chose the right tool for the job.
Developers Dictionary(wiktionary) / Encyclopeda(wikipedia)
Drupal book pages are not all simple nouns
This is undeniably true, but at the same time all my experience trying to help new developers "get it" suggests that there's a real lack right now of well-orgnized concept-documentation. The handbook primarily reads like an owners manual, which is what they should do, but for people who are still working to grok The Drupal Way, a reference guide to terminology and concepts -- what's a node? what's a hook? etc -- would be very helpful.
The general handbook has a couple pages like general concepts, but they're buried and lack some detail. I think a lot of people who bemoan the "lack of wiki" are really bemoaning a lack of concept-oriented documentation, which would be organized mostly around the simple nouns which newcomers encounter and find hard to grasp.
For my money, the desire is less about people wanting to contribute wiki-style, and more about a desire for documentation to be organized or presented or differently.
Actually, there are some
Actually, there are some modules exist to support wiki in Drupal. You could check these modules at http://drupal.org/project/Modules:
- wikitools
- Liquid Wiki Engine Project
- freelinking
- pearwiki_filter
- talk
- backlinks
- diff
- tableofcontents
What we need are a more robust revision system (diff module) like the one in MediaWiki and the ability to edit only a section without editing the whole page.
There is also an ongoing discussion on this topic in Drupal group:
http://groups.drupal.org/wiki
Hope it helps.
you overlooked the MOST important aspect for the user
In your post you have missed the most important aspect of a wiki for the user. That aspect is the [[mediawiki markup]]. If you do not have this aspect, you really don't have a wiki as far as the user is concerned.
Perhaps if you simply added the mediawiki filter to posts on drupal pages you could argue that you have a wiki, but until you have the media wiki mark up, you don't have a wiki as far as the user is concerned.
False
Considering that MediaWiki is one particular wiki application, and its fake-HTML syntax is proprietary and not the same as any other wiki application's, and other wiki applications also have their own particular quirky syntax, I dispute your claim. Unless you're saying that a wiki is defined by having an obscure, proprietary syntax that is less self-documenting than HTML but gets converted to HTML anyway, in which case I'd call wikis a blight upon the Net and something Drupal should actively avoid. :-)
Wiki links and discussions
Being a wiki expert (see below) but hardly having any experience with Drupal I got pointed to this discussion. Let me add my 2 cents:
Linking
One of the most important wiki features to me is the easy way to link articles. If we assume that every page has a short name (need not be a noun, but it's sometimes convenient) that can easily be remembered, you can just write the name of the page and a little bit of syntax, and it will be linked – even if the target does not exist: then the user gets the opportunity to create it after following the link.
I do not want to remember a numeric ID of a page, and I want links to be short. In the current context (don't know the Drupal terminology, in most wikis it's a namespace) I just want to write the name of the page, and for resources in other namespaces or probably on other websites frequently linked to I prefer a prefix:name syntax instead of full URLs. And if my link target does not exist, I do not want to get an error message but an editing form.
Some older wikis linked WordsWithMixedCapitalization, most newer wikis use some kind of [[brackets]]. Of course this is primitive, and Drupal could of course do better, e.g. by offering an automatic completion of link targets while the user is typing. Secondly, in many wikis there is no "create content" button, so creating a broken link and then traversing it is actually the only way to create content. Of course it is good to have the "create content" button, but sometimes a broken link can serve as a to-do item: "I know that I want to create that piece of content, and it should be linked from this place, but I want to create it later."
Syntax
With a good WYSIWYG editor the question of text syntax vs. HTML should eventually be obsolete. But as long as WYSIWYG editors are still not perfect, my opinion is that HTML is just too verbose for many simple things that make 90% of your content. (On the other hand, it makes complex things possible; just compare how messy tables are in MediaWiki.) With WikiCreole there is an emerging standard that is supported by more and more wiki engines (just not yet by MediaWiki, sorry).
Discussions
I think that threaded discussions are much more advanced than wiki discussions. In fact, I would like the "discussion" tab in every wiki be a container for a threaded forum. Wiki discussion pages that are "just" wiki pages (with a bit convenience maybe, such as the "add section" button in MediaWiki) are just too primitive, and users need to respect a lot of conventions, e.g.: indenting replies, signing your post, not editing others' posts.
What is a wiki
There is a common misconception, part of which I have also seen on this page: Many people think Wiki = Wikipedia = MediaWiki, but there are other engines than MediaWiki (just see http://www.wikimatrix.org), and there are other sites than Wikipedia. For example, the [[bracket link syntax]] is not a key feature of a wiki in general, but of some wikis; the actual wiki feature is easy linking, however it is done. The possibility for admins to roll back changes with a single click is a feature that AFAIK only MediaWiki has (coming from the negative experience with vandalism on Wikipedia), but the general wiki feature is that it is easier to restore an old version than to do serious damage.
My wiki expertise: Wikipedia admin since 2004, edited two books about wikis, having administered more than 5 different wiki engines, and doing research on semantic wikis
great discussion
hey folks,
so glad to hear all your thoughts on this.
I'm in the midst of a discussion of how to create a wiki like component to a large site I'm working on.
Key elements seem to be that
- users need to be able to edit the the current page they are looking at for additions and changes to content.
- there is not a large staff base to moderate and change content
- items need to be categorized with tags
i'm looking at trying to keep it within the drupal system so that there aren't two user accounts.
but i have to say, even though some really smart people have often encouraged me to use books, I just find it a system that doesn't seem to work well for me. Maybe it's a theming issue, and yes so much of drupal's smartness could be so much better with good theme examples. I'll take another look at it and see if I can make it clearer to myself and all the random users who'll be accessing it.
thnx for all the good info/thoughts above tho.
wiki-ness
Yes, to a first approximation, drupal.org is sufficiently wiki-like.
The next step in usability is to add links to the conventions and to the accepted ways to navigate and enhance.
My own initial impression has been that drupal.org is less well-organized and searchable than the web at large (ymmv, ianal, ls/mft).
Wiki Features
Wikis offer an assortment of features where not every feature is important for each use. I have used lots of Wikis and while all the "content sites" that are for the general public have been Drupal or Joomla, that doesn't mean I don't see places for a Wiki. Suggesting that Drupal users "have it in Handbooks" or "don't need it" is just plain wrong.
On my NicaLiving site, we have an assortment of issues. One of them is the ability for an arbitrary user to "contribute to a list". I my recent post there I used a "trusted taxi driver" list as an example. The critical element for this would be a linked-to page that anyone could edit.
Now, maybe there is a good Drupalish way to create such a page but, if there is, I have missed it. But, if there was really a Wiki within the Drupal site, this would be the default behavior for such a page. This is a specific current need but, if there really was a wiki within Drupal (and, with a bit of creativity, it seems there is these days), I would use more Wiki features to address additional needs.