Brian wrote:
There are lots of usability improvements that can be made to the templating system. First and foremost the new system should allow advanced wiki users to perform programmatic operations on article data without the requirement that the data in the article be made unreadable.
If we only focus our efforts on making the template namespace more complicated by giving it a more advanced programming language and we leave the article namespace as it is then we have not even touched the usability issue. We have just made it worse.
These are totally orthogonal issues, and paying attention to one doesn't mean ignoring the other.
The ideal markup situation for the article namespace is that markup shouldn't even *be* exposed to most users. A long-term goal is migration to a more WYSIWIG-like editing experience -- to which one of the potential stumbling blocks has been "but how will we do templates, which currently are built with our horrifying wiki markup?"
Most editors will never know or care about the internal implementation of templates, just as they don't know or care about it today. Cleaning them up to allow the power-users who *write* templates to make them functional and useful *and* maintainable is a win for template writers, while having no direct impact on general editors.
(Indirectly, it will mean they're provided with better tools to use in their articles.)
<not the subject of this thread> For the general article editing experience, the issues are very different, and that's the area the Wikipedia Usability Initiative is concentrating on.
In the very short term, we're working on general look & feel, workflow, and making it easier to figure out what you're supposed to do (such as making the markup cheat-sheet available without leaving the editing window).
In the medium term, we hope to be able to "fold up" things that are particularly ugly in markup such as images/media, template invocations and tables, and provide friendlier widgets for adding and editing them.
In the long term, we might hope to be able to drop the front-end markup entirely... but that's still a harder problem with several possible trade-offs. </not the subject of this thread>
-- brion