Not only is the current markup a barrier to participation, it's a barrier to
development. As I argued on Wikien-l, starting over with a markup that can
be syntacticly validated, preferably one that is XML based would reap huge
rewards in the safety and effectiveness of automated tools - authors of
tools like AWB have just as much trouble making software handle the corner
cases in wikitext markup as new editors have understanding it.
It's no wonder really, as the current markup is the result of bolting on
feature after feature, often to handle various corner cases, basically a
really undisciplined approach to development. I honestly wouldn't
be surprised if there were security issues waiting to be found in the
parser, because of the way it's been thrown together.
The switching cost to a new markup and the development cost for an editor
for it would probably be comparable to that of writing a WYSIWYG editor that
understands the current one. A new markup gives us some huge advantages. A
new parser could potentially handle different output formats (print, web,
mobile, pdf, etc) seamlessly, could largely eliminate accessibility issues
that currently are created from ad-hoc formatting capabilities, and would
enable tools that actually understand the markup to start being employed.
Making that parser XML based would mean we can reuse the existing ecosystem
of libraries and tools for manipulating and parsing XML text, and would have
a truly seamless transition into any future markup changes, thanks to XSLT.
XML also gives us the benefit of being able to do validation, possibly at
the time an edit is saved, allowing us to stop broken markup, rather than
having to fix it later, and it allows us to completely remove presentation
from the hands of casual editors - the presentation of articles could be
controlled at site level, with existing consensus processes similar to that
used to change major templates being required to get changes to the site
templates (the article template basically becomes part of the interface at
this stage.)
Transition will be ugly regardless of whether we keep the current parser or
replace it. There are a lot of complex features in the current markup that
need to go because a WYSIWYG editor wouldn't understand them, and it would
also be ideal going forward to "flatten" the formatting capabilities into a
subset that assures consistency - ad-hoc HTML and CSS formatting would
likely have to go.
I honestly think WYSIWYM is a more realistic target once the more
problematic features in the current markup are gone. The editing experience
is largely the same, with the key difference being that what you see in the
editor doesn't have to look exactly like what you see in the rendered
article. By aiming for WYSIWYM, some things would render in the editor in a
way that makes them easier to understand and edit. For example, templates
could render in the editor as tables or as a block that loads the template
parameters into a sidebar when clicked. The same could be done for
references. This has a very shallow learning curve, and a tremendous
advantage over WYSIWYG in that elements that don't lend well to editing in a
WYSIWYG environment are presented in the manner easiest to edit, rather than
in the manner in which they appear. It may take one or two "second looks" to
figure out what's happening, but after that, it's smooth sailing, and by
doing it this way, we avoid the downsides of editing complicated parts of a
page with a minimum cost of initial confusion. WYSIWYM editors can be
friendly to both experienced and new users alike - take LyX as a good
example of such an editor - being WYSIWYM, things that are naturally complex
and unwieldy in WYSIWYG mode become easy because the interface is built to
provide a visual understanding of what is going on rather than 1:1 fidelity
with the final document - as a result, you spend more time editing and less
time worrying about pixel perfect formatting, because you can trust that the
underlying formatting engine will handle things right when you do go to
render the finished document.
As far as current markup goes, a creative solution would be a fork of the
parser into three parts, with a corresponding fork in namespaces as well.
The resulting parts would be an article parser, a template parser, and a
parser for a new layout namespace. Initially, the existing parser is lumped
into the article parser, and class inheritance is used so that the template
parser inherits all markup from the article parser, and in turn, the layout
parser inherits all markup from the template parser. (I'll get more into
layouts below.) This gives us a framework to do several things that improve
usability and consistency. Once the initial "split" is set up, we begin to
move markup features from the article parser into the template and layout
parsers to remove ugly markup from general use, and to restrict formatting
capabilities to a subset that both allows a WYSIWYG or WYSIWYM editor to
work correctly, and allows some level of consistency to be enforced at a
site level. Layouts would be a new form of template, designed to apply as a
block-level outline to an article, providing both a framework to build a
particular type of article, and defining the formatting for that article in
a manner that templates and article markup would no longer be permitted to
do. It's likely that layouts would be treated like highly used templates and
the interface itself, with the ability to create and change a layout
restricted by a permission bit. Layouts would be one to an article, so the
interface to select one would probably be just selecting it from a dropdown
or typing it's name. Every layout would have at least an article body, and
would have one or more additional "blocks" defined - so for basics you could
have the default layout (a flat article), an article with infobox layout,
and a list layout. The end result of this solution is that ad-hoc formatting
using HTML and CSS is gone as far as most editors are concerned, complicated
or easily misused markup features that might cause problems are removed from
the parser that most users will interact with, and the most problematic of
markup is effectively reserved for experienced editors. A new interface can
then be built at a fraction of the development cost, because the "hard
stuff" is out of article space. This both makes sense for usability now, as
well as makes sense as a possible first step if we are ever going to change
parsers, because the things that we probably couldn't convert would be
"contained" rather than spread across articles.
-Steph