On Thu, Sep 24, 2009 at 8:48 AM, dgerard <[email protected]> wrote: > 2009/9/24 Aryeh Gregor > <[email protected]<simetrical%[email protected]> > >: > > On Thu, Sep 24, 2009 at 3:31 AM, Dmitriy Sintsov <[email protected]> > 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
