Tags:
create new tag
, view all tags
TWiki, and other wikis too, could benefit from an Easy Editor. I'm the purposely using the term Easy rather than WYSIWYG or GUI because a better editor does not necessarily mean graphical. See AppletBasedEditor for some related thoughts on this. That said there are some gui-based editors based on web technology which look promising.

KupuEditorAddOn is currently showing the most promise using the GUI approach. It is under active development and works with twiki right now. It is still in the early stages and there are some rough spots though. The rest of this page is largely historical

From the research done so far [now out-dated], the most promising candidates are listed below. Lacking the skill to integrate them myself into Twiki, I (MattWilkie) asked each of them for a price tag on building an integrated editing app for Twiki.


>> Are you still interested in possibly funding EasyEditor development?

Interested but unable. frown I'm a GIS guy. I'm not supposed to be working on Intranet stuff, which is quite outside my job description now. There is no apparent interest from the folks who are responsible for our intranet to improving our horribly inefficient and underused setup. The issue is not whether TWiki is an appropriate tool, but whether there is anything to fix in the first place. On the bright side, my boss's boss took some kind of management course last spring wherein the virtues of wiki were extolled. She was delighted to be able to say "Hey! We have one of those already!" Not that she uses it much mind you, but at least I have some support from above.

I'll leave my original request in place for context though (and in case anybody else wants to pick up the ball).

-- MattWilkie - 06 Feb 2004

Request for Price Estimate Letter

To Whom It May Concern,

How much would it cost to modify/adapt your application to editing TWiki?

TWiki is a web based collaboration platform which uses TEXTAREA boxes and custom markup delimiters to allow users to edit and contribute content to the site. While using a simplified custom markup language is easier than learning html it still is a significant entry barrier for non-technical users. TWiki could greatly benefit from a client side application which handled the markup and allowed the user to leverage their existing word processing skills.

Requirements:

  • Must leave existing text alone. This is important for two primary reasons: 1) Users with non-supported browsers must be unaffected, and 2) we don't want to screw up the version control.

  • Configurable on a per site basis - though >90% of installations use the default formatting codes, there are significant installations which use slightly modified rendering rules. This would also enable different wiki flavours to use the same application. The particular ruleset I'm interested in is described at http://twiki.org/cgi-bin/view/TWiki/TextFormattingRules.
    • There is one difference from the ruleset described there which I would like very much to see: the ability to use [tab] instead of "[beginning of line]three spaces" for doing bullets.

  • support as many browsers as possible, with the bare minimum of IE and Mozilla/Netscape. (If only supporting one browser is possible with your app, please provide a quote anyway but understand it will lose marks because of this)

  • If necessary, changes to Twiki could be made to help better integrate the two environments. Please be as specific as you can about what changes would be necessary.

  • If we pay for this development, the resultant application and source code must either:
    1. available under an OSI approved open source license (http://opensource.org/licenses/) {this is the preferred option}
    2. jointly owned by you and us, with each party being free to modify and distribute the application at will, irrespective of the other party's activities.

Secondary Goals:

For more information:

Sincerely,

-- Matt Wilkie
--------------------------------------------
Geographic Information,
Information Management and Technology,
Yukon Department of Environment
91780 Alaska Hwy * Whitehorse, Yukon * Y1A 5X7
867-667-8133 Tel * 867-393-7003 Fax
--------------------------------------------


Comments

Am I missing anything important? (feel free to add requirements and/or clarification inline above)

Please note that I haven't actually secured any funding for this yet. I'm hoping that I can use the answers to this query to do so, or failing that do a donation drive or something on Twiki.org.

-- MattWilkie - 17 Oct 2002

I'm not sure how paying a company to do this would work, though if the money is available to develop an OpenSource implementation that would be great. Since TWiki is GPLed it might be good if the app too was GPLed - at the very least it must be OpenSource, perhaps with a BSD-style license. If the app is going to end up OpenSource, it's best IMO if it is already OpenSource, in which case you just get one of the CodersForHire to work on the best starting point you can find smile

Agreed, open source is best and preferred, however I need an easy editor enough that I'll use a closed source solution if I have to. As for the CodersForHire route, I just assumed that if any of the twiki coders around could write an easy editor they would have done so already. Perhaps that assumption is invalid. They are as free to respond to my request for a price quote as anybody else. --MW

I do think that an EasyEditor and BetterSkins would make it much easier to get TWiki adopted within many companies, and on the Internet.

Also, I'm not sure there would be much integration required - just some tweaks to the Edit and Save scripts really, ideally in a standard editor-independent format (i.e. a consistent way of interacting between applet and TWiki scripts. Some people would like to use EmacsEditor and VimEditor on the client side, so this would not just be for EasyEditors (guaranteeing uptake amongst the hacker community IMO).

As I see it from standing outside the developers sandbox, the hardest part is 1) getting the app to treat existing text as inviolate, and 2) the output of the app has to be indistinguishable from text entered in a browser textarea box by a user, or another editor such as vim or emacs. -MW

-- RichardDonkin - 17 Oct 2002 -- MattWilkie - 18 Oct 2002

I'm trying to understand what you are looking for, so putting part of the above (or maybe, what's not written above) into my own words, you are looking for a:

  • an editor that is built into or can be called from an existing browser (via something like a Java or javascript call)

  • an editor that "focuses" on editing the text area(s) in a web page -- perhaps invoked automatically when you click edit on a wiki page (??) (or perhaps issues the TWiki URL for that page with edit when something is done on the browser / editor) then captures the text in its edit buffer (??)

  • and then issues a TWiki URL command with preview and save to preview and save the page (??)

Perhaps all of the above is beside the point -- maybe I should read up on the four editors you mention as likely candidates -- maybe each of them approaches the above in slightyly different ways and you don't care (very much) about the details of the approach as long as the one chosen has some workable approach.

The reason I added these comments is that I wanted to suggest my own favorite (Linux) editor as a candidate -- nedit. It has a lot of the features I'd like to have already (user definable macros, lots of other good stuff that doesn't come to mind immediately) and a willingness to consider adding folding in the future. (IIRC, some macros may already support some form of folding).

So maybe I'm really want to do two things --

  • mention the features of an editor that I'd like to have (in addition to those mentioned above or by anyone else, but feel free to expand the following list):
    • user definable macros, capable of being started via (user assignable) keyboard shortcuts
    • folding / collapsible outlining -- as I learn more about folding, I recognize it can "fold" based on various criteria (keywords in a specific programming language, etc., etc., etc.) -- I'd like to fold on headings to make it closest to the collapsible outlining feature available in Word

  • Think out loud about a TWiki interface that any word processor might use (if customized appropriately) to edit TWiki. I think mainly an editor should have (three) added commands which do the following:
    • edit TWiki page -- issues the edit URL for a (designated) TWiki page and captures the text from the textarea in its edit buffer for editing
    • preview TWiki page -- issues the preview URL for the TWiki page currently in its edit buffer, and, if possible, invokes the user's preferred browser to view the preview
    • save TWiki page -- issues the view URL for the TWiki page currently in its edit buffer, and, if possible, invokes the user's preferred browser to view the page

Other details probably need to be discussed (does the editor close after saving ...), and additional commands could be imagined, like a "checkpoint save" which automatically issues a TWiki preview URL followed by a view URL but leaves the contents of the edit buffer open for additional editing (and maybe updates the browser view when the save is complete).

The other things you mention are important as well, but might be editor specific. (Some editors might arrange to display and allow entry of <tab>*<space>, but always save it to TWiki as three spaces *<space>, some editors might have a ruleset built in specifically (and only for TWiki), others might include rulesets for a variety of wikis. (By ruleset I mean a variety of things -- one part of the ruleset is the commands issued to get the page for editing, preview, and saving; another is the process of changing tabs to spaces and vice versa for bulleted lists; others might include that when you use the editor's command to bold some text, it surrounds the selected text with asterisks (and adds extra asterisks as appropriate if the selected text for bolding crosses paragraph boundaries).)

Perhaps I've digressed so far from what you (Matt, or anyone else) had in mind that this should be moved to another page? If so let me know, and I'll move it -- perhaps you have a suggestion for a good page name?

-- RandyKramer - 19 Oct 2002

Randy: yes a lot of your thoughts digress from the thrust of this topic. They do fit in AppletBasedEditor, though perhaps that discussion is a little long in the tooth. You needn't move everything, just clarify your thoughts a little and look at the example apps.

I don't know if it matters if the EasyEditor is integrated into the browser window like Xopus, Bitflux, & Ekit (or the already working JavascriptBasedEditor) or spawns a separate window like Composite. I think the integrated approach would be better, but perhaps not essential. What happens if the user forgets the editor is open, moves on in the browser window, and then saves in the editor?

As for using %favourite text editor% to edit topics I just know I've seen a discussion of that somewhere around here but I can't find it right now.

As for preview.... well, a proper wysiwyg would make that redundant.

Wild thought: MartinCleaver is often saying what makes TWiki valuable is it's RenderingPipeline, could that pipeline be lifted straight into a client side application?

-- MattWilkie - 23 Oct 2002

Hello there, I'm Howard Kistler, the author of Ekit. I was doing an "ego search" in Google and came across this discussion. I haven't really done any Wiki work, but Ekit is being added to at least one blogging system and several CMS systems, so I expect it could be tweaked to support Wiki as well. It's also Open Source and all code included, so there's nothing to stop Wikization of it into a custom component for Wiki webs. You can also gut the unnecessary bits and that would make the Wiki version more streamlined and cross-compatible.

If anyone is interested in pursuing this, email me at hexidec@telepathPLEASENOSPAM.com and I'll see if I can provide any help.

Cheers!

-- TWikiGuest - 23 Oct 2002

I sent out the requests today.

-- MattWilkie - 23 Oct 2002

Request Recieved. Formulating Reply for Composite. Composite is an open source project btw.

-- AndyEd - 23 Oct 2002

Summary of Responses

Well, unfortunately this summary is very easy: void. I did not recieve any price estimates at all. That is not to say nothing was learned however:

  • Bitflux was completely silent. For the most part CodersForHire were silent as well, though one did do me the courtesy of politely declining while wishing me luck in the endeavour.

  • Xopus, and by extension Bitflux as well, is not appropriate for TWiki unless/until TWiki adopts an XML/XSLT framework. The Xopus developer I corresonded with did not have the time to go into detail as to why not, just offering that "... if not absolutely necessary you shouldn't [make] Twiki work with XML/XSLT/Schema" . He said in that in the past, it has taken somwhere from 2 - 4 hours to adapt Xopus to new XML-based CMS systems.

  • The Composite developers had the most questions and expressed the strongest interest but no proposal has so far been forthcoming. I may see one in the new year.

  • Ekit is the most suitable candidate, being browser agnostic. However there is only one real developer and while he is interested, he just does not have any time right now. However: "On the up side, another developer wrote me talking about all these plug-ins he wanted to write for Ekit, and one of them was a Wiki editor. So maybe something will come of that."

I confess to being quite surprised to not recieving any prices at all. I had myself braced for rejecting a slew of proposals which offered to accept money in exchange for their favourite X-app, which doesn't really address the described problem domain. That's what normally happens in an open ended request like this... maybe I should just put an add in the newspaper. wink

-- MattWilkie - 19 Dec 2002

Check HtmlAreaEditor for promising development towards a solution.

-- StefanLindmark - 10 Nov 2003

I think MicrosoftWord is the newbie's dream editor.

-- MartinCleaver - 11 Dec 2003

I ran the idea of using Wiki for our product in the department, from inital reponses it looks like;

  1. Acceptance will be easier if Twiki has a WYSIWYG type editor. Like editor of EditMe
  2. Using EKit seems to be a pretty good idea. But their demo is somehow very very slow. It seems to me their server is a slow one, or have a slow connection. And when I tried to use it at home with IE 5.5 demo didn't start (could be my home PC setup issue as well, and I emailed Ekit folks about very very slowness of their demo).
  3. I beleive CrawfordCurrie was ahed of me on this, I'm wondering what happened with his experiment?

-- IlkerKiris - 16 Jan 2004

See PowerEditPluginDev for a demo. Not EKit, a Java1.1 applet written from scratch.

-- CrawfordCurrie - 03 Feb 2004

Related Topics:

Edit | Attach | Watch | Print version | History: r28 < r27 < r26 < r25 < r24 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r28 - 2004-10-19 - MartinCleaver
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.