Re: Python Wiki & wiki Hosting?

Discussion in 'Python' started by Eric S. Johansson, Jun 6, 2004.

  1. 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
     
    Eric S. Johansson, Jun 6, 2004
    #1
    1. Advertising

  2. Eric S. Johansson

    Paul Boddie Guest

    "Eric S. Johansson" <> wrote in message news:<>...
    >
    > 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
     
    Paul Boddie, Jun 7, 2004
    #2
    1. Advertising

  3. Paul Boddie wrote:

    > "Eric S. Johansson" <> wrote in message news:<>...
    >> "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
     
    Eric S. Johansson, Jun 7, 2004
    #3
  4. "Eric S. Johansson" <> wrote in message news:<>...
    > 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.
     
    A. Lloyd Flanagan, Jun 7, 2004
    #4
  5. Eric S. Johansson wrote:

    > Paul Boddie wrote:
    >
    >> "Eric S. Johansson" <> wrote in message
    >> news:<>...
    >>> "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/
     
    Christophe Cavalaria, Jun 7, 2004
    #5
  6. 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
     
    Eric S. Johansson, Jun 8, 2004
    #6
  7. Eric S. Johansson

    Paul Boddie Guest

    "Eric S. Johansson" <> wrote in message news:<>...
    >
    > 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
     
    Paul Boddie, Jun 8, 2004
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. chris
    Replies:
    4
    Views:
    913
    chris
    May 17, 2004
  2. Eric @ Zomething

    Python Wiki & wiki Hosting?

    Eric @ Zomething, Jun 5, 2004, in forum: Python
    Replies:
    2
    Views:
    548
  3. Mahrt, Dallas

    RE: Python Wiki & wiki Hosting?

    Mahrt, Dallas, Jun 7, 2004, in forum: Python
    Replies:
    0
    Views:
    441
    Mahrt, Dallas
    Jun 7, 2004
  4. Replies:
    0
    Views:
    333
  5. teo1991
    Replies:
    0
    Views:
    650
    teo1991
    Apr 2, 2009
Loading...

Share This Page