On Wed, Sep 16, 2009 at 1:35 AM, <brion(a)wikimedia.org> wrote:
On Tue, 15 Sep 2009 13:34:07 +0200, Roan Kattouw
<roan.kattouw(a)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