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