Wiki Engine Review Rhk Criteria Discussion

What I'm Looking for in a Wiki, then Why

The following discussion was refactored from WikiEngineReviewRhkCriteria. Some of the criteria listed there were changed after this was moved. I have changed some of the text here dealing with my reasons for the requirements, but have not changed SunirShah's comments to deal with any of my changes. So, I guess I'm saying read this at your own risk.

SunirShah asked me to motivate my requirements. This is that attempt.

I recognize that some of my reasons (whys) can be satisfied by a variety of capabilities. The requirement to never lose information could be met by password protected editing (maybe) or revision snapshots and rollback capability. I guess I might still like password protection - I can imagine some information that should not be edited except by authorized personnel, like LVLUG meeting announcements or whatever. Maybe not.

So security translates into some or all of the following:

  • Password protection on editing

  • Snapshots of most revisions, and associated rollback and diff capability

Also, the LVLUG (Lehigh Valley Linux Users Group) WikiSite might mirror another site (like the CLUG). If we do, it will be important to have an easy method to import and export pages.

The reason for the previous two capabilities is that I want my wiki pages to be portable. I may move (or copy) individual pages from one WikiSite to another, or I may someday switch from one WikiEngine to another. (I'd like to make as good a choice in WikiEngines as I can now, but I recognize that I may have to (or want to) change that choice in the future. I want the ability to do that as painlessly as possible. (But maybe I am violating the ExtremeProgramming principle of YouArentGoingToNeedIt.))

I don't know if mirroring a WikiSite makes sense. I started this quest with the idea of creating a WikiSite for the LVLUG to replace (or supplement) our discussion forum. I thought mirroring the CLUG site would allow both of us to develop "content" quicker. However, until we run into a bandwidth bottleneck, it makes just as much sense for us to simply use the CLUG WikiSite (with their permission).


Pedantic nit. When referring to this wiki, you can use the terms Wiki, WikiWiki, WikiWikiWeb, PortlandPatternRepository, WardsWiki, or TheOriginalWiki, etc. However, when referring to any particular wiki, use the term "wiki" (lowercase). It's much less confusing, especially if you consider cases like the wiki community and the Wiki community.

Ok

Anyway, I shall respond.

Never lose data.

You will automatically fail with a wiki. With the ability to edit other people's text, you can delete, destroy, maim, mutilate, "refactor", move, improve, correct, beautify, etc. existing content. If you respond by maintaining full history, you defeat the purpose of using a wiki: the ability to correct mistakes collaboratively. Instead, you will never forget embarrassing mistakes, unpleasant episodes, vandalism and outright flamewars.

Consider the extreme case if someone posted porn images on a wiki; you could never "forget" the porn and thus, in some way, you are presenting porn on your site. If you did that on a wiki hosted on sunir.org, I could be in big trouble as my site license forbids porn or piracy.

Indeed, read and understand why the WikiNow is absolutely important with an open community.

In a externally constrained organization where complete document tracking is necessary, like say a law firm or a software development house, full history may be essential. This is why we all use version control systems for our source code, for instance. (Well, I wish.)

I understand what you are saying. I believe I can deal with the problems with the right wiki software. I will be looking for a system that stores frequent "revision snapshots" but I will also look for a tool that gives the administrator (at least) the ability to remove pages that must be permanently deleted.

Edit locks

If you do not wish unauthorized people from editing the material, why post it on a wiki? Just use a separate static space for that. Since you are all using Linux, create a group-shared web space for all the administrator.

Making a strong dichotomy between end users and administrators is not a good thing. No one likes god kings (http://usemod.com/cgi-bin/mb.pl?GodKing).

Easy to install in Linux

Most Perl implementations just require that you are running httpd (Apache) and have Perl 5 installed (which is standard on Linux distributions now). Maybe a little mucking around with Apache to turn on CGI scripts, but nothing that you wouldn't need to learn anyway. Things like PHP, ZOPE, JSP, ASP may land you in trouble. Python may come pre-installed, but it's not hard to install anyway.

Running a LUG's website on Windows would be interesting. You could probably anthologize the flamewars for future readers' entertainment.

Yes, it could be interesting. I expect Linux to meet my needs (which sort of implies taking over the desktop), in one to three years. The members of the LVLUG recognize that Linux is not perfect.

Finding information

This is a non-trivial problem. Wikis are extremely bad at information retrieval, often requiring the members to manually link pages together by memory. On the other hand, they are extremely good at letting people build interesting structured hyperdocuments quickly. Most users have a "getting lost" feeling on a wiki because there is no real starting place. Of course, there are the front page, StartingPoints, and a RecentChanges variant on most wikis, but these aren't as useful as the front page of CNN, for instance.

See http://usemod.com/cgi-bin/mb.pl?IndexingScheme for a collection of known (to Meatball) indices.

Also, make Google to index your site.

I'm still confused about what I must do to make Google (or Alta Vista, or ?) index my site. I think I understand that at least some Web search engines will not normally index dynamic web pages. Ahh, but I need to remember what CliffordAdams wrote to me - I think the inference I made was that Google and some other search engines could cache your site (or more likely, I have to cache them at my site) and then Google will index them.

E-mail notification

You won't be able to get the wiki off the ground if you don't monitor it, contribute to it, market it regularly. Wikis don't work until you reach a critical mass of community such that there are always some people contributing at any given time. If you don't have enough eye balls, the PeerReview and most of the SoftSecurity will fail. This is why most open source projects die.

It's a common engineering fallacy to believe if you build it, and it is good, they will come. But as any good marketroid knows, you must advertise, build, encourage or it will fail.

Attract an audience!

I understand, and we (I) might have to do more of that, but my goal is to attract people who need information and who are willing to contribute information.

Security because the content many change

If you are concerned that the content is in constant flux, you really don't want to use a wiki. Wikis facilitate dynamic content. If you want static, archived content, you need a technology that facilitates that.

Consider a WebLog. I recommend the kuro5hin Scoop engine: http://scoop.kuro5hin.org.

I looked quickly and will look again.

Passwords

Passwords are evil. Actually, if you listen to JefRaskin, passwords are stupid. You have an unsecure identifier (your log in name) and a secure identifier (your password). Why do you need both?

Anyway, consider the opposition: on one hand you have a completely open editing structure; on the other, you prevent anyone from getting at it.

Passwords are possibly contingently maybe ok if you want to fishbowl the wiki - i.e. have a small group write the content, while the rest of the world can only read it. For instance, the OrgPatterns site does this. You can also use this for developer's notes that you publish to the web so third party users can see what's going on without fubaring your work.

Tables

Tables are bad. You can't read them in Lynx. Not good for a LUG. Aim for HTML 1.0.

http://usemod.com/cgi-bin/mb.pl?LynxFriendly.

Embedded HTML and more gross style tags

HTML is evil. I really hate the <b> and <i> tags on UseModWiki. In fact, you can see why on http://usemod.com/cgi-bin/mb.pl?EmphasisPattern.

Anyway, there is no good reason to embed HTML. Usually what you want can be easily accomplished with the existing syntax and use of English (English is good!). Consider that books have been published without JigglingBaloney for centuries now, using only a small set of formatting primitives. You can do the same.

Content over form. Information over style.

See also

Fubaring the LinkPattern

"Enhancing" the LinkPattern (which makes for WikiNames) is usually a bad idea. You usually wind up breaking accidental linking, which breaks the wiki. The constraints make you stronger. J.S. Bach said that his art was in the form. Poets know this too, which is why free form poetry is often crappier than structured poetry. Haiku forces simplicity. The "impoverished" LinkPattern makes for better names and better guesses.

See also

InterWiki

Yes! InterWiki is goodness. Well, more like http://usemod.com/cgi-bin/mb.pl?InterWiki, not the InterWiki talked about here.

By the way, UseModWiki/MeatballWiki publishes its intermap.txt file for public consumption. You can also petition to add things to it. See http://usemod.com/cgi-bin/mb.pl?InterMap. It already has a handful of subscribers.

Subpages

This is iffy. Most of the pages you have generated here probably can be deleted. In fact, most of the content can be deleted. The template format you are using for the reviews is excessive. A nice essay would be better, and even that would best fit on the pages describing the wiki itself. Like "MoinMoin" and "UseModWiki." WikiCloneReviewMoinMoin? is pretty obtuse.

There was a nice comment on this wiki from 1995 about how the pattern movement was bogus because it only set about to obfuscate the existing textbook format with ugly templates. I agree (somewhat). Too much structure obscures the point.

I guess this is the point that I most wanted to respond to you on. I agree a nice essay would be better, but the essay comes after I collect the information. I intend that the review pages be a permanent repository of information about each wiki (and revision). For lots of reasons. Someone else comes along, wants the same information, there it is, hopefully organized in a way that they can find and use it. (And, being a wiki, they can reorganize it if need be.) Granted, some of the information on the review pages is subjective. I can probably not eliminate that entirely, but maybe I should strive for that.

Import / export capabilities

This is trivial on all web sites. Just save the HTML. If you want the WikiSyntax, save the text in the edit box. If you own the wiki, just back up the PageDatabase. You can also write a simple Perl script to save almost anything you want. There was a script available to archive material from this site floating around somewhere... not like it's difficult to write.

Of course, I agree. In many cases you'd just like some easy feature to bundle up the WikiSyntax version and save it somewhere for you. Cliff is working on this for UseModWiki in theory.

Then again, I'm dubious about its benefits. I really despise it when people archive copies of material for political ends. There was one person who was saving EditCopys [sic] of a WikiVote? here, which is rather unethical. Nonetheless, this can easily be accomplished with any decent browser by saving the HTML source.

I can see it (saving EditCopys) being not nice or against the social norms of this wiki, but I'll have to look up ethical.

Besides, I refer you to the WikiNow again.

And I also refer you to the fair use section of your local copyright statute. Mirroring is usually not allowed (or even ethical) without permission.

Just for the record, absolutely. We would get the required permissions.

Translators

Learn Perl. Perl is good. ;)

-- SunirShah

Learn Python. Python is better. -- JuergenHermann

Go back to Algol60, PL1, TurboPascal - then I wouldn't have to try to learn this new fangled stuff. -- YoungAtHeart?


CategoryWikiEngineReview

EditText of this page (last edited December 22, 2007) or FindPage with title or text search