removed at example
Sep 24, 2009, 1:03 PM
Post #23 of 96
(1572 views)
Permalink
|
|
Re: Proposal for editing template calls within pages
[In reply to]
|
|
On Thu, Sep 24, 2009 at 8:48 AM, dgerard <dgerard [at] gmail> wrote:
> 2009/9/24 Aryeh Gregor <Simetrical+wikilist [at] gmail<Simetrical%2Bwikilist [at] gmail>
> >:
> > On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov <questpc [at] rambler>
> 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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
1
