Ideas for Wikit enhancements

CM (8 Aug 03) First about the page name: the stuff below has been first described on my personal page, then relocated by JCW on his Wiki about Wikit, then relocated (still by JC) here.. ;-). That's why it sounds like a duplicate of Suggestions for Wikit. Sorry about this. (I have started reorganizing the page while keeping some of the 2002 stuff, but it will take some time...)

JC: This page relocated from ... most of this is by Christophe Muller.

Ideas for Wikit enhancements


Suggestions for the Wikit engine are gathered into the Suggestions for Wikit page. Below are described a couple of ideas that I have been experimenting with on some previous sources of Wikit before a overhaul from JC and others (AK I think). For a long time (one year?) these experiments have not been applied to the new wikit source. I have now (08 Aug 2003) almost completed the port to the Wikit currently in use.

I will send a tarball to JC so that pieces might get integrated if he wants. Note that I am not advocating to take everything, as I am not sure yet of all UI aspects.. and of the use for the Tcl'ers Wiki. This is provided as-is.. I can also provide the patches for people who are running "home-Wikit"s ;-) if they like some of the features. (I would create an "experimental" branch on CVS but have no access through our firewall :-( except to sourceforge because of their hack..).

I first describe the principles in which I believe, from a GUI-guy point of view, you might disagree of course.. debate is always welcome. See also in the "Biblio" section below a link to Dr. Nielsen's illuminating harangue :-). Then I (too shortly) describe the ideas one by one, and precise if they have been implemented already, if the developments are in progress, or if they are just vaporware..


The question one might ask is Why are you not using a Perl or PHP wiki that is already much more developed than wikit?

And my answer is that I'm very much concerned by the usability issue. I see other wikis with embedded HTML, %variables%, keywords, plugins, etc. and IMHO, they have many advantages but they also have a big drawback- their learning curve is slowly becoming as steep as HTML or LaTeX or even worse (Word!). Actually, I even find the rendered HTML pages difficult to read (and so difficult to use!) with many links, tables, etc. KISS is a good principle in UI (still IMHO). See, in the links below, Dr. Nielsen's site.

So yes, I would like more powerful features in wikit, and also a better looking CSS-ized HTML code with a few nice looking features, but no, I don't want Word at all. For this reason, I prefer to slowly modify wikit in a way that suits this philosophy rather than switch to Twiki, PHPWiki, or you-name-it-wiki.

A good example of this is the "Generation of headers" feature (see below) in wikit without any new markup!


What has been developed by JCW in the latest Wikit versions

I haven't ported my versions of these as they have been redevelopped by JCW (most of the time in a more elegant way) and intergated into the official Wikit, so they now come for free !

  • Edition conflict detection
  • Proper HTML <html>, <head>er, etc.
  • Support for CSS styles
  • Link to the Help page in every footer
  • Static caching of pages
  • Image embedding (that has been added long... ago)

What is available as patches in an experimental version of Wikit

  • Local references using "http:" protocol (instead of local://)
  • Upload script. This actually has been developed outside of Wikit by a colleague using (shame on us) PHP. Local refs are really useful only with this feature. I know that on the Internet, this needs some caution but the script already limits 1) where the file is uploaded and 2) its size (2MB I think).
  • Labeled URLs with a different UI than the awful first one: label@http://url It works also for mailtos etc.
  • An H1 Header is generated for the title (instead of H2 currently)
  • H2 Headers are single bold lines (^``...``$)
  • H3 Headers are single italic lines (^`...`$)
  • A counter of sections and subsections automatically inserts anchors (<A>) to allow referencing like
  • Some HTML "titles" have been added, e.g., to page titles (click for backlinks), to URLs when labelled (go to..), or to all bracketed links, i.e., [1] (actual-URL)
  • A mechanism for citations of people has been added ( "bla.." --author)
  • Support for a shortcut icon defined in WIKIT_ICON
  • Support for two stylesheets, one seen by all browsers and one unseen by NS4
  • In CSS: automatic bullet icons insertion for remote links, mailtos, pdf, etc.
  • In CSS: addition of BODY class=wikit to allow user's stylesheets redefinitions (works in Mozilla but not IE).
  • CVS Support has been added: at each edit, a CVS version of the page is committed. (use the generation of source pages of the official Wikit). It has allowed very easily the next feature:
  • Diff link in the footer. Rather than port the code of Brian like I did in my previous version, I simply added a link to a ViewCVS server that wa had running already and colored diff is available! This can be disbled in the (new) WIKIT_VIEWCVS variable is not set. I know that a pure Tcl solution embedded in Wikit.kit would be much better, but this one was really easy to implement.. although it needs some configuration (creation of a CVSROOT, installation of CVS and ViewCVS..).

(I might have forgotten things.. I'll have a look at diff files.. :-).

What has not been ported to the newest version

  • Support for MAP images (this worked well but has actually never been used so I didn't bother.. :-)
  • Export script to an other web site of "public"-tagged pages (see below). This was very specific for a protected Wiki

What has not yet been coded

  • See also the not-yet-reorganized ideas below, and Suggestions for Wikit
  • Database Pages: provide a mechanism to declare, e.g., in Web Settings, a set of pages that are "databases" and which will automaticaly update separated Metakit tables. This could then be use in other parts of Wikit, e.g., to provide features such as Interwiki links, Acronym titles, IP2name table, etc.
  • Typed pages (probably the same than what AK refers to in th echat as "MIME" pages, but I'm not completely sure :-). The idea would be to parse page titles and if they end in ".something" lookup in a list of types if something is one, and then wxhat we have to to with "something" type of code in a TK context and in an HTML context. This seems strange I know. Some potential applications are: colorized language pages (.tcl, of course, .java, .sh, etc.), SVG pages (would be just embedded as-is), Ploticus pages (would be rendered as an IMG), even XPM pages would allow uploading images by just editing a page! Other ideas will come.. .tables, .math, etc. Some types will be a page of their own, and some will be meant to be "embedded" where a link is put, like it is currently the case for PNG/GIF/JPG images.
  • A mechnism to "tag" pages in the local version as "can be exported" and some type of synchronization/auto-merging mechanism. It would allow people to work on a Wiki locally while it is updated on the network, then merge all contributions, but not the pages that are "private" for the person.

What is below is either out-of-date or not reorganized yet, and needs to be updated ---> very soon! ;-)

Old Roadmap

Already implemented features are:

  • Page Editing Conflict Detection. This is using mostly code in the CGI launching script and so uses the bourne shell heavily. I have an almost complete TCL counterpart (still in the CGI script) but I never tested it too much and the conflict detection has not been ported to TCL yet. People on the mailing-list would like to have the mechanism inside wikit directly, which indeed is probably a good idea in case of shared disk partition and local mode usage (is there a DB lock in this case?).
  • Local FS access through the new "local://" protocol. As we use the wiki internally on our intranet, it is very easy to mount the partition which is used and copy files on it (HTML, GIF, ZIP, etc.) that then can be referenced inside the wiki pages. AK has some ideas about wiki pages that are non-wiki-code content, e.g., GIF, with an associated mime type. Any description somewhere? Note also that the current referenced contents of our project (6 persons) weigths 80MB. Wouldn't that slow the accesses?
  • Proper HTML <html>, <head>, tags are generated. It was needed for the export feature.
  • A <link> tag for CSS is generated with styles/wiki.css as default. I have setup styles for headers, links, lines, lists, and pre-formatted zones.
  • Possibility of giving labels to external links (this one is a yucky hack...). The users sees a labeled link (such as a link to a wiki page) but it references an external page. The (horrible) syntax is something like h ttp://[email protected]/. With a better work in regexps and wikit code, it is certainely possible to think of something better.. :-( but the users love this feature! MHo: I don't see this feature in current wikit - is it alive?
  • Title information added to numbered links in brackets. An HTML "title" indications is added to the URL. It works with Mozilla on Linux and I think it works with IE too (this is real HTML but not always implemented).
  • Generation of headers for the title (H1), bold (H2) or italic (H3) lines. This one is really simple and I'll try to describe it with a patch (on the new sources) soon. With a proper CSS, it leads to very nice looking pages. Who needs word anymore? :-D.
  • Addition of Named anchors for headers, to make linking easier. Each section header (H2, as H1 is the title) has an anchor that allows referencing in emails, etc. Something like http://wiki/12.html#section3
  • Link to the Help page in every footer.
  • Static caching of pages after each edition for speed-ups. The new wiki is generating a dump of the page in wikit source form. Would it be possible to get a dump in HTML form as well? (or a background script doing it that after the page has been sent back). For some reasons, I couldn't use the Unix "tee" command in the CGI script, and so I have implemented it using my own "tee" in the wikit sources, but I am pretty sure this is also a hack and there is an other way to do it "right"!
  • Export script that allows tagging some of the pages as "public" and export them to a static web site (was useful for us..). This is done mostly in a shell script, using all sort of Unix tools such as find, grep, perl, sed, and... lynx! Anyway, if you want to have a look, do not hesitate to ask and I will send the source...

Plus the integration of two patches:

  • the Image Embedding patch from Jean-Claude, and
  • the Last Diffs patch from Brian Theado.

Brian is the author of tkoutline. For seeing its new feature in action, click to see the last diffs of its own wiki - Home Page: [L1 ]). BTW, I find it very nice the way Brian gave access to the diff (i.e., the footer's Update on ... becomes a link).

My roadmap is:

  1. Finish implementing the new enhancements (see the list below)
  2. Port everything to the new nwikit <---we are almost here :-)
  3. Work on future enhancements, from the suggestion list (see below)

Still in progress are:

  • I didn't take the time to integrate a second patch from Brian dealing with "Table of Contents",
  • Support for map images, (I will be using the Local FS feature for the first time, so for an internet wiki, it would need an upload script in addition, but this is not something very hard), Update: It works now!
  • Support for drawing images with a Java applet [L2 ] such as Jfig or TWikiDraw,
  • A small wiki2latex script similar to the wiki2html (see Wiki format to HTML) that already exists, to help producing papers.. :-) although generation of Docbook instead of LaTeX would be fine too,
  • An index maker script that lists all the existing pages by alphabetic order, or by page number,

Other Suggestions (see also Suggestions for Wikit):

  • Submission of comments by email,
  • Page GC (or page deletion) for an empty page after an amount of time,
  • Table syntax (?) I'm not sure about this one.. Maybe a small Java spreadsheet widget generating a GIF would be simpler.. (?),
  • Email alerts on specific pages,
  • Conversion of the CGI shell script to pure Tclsh first, then conversion either to FastCGI or to a script that does RPC to a wiki server using the Tcllib comm features. This would dramatically reduce the browsing time (although after the implementation of static pages features, the priority lowered..),

Wow... - After seeing all this, I'm now bent more than ever on placing nwikit into CVS. It will, as with Metakit and Tclkit, be essentially a reado-only setup. But in this case with eager interest in helping to consolidate things. There seem to be, right now, three people working on wikit improvements - not to ignore several who have helped in the past. The CVS setup is not intended to prevent anyone from going their own way and doing whatever they like with the wikit codebase - just an option for those who wish to see things come back full circle.

One last comment, *please* consider joining the TclersWiki discussion group on Yahoo. It's been dormant lately, but I suspect that'll change soon. I'll announce my nwikit progress there asap.

Anyway, great to see all these ideas... -JCW

PS. One of these day's I'll move my notes to the Wikit or Suggestions for Wikit page, or perhaps create a new page do discuss progress.

CM Thanks for your fast comment! I also agree that for three developers, a full-featured sourceforge site is really not worth the time to set it up!.. but a CVS with all the versions would be nice. I will try to finish the features that I am currently developing asap, in order to reach a stable state (hopefully). Then I will send a version to you and Brian, so that you can play with it, then I'll try to apply my patches to your new version (CVS might help me there.. :-). BTW, I am subscribed to the TclersWiki mailing-list (Larry "LV" put me in :-)

BTW, I am not sure that everything listed above will be desirable for the official version, even if some features are very necessary for us internally (I'm thinking about the export mechanism for instance), I'll leave it to you to decide what to integrate...

JCW Ah, but see, that's one of the things I'd like to refine a bit: the presence of packages will trigger functionality, i.e. plugins - in the nicest possible way I hope.

Info about Obtaining Wikit from CVS has been moved to a separate page -jcw

KPV I like it when you search for a page, the resulting list has the date the page was last changed. I'd like that also when clicking on a reference. That's the page you get when you click on another page's title, or by going to, say "[!] ". mmmm, how do I get the "!" to be part of the URL?

12nov02 jcw - Date is now listed on back-ref ("bang!") pages. As for getting it into an URL wikit will accept, try this:

DKF If you're going to refer to local resources, couldn't you use a file: URL?

CM (8 Aug 03): actually the "local://" URL protocol has a different meaning than "file:" which according to the W3C RFCs means "access a file on the local computer". It would be like " ". What I really want is accessing a file that is remote and by the HTTP protocol. So your remark made me realize that choosing local for something on the server was a bit of an abberation too ! :-D I was thinking as the server guy... I have evaluated several other possibilities such as "http://this/file ", "http:/// ", "http:file ", "fs://file" (inspired by nsf://) and finally decided to port the feature as http:path/file as it really represents what we want, an HTTP way of getting a file relative to the current page... except in pure HTML we would have no protocol as all in the HREF (just "path/file") but this is not possible in Wikit as we need to recognize when to put a link or not.. What do you think of the new UI ?

DKF Also, the most painful part about going from something based on ISO 8859-1, or even ASCII, to (La)TeX is the fact that TeX uses a completely different encoding, but which is similar in enough places for you to think you've done enough when just doing simple tests.

CM I have have "swapped" the doc generation ideas for a while :-), but I have a small hack already running: a bourne shell script is gathering a list of pages, then running a couple of sed/awk/whatever to fix things, then html2ps, and finally ps2pdf, which produces ... something, if not as nice as LaTeX :-). An elegant way of developing a doc generation feature would be: to add a third formatter to Wikit (besides Tk and HTML) that would produce Docbook SGML (or Docbook XML I have no clue which is best), which could then be concatenated, and converted to LaTeX, Ooo's XML, etc. A nice project for 2004..


What I would like is some feedbacks on what features would need to be ported first to the new wikit structure. My first guess would be the HTML tags, CSS tags with a sample of CSS, and the generation of headers. Maybe also the title information for brackets links. Any thoughts?

(Same day -jcw)

Please be sure to visit the new starkit site [L3 ]. It's a name change, but also has some technical implications. Very very new, though the plans to do this were born several months ago.

Well, first of all, by now the new wikit is a fact, it's a starkit, it drives the Tcl'ers Wiki, and it seems to hold out. I've made a few changes since you first set up this page - I sure hope they simplify your future work on wikit:

  • conflict detection is now part of the web-mode of wikit
  • all pages link to the Help page
  • there's a static page cache facility, see Wikit configuration
  • there are also some logging and archive facilities, see that same config page


A few interesting links for people working on Wiki engines (there are so many! ;-)

         Metakit mailing-list:

Shin: How about a tool to extract an RSS-Feed from the "Recent Changes" page? Or even better, how about creating a RSS-Feed-Page (Let's say page 8)?

Done a long time ago: see How to generate a Recent Changes RSS Feed, or, .

Category Wikit