Will Mau Have Seven Lives, Like All Cats?

There is a new markup language on the market. As a Wikificionado I like markup languages better than using any wordprocessor – for my own writing I haven’t used a wordprocessor in many, many years. Even at work I only use Word when I have to, and that has been a while ago (that probably means all I write are emails and code). And bug reports and documentation get dropped into JSPWiki and Trac and Joplin – all I need is simple markup.

I like markup for regular writing, and I use it daily in tools like Trac and JSPWiki. The trouble, of course, is that each of those tools (and many others!) uses a slightly different markup scheme.

And now there is a new contender on offer: Mau.

I can see where it comes from: the author needed more than what any simple markup could offer. I too have at times been frustrated by the lack of feature X or Y in any markup scheme. It surprised me to see that he did not check out LaTeX, which as far as I know should have covered his requirements. But it would probably have been too steep a learning curve.

Back to Mau: I haven’t yet tried it, but I can see that it would be a very nice tool for writing documentation. However, for me the system should be an extension of Markdown, let’s say a SuperMarkdown or MarkdownPlusPlus, rather than another variant markup scheme with subtle differences from what I know.

I guess I am not the only one to dislike “yet another divergent markup scheme”. So far I haven’t seen much traction for Mau… although it is, in a way, a very cool project. I applaud Mau’s author for making the effort – he clearly thought this through. And who knows: perhaps Mau becomes wildly successful in the future?

Advertisement

Read Full Post »

There’s Nothing Magic About It, But It’s Still Remark-able

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 »

InterWikiLinksPlugin Source Code Availability Restored

The InterWikiLinksPlugin, my small addition to JSPWiki is part of the JSPWiki source tree (or at least it 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

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 »

The InterWikiLinks Plugin Goes Public By Itself

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 »

ProseMirror As An Editor (And More) For Your Wiki May Be Coming Soon

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 »

Editing API Versus Markup Standardisation? The Latter Gets My Vote

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/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 »

Pure Blogging With Open-Source Software Is Coming

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 »

Ice Cream And Wiki* Make A Strange Combination

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

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 »

Wiki’s Are Still A Relevant Content Management System Variant

Wiki’s are no longer the spearpoint of the ‘social media’ that they were a few years ago. That does not mean they have gone away or, worse, have become irrelevant. It’s good to see that a major player like Ars Technica publishes a nice Mediawiki installation manual: “Web Served 7: Wiki wiki wiki!“.

The rest of the ‘Web served’ series – on how to setup and use a secure webserver – is worth reading as well, if you have little or no experience with the subject.

Read Full Post »

JSPWiki, Don’t Throw Away Your Past

JSPWiki is (finally) almost ready to become a first-class citizen in the Apache universe. That’s good news, of course, and it proves that JSPWiki is indeed a stable and worthwhile open source product, that deserves global recognition as such. Of course, an official Apache release of JSPWIki also requires official documentation. The ‘old’ site already had new branches for several releases, and I guess the same approach will be used for the upcoming 2.9 release, albeit in the official Apache infrastructure.

The JSPWiki crew plans a move of the current ‘www.jspwiki.org‘ content to the Apache infrastrucure – and what I read about this on the Apache issue tracker is somewhat worrying. Yes, the current content is not really very up to date, but still: it may contain useful information for those of us still running older releases of JSPWiki. There’s the list of not all too official plugins, there are comments all over the place that may be useful – or not, etc.

Rather than throwing everything away, wouldn’t it be possible to keep a read-only copy alive, for example under the name ‘old.jspwiki.org‘ or so?

Read Full Post »

W3C Wiki Documents HTML5, CSS3, And More

The W3C, the standards body that oversees the development of HTML, is starting a Wiki to (hopefully) create a definitive, up-to-date collection of documentation on all the web standards (and more). In the words of Webmonkey: “The W3C has managed to bring together some of the biggest names on the web to help create Web Platform Docs. Representatives from Opera, Adobe, Facebook, Google, Microsoft, Mozilla and Nokia will all be lending their expertise to the new site“.

Of course, the really interesting part – for me, that is – is the Wiki that will encompass all those Web Platform Docs. I do wonder how much “non-expert” material will be added to the site – writing documentation is not the same as writing code, as evidenced by the lack of decent documentation in many software projects. Then again, not just developers can (should) add their expertise.

I guess the W3C will be exercising some kind of editorial supervision. To their credit, the creators of the site have clearly indicated how anyone can help, even if you’re unfamiliar with the technologies mentioned – that’s a good idea for any Wiki, by the way.

Read Full Post »

Word Of The Week: Mapocalypse

Of course, Robert Cringely writes about the snafu with Apple’s iOS6 maps application troubles: “Apple’s Maps is so spectacularly bad it’s inspired its own Internet meme. Funny? You bet“.

But as always, it pays to check your facts before publishing. Even Google Maps knows about the “tiny hamlet in Austria where every street name starts with the F word” – because that hamlet does exist in the real world! Just check the Wikipedia: Fucking, Austria.

Then ask yourself: why does Google Maps call the streets in that hamlet “Hucking” ? Creative spelling indeed!

Read Full Post »

Foundations For A Wiki

WikiNotes is a wiki-based note-sharing platform created to facilitate student collaboration (beware: the site can be slow!). Basically it’s a system that allows students (and others ;-) to publish course notes, questions from examinations, study notes, etc. The current version of WikiNotes is based on the classic MediaWiki-software that also powers the WikiPedia. But a small team of student developers is rewriting the system from scratch. A beta version can be explored at http://beta.wikinotes.ca/ – and its source code is published under the GPLv3 on GitHub.

Why do I mention this project? First of all: I am a Wiki fan ;-)

Secondly, it’s a good example of what a Wiki can be used for: the creation of a public body of knowledge that is fed and maintained by anyone who wants to help. Of course, not all courses are equally well documented, but since a Wiki can be edited anytime that might change rapidly (or never ;-). Not everyone was (is) convinced of the value of such an initiative – users of WikiNotes should be aware of possible copyright issues, to name the most frequently mentioned counter-argument –  but I have found several pleas for a more nuanced approach that can benefit both the students and the University. Check out this editorial from the McGill Tribune for suggestions on how to govern the WikiNotes site.

Thirdly, the new version is being written in Python and created on top of the Django framework. I find it stimulating to see the progress in the development of this application, from a developers prespective.

Last but not least, this Wiki started out as a student initiative – there are clearly smart students at McGill!

At the same time, this project illustrates an essential aspect of any content management project. Before choosing any CMS, or writing your own, you have to analyse your requirements. You have to know what you will be dealing with: what type of “content” (text, image, video, …) about which subjects will you be handling; what metadata do you need for each content type; who is going to handle that content, and what will they be doing exactly; who is the target audience for the content, and what are their expectations; etc. Without clear answers to these and more questions you will never be able to set up a suitable CMS, let alone claim a succesful implementation.

PS. This is why I fear that the brand new Brussels Wiki (‘Wikibru, the wiki of the City of Brussels‘) will be a failure: a wiki needs more justification than the possibility “for people to add something to the site”…

Read Full Post »

This Wiki Is An Adventure Game Runtime

“Choose your own adventure” is a Wiki unlike any I had seen before, but it’s actually a fine example of what a Wiki can be: a tool where multiple authors create content, packaged in linked pages. In fact, it might be an excellent example to teach the basics of a Wiki!

How does it work? It’s simple, and the site explains itself thus: it’s “a wiki that contains stories where the reader assumes the role of the main character. In each page you choose how the story should progress. If you don’t see an option that you would like to pursue, click the edit tab on the top of the page and add a new path to the page. Then you get to write in your own adventure for the character…”

There is no guarantee as to the quality of the stories of course; you’ll have to explore them and assess that aspect for yourself. At the same time, you’ll experience what a Wiki is all about. Enjoy!

PS. For a dutch version of this post, see the innologos website…

Read Full Post »

The Wiki Core

On Tuesday, Bruno and I repeated our workshop “Getting Started with Wikis“. Have we failed in our mission if one of the participants decides that a Wiki is not the solution for his specific problem? Of course not. Wikis are tools, not a magic wand to solve all your problems in one fell swoop. If I had  to summarize the core of Wikis in two words, then those words would be “co-authorship” and “interlinking”.

• “Co-authorship” refers to the fact that Wikis are designed to support collaboration and co-writing or co-creation. Anyone can complement and improve the existing content in a Wiki, and thus adds value by ensuring higher accuracy and completeness of the contents.
• “Interlinking” is my word to describe how easily Wiki hypertext links can be established between the different WikiWords or pages in the Wiki, or even towards URLs outside the Wiki. CamelCase and InterWikiLinks are powerful tools for fast and accurate building of links.

If these characteristics are not essential to solve your problem, then a Wiki might help – or not (it could even be counterproductive). If that is what you learned during our workshop, then you did not waste your time!

PS. For a dutch version of this post, see the innologos website…

Read Full Post »