Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Python Wiki & wiki Hosting?

Reply
Thread Tools

Re: Python Wiki & wiki Hosting?

 
 
Eric S. Johansson
Guest
Posts: n/a
 
      06-06-2004
Eric @ Zomething wrote:

> Greetings Comrades, Pythonistas!
>
> I am looking for guidance on the quick and easiest path to set up a
> Python wiki.


as others have undoubtedly suggested, there are numerous python Wikis available. Let me give you an idea that might make wikis more usable by mere mortals.

When I was CTO of a small startup, we used twiki to hold all of the development documentation. It worked reasonably well until the pages became quite large. Eventually, we all noticed that we didn't update our pages as we should because it was too much like work. Editing a markup language inside of a browser text area was lame. Even the CEO complained and said something we all should have recognized: "Why can't you edit wiki pages like you were in word".

with that simple statement, I realized that wikis are fundamentally good tools but they are hampered, horribly hampered by the user interface. 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.

---eric



 
Reply With Quote
 
 
 
 
Paul Boddie
Guest
Posts: n/a
 
      06-07-2004
"Eric S. Johansson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>
> When I was CTO of a small startup, we used twiki to hold all of the
> development documentation. It worked reasonably well until the pages became
> quite large. Eventually, we all noticed that we didn't update our pages as we
> should because it was too much like work. Editing a markup language inside of
> a browser text area was lame. Even the CEO complained and said something we
> all should have recognized: "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.)

> 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.

> 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?

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.

Paul
 
Reply With Quote
 
 
 
 
Eric S. Johansson
Guest
Posts: n/a
 
      06-07-2004
Paul Boddie wrote:

> "Eric S. Johansson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>> "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


 
Reply With Quote
 
A. Lloyd Flanagan
Guest
Posts: n/a
 
      06-07-2004
"Eric S. Johansson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
> Eric @ Zomething wrote:
>
>>> When I was CTO of a small startup, we used twiki to hold all of

the development documentation.
>>It worked reasonably well until the pages became quite large.

Eventually, we all noticed that we
>>didn't update our pages as we should because it was too much like

work. Editing a markup language
>> inside of a browser text area was lame.


While I like your suggestion for better editing, I've got to point out
that I think your real problem was that the pages "became quite
large". It would be much more "wiki-correct" to make a larger number
of small pages, with many links between them. Easier to use _and_
maintain.
 
Reply With Quote
 
Christophe Cavalaria
Guest
Posts: n/a
 
      06-07-2004
Eric S. Johansson wrote:

> Paul Boddie wrote:
>
>> "Eric S. Johansson" <(E-Mail Removed)> wrote in message
>> news:<(E-Mail Removed)>...
>>> "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.


Something like that maybe : http://www.mozilla.org/editor/midasdemo/


 
Reply With Quote
 
Eric S. Johansson
Guest
Posts: n/a
 
      06-08-2004
A. Lloyd Flanagan wrote:

> While I like your suggestion for better editing, I've got to point out
> that I think your real problem was that the pages "became quite
> large". It would be much more "wiki-correct" to make a larger number
> of small pages, with many links between them. Easier to use _and_
> maintain.


Thank you for raising that point. What you are describing is a higher level of operation above just formatting text and its presentation. so question now becomes how do you make these meta operations of partitioning and showing connectedness visible and *easy to do right*?

I believe the pages grew large (and large in my definition is over 1k characters given the crippled nature of text areas)because people want to keep connectedness between different components visible and there was no easy way to do this. For example, a list of product requirements tends to grow and really is an atomic element. how would you split that and partition information in a way that is useful to someone who doesn't already know what's there.

This is getting rather far afield from Python and related topics so I would not be offended if folks want to drop it or take it to private e-mail.

---eric


 
Reply With Quote
 
Paul Boddie
Guest
Posts: n/a
 
      06-08-2004
"Eric S. Johansson" <(E-Mail Removed)> wrote in message news:<(E-Mail Removed)>...
>
> yes, he did not actually want to use word and if you notice I said "like you
> were in word".


Yes, sorry: I afforded myself a rant about documentation in Word from
bitter personal experience of the subject. :-/

As far as editing tools are concerned, though, there are various
JavaScript/DHTML-based editing tools which give a pretty reasonable
WYSIWYG experience, producing HTML as output (obviously, since it's
all going on in the browser). You could then do various analysis on
the HTML to get Wiki-compatible information (if you really wanted to,
since it isn't strictly necessary), or go straight to the cutting edge
and produce some RDF.

[...]

> 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.


Well, that's the most interesting part as far as I'm concerned. We
could wait for Microsoft to produce their own perverted implementation
of the concept and let them sell it to various punters for $150 per
CPU per user, or we could consider how it could be done and move a few
steps closer to working code (although I'm fairly sure that if this
hasn't been done, the components are ready and waiting for it to
happen).

Paul
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
MacPython wiki "moved" to Python wiki - now it's your turn... skip@pobox.com Python 0 02-13-2007 04:27 AM
Wiki engine used by Ruby Wiki? Robert Oschler Ruby 3 06-25-2004 09:45 AM
RE: Python Wiki & wiki Hosting? Mahrt, Dallas Python 0 06-07-2004 09:52 PM
Python Wiki & wiki Hosting? Eric @ Zomething Python 2 06-05-2004 09:23 PM
general Wiki format question and Python Wiki markup parsing libraries chris Python 4 05-17-2004 05:27 PM



Advertisments