Applet based editor for the less geeky individual

What do people think of this:

• User can opt for applet based editor in their preferences (rather than existing text box)
• Most of applet is large text area
• Buttons for common markup: bullet, bold etc
• Button for signature
• Way of putting in a drawing, toc etc - with some help on parameters
• Launch as either (resizable) separate window or have (if possible) as resizable embedded applet
• Would be useful where there are browser limitations for text area, but Java is available e.g. Netscape

I'm not suggesting a WYSIWYG application, might be possible, but sounds like hard work.

-- JohnTalintyre - 09 May 2001

Yes yes yes. Soo many people have told me that they don't want to learn Wiki markup and that MS Word is too much easier.

There must be a Java or Javascript applet that we can steal to implement this.

WRT Signature: why not automatically append the signature when the edit pane is opened?

-- MartinCleaver - 10 May 2001

This is not an issue of stealing something as this needs to be TWiki specific. I don't think Javascript works, because I don't think cursor location in Textarea is available (might be wrong about this). Even if it is - they'll be big variations between DOM for Netscape and IE to contend with.

It's not always acceptable to add a signature. However, see AddToTopic.

-- JohnTalintyre - 10 May 2001

WRT Stealing something - I was thinking of either (1) leaving HTML in the pages (shock horror) or (2) round tripping HTML to/from WikiMarkup.

Why would the cursor be an issue? Is there a toolkit that has factored out the differences between IE and Netscape?

WRT signature: when would it not be acceptable? Could they not delete the signature if they need to?

-- MartinCleaver - 10 May 2001

This would be really useful - I'd like to roll out TWiki to non-technical users (e.g. sales people) but there's no way that the current ascii-formatting approach would be acceptable.

There must be some Java-based editing applets out there that are open source. I had a quick look and found the following - none is exactly right, and none is an applet, but all are open source:

• JE, http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/je/ - standalone application, quite feature rich but not yet complete - can be tried as an applet at http://mathsrv.ku-eichstaett.de/MGF/homes/grothmann/je/Try.html
• Simredo, http://purl.oclc.org/net/klivo/simredoeng - simple, includes fonts and Unicode support
• Jedit, http://jedit.sourceforge.net/ - complex programmer's text editor, includes plugins. Also has a separate text control that might be useful.
• mpEdit et al, http://www.javacommerce.com/mptools/ - various editors including some quite simple ones - one is designed for use from other Java apps.

One Java editing applet is Gibberish, at http://javaboutique.internet.com/Gibberish/ - not open source, gives an idea of how this should work, and on download times for a simple applet. Since TWiki is intranet focused and the editing applet would be optional, size is not too critical but the smaller the better - Simredo is only a 100 KB JAR file and could be slimmed down quite a bit for TWiki use, I think.

I don't much like the idea of using JavaScript, since it is so variable between editors, but a shareware editor in JavaScript is at http://www.cris.com/~raydaly/hjdemo.shtml

Probably something simple is the best starting point, since TWiki's needs here are quite different to those of most Java-based text editors.

As for the requirements, I mostly agree with John:

• WYSIWYG would be useful, as it would enable much less technical users to use TWiki by hiding the TWiki syntax details, but is obviously a lot more work so not essential to start with. TWiki's biggest competition is probably Microsoft Word, which most people are very comfortable with, so adding WYSIWYG in medium term would be great.
• adding signature - I'd like to see auto insertion as a feature, controlled by site, web and user preferences, as well as having a button
• cut, copy, paste
• undo (nice to have, but IE 5.0 does have this)
• buttons to help with formatting, bullets, etc.
• buttons that pop up dialogue boxes for more complicated syntax, e.g. external links, TOC, etc.

-- RichardDonkin - 20 May 2001

I have one if you'd like it. Very fast, very basic plain-text Java 1.1 editor applet, find, replace (both regexp), cut, copy, paste, undo. Only runs in a separate frame, not on the browser page, as it requires menus and dialogs. Integrated (and working) in the Dec 2000 TWiki release. Requires a modified edit script and a modified upload script, so it will probably need updates for the upcoming (!) major release, which is why I haven't submitted it before. If there's interest, I would be prepared to do the necessary integration - perhaps as a plugin?

-- CrawfordCurrie - 23 Jun 2001

Oh yes yes yes Pleeeeeeeeease.

-- MartinCleaver - 24 Jun 2001

Crawford, I'd like that as well, and my comments are not directed specifically at your applet, but just some wish list items I'd like to have in such an applet.

I'd like to have some shortcut method to insert "arbitrary" boilerplate text of my own composition. Maybe keyboard shortcuts, maybe a series of user definable buttons, maybe ??

And, I know that several people have asked for some sort of feature to remind them of the names of other existing topics while editing.

If your applet doesn't have these, I'd still like to see it implemented -- after all, it will be open source, and someone can surely modify it. (Java is not on the list of things I want to learn, at this time.)

One more thought -- I read and edit Twiki from both IE5 and konqueror (as I'm trying to switch to Linux to the extent it's practical). I set my personal preferences so the TEXTAREA edit box fills my entire window vertically and horizontally. The problem is that the settings have to be significantly different under IE5 and konqueror (because my "chosen" fonts are sufficiently different to require this) -- IE5 handles something like 30x92, konqueror handles something like 24x72. It would be nice if an applet could recognize which browser I am using and size itself accordingly. (This may be less of an issue with an applet than with the current editing scheme -- this just seemed like a convenient place to raise this issue in general. Of course, I could register in TWiki twice under two slightly different names, but I hesitate to do that.)

-- RandyKramer - 24 Jun 2001

Oh, and a paste rich text format would be nice, especially if it could paste pictures. (My enthusiasm level is back to normal now :).

Anything, my users tell me, is better than plain text. (Hey, I came from a coding background so I care less than most.) Even I would find it so nice to be able to do stuff like ctrl-l for list bullet, ctrl-b for bold.

-- MartinCleaver - 24 Jun 2001

I'd also be interested in experimenting with this - would make a big difference to most environments, where most people use rich text even for email. Only the old ASCII email lags like me even know that *this* signifies emphasis...

-- RichardDonkin - 26 Jun 2001

If you work in a company we're IE is the dominant browser, a quick solution is to add a JavaScript-based "markup-helper-line" (as shown in the picture below).

I've attached the source code for it (taking from the lovely Manila editor). It includes some test text and additional markup, but it should be pretty easy to cut'n'paste the pieces you need.

And even if you're workplace is 50% IE/50% NS you'll do good by adding the "markup-helper-line", as it just doesn't show up in NS.

-- DavidHeinemeierHansson - 28 Jun 2001

I like it, thankyou! Its quite a simple piece of code as well, shouldn4t take a programmer more than a few hours to make it do WikiMarkupLanguage.

It4s a nice way to get people up the learning curve, even if it isn4t WYSIWYG. Perhaps we can make it a plug-in for those installations for which Crawford4s java editor is not acceptable?

-- MartinCleaver - 28 Jun 2001

Using textarea with this MS exentensions, looks okay for IT users. Need to fiddle a bit to do other changes that insert at start of line, but not too bad. No need for a plugin (unless you only want it to appear based on user preferences), just put in edit.tmpl.

-- JohnTalintyre - 28 Jun 2001

JavaScript based editor looks like a useful alternative. BUT: What about copyright? We can't takethis code since Manila is a commercial product!

-- PeterThoeny - 28 Jun 2001

I think we just need to take a couple of ideas from the JavaScript, I'll try and post and example soon.

-- JohnTalintyre - 29 Jun 2001

While our 'standard' is IE, we have people on Opera, Netscape, Konqueror and Mozilla as well. Using IE tags is therefore out of the question for us, and even JavaScript has a very bad name due to it's propensity for crashing browsers.

Since my last post I've managed to make the applet live in the browser frame as an alternative to a separate frame. As for markup, it's simplicity itself to add button furniture and key accelerators to add whatever markup you like. I haven't done it (other than to add a "sign" button) simply because the KISS principle dictates otherwise.

I'll attach the latest jar (when I get home tonight) for you to have a look/play.

I've also done some experiments with a JDK1.3 enabled browser and the Swing HTMLEditorKit (Swing has powerful HTML handling built in). Given a DTD for the TWiki markup language and a 1.3 enabled browser it should be possible to create a simple WYSIWYG editor with a relatively few lines of Java.

-- CrawfordCurrie - 29 Jun 2001

I've done a few mod's to the Javascipt based editor - see JavascriptBasedEditor

-- JohnTalintyre - 29 Jun 2001

See attachment twikiedit.tar.gz for the prototype editor applet. Source will follow shortly. Share and enjoy. The applet is installed in JavaEditorAppletSample but I get security exceptions downloading the jar. Anyone who knows about these things, please fix it! Thanks. Oh, and I added markup macros.

-- CrawfordCurrie - 29 Jun 2001

There is an IE only WYSIWYG JavaScript at http://standardbrains.editthispage.com/ the author, Derek Robinson, mentions he thinks (hopes?) he can create a cross browser version with Mozilla/NS6+.

-- MattWilkie - 27 Sep 2001

Editor like this keep on cropping up. Always look for execCommand in the JavaScript. This means two things:

1. It's specific to IE
2. It's specific to HTML (i.e. can't be used for Wiki markup), it magic for the built in html capabilities in IE. Unfortunately it's not even DOM based.

-- JohnTalintyre - 27 Sep 2001

Well, to answer (1) - I suppose for the IE people among us, we could write a filter that post-processes the HTML.

And for (2) - Some of my people don't care too much whether the underlying page is stored in HTML or in WikiMarkup, although others do. Personally what I care most about is that the page names are WikiWords and that everyone can use our server.

I did a bit of research into HTML editing and found this:

• http://www.byte.com/documents/s=357/byt20000504s0001/index3.htm

• http://www.softwarefiles.com/Files/1145.shtml

Given requests such as ImportingExistingHTMLintoTWiki it looks like the filter to go from HTML to WikiMarkup would be generally useful. After all, the TWiki community have the GenHTMLAddon to go the other way and we want to encourage people in rather than out!

-- MartinCleaver - 19 Nov 2001

I see the whole problem as a dilema. The TWiki syntax is both very easy to learn and, because of providing HTML, also very mighty. But then todays non-computer related users don't want to learn any kind of markup (not TWiki, not HTML, not XML, not TeX or Lout). TWiki markup is a very good compromise for programmers. But then if some kind of word processor app should hide this, the TWiki markup is not good to represent rich text, because it's very hard to both handle TWiki and HTML. Leave TWiki out and you loose all benefits for "us hackers" who'ld prefer the text box for quick editing. Leave out HTML and you loose formatting capabilities which make especiall TWiki a very attractive Wiki.

First converting TWiki to HTML, then use an HTML-WYSIWYG and edit, then convert back to TWiki what's possible, seems to be extremely difficult to me. Besides, would this really be WYSIWYG? For which browser?

This suggests using another well defined and structured representation, say some XML language that could be transformed back and forth to TWiki markup as well as beeing easily used be some wysiwyg tool. But this sounds a bit like overkill for this tool.

Not considering WYSIWYG, then a texteditor as proposed above would clearly be nice, but I'm quite sure that dummy users still won't like using twiki, as Word, Excel and Access still work differently. I see no way to convince "them", that text editing is really not so bad and markup not so hard to learn and use.

-- MichaelUtech

-- MartinCleaver - 21 Nov 2001

I found a perl script for converting html to PhpWiki, html2wiki.pl - perhaps it contains material which can be adapted to TWiki. Google finds 2 references to an older 1999 html2wiki.pl but not a link to the script itself.

-- MattWilkie - 21 Nov 2001

Just catching up after not visiting for a while.

Another approach would be to DIY. Java 2 includes something called the "HTMLEditorKit", using which it's fairly easy to build a simple WYSIWYG editor for HTML. What's more, it's wide open to the addition of new formatting types. An editor based on the HTMLEditorKit that also reads and generates WikiMUL sounds like a lovely little undergrad honours project. Of course, users would require the Java 2 plugin in their browser.....

-- CrawfordCurrie - 27 Feb 2002

I found http://www.seedwiki.com - a WikiFarm with free wikis. They have ActiveEdit an ActiveX DHTML editor. Is something relevant, or different technology? Sorry, it is jumbo mumbo for me. homepage is http://www.cfdev.com/activedit/

-- PeterMasiar - 28 Feb 2002

This won't really help - ActiveX is proprietary to Microsoft (part of InternetExplorer)...

-- RichardDonkin - 28 Feb 2002

I'm not sure if this will help anyone, but I will relay it anyways.

I've been looking for a decent solution for page edits on TWiki besides the crappy textarea, and one thing that came to my mind is to provide an instant preview.

Below is sample code that will allow for instant preview. There are several problems with this code.

1. Code does not parse TWiki syntax variables etc. (haven't figured out a way to do that without doing requests to the preview cgi constantly in a iframe, or something else) This would be a good way to see your html code instantly though.
2. innerHTML attribute in javascript seems to only be supported in IE, so a different means would need to be created for Netscape(Mozilla) users.
3. Other things I can't think of at this time.

This code is just provided for a means of sparking someone's creativity to come up with a decent solution.

Anyways, here's the code:

<html>
<head>
<title>Test for TWiki non-textarea editor</title>

<script language="JavaScript">
<!--

function updatediv(textobj)
{
    preview.innerHTML = textobj.value;
}

// -->
</script>

</head>
<body bgcolor="#FFFFFF">

<textarea id="text" name="text" style="width=100%;height:200;" onkeyup="updatediv(document.getElementById('text'));">
</textarea>


<div id="preview" name="preview" style="width:100%">
</div>



</body>
</html>

Hope this helps.

I'm afraid nothing is going to change the fact that moving beyond the existing Javascript template (not enabled by default on TWiki.org) to a WYSIWYG will take a fair amount of development work. The are various ways of rendering HTML that can be used in different browsers, but not of Wiki markup. The simplest starting point would be to do a basic TWiki markup to HTML applet in Java - the Java based Wikis should help here. This would provide at least partial preview, which could be made semi-live by running in a separate thread. However, going for a full editor will be far from simple.

As well as only working in MS Internet Explorer, ActiveX poses major security issues. Some users of TWiki worry about cookies - ActiveX is almost infinitely worse.

-- JohnTalintyre - 08 Mar 2002

Or by using an xml template via the Sablotron plugin? The xml template loads into a stand alone applet (xybrix?). User modifies the form, saves and the xml is saved either to the user dir (if local) or saved to the DOM and then to the server. The xml is then transformed to perl via xsl.

This would certainly make creating new forms easier... -- DennisDaniels

-- JustinHickman - 08 Mar 2002

I think the solutions proposed have been overkill. As nice as it would be, you don't need to have a browser based editor. You don't need to start with XML, HTML, or anything else as complicated.

All you need is an editor that can suck the raw twiki format document out of the twiki site, render it correctly (minus obvious problems such as some types of twiki variables) and then spit it back in two twiki. I do this manually with Emacs and cut and paste. It shouldn't be much harder to create the appropriate CGI input and output code as well as the host resident editing code.

I'm just thinking out loud here but, I think you could probably handle twiki variables by prerendering them if that's possible and letting the editor render the others on the client side. Of course, the whole topic of twiki variables creates an interesting discussion in and of itself.

-- EricSJohansson - 21 May 2002

Just found out about the XopusEditor. It promises to be a browser based in-place wysiwyg XML editor with a plugin architecture.

-- MattWilkie - 04 Jun 2002

Slightly digressing here: People edit twiki pages for different logical reasons:

• Add a comment (Plug-in can do)
• Collaboratively write a longish document
• Changes to existing (longish) document:
  • Add/remove specific item in a list
  • Change a specific paragraph (or add a new paragraph)
  • Change a table (or add/delete rows etc.)
• Reorgainize page / thoughts / comments

And so on. The applet-editor is required for creating longish documents, or for a large editing. But I find that most of the times, we manage data. So even a simple "Add new item" in an existing list will do for me.

In essence, the requirements for structured editing - where the individual items of a logical structure of a document are to be edited - are different. And like we have a table editor plug-in, we could add features specifically for structured editing.

For "bulk" editing, one of the ideas that I had was to allow people to use Word to edit the files. We can use libraries such as wvware (http://www.wvware.com/) to parse them and convert them back to what TWiki expects as format.

-- VinodKulkarni - 06 Jun 2002

Just one addition with no comment for those who fuss about browser independent WYSIWYG editor:

http://www.cen.uiuc.edu/bstats/latest.html

Browser Statistics for Wednesday 19/Jun/2002

Browser Platforms
 Browser Platforms                Hosts     %
 --------------------------------------------
  1. Windows                       3643  44.4
  2. Windows 2K (NT5)              2946  35.9
  3. Windows NT                     601   7.3
  4. Macintosh                      301   3.7
  5. X11                            205   2.5
  6. other                          514   6.3


Browser Flavors
 Browser Flavors                  Hosts     %
 --------------------------------------------
  1. Microsoft                     6786  82.7
  2. Netscape                       937  11.4
  3. other                          487   5.9


Browsers
 Browsers                         Hosts     %
 --------------------------------------------
  1. Microsoft Explorer (NT)       3348  40.8
  2. Microsoft Explorer (Win)      3245  39.5
  3. Netscape (Windows)             436   5.3

  4. Netscape (X11)                 200   2.4
  5. Microsoft Explorer (Mac)       191   2.3
  6. Netscape (?)                   131   1.6
  7. Misc Netscape-compatible       130   1.6
  8. Netscape (Macintosh)           102   1.2
  9. Opera                           85   1.0
 10. Netscape (NT)                   68    .8
 11. Java/JDK/HotJava                14    .2
 12. GetRight                         5    .1
 13. Microsoft Explorer (WebTV)       4    .0
 14. Lynx                             4    .0
 15. OmniWeb                          3    .0
 16. NetPositive (BeOS)               1    .0
 17. WWWC                             1    .0
 18. Crescent ToolPak                 1    .0
 19. Linkbot                          1    .0
 20. other                          240   2.9

So I would love to see an IExplorer specific one.

-- DavidKosa - 20 Jun 2002

The SeedWiki provider makes use of a WYSIWYG control that works in IExplorer. The control, called ActivEdit, is from a commercial venture. I'm not sure if it was donated to SeedWiki or what. I'm also not sure if it could be gotten for or adapted to TWiki. But it sure makes editing easier!

-- PhilBarnes - 21 Jun 2002

Just came across this page. Most interesting as I have been thinking about a java based editor for a while. Not WYSIWYG, but with the ability to do lists, italics, bold, headings (ie: basic wiki formating).

Beware Javascript solutions (I never use IExplorer as they won't support my OS :-). Opera does not have a good javascript implementation and there are just too many differences and gotchas between Netscape and IE. I think it has to be a java applet of some sort, similar in concept to twikidraw. I'll have a look at the afformentioned examples (above) and see what state things are in.

-- BrianWallis - 28 Jun 2002

Just a really really short note... Wouldn't it be better to have Applet in MacromediaFlash ?

With advancment of this technology a lot of ambitios projects started appearing. Actually my home organisation, Multimedia Institute will be developing this in next year to accompany existing MoinMoin fork which relays on TwistedFramework (Python). It would be interesting to use Wiki concepts in non-browser environment and since latest Flash parses XML with no problems this might be better interface for working (no browser bugs, saveing and going back to documents... waiting for rendering of long pages...).

It might be interesting concept however to have API that access the Wiki data directly and draws tham in vector data like http://www.thebrain.com/ does.

• see TouchGraph, WebMap and WebDOTPlugin for working proof of concept implementations in java and svg. -- MattWilkie - 20 Aug 2002

-- ZeljkoBlace - 20 Aug 2002

Just stumbled upon http://www.bitflux.ch/editor - open source, wysiwyg HTML editor for Mozilla, with IE6 support coming. Works nice and produces fairly clean html. With such a product I guess roundtripping wiki-html-wiki would become possible? Still you've issues with Wiki specific stuff (like %SEARCH% etc) but well, it could be a start ... And since the thing is opensource, we could add stuff like a 'query builder' which inserts a search tag (of course this would not be wysiwyg - unless you go through hoooops.

The most comprehensive list I've encountered of browser based editors is hosted at http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html:

To be listed below the editor widget must be TTW ("through the web" - it works within a browser) and WYSIWYG ("what you see is what you get" - you don't see HTML). Some widgets allow you to toggle between "view" and "source" modes - this is a bonus but not a prerequisite for this list."

What will it cost to develop an EasyEditor for Twiki?

-- MattWilkie - 17 Oct 2002

Here is another approach: In email based interface to twiki, the user receives all changes to twiki topic(s). Select the latest version of topic, open it in "Edit" mode, Edit it, and send it as email back to twiki. Most email systems have good editors. By including raw markup as well as HTML markup, we let the user choose whatever editing she wants. And if we make HTML editing in this mode easy to do, it will greatly help push twiki into organizations.

And since we are generating HTML in the first place, include extra information in the HTML so as to have two way synchronization possible between twiki markup and HTML markup. For example, an element such as

 
   Example *Bold* and a link to WebHome.

<p id="p21">Example <B id="b22">Bold</B> and a link to <A id="a23" args="WebHome" href="https://twiki.org/...">WebHome</A>

Here id has info about type of tag auto-generated, and a sequence no. so that you identify whether the information was re-arranged. And some tags may have arguments retained as is as extra information. Simple modifications to pages are almost always identified in this mode. But creating completely new sections would require us to convert that part of HTML into twiki markup. Tables can also be managed in same way.

-- VinodKulkarni - 26 Oct 2002

The problem with this style of autogenerated tag is that the trip is one way. All of your users would have to use the new edit mechanism as the raw text becomes unreadable with the proliferation angle brackets and id labels.

-- MattWilkie - 28 Oct 2002

Let me clarify here: I was talking about two-way synchronization between twiki "raw" data and HTML generated output. Whenever the version changes, you generate one from another automatically. So the question is, given auto-generated HTML version, how do you generate original twiki source as is?

I am trying to do two-way synchronization between twiki content sent by email (i.e. include both raw and html for every changed topic) and topic source at the twiki setup. I would like to be able to integrate changes done through email editors (either html composers, or just plain simple raw text editing with 'edit as new' option in mozilla) back into original source, and increase version by one. (Well, still dreaming.)

-- VinodKulkarni - 29 Oct 2002

See my comment on DownUploadForEditing (JeroenVanDongen - 31 Oct 2002) for a potentially usefull approach (down/uploading in combination with a desktop WikiML editor).

-- DirkLuetjens - 24 Nov 2002

Just found another embedded WYSIWYG HTML editor at http://richtext.cs.ramesys.com/. Form the website

"The editor is an Internet Explorer based WYSIWYG HTML Text Editor which can be hosted in a web page or form. It requires no additional components as it is written entirely in DHTML and JavaScript."

So it only works for the Microsoft Internet Explorer.

Could we have a go at integrating The Midas solution? This ia a solution that nicely works together with Mozilla & IE. Seamlesly. Have a look at:

* http://www.mozilla.org/editor/midasdemo/

Don't know where to start, but I'd love to have this verry light solution in.

-- GerkeKok 17 Apr 2003

The Mozilla Midas demo looks really good and works in IE as well, so it seems like a good starting point - best discussed under JavascriptBasedEditor, or on a followon topic since it's a lot more more ambitious, but not here since it's not applet based.

-- RichardDonkin - 17 Apr 2003

I have almost finished extending the PowerEditPlugin to support an optional "Live Preview" pane. This displays the formatted page (TML and HTML) while you are editing. I'll post a demo to PowerEditPluginDev when I've finished testing against the XHTML1.0 spec.

-- CrawfordCurrie - 18 Jan 2004

Demo posted as promised. feedback ( any feedback) welcome.

-- CrawfordCurrie - 03 Feb 2004

Just wanted to add, that I just found out that http://www.editme.com has a very good WYSIWYG Editor implemented on their site. Sadly they do not offer the source, since it is a commercial site. (editme.com appears to be using the HtmlAreaEditor. -- TC )

-- RobertRackl - 10 Feb 2004

Not sure how far you are on a WYSIWYG editor, but a nice, source included one is eKIT

-- MarkMurphy - 15 Jun 2004

• http://www.bris.ac.uk/is/projects/cms/ttw/ttw.html - a comprehensive list of browser based editors
• http://www.oreillynet.com/pub/wlg/2449 - Uche Ogbuji at O'Reilly Net also plans to keep track of wysiyg web editors
• http://meta.wikipedia.org/wiki/WYSIWYG_editor - Wikimedia's plans for WYSIWYG editor with links to resources