July 9, 2006
User Needs /

Why I think that some form of WYSIWYG would be very helpful

If we are looking at Wiki-communities outside software or web development - communities that are concerned with issues totally unrelated to computers - the necessity to use - or * or #, etc, is a real entry barrier.

Certainly, the Wiki markup is much simpler for users than html, but it is still something very awkward for people who would just like to write something and who are used to writing things in Word or Open Office.

I remember the first time I wanted to contribute to a wiki: it took me a long time of looking around and trying to understand, before I eventually actually wrote something - and I am certainly using the computer much more than the average user. I mean, it requires some commitment, you have to be really convinced that this is worth it - but at this point, you are still new to the whole thing, and you do not know yet, you might only have a slight idea of the possibilities of online collaboration and wikis.

My feeling is, that the minimum one should offer to users, are a few buttons that enable them to do the main formatting via those buttons (like many Wiki-engines offer). Even better, although I do not know how difficult this would be to implement, if the formatting through a button was directly visible as formatted text (instead of adding the ' or = or whatever code-sign), similar to the way a modern Word-processor (I mean after WP for DOS) is handling it. I think there are only a few Wikis that offer this kind of direct WYSIWYG.

To give a practical example, we would like to use a wiki for our self-organised and self-managed organic food cooperative. Most of the members are using computers nowadays, but the vast majority is really just using it. For most of them it is already quite a step to imagine and use the computer and the internet for collaboration with others (I mean more than e-mail). For them to be able to really start collaborating in a wiki, the entry barrier should be as low as possible, i.e. writing text should be as similar as possible to what they are used to. And that is, for the majority of people, writing in a word-processor. To them, a wiki-formatted text doesn't look like a text, but like a code and they feel they (almost) have to become programmers in order to be able to write something.

From another point of view, we all know, how difficult it is for most people to really collaborate with others ('cause our socialisation taught us otherwise) and there are many hurdles to take in the process. I think formatting should not be one of the hurdles.

Right, too many words, I'd just like to know, if such a feature, or option, is foreseen for the near future (say 6 months or so) or if there are serious arguments against implementing ProWiki more average-user-friendly in this respect.

I made it a bit longer, because I really like the concepts in ProWiki and the many considerations given to structuring and flexibility and I would love to see this imlemented.

- Thomas

Thomas, thank you for writing about this in detail. Actually this has been a weak spot of wiki and ProWiki all through these years, and I have always been in a defensive position. Not because I wouldn't like to have a decent WYSIWYG myself, but because I wasn't able to promise and provide it up to now. In fact one of the main reasons why I decided to make ProWiki OpenSource and FreeSoftware now is to get WYSIWYG and a few other features for free from other OpenSource projects or by finding an enthusiast who would implement this.

There are a number of problems that hindered the implementation of WYSIWYG. These problems seem to get easier to solve year by year, although it is not quite clear what the status is right now. It's hard to explain to non-technicians who compare the Office runnning on their PC and the wiki running on the same machine that these two systems are very different in structure (Office builds on the OperatingSystem, wiki has to act in a window of the WebBrowser) and that the wiki-interface is much harder to control because of this situation. BrowserIncompatibility is a key word. There are about a dozen different browsers that people use and that differ in their ability to be programmed and what JavaScript commands can be used. The risk - and typical situation - is to have a WYSIWYG that works for 80% of the users and doesn't work at all for the rest.

But I think the situation is improving and I'm confident that we will have WYSIWYG in ProWiki in 6-9 months one way or the other. I hope that we will find someone in the ProWiki community who will implement this. -- HelmutLeitner

Thank you very much for your explanation. We have - for now - decided to go ahead with DokuWiki, although I do regret not to have the structuring and autolinking capabilities of ProWiki. I hope we will be able to convert our pages later to ProWiki, once WYSIWYG is available.

A few days ago, I stumbled across this page: WYKIWYG, maybe it is helpful for the WYSIWIG-Integration-project?

Best, Thomas

Thomas, thank you for your openness. I know the WYKIWYG project since Oktober 2005. I last visited it about two week ago and within a few minutes I stumbled over a number of obvious faults. If you show me an OpenSource implementation that works for the major browsers, I'll promise to do a corresponding implementation for ProWiki within 2-3 weeks. -- HelmutLeitner June 19, 2006 15:43 CET

We will try our best to find something, although I am not sure, if we will find something. I guess you have been looking around quite a bit? - Thomas

Yes, of course. I'm confronted with this need since I've first demonstrated a wiki to a friend in 2000. It's pretty easy to arrive at a solution that looks good from the outside, for a management demonstration or a screencast. But the devil is in the detail. Even in 2000 there were already WYSIWYG solutions. Lotus QuickPlace was a commercial Wiki clone that used a Java applet WYSIWIG. It looked good but was terrible slow and went nowhere. Also technicians built it according to their mindset instead of listening to the community needs. The Java solution is probably best but it needs high bandwidth and Java version stability. I think that end of the year the timing will be right for that. Current popular solutions build on Web 2.0 Javascript and "rich text" editing fields. Although this looks good because Javascript is better integrated with the web page elements, it lacks the sound basis, because of browser incompatibilities and because Javascript is much weaker (less performing, less expressiveness) as a programming language. -- HelmutLeitner June 21, 2006 10:37 CET

I think its time to plan a WikiWysiwyg solution. -- HelmutLeitner July 9, 2006 12:23 CET

Some other discussion moved to ToolBar.