I frequently hear the feedback that editing in TWikiML is too hard, especially for newcomers. There has been progress towards solving this problem, discussed extensively elsewhere.

One of the assumptions implicit in the "re-use of another editor" discussions has been that the place to start is a fully-featured HTML editor, because TWiki supports embedded HTML as well as TWikiML. While there are powerful browser-based WYSIWYG HTML editors out there, none of them quite fits the bill; either they are commercial, or they are browser-specific, or they require Java1.4.2 Plugin installation, or they would simply require too much work to integrate TWikiML.

I think we may have been blinded by science. Looking at the problem from an another angle, how many newbies actually want access to the full formatting power of HTML in their pages? TWiki has never pretended to be a web design environment. TWikiML is all about fast and simple access to simple pages with simple formatting, as documented in TextFormattingRules.

So, instead of looking at the problem of re-using a powerful 3rd party HTML editor and making it understand TWikiML, how about looking at the problem of sourcing a TWikiML WYSIWYG editor? To make myself clear, this would not support HTML tags - it would display them as plain text. It would support only TWikiML as documented in TextFormattingRules. This seems to me to be a much more tractable problem.

I have done a few experiments on the PowerEditPlugin with this in mind, and I think it isn't a prohibitive amount of work to extend it to be a WYSIAWYG (A=Almost) editor, focused on TWikiML. The package already uses the gnu.regexp Java classes, so the TWiki RE's that are used for formatting can be reused directly in the editor. It could either be mode-switchable (plain text / formatted text) or with a bit of extra work, it could provide proper WYSIAWYG editing. It would be entirely JDK1.1, so no Java Plugin would be required with most browsers.

Anyone interested? Any point in pursuing this?

-- CrawfordCurrie - 12 Dec 2003

I think this is a great idea. I also think a Java 1.4 client application with more features would be a good idea, likely based on an existing powerful HTML editor. So that would give us a spectrum of editing capabilities:

• Text area of the Web browser (very useful, suprisingly powerful, but very offputting for many potential users)
• JavascriptBasedEditor - a bit better than the text area
• EasyEditorRevisited - as above
• TWikiEditClient - a full feature standalone client

And while I'm wishing for great things - WebServices to support the above.

-- JohnTalintyre - 12 Dec 2003

Crawford, I was thinking exactly along the same lines. The best approach seems to be a WYSIWYG editor that works natively on TWikiML and that leaves HTML tags alone. Advantages:

• Avoid the error-prone TWikiML => HTML => TWikiML roundtrip
• Possible to edit same content with / without WYSIWYG editor (depending on client capability and platform)
• Discourage user to use of HTML
• Maintain clean content which can be transformed easily into other formats like DocBook (see TWikiForBookAuthoring)

-- PeterThoeny - 14 Dec 2003

Looks like this discussion is mostly over. But I'll tell you my biggest user-experience problem is finding the text I wish to change on a long page. Its frustrating to have to use Find-and-Replace to find the bit you want to change after you press "edit" button. In a WYSIAWYG editor/viewer, presing "edit" wouldnt change the screen much, making the transition from reading to editting much easier. I think Peter's comments are on the money. Best to avoid HTML tags

-- MikeRoss - 29 Jul 2004

This discussion is just hotting up for me. I've got a group of users who are technophobes at the best of times but really want to be able to use the TWiki cause its perfect for the environments in which they work. We've been working on implementing the TWiki for a year now and still can't get them over the barrier of having to use a bit of TWiki code. Its no use saying that they can just put their content in in plain text; there's a degree of professional pride that goes with putting your stuff out in public. The group is a global group dispersed as individuals across the world - so the option of a short group face to face intro isn't possible.

One of the people in the group has discovered Wikipedia that has a simple edit page and now there's even more of a resistance to the edit screen of TWiki even with, what I think, is very helpful coding support on the Cairo release.

I've just spent the last couple of days going through all the options available for TWiki and can't find one that doesn't have bugs yet to be sorted out, needs server level skills beyond my simple skills to install, needs specific applications at the server level that aren't on my service (futurequest.net), or needs compromises of some sort that really aren't acceptable.

I'm frustrated. I'm not sure that there is anywhere I can go with this frustration, except to go back and look at Wikis again to see if their content management has improved. BUT I don't want to give up yet and heck its been a lot of work to get the TWiki this point. Another BUT - but I can't deliver what my users want. From their point of view the brilliance of the backend of the TWiki is not something that even enters their heads. They just see the problem as - "if Word can make it so simple, and the same sort of edit functions are on the Wikipedia - how come it can't be done on this TWiki?"

Is there a light at the end of the tunnel on this? Has there been any recent breakthroughs? Kupu looks promising I know - but its not going to work for me.

-- SueLocke - 28 Sept 2004

Did you consider enabling WebDAVPlugin on your server? It lets people use the tools they are used to for editing content. Though it still doesn't overcome the TML barrier. The way you describe it, only a WYSIWYG editor is going to be suitable. Quite simply, there are none out there until Kupu is fully integrated (though there is an editor for Linux Qt called owikipad that might be what you want.)

I'm afraid that as is often the case with this sort of thing, everyone wants it, but no-one is prepared to put in the resources to provide it. I personally had to drop development of PowerEditPlugin in favour of things that pay the bills.

-- CrawfordCurrie - 28 Sep 2004

Sue, you don't say why Kupu won't work for you. Is it that the current implementation does not work, its system requirements too high or something else?

-- MartinCleaver - 28 Sep 2004

Thanks for the quick feedback. Thanks also for the tip about WebDAVPlugin. I'll investigate that. Sounds interesting. Yes I know about the bills dilemma. Facing it myself at the moment while I'm trying to track down a WYSIWYG solution that someone else has generously coded voluntarily and made available for free.

The reason for not wanting to go with Kupu is that I'm worried about a comment or two in the discussion on this TWiki about Kupu. Someone (can't remember who) talked about how Kupu will require you to manage links through the drop down list box meaning that the ability to "handcode" links won't be available. That's important to me - I want any plugin or add-on to enable flexibility in coding approaches. The fact that its buggy isn't so much of a problem - early days yet.

I've worked a work around in the meantime (thanks to a quick response from Peter to a support question). The HTMLarea application which is one of the possibilities being explored is up on the web for free usage at http://fslactivities.sd61.bc.ca/ezHTMLarea/index2.html. So I've added a link to that as part of the formatting help at the end of the edit screens and put some basic information on how to use it there as well.

Its not ideal cause of the HTML as well as a possible confusion for users over any existing page content not appearing in the HTML editor.

I REALLY like TWikiML - so clean and slim. But for my technophobe users they see WYSIWYG as a simple way to go (just proves I think that its really about what you're used to) and I don't expect that they are going to get deep into editing existing pages. My observation of their behavior to date is that they'll just use the comment box I've included at the end of the user pages, or simply create a a Wikiword and spin off a new page altogether. I'm hoping that they'll discover themselves the simplicity of TWikiML themselves (given that both methods will be constantly before them) and so its not a case I have to use this if I want to use the TWiki rather its I want to use these codes. Anyway time will tell. Sorry for the long rave.

BTW - I still think TWiki rocks, and I still can't find anything better.

-- SueLocke - 29 Sep 2004

If your users are asking for Wikipedia like editor, then they are asking for a Javascript based editor, not a true WYSIWYG editor. TWiki has a JavascriptBasedEditor, although with a flaw: It is packaged as a skin, so you need to enable the iejs skin to use it, loosing any other cool skin you have. You can try it out by editing a page and appending &skin=iejs to the edit screen (This skin is disabled on TWiki.org but shipped with TWikiRelease01Sep2004). If packaged properly as a Plugin it would be a low hanging fruit to get what your users want.

Anyone interested in helping out Sue by creating a JavaScriptEditorPlugin based on the iejs skin?

-- PeterThoeny - 29 Sep 2004

Sue, the wikipedia editor is not WYSIWYG, it is like the one we find in a lot of forums: something that will get your users the illusion of comfort for 20mn then they will be as much frustrated as before.

On the HTML editor rather than native TWiki ML editor, I think we should go the HTML route. Why?

• Writing a good editor is super-hard. Manpower can be found on the widely used HTML. You will not find it for TWiki, forget it. Nobody will put the gigantic effort to make a reliable editor for just TWiki. If all the Wikis had the same syntax, it may be a possibility, though. An editor should be able to confortably edit big tables (non-tech users tend to do a lot of tables), and be as reliable as possible.
• An HTML editor gives you ... conversion from HTML to TWiki !!! For instance we at ILOG are using the kupu editor converter to automatically convert a 150 pages + 450 html web site to TWiki. Basically, HTML->TML is hard but it will bring you LOTS of goodies:
  • conversion from legacy HTML
  • interchange with other twiki (by converting to html as a pivot format)
  • offline editing with any html editor

I am debugging now the HTML->TML converter part and hope we can get a really usable Kupu TWiki editor soon.

Note that the recent move of Damien & Romain to javascript for the translator may prove more difficult to have also an offline standalone converter than the previous server-side java implementation, we will see... The best solution may be to rewrite the converter in perl, server-side.

-- ColasNahaboo - 10 Oct 2004

Colas. That's great to hear, and I look forward to seeing the outcomes of your work. I particualrly like the sound of - "An HTML editor gives you ... conversion from HTML to TWiki !!!". Just want to check the flexibility of Kupu - will it enable "hand coding" of TWiki ML as well.

-- SueLocke - 12 Oct 2004

On hand editing: It is a tricky question. If you allow TML you will not be WYSIWYG anymore, that could puzzle users, and make the editor react unpredictably. We'll look at the ways we could overcome this difficulty.

-- ColasNahaboo - 12 Oct 2004

Have just installed the Firefox extension - http://twiki.org/cgi-bin/view/Plugins/FirefoxExtensionAddOn. A step in the right direction, although obviously only in the Firefox environment.

-- SueLocke - 14 Nov 2004

I think that FCKEditor is the best WISIWIG editor so far. I used it for coding ColdFusion applications and think it is almost perfect WISIWIG solution. It lets you toggle between WISIWIG or html source views and even lets you make tables and place images. It is almost like working in a desktop editor. It works in both IE and FireFox. I wish I could integrate it with Twiki myself but Perl is not my expertise. I hope someone can work on it and integrate FCKEditor into Twiki. It has native perl integration in its most recent release. (released in March 2, 2005). Here is the link: http://www.fckeditor.net As many of you wrote here, I spent many hours for research and installing Twiki but am facing non-techie users reluctant to learn TML. I am looking forward to see someone making a great leap happen.

-- JimmyCretney - 04 Apr 2005

I now have FCKEditor working in my Twiki installation. This is the javascript above and replacing the initForm function in my /pathtoTwiki/templates/edit.pattern.tmpl file. I copied the FCKEditor files to /pathtoTwiki/FCKEditor. I have not done extensive testing with this but things seem to be working fine for now.

<script type="text/javascript" src="../../../fckeditor.js"></script>
<script type="text/javascript">
<!--HIDE
ns4 = (document.layers)? true:false;
ie4 = (document.all)? true:false;
dom = (document.getElementById)?true:false;

toShow=new Array();
toHide=new Array();

function initForm() {
  document.main.text.focus();
  var editor = null;
  for (i = 0; i < toShow.length; i++) {
     if(dom) {
        document.getElementById(toShow[i]).style.display="inline";
     } else if( ie4 ) {
        document.all[toShow[i]].style.display="inline";
     } else if( ns4 ) {
        document.layers[toShow[i]].style.display="inline";
     }
  }
  for ( i = 0; i < toHide.length; i++) {
    if(dom) {
        document.getElementById(toHide[i]).style.display="none";
    } else if( ie4 ) {
        document.all[toHide[i]].style.display="none";
    } else if( ns4 ) {
        document.layers[toHide[i]].style.display="none";
    }
  }
  editor =  new FCKeditor( "text", "100%", "200", "Default") ;
  //editor.Create();
  setTimeout(function() {
     var sBasePath = '../../../FCKEditor/'
     editor.BasePath     = sBasePath ;
     editor.ReplaceTextarea();
  }, 500);
  return false;
}

-- ChrisMoon - 08 Mar 2005

Chris - Good work on FCKEditor! Do you by any chance have a public site where you could demo it? Also, I'm wondering a couple of things:

• I'm assuming that you've not incorporated any kind of TWikiML translation. Have you abandoned it all together, or do you offer both options?
• What effect does your implementation have on versioning? Does it still create an edit history and, if so, how does the version diffs long?

-- LynnwoodBrown - 04 Apr 2005

Related Topics:

• TextFormattingRules - the twiki markup to html equivalents table
• AppletBasedEditor - the topic that started it all, most of the background material is here
• JavascriptBasedEditor - a working text only and browser integrated app, IE only.
• DownUploadForEditing - click link to load textform into your editor; click upload button to send it back
• EditDaemonWithGVimIntegration - program to fetch and save TWiki files, integrated with the VimEditor.
• PowerEditPluginDev
• EasyEditor
• DeactivateHTML