MoinMoin: KlausHeinisch

What about WebDaAV? What about a course for MoinMoinProgramming?

MoinMoin Folks around the world. This are some impressions from the front-line...

• Today im thinking about a WebDAV-Function for MoinMoin. That's because in my company (great data processing center for Banks), some Admins mean, the nice BSCW-Tool from the Fraunhofer-Company is a better tool than any WikiWiki. Their arguments are:

  • BSCW supports searching in "office-documents" like .pdf, .doc, .vsd etc. (realized by swish-e). MoinMoin doesn't...

  • BSCW supports an easy-administrable LDAP-Authentication and respectively provides an own "klickable" frontend for useradministraion. MoinMoin doesn't...

  • BSCW supports "Offline-Working", synchronising folders on my private disk whith the online folders. MoinMoin doesn't...

  • Please understand: I'm workin' whith MoinMoin every day:

    • Teaching trainees and colleagues
    • Organizing my own knowledge
    • Organizing tickets, proplems and phone calls

    • Im using MoinMoin for nearly everything, what is related with Information- and Knowledge-Management

  • But:

    • How can I index attachments?

    • How can I link Attachments from a central file server
      (I realized this whith the Interwiki-Mechanism, but that's (at this moment) whithout WebDAV)

• And i'm thinking about a workshop like "Learning Python trough the MoinMoin-WikiEngine for administrators and Python-Newbies"

  • Since one year im having a look at myself and my distance to python. I could not see any substantial progress in learning python.

  • Who will be able to spend some time in explaining MoinMoin-programming?

Better LocalSiteMap-Action:

• At my company, i realized an icon for the LocalSiteMap-Action (and also for the Attach-Action).

  • You see the icons: Right is the Homepage-Icon, left aside the LocalSiteMap-Icon (not very nice ), next left the AttachIcon.

• The reason is: To improve the acceptance of wikis in my company, i need to sort pages treelike. I made some "menu-pages", for each topic en own page. The LocalSiteMap-Action shows the menu-hierarchy, i made by my own hand.

• The actual action build the complete tree up to the limited depth.

• My wish was a clickable tree like the explorer/konquerer.

Other Action like TreeAction:

• Like the normal LocalSiteMap-Action there could be a special Tree-Action. The special point could be, that the action would use some meta-data on the special tree-pages:

  •  #pragma tree-page

    this switch forces another icon than normal pages like real information-pages, the menu-action would interpret this switch and show a folder-icon in the tree-view instead of a document-icon.

Why do I think, that we need tree-views?

At the moment tree-views in this wiki are nearly impossible:

• Sometimes we had to organize informations in a tree.
• Treeviews should be an addon to some other views of information in the wiki.
• Treeviews should be buildable by an action-button like "raw, print-version or information" from any Page.
• Treeviews could raise the acceptance of wikis for people, who are used to work with tree-views, until they learn about the benefit of wikis.
• I know, that a tree only helps, if we have some hierachical data. But often my users have the problem: Where should i put the Information "into"??
  • If I say them: Put it in in any way you would, they do answer me: "We would not accept the risk of any uncontrolled growth of our documentation, so we would use any kind of treeview and would initiate some editors, who control the tree."
  • They could not see the benefit of the wiki, until they work one year with it...

  • So i have to give them some treeview, handmade or automaticaly made by the "not-written-TreeAction"

Comments

Please check the discussion in PagesHierarchy.

• Hello Eduardo. I agree completely with you in the following points:
  • Informations, content is multidimensional. That means, that most informations can put into more than one category. So the place of this information in any kind of tree is unclear.
  Thanks. What do you think if we move this talk there? --EM.