On Thu, Sep 24, 2009 at 8:48 AM, dgerard <dgerard(a)gmail.com> wrote:
2009/9/24 Aryeh Gregor
<Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com>
:
On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov <questpc(a)rambler.ru>
wrote:
> So it would be menu and icon-driven editing,
where the hands should move
> from keyboard to mouse and vice versa, like MS Word. Not very handy for
> programmers and people who prefer to do most of tasks in command line.
Programmers rank far, far below normal people
when it comes to
usability prioritization.
Indeed, as do robot editors. This is part of the "no way, not even
with logic twisting, is the impenetrability of wikitext a feature."
As far as I'm concerned, a situation in which
WYSIWYG is the only
supported editing method would be far superior to the current
situation. If we could allow power users to edit manually, that would
be a nice bonus. Note that even if we use a format like XML that's a
pain to manually edit, programmers can write up their own front-ends
if they like -- they're programmers, after all! And also note that as
with most WYSIWYG editors, there would presumably be a slew of
keyboard shortcuts for power users to memorize if they didn't want to
use the mouse.
Realistically, Tim has already stated we're not throwing out wikitext
because of the huge body of text already in it. WYSIWYG editing is
getting there bit by bit - FCKeditor would be fine on a fresh wiki
without the unspeakable atrocities inventive geeks have perpetrated
upon wikitext on en:wp and should continue to get better at dealing
with more obtusities.
- d.
This round the Usability Initiative got 800,000 dollars. That's a load of
money. If the Foundation decides that it wants to fix the problem the
correct way then it can. And it can start at any time! We just need to agree
on a solution.
We can't fix the problem by looking backwards at the wikitext that has
already been produced along with the language definition (5,000 lines of
parser code) and saying that the problem is simply intractable. In fact, the
problem does not depend in any way on the quantity of wikitext that has been
produced - it only depends on an understanding (if not a definition) of the
language as it currently exists. Hard work but not, at all, impossible.
It doesn't seem productive to me to start by looking at the problem from
that looking-backwards angle of "oh my god there is so much wikitext written
in this language that isn't even defined". It would be more productive to
first decide what we would like to see. For example:
* wikitext parsing would be much faster if the language was well defined and
we could use flex/bison/etc...
* usability would be greatly enhanced if all wikitext was easy to
understand, even for newcomers. this includes a clear breakdown of the
problem of including/querying remote resources and a clean solution to that
problem (unlike templates)
* if the language is well defined, then we can have a wysywig editor whose
behavior is well defined
* if the language is well defined, we can have multiple fully compatible
parser implementations, for example, flex/bison, php, python and
importantly, javascript.
After we have together designed and implemented the new solution we could
start work on the isomorphic mapping between old school wikitext and new
school wikitext. Or they can happen in parallel. It certainly doesn't seem
helpful to our movement to settle on the existing solution, which has so
many flaws, when we can easily imagine so many other solutions which are
clearly better.