On Wed, Sep 16, 2009 at 1:35 AM, brion@wikimedia.org wrote:
On Tue, 15 Sep 2009 13:34:07 +0200, Roan Kattouw roan.kattouw@gmail.com wrote:
There's still quite a few issues with FCKeditor, and as far as I know it's been decided that the usability project is not gonna cover WYSIWYG; I'm not entirely sure of the official stance here, you'd have to ask Naoko.
Full wysiwyg has lots of fun problems, mainly because the strategy of translating between wiki markup and HTML leads to a lot of edge cases which ends up breaking things. Folks have been trying to tackle it for years and still aren't quite there; Wikia's current work with FCKeditor is pretty good but still has a lot of things that just don't work... conversion can be lossy and the handling of templates, tables, extensions, etc would lead to most pages having to be edited in source mode at exactly the times you least want to touch the raw markup.
Instead, we've got the Usability project focusing on things we think we can really deliver, providing most of what's actually useful about a wysiwyg environment:
- modernizing the look, feel, and interaction model (more live, less
post-and-wait)
- getting the scariest parts of the markup out of your face
- providing humane user interfaces for tasks like finding links and
categories, uploading/picking/sizing images, filling out templates, creating and editing tables
- context-aware editing (an editor that knows what section you're in,
where this link points to and if it exists, what fields this template needs, etc)
Not sure if this was considered: * Categories (in the page, not in templates), language links, and magic words (NOTOC) are position-independent within a page * They are also relatively easy to extract from the wikitext (regexp should do, after removing HTML comments and nowiki; I did something like that in JS a while ago, should be much easier if supported from PHP) * They clutter the text (even though they tend to be towards the end of the text), and might scare off newbies * They can be represented in separate visual elements (toggles, lists, or some JS as I did with hotcat)
Any plans of separating these on edit, then re-attach them to the text on saving? It's low-hanging fruit IMHO.
Cheers, Magnus