Archive for the ‘Wiki’ Category

It’s been a long time since I suggested that a system like S5 should include an editing mode, and see my post of March 15, 2012 repeated that suggestion. As it turns out, there is now a very similar tool that does just that: remark. No, it’s not a Wiki, it’s a lightweight CMS, using Markdown (plus extensions) to do its magic.

To be honest, between my first suggestions in 2005 and now a number of similar tools have been created, many based on S5, by the way – just check out http://wiki.s5project.org/HTML_slideshow_tools. But things over there aren’t too lively anymore, it seems…

I’m waiting for a good opportunity to try ‘remark’ out, if only to see  on how many platforms it can be used for editing without too many limitations.

For a quick try-out, head over to Platon.io – it’s an editable webpage powered by remark.


Read Full Post »

The InterWikiLinksPlugin, my small addition to JSPWiki is part of the JSPWiki source tree (or at least is was somewhere in 2009). But Pikacode managed to lose the version I installed there, so I am storing it for posterity on this site as well ;-)

Click the image to download the PDF

Click the image to download the PDF

I had to package it as a PDF file here in WordPress.com, but just copying the text content of the file and saving it as a Java file in the JSPWiki Plugins source directory should suffice for a successful compilation.

Read Full Post »

A long, long time ago I wrote a small extension to JSPWiki (which is still my favourite Wiki, by the way). It happened in 2009, and I even mentioned it it here on my blog! Contrary to what I promised, I never wrote any instructions. Luckily, there isn’t much to say in terms of instructions: the plugin just gives you a bit of control over how to display the list of Wiki-wide InterWikiLinks.

  • A JSPWiki plugin is just a Java class that implements the com.ecyrd.jspwiki.plugin.WikiPlugin interface and can be found through your class path. That makes adding a plugin pretty simple, if you are somewhat familiar with Java. And remember that the InterWikiLinks plugin has been integrated in the standard JSPWiki distributions starting with 2.8.4.
  • Using the InterWikiLinks plugin in a Wikipage is simple as well. Adding the following text to the source of your Wikipage explains the full syntax of the plugin:
    [{INSERT InterWikiLinksPlugin WHERE type='text', tabletitle='Your preferred title', separator=', ' }]
    This will render all your InterWiki links as a simple list of links, separated by commas, and preceded by a title. The ‘type’ parameter can take four values: ‘text‘ is the default; ‘ulist‘ creates an unordered (bulleted) list; ‘olist‘ will render the links as an ordered (numbered) list; and ‘table‘ will create an HTML table. The ‘separator’ parameter can take any HTML markup you want – as long as it makes sense in the context of the display of a list of items, of course.

Just know that I have only used and tested it with the 2.8 releases of JSPWiki. Here’s a simple example of how to use it: In the SystemInfo page, replace the default overview (using a WikiVariable) with

| __Available InterWiki links__      | [{ InterWikiLinksPlugin }]

 Anyway, what I wanted to note here today is that I have finally uploaded my original version of the source code to a public repository: https://www.pikacode.com/nukleos/InterWikiLinks/. So if you want to use this plugin with a JSPWiki instance that does not have it included, you know where to find the source code.

Read Full Post »

It seems the debate about in-browser editors is ongoing, in a good and serious way. Dave wrote about it again, in “There’s a content-editable community“. He points, amongst other things, to an Indiegogo project called ‘ProseMirror‘. I have only read the project description, not the code; it seems to me that it is part editing tool, part content representation. That makes it similar to Dave’s OPML Editor, and both will allow you to represent the content as you like, depending on the transformation you apply to the content. That’s a good approach, in my view, because it makes the tool very flexible.


Of course, ProseMirror could be the editing environment for a Wiki! Storing Wiki-content in a format that is not dependent on a representation such as HTML is the basis for re-use of that content in as many forms as you need/want. I hope Marijn Haverbeke reaches his goal, and then we’ll see if someone picks up ProseMirror as the basis for a Wiki, a blogging tool, etc. From what I remember of the JSPWiki implementation, it should be relatively easy to whip up a ProseMirror “storage provider”  for JSPWiki that does exactly that: use the ProseMirror content format as the corner stone of a Wiki. Any takers?

PS. If the Indiegogo project should disappear, then you’ll also find more details on prosemirror.net

Read Full Post »

Dave asks: should there be “Editing APIs for Wikis?“.

Wikis have been “invented”, to use that word, to make it possible for anyone to edit a Wiki page inside the browser. In a Wiki, content is more important than fancy layouts. Wiki editors thus prescribe a simple markup system for things like ‘bold’ and ‘italic’ lettering, bullet lists, etc. Creole, the attempt to unify dozens of markups, has never been a success. When going from one Wiki to another you may need to adapt your markup automatisms. These markup languages are rather similar, so in practice adaptation from one to another isn’t too hard.

Would it be nice to have a WYSIWYG editor in your Wiki? For some people, the answer is yes. They will indeed be more comfortable with an editor that resembles the editor they use for writing books or letters. But many Wikis allow you to change the editor used for editing Wiki pages. At work, I have activated the FCKEditor (aka. CKEditor) in JSPWiki, and currently our users can still choose the editing style they prefer.

All/most Wikis store the user’s content in their own markup format, not in HTML. The MyWord Editor that Dave Winer has built works differently, if I’m not mistaken: it is a WYSIWYG layer for HTML editing. It should not be too hard to convert the HTML from a simple HTML editor to whatever markup the Wiki uses. But even for a single editor that would require a convertor for multiple Wiki markup dialects.

Yet another Wiki editor: Eclipse and Textile

Yet another Wiki editor: Eclipse/Mylyn and Textile

In the end, the real question is: what would be the added value of such an API?

The purpose of a Wiki is to capture information and not layout. That is why the built-in editors are relatively simple. For hard-core Wiki authors, an HTML textbox plus knowledge of the local markup language will be enough. Occasional authors will have to make do with the built-in MOLWYSIWYG (More Or Less WYSIWYG) editor. I suspect most occasional wiki authors won’t be authoring texts in more than one Wikis, so they will deal with a single variant only.

Would a common API be a good idea? Of course! But such an API would already exist if it served a greater purpose beyond the technical promise of plug-and-play editors.

If you ask me, Wiki’s would be better served with a common markup language like Creole or Markdown or ReST, rather than an editor API. If you think otherwise, then just build such an API. I’ll be happy to write about it!

PS. For a comparison between Creole, Markdown and ReST, check out “Why Markdown Is Not My Favourite Language“…

Read Full Post »

Ghost, the blogging platform mentioned yesterday, is well worth a look – literally. The page design as proposed out of the box is very much to my liking, and if the system proves to be as easy to use as promised, then it might well be a excellent choice for a beginning blogger (I have too much invested in this blog to contemplate moving again!).
And not only does Ghost look great, it also does away with the pseudo-rich-text-editor approach I don’t like at all. For those of you still not convinced: no, you don’t need dozens of fonts, font sizes and colors for textual content on the Web! What you need is a few ways to indicate structure in your text, and that does not require a bad MS Word clone. Ghost smartly chooses Markdown. That editor reminds me of the way text is edited in many Wikis – an excellent approach, focussing on content, not on presentation – presentation is the responsibility of the tool and its designer.

Read Full Post »

This is what you can experience if you look for the word ‘Wiki’ everywhere: the word ‘WikiBar’ has nothing to with Wikis, but it’s all about ice cream.

The WikiBar

The WikiBar

Ice cream in the form of WikiPearls… I’ll stop here: read all about this bioengineering technology in Wired’s “You Can Hold This Ice Cream of the Future in Your Bare Hands“.

Read Full Post »

Older Posts »