[WikiEN-l] Eschatology and Wikipedia

Sun Dec 26 16:12:10 UTC 2010

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 at gmail.com>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 at gmail.com>wrote:
>
>> On Thu, Dec 23, 2010 at 3:51 AM, David Gerard <dgerard at gmail.com> wrote:
>> > On 23 December 2010 11:48, Tony Sidaway <tonysidaway at 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 at gmail.com
>>
>> _______________________________________________
>> WikiEN-l mailing list
>> WikiEN-l at 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.