MOving over to the other side of the argument for a moment, it seems to me that the building could be built one brick at a time. E.g., get the basic features in place first, such as bolding, underscoring, links, and god-forbid tables - and then move on from there. Worry only about the visual componets and leave under-the-hood stuff like categories for another day. Whenever I need to write a 6-inch long formula in Excel, it rarely saves any time or effort if I try to do it all at once. Invariable breaking the problem down into smaller parts, then joining them up, results in a working solution "more fasterer." Not that anyone here needs a lesson in applied software engineering, but maybe the problem really *is* that too much is being attempted in the first go. ----- Original Message ----- From: Daniel Barrett <danb(a)VistaPrint.com> To: MediaWiki announcements and site admin list <mediawiki-l(a)lists.wikimedia.org> Date: Wed, 19 May 2010 13:24:31 -0400 Subject: Re: [Mediawiki-l] FCK Editor svn head and MW 1.16b2 - correct venue? makes me ancient. :-) work flawlessly... 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? 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.