On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw roan.kattouw@gmail.comwrote:
2009/9/26 Brian Brian.Mingus@colorado.edu:
Roan, sorry that the idea is pretty hard to convey, I'll try again. The basic idea is that you can create templates using templates (just using current tech). It's easy, you just pass parameters to a template that control its output, and this output is a new template. The parameters that you passed determine what
the
new template looks like, and what it's output will be.
Right, so basically this is just templates calling other templates, right? This already happens to some degree already.
We can imagine a master template on Wikipedia that is used to generate
all
infoboxes. It could work in arbitrary ways, but suppose it works this
way:
The master infobox template creates a template for each wikiproject. The template that it creates for each wikiproject further creates templates representing every kind of infobox that this wikiproject uses. So you
have a
master template that creates baby templates that create infobox
templates.
Using current tech this isn't exactly feasible, only advanced users will
do
it since you have to directly interact with the templates and it would be tough to code up. But if you make such a feature highly usable, by, for example, tacking an easy to use interface on top of it, the usage of such techniques will proliferate.
To use the master infobox example: such a template would have about a dozen usage modes, each with dozens of parameters. Such constructs are actually /easier/ to call by hand than with a form, because you'd either have to store all the relationships between the parameters and usage modes in the XML file and let the form handle all that (which is a degree of complexity I personally would not like to see in a template forms implementation) or just throw a couple hundred parameters in the user's face.
Also, this being tough to code up would not change: again, we're not simplifying the *writing* of templates *themselves* in any way. The fact that these templates include template calls doesn't change that, because 1) you're gonna be using #if constructs all over the place anyway, 2) you'd need to use stuff like {{{2|{{{1|}}}}}} as arguments to template calls, which the GUI doesn't simplify and 3) if you're skilled enough to do 1 and 2 and familiar enough with the templates you're calling to be writing a master templates, you don't need an editor or form to build the template calls for you.
More general kinds of interface builders that build all imaginable kinds
of
interfaces are conceivable.
Is this not possible within the scope of the suggested system?
Yes, but it's also possible within the scope of the current system. You don't /need/ a template editor to be doing this kind of monkey business. In fact, I think a template editor would actually discourage these practices, because relatively unexperienced users must be able to build a reasonable template call using the template editor. For the latter to work out, templates need to be simpler rather than more complex.
In short, I don't think introducing a template editor would encourage master templates and similar complexification of templates; in fact, I believe it will actually encourage simplification, because a nice-looking GUI for a big incomprehensible parameter soup is worth the soup.
Roan Kattouw (Catrope)
* wizards, workflows, meta-interfaces, these are accidental implications of a feature whose only purported design goal is to make editing templates on articles easier. and i haven't been at all convinced that the new system won't make it possible to create really elegant interfaces that are easy to use. e.g., that make it really easy to create monstrosities of templates and parser functions that no human can conceivably understand. :* historically, if it can be done on the wiki it will be done :* and it will be spread and copied, hundreds of thousands to millions of times, within just a few years
* nobody intended to make template syntax turing complete - it was an accident
* the obvious solution to templates is *not* to hack on an interface for editing them. wikipedia is supposed to be the encyclopedia that anyone can edit. it was a poor design decision to enable (or indeed, to create) a template system on wikipedia that allowed people to create, in the first place {{qif}}, and other things like it. the only reason even worse things weren't created is that it was hard. :* and the result of this accident was not just to put limits on recursion and the things that could be done with templates, but to further enable those use cases (without much discussion or regard to long term strategy and usability).
* so not only were templates bad, but this Incrementalism, otherwise known as [[Feature creep]], which brion just described as his guiding "strategy," led us to kludge something even worse on top. and now here we are, further incrementing the size of the snowball with no clear long term vision to guide us as we increment. we continue to achieve "consensus", a.k.a several people at wikimedia headquarters, for kludges on top of this core problem because nobody there has any vision about where the software should go let alone the will to actually fix it. it's been several years off for several years now.