I was particularly keen to get halfway-usable WYSIWYG editing in MediaWiki for our office intranet. So I just did a test installation of MW 1.16b2 with FCK Editor Official svn head.
It's pretty good, I'm really impressed! But it's buggy. (Chews up form fields for the InputBox extension, and there's glitches in the rendered editing window.)
I'd quite like to help get it into shape, as we'd like to do a customer-facing MediaWiki installation for our (utterly nontechnical) sales guys to use.
Is this a suitable place to talk about problems with it? Is anyone from FCK here?
- d.
On 5 May 2010 11:26, David Gerard dgerard@gmail.com wrote:
Is this a suitable place to talk about problems with it? Is anyone from FCK here?
Given the tumbleweeds in response, it appears not ;-)
I'll be filing bugs on it, then. Here's the first, an apparent incompatibility between FCKeditor and InputBox:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23561
- d.
On Mon, May 17, 2010 at 8:27 AM, David Gerard dgerard@gmail.com wrote:
On 5 May 2010 11:26, David Gerard dgerard@gmail.com wrote:
Is this a suitable place to talk about problems with it? Is anyone from FCK here?
Given the tumbleweeds in response, it appears not ;-)
I'll be filing bugs on it, then. Here's the first, an apparent incompatibility between FCKeditor and InputBox:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23561
- d.
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
They seem to maintain the extension outside of our SVN over at fckeditor.net. We also have a copy in our repo. I've always been curious as to why that is. As we're all aware, extensions not in our repo tend to get neglected (and unsupported) by our developer pool.
If you file a bug and I fix it in trunk, will the changes ever get to their copy? Or vice versa...do we ever get downstream changes they've made? This is different from having an external dependency like GeSHi that we have to occasionally update... this is a full blown fork and it's confusing.
-Chad
On 17 May 2010 13:37, Chad innocentkiller@gmail.com wrote:
If you file a bug and I fix it in trunk, will the changes ever get to their copy? Or vice versa...do we ever get downstream changes they've made? This is different from having an external dependency like GeSHi that we have to occasionally update... this is a full blown fork and it's confusing.
Indeed. The page on mediawiki.org says to file bugs in WMF Bugzilla. Hrm.
- d.
David Gerard wrote:
On 17 May 2010 13:37, Chad innocentkiller@gmail.com wrote:
If you file a bug and I fix it in trunk, will the changes ever get to their copy? Or vice versa...do we ever get downstream changes they've made? This is different from having an external dependency like GeSHi that we have to occasionally update... this is a full blown fork and it's confusing.
Indeed. The page on mediawiki.org says to file bugs in WMF Bugzilla. Hrm.
- d.
Seems that we host the php part and they keep the editor (as an external dependence, r50699). Looks to be done/supported by Jack Phoenix.
Forwarding on behalf of Jack, which is not subscribed:
Hi it's true that I created that fork of FCKeditor, but I'm afraid that I no longer maintain it. Tim Starling recently approached me with a FCKeditor-related question and I had to tell him the same thing. A WYSIWYG editor for MediaWiki seems to be nearly impossible to do, but the current best implementation is probably Wikia's RTE (Rich Text Editor, integration with CKeditor). Maybe the best idea would be to kill off our FCKeditor extension and try to collaborate with Wikia regarding their CKeditor integration extension. It certainly would be cool to have a good WYSIWYG editor for MediaWiki
one day...
Thanks and regards,
Jack Phoenix MediaWiki developer
On 18 May 2010 18:35, Platonides Platonides@gmail.com wrote:
Forwarding on behalf of Jack, which is not subscribed:
Maybe the best idea would be to kill off our FCKeditor extension and try to collaborate with Wikia regarding their CKeditor integration extension. It certainly would be cool to have a good WYSIWYG editor for MediaWiki
one day...
argh argh argh. I was so looking forward to 1.16 specifically for a half-decent WYSIWYG editor ...
- d.
On 05/19/2010 01:20 AM, David Gerard wrote:
On 18 May 2010 18:35, Platonides Platonides@gmail.com wrote:
Forwarding on behalf of Jack, which is not subscribed:
Maybe the best idea would be to kill off our FCKeditor extension and try to collaborate with Wikia regarding their CKeditor integration extension. It certainly would be cool to have a good WYSIWYG editor for MediaWiki
one day...
argh argh argh. I was so looking forward to 1.16 specifically for a half-decent WYSIWYG editor ...
I dug up some info on what Wikia is doing... http://help.wikia.com/wiki/Help:New_editor
The old FCKEditor is available but not enabled by default on the OpenOffice.org Wiki. I'd be really interested in finding a update/upgrade to the current editor... like others, we've discovered some bugs and problems, but aren't getting too far with finding fixes etc. (which is why it's not on by default on the OOoWiki).
C.
I've been following the CKeditor effort and their promises, once version 3.0 was out, to work on a CKeditor+Mediawiki. Version 3.2 is now out and no sign of a CKeditor+Mediawiki effort, and most concerning is the lack of any recent responses to direct questions about the previously promised effort on the CKeditor's forum. Wikia's efforts are not comforting either. Almost all wikia wikis I have visited have the wysiwyg editor disabled, which is not the default, so people must be purposely disabling it. And the discussion page of wikia's editor help page (http://help.wikia.com/wiki/Help_talk:Rich_text_editor) has people asking for the older version of the editor because of problems with their latest version.
We are currently using version 2.6.4 of the FCKeditor and even with its issues have found it has lead to a wider acceptance of using our wikis. For us there is no going back to wikitext. If the wysiwyg editor future is not resolved for Mediawiki soon I'm afraid we will be forced to move toward another wiki software, most likely commercial where wysiwyg has been around for years, because requiring non-technical people to learn a markup language to use a wiki seems archaic in the 21st century.
-Jim
-----Original Message----- From: Clayton [mailto:ccornell@openoffice.org] Sent: Wednesday, May 19, 2010 3:51 AM To: MediaWiki announcements and site admin list Subject: Re: [Mediawiki-l] FCK Editor svn head and MW 1.16b2 - correct venue?
On 05/19/2010 01:20 AM, David Gerard wrote:
On 18 May 2010 18:35, Platonides Platonides@gmail.com wrote:
Forwarding on behalf of Jack, which is not subscribed:
Maybe the best idea would be to kill off our FCKeditor extension and try to collaborate with Wikia regarding their CKeditor integration extension. It certainly would be cool to have a good WYSIWYG editor for MediaWiki
one day...
argh argh argh. I was so looking forward to 1.16 specifically for a half-decent WYSIWYG editor ...
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
I'd be amazed to see a great WYSIWYG editor for any wiki, even among commercial packages. I evaluated Atlassian's very popular "Confluence" wiki awhile back, and it took me all of 5 minutes to find several bugs in the editor. Likewise for the wiki in SharePoint 2007, which was far less powerful.
WYSIWYG doesn't mix well with powerful features like templates and parser tags, and I'm not optimistic this will ever be fixed. Look at today's issues in a similar area, application configuration. Some apps provide graphical control panels to change their behavior, like Windows and Macintosh control panels. On the other hand, you have MediaWiki and Linux requiring people to edit configuration files. The graphical control panels are easy to learn (just point and click), but for serious application management, give me config files ANY DAY. Config files can be saved, restored, version-controlled, compared, edited with infinite Undo, shared with other users, emailed, deployed to multiple computers easily, edited remotely via SSH, etc etc etc. There is currently NO WAY a graphical control panel can compete for serious application maintenance. (I'm aware that you can put a GUI on top of a configuration file, but these GUIs frequently modify or rearrange the lines that you didn't change... which makes diffs unreliable.)
Likewise, end-users have done great things with WYSIWYG editors like Microsoft Word, but I personally would never write anything large or complicated in Word (say, a 500-page book) because it lacks important features for seamless version control, typestyle management, search-and-replace by regular expression, document comparison, multi-author collaboration... even complex cut and paste operations. (I wrote the O'Reilly MediaWiki book in Docbook/XML with GNU Emacs and Subversion.)
I think the WYSIWYG problem for wikis is similar. A graphical front-end can hide the complexity and encourage end-user adoption, but it also makes the advanced features difficult to use (and too easy for end-users to break by accident). I think it'll be a while before both audiences can be served excellently.
DanB
-----Original Message----- From: Sullivan, James (NIH/CIT) [C] If the wysiwyg editor future is not resolved for Mediawiki soon I'm afraid we will be forced to move toward another wiki software, most likely commercial where wysiwyg has been around for years.....
Well, yes and no. Early word processors were quite buggy, and they had to produce postscript to send to a laser printer, postscript that no one ever had to edit in. And what you saw was not always what you got, but improvements were made and today we expect word processors to work flawlessly and postscript is a term only known by us old technical guys. I also remember when spreadsheets had one sheet per file and far fewer abilities (last century :0). Advanced features and perfection come with time.
FCKeditor's flaws are not only unsurprising they are to be expected. Its only been around a few years with an open source level of support (Thank you Frederico!). Yet its bugs are considered minor by our wiki users who rarely use wikitext. I guess my frustration comes from the fckeditor having just reached an acceptable level of performance only to see the effort to continue improving it dissolving, at least that is how it appears. As Churchill might have said, this is F/CKeditor's finest hour!
Jim
-----Original Message-----
I think the WYSIWYG problem for wikis is similar. A graphical front-end can hide the complexity and encourage end-user adoption, but it also makes the advanced features difficult to use (and too easy for end-users to break by accident). I think it'll be a while before both audiences can be served excellently.
DanB
-----Original Message----- From: Sullivan, James (NIH/CIT) [C] If the wysiwyg editor future is not resolved for Mediawiki soon I'm afraid we will be forced to move toward another wiki software, most likely commercial where wysiwyg has been around for years.....
_______________________________________________ MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
James Sullivan wrote:
Well, yes and no. Early word processors were quite buggy, and they had to produce postscript to send to a laser printer...
Hmmm, the "early word processors" I remember were HARDWARE. I guess that makes me ancient. :-)
...but improvements were made and today we expect word processors to work flawlessly...
Well, yes... except they don't. :-) My wife's word processor (Word 2008 on the Mac) crashes almost daily. And even the most sophisticated word processors today lack advanced features for writers. Consider a simple search-and-replace that changes "MediaWiki" into "Wikimedia." What if you want replacement only if "MediaWiki" is in a level-1 heading? Or only when it's part of a URL?
I'm going off on a tangent, so I'll stop here. :-)
Anyway, I agree with your points in principle and definitely welcome improvements to ease-of-use. I just don't think they're going to come in the form of a fantastic WYSIWYG wiki editor, because the features that make MediaWiki great, as opposed to merely good (templates, parser functions, parent & child categories, etc.), seem incredibly difficult to support in WYSIWYG, and even harder to prevent novices from deleting by accident.
DanB
mediawiki-l@lists.wikimedia.org