Python Wiki & wiki Hosting?

[Eric S. Johansson]

Paul Boddie wrote:

> "Eric S. Johansson" <esj at harvee.org> wrote in message news:<mailman.629.1086534578.6949.python-list at python.org>...
>> "Why can't you edit wiki pages like you were in
>>word".
> 
> 
> Development documentation in Word? Welcome to a world of pain! Sounds
> like exactly the sort of thing a CEO would want to have. (Yes, of
> course I'm twisting the very meaning of the words, and perhaps the CEO
> didn't actually want you to use Word.)

yes, he did not actually want to use word and if you notice I said "like you were in word". :-)

he was looking for a WYSIWYG interface on the tool.  And I have my own reasons for wanting it as well.


>>with that simple statement, I realized that wikis are fundamentally good tools
>>but they are hampered, horribly hampered by the user interface.
> 
> 
> I'm not entirely in agreement. Certainly, the more arcane Wiki
> syntaxes in use somehow make the most straightforward notes baroque,
> whilst hardly scaling up to the level of sophistication required to do
> things like tables, for example. But I'd argue that when using Wikis
> to store information, minimalism is crucial, duplication of
> information (as is common in more traditional documentation) should be
> avoided, and linking should be used aggressively. Consequently, I'd
> imagine that many "high end" presentation techniques could be avoided,
> although the output might not, admittedly, look that good. Still, one
> could always postprocess the results, offer multiple "views" of the
> underlying data, and so on.

I think we are mostly an agreement.  I would however point out that I was talking about a user interface at a basic level.  The markup language itself, as far as it goes is an impediment.  The fact that you're editing is in a text area is another usability impediment.  one of the biggest pains is that you can't search in a text area.  It got to the point where many of the developers would cut the information out of the text area, work on it in Emacs, and paste it back.  The end result being that many changes were not made without a great deal of nagging on my part.

all I want this to take what a wiki presents and put a better user interface on it.

>>the project would be figuring out how to manipulate a wiki using a WYSIWYG
>>infrastructure components such as abiword.  The reason I suggest using abiword
>>as the base is that it is a reasonable, lightweight word processor that can
>>use plug-ins written in Python.
> 
> 
> Why not use anything which can save documents in a half-decent
> representation (possibly XML since the user shouldn't actually see it,
> but it lends itself to deconstruction) and upload the documents to the
> Wiki?

again, we are saying the same thing from different angles.  At the end of the day, I don't give a flying fire truck what the internals are.  All that should be there is a WYSIWYG interface to changing a wiki page with all of the features of the wiki available.  That's all that matters.  Click some button or link to edit, make your changes, hit another button to save or cancel and you are done.  No need to preview because what you see is what gets uploaded.

know we can blather on about how to make it work etc. but quite frankly, that's not my concern unless I'm writing the code.  I'm content to leave the determination of internals to the developer who makes it work.

> As far as I can tell, from looking at how various moderately large
> public Wikis are used, the biggest problem (apart from filtering out
> vandalism) is keeping the structure pertinent (so-called Wiki
> refactoring) and up-to-date.

scalability is a function of usability.  Another thing to consider is that there are people who can contribute information and people who can edit information.  For example, I've been doing a fair amount of writing on the camram project (hybrid sender pays anti-spam).  I can put a bunch of words on a page and if you work real hard you can understand what I'm trying to say.  But fortunately, I have a friend who was a writer and is willing to be my editor.  He is able to extract meaning that I hadn't known I had put there.  End result being that I have something which is clearly my words but has a polish and readability that I didn't know was possible.  The end result is that I list as a coauthor on papers and articles such as the one published in Technology Review online a couple of months ago.

The point of this preamble is that wiki's need editors.  They need someone who can go through and do the refactoring, grammar changes, rewrites etc.  Without these editors, it's less useful information.  The question is, how to bring these editors to the wiki?  I will argue that while good human factors won't bring people, it will make it easier to not drive them away.

---eric