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