On Fri, Sep 25, 2009 at 4:49 PM, Roan Kattouw <roan.katt...@gmail.com>wrote:
> 2009/9/26 Brian <brian.min...@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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
