Brian wrote:
I am quite sure that the answer to Wikipedia's usability issues was not properly taken into concern when ParserFunctions were written. This is based on a very simple principle that I am following in this discussion: Improvements in usability in MediaWiki will not happen through the addition of syntax, but rather the removal of syntax, and the improvement of the User Interface Design.
I also believe this new grant will help, but I do not believe it will fix a broken process. I would like to discuss that process further, and how it could be improved.
[Apologies in advance for a fairly long email.]
Although I agree that wiki-syntax in many cases is far from ideal, this is also a rather tricky issue that hasn't been satisfactorily solved despite decades of academic and industrial research. So I don't think it's really the case that best practices exist that MediaWiki developers have egregiously failed to follow. I have a bit of interest in / knowledge of this, since developing end-user-programmable systems that are also easy to use is my research area / day job. ;-)
The fundamental issue is that in complex domains (like "writing an encyclopedia"), you can't fully analyze and understand the domain ahead of time, use that understanding to provide an easy-to-use domain-specific language or interface, and then be done. So for Wikipedia, it's virtually impossible to provide a built-in set of simple formatting features (a person infobox, a map-dot-placement feature, etc.) that are both easy to use and cover all situations. Domains change, understanding of domains changes, new issues come up, and users need some way to develop their structures and representations as they're being used. If you *don't* allow that, what ends up happening is that people keep using the simple features you've provided, but in more and more convoluted ways to try to force the system to do what they want.
MediaWiki's first solution to that was templates, which are supposed to factor out common formatting. But they ought to be edited to handle new cases---i.e. the proper solution to a template not handling a case is to change the template, not to ask article authors to use it in some more complicated way. That often requires if-else type of logic. To implement that required a convoluted use of templates to force if-else logic into a feature not designed for it. That started happening a lot---as always, when faced with something that they want to do that the system has no interface for, users creatively resort to convoluted ways to force it to do what they want anyway. ParserFunctions were a solution to the convoluted template logic, giving MediaWiki some logic that can be used directly.
I don't think it's on the whole a terrible solution. The general problem of making systems both end-user-extensible and easy to use has been rediscovered dozens of times, ranging from the 1980s idea of "open systems" [1], to attempts to make end-user-programming usable [2], to an idea of "meta-design" [3] that argues for the need for design environments like CAD to be built with end-user-customization in mind [3]. But how to do all that is hard, and I think it'd be fair to say it's an open problem.
So of course I'd welcome a usability push and carefully designed solutions, and no doubt there are things that could be done to make templates/ParserFunctions easier to use while retaining their power. But I wouldn't expect too much magic to appear. =]
-Mark
[1] Carl Hewitt (1985). The challenge of open systems. _Byte_ 10(4): 223-242.
[2] Bonnie A. Nardi (1993). _A Small Matter of Programming_. MIT Press.
[3] G. Fischer, E. Giaccardi, Y. Ye, A. G. Sutcliffe, and N. Mehandjiev (2004). Meta-Design: A manifesto for end-user development. _Communications of the ACM_ 47(9): 33-37. http://l3d.cs.colorado.edu/~gerhard/papers/CACM-meta-design.pdf