Just to add, If we go with a new markup, make it XML based, please, and
validate. There are existing tools for working with XML that can be
leveraged both in building a parser, and in building interfaces and tools.
XML assures that the markup is machine readable AND writable in all cases,
which eliminates a lot of hell with using automated tools. Being easy to
validate also eliminates a lot of hell with manually editing the code - you
can make sure at the time text is saved that it will parse, even if it won't
parse as expected, it will be easy to fix. We could even reuse an existing
XML application like DocBook if so desired. Making it XML also means that
upgrading the markup can be done less painfully in the future, even if the
markup completely changes, XSLT offers a means to convert one XML markup to
another predictably.
There's also a side benefit. Almost all modern browsers can parse, style,
and display XML natively, either by directly applying CSS styles or by
applying XSLT to render the XML as XHTML. That means we can offload the
parsing to the browser if so desired, and we could eliminate a lot of
overhead for the site in doing so.
The only major downside is that XML is much more verbose than wikimarkup.
The learning code to produce basic documents directly (without a WYSIWYG or
WYSIWYM editor) is a tad steeper, but becomes shallow after that, as once
you understand the basics, everything else is easy. More verbose markup
means more typing for those of us that do things by hand though, which does
present a disadvantage. A good editing interface though with code
completion, and a strong WYSIWYM or WYSIWYG editor with keyboard shortcuts
would mostly negate this disadvantage.
On Sun, Dec 26, 2010 at 10:43 AM, Stephanie Daugherty
<sdaugherty(a)gmail.com>wrote;wrote:
I think trying to bolt on WYSIWYG to the current
parser is a mistake. Even
if it "works" there will be complex markup cases still that are beyond a
WYSIWYG editor (and way beyond 99% of potential editors). Either replace the
current parser, or strip out the complicated parts systematically.
If you want to strip down the current parser, you could do this by making
articles a small subset of the markup, and letting full markup be used in
templates. Gradually depreciate, and then turn off features that are too
complex. A good start would be HTML code in articles, it's not necessary,
and it lets people introduce inconsistencies that look unprofessional, as
well as leaves text in an article that's hard to edit.
If you want to start over, start simple, and think "WYSIWYM" (What you see
is what you mean) rather than "WYSIWYG". That is, the editor should make it
easy to see the structure of the text and edit it without concern for the
final formatting. LyX is a good example of this sort of interface, although
the underlying LaTeX markup probably isn't what we want (just as complex as
what we have now, it's still too presentation oriented, etc).
If we end up replacing the parser, the only way to do that smoothly, would
be to run both parsers at the same time during the transition period. Those
articles that can be converted automatically are converted early on.
Software restrictions (perhaps an edit filter) can prevent starting an
article with the old markup, and discourage reverting to versions with the
old markup. There would be a large number of articles that couldn't be
automatically converted. There are a few ways to handle that. A large manual
conversion effort would be needed. At some point, we should disallow saving
changes to the old markup (forces editors to convert the article to edit it,
or allow an automatic conversion that could break the article after a
certian deadline.
In either case, the process would be painful, but would pay off in the end
with improved editorship, and I suspect greatly improved article quality.
Editors that aren't familiar with the more advanced markup constructs tend
to have to dance around them when editing, and that makes editing harder, as
well as leaves behind broken markup. That means a lot of fixes end up either
not happening, or happening anyway, and doing more damage than what they are
meant to fix.
This would amount to the largest usability project we've undertaken no
mater how we go forward, but the payoffs would be enormous.
On Thu, Dec 23, 2010 at 4:31 PM, George Herbert <george.herbert(a)gmail.com>wrote;wrote:
On Thu, Dec 23, 2010 at 3:51 AM, David Gerard
<dgerard(a)gmail.com> wrote:
On 23 December 2010 11:48, Tony Sidaway
<tonysidaway(a)gmail.com> wrote:
Not everybody works that way. Most of us
don't. To those people the
buttons I find annoying may be the only thing they *do* understand,
they're the most accessible way of using a computer, and a user
interface lacking those buttons is alien and incomprehensible. With
the buttons, these people are intuitively able to produce a reasonable
minimal subset of tasks immediately as long as the result of their
work is displayed immediately (WYSIWYG).
It's still annoying, though.
Yeah. It won't be a happener on WMF sites, I think, until WMF has
money to throw at developers to develop something that actually works
and has fidelity with wikitext as it's used. This is a *big and hairy*
problem that interested parties have been dashing their foreheads
against for *years*.
Right.
The social stuff which is complex is something which is a barrier, but
one that all western society members who are modern communications
literate are fundamentally equipped to handle. Some will fail at it
but you really just need to be good at electronic communications,
functionally literate, and social enough to handle basic give and take
discussions.
Very few people master the markup; very many fewer than that can hack
or understand the underlying code. I'm a coder; I've dived into the
MW parser on and off, and other parts of it, to understand functional
behaviors better. But I also do outreach and computer training at
times, and most normal people could never approach that level, and
find wiki markup onerous when I ask them about it...
--
-george william herbert
george.herbert(a)gmail.com
_______________________________________________
WikiEN-l mailing list
WikiEN-l(a)lists.wikimedia.org
To unsubscribe from this mailing list, visit:
https://lists.wikimedia.org/mailman/listinfo/wikien-l
--
Faith is about what you really truly believe in, not about what you are
taught to believe.
--
Faith is about what you really truly believe in, not about what you are
taught to believe.