Feeds:
Posts
Comments

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

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.

prosemirror.png

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!).
ghost-logo.png
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 »

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 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 ‘http://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 »

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 »

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 »

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 »

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 »

No matter how you describe it, Apple’s HyperCard was (is!) an amazing tool. The simple concepts behind it, together with a programming language that looked a lot like plain English,  made it a tool used by many non-programmers. And it had “links”, allowing you to jump from “card” to “card”, thus offering a first glimpse of the power of hypermedia and hypertext that we all take for granted today in our web browser. Ars Technica has a good overview of “25 years of HyperCard — the missing link to the Web“. Too bad they don’t mention this little nugget: HyperCard inspired Ward Cunningham to flesh out the basic concepts of the WikiWiki software that made him famous.

HyperCard diskette from 1990

HyperCard diskette from 1990

I still have the original disks that (probably) came with my first Mac, a Macintosh IIsi in 1990… I used a later version of HyperCard in 2000 (on Mac OS9) to write a small stack with simple math exercises for my kids. Nothing fancy, but it worked well, and it allowed the kids to familiarize themselves with a computer. My son now dabbles in the construction of web sites and simple web apps; I’m pretty sure he would learn more (and have more fun at the same time) by using a modern HyperCard clone, rather than writing code in C# without a serious background on classes, objects, inheritance, etc.

Read Full Post »

Older Posts »