On Sep 3, 2014 4:46 AM, "MZMcBride" <z...@mzmcbride.com> wrote:
>
> Hi Martijn. Thanks for starting this thread.
>
> Martijn Hoekstra [roughly] wrote:
> >* Catalog the problems with [dev issue]. Make a comprehensive list that
> > enumerates the problems with [dev issue] we have now, categorise the
> > problems (right now I'm roughly thinking in style, wikitext parsing
> > rules and generated HTML, creation and writing issues (let's hope there
> > is little of this one left after Scribunto), and usability by editors).
> >* Note which quirks that lead to technical difficulties are used in the
> > wild as features rather than bugs.
> > * Brainstorm possible (partial) solutions.
> > * Find candidates that have high bang-for-buck possible solutions
> > without impeding future improvements much.
> > * Refine those solutions so we know quite exactly what it will fix, what
> > it won't fix, and what it would possibly break.
> > * Define sane fallback procedures for when things break; this should
> > mainly come from the editing communities, but could probably use some
> > guidance of what is possible/easy/logical/feasible from a technical POV
> > from the development community.
> > * Fix [dev issue].
Yeah there are a couple of dev issues above. This email is purposefully
sent to the broadest list I could find, because it are broad issues, and
the dev community is part of the audience of this list. One of the issues
(but not the only issue) is that if templates were less troublesome, it
would be easier for dev to make great products. It would be easy to say
that is their problem, but since everyone benefits from the software being
better, helping dev by reducing template madness helps all of us.
>
> I don't disagree with what you're saying, but I don't think it's really
> specific to templates. We should roughly be following these steps for most
> development issues, no?
>
> There won't be a "one size fits all" approach to templates.
>
> >In the recent discussions/debacles about technical and stylistic
advances,
> >a recurring theme is that the use of some templates causes major
> >headaches, and a commonly heard complaint from the developers and
> >designers is that their products exhibit problems and shortcoming because
> >of that. Anecdotal evidence I've lately encountered includes:
> >
> >* The mobile skin obfuscates talk page access because the templates
> > commonly found on talk pages makes them render horribly.
>
> Talk page templates are dumb. We should integrate their functionality into
> a MediaWiki extension. We currently have people going around assessing
> articles on talk pages and adding talk page banners using iterator tools
> such as AutoWikiBrowser. These are fine people and they're doing fine
> work, but the mechanism by which they're doing it is sorely lacking.
> We can easily store and manage page properties such as an article's
> quality assessment or which WikiProjects are interested in the article in
> a structured database. We already track (and can query!) by many page
> properties. Let's leverage the software platform we've built.
>
> Regardless of whether we use a built-in tool or we continue to use
> templates, you're talking about trashing templates because of CSS issues.
> That doesn't make much sense to me. Templates make life vastly easier. We
> can likely update most talk page templates on large wikis with a single
> edit to a meta-template or perhaps even just a CSS edit. That's great!
>
> >* The mobile skin special-cases some templates (notably issue templates
> > and infoboxes) because they would render horribly.
>
> Second mention of the mobile skin. Perhaps it's the mobile skin that needs
> work. I think the mobile experience is horribly and painfully deficient
> and flawed. Any help you can provide in trying to make it better would
> surely be welcome. I've tried a few times and it only results in sadness.
There are a couple of interlocking problems here. Templates are often
inline styled for the desktop. Writing and maintaining inline styles is a
bit cumbersome, writing good styles that work for desktop and mobile isn't
all that easy, and those two amplify each other.
The mobile skin does the wrong thing (stripping inline styles) because the
templates have inline styles that aren't suitable for mobile, and they have
to do something to get an acceptable end result.
The templates don't have suitable styles for mobile because it's so hard to
inline style something. If the styling of the templates becomes less
cumbersome, we can start making them better suited for mobile, the mobile
skin can stop special casing them, and everyone will be happier.
>
> >* Media-viewer has a tough time doing to correct thing with attribution
> > and license information because parsing template-madness is hard.
>
> Structured data, a.k.a. Wikidata, as Brad noted.
>
> >* VE development has spent a large amount of time around templates, and
> > it's still one of its weakest suits. Template substitution is still a
> > problem, as well as templates that produce wikitext that in itself
> > doesn't map cleanly to HTML tokens.
>
> VisualEditor actually doesn't deal with wikitext, as I understand it, it
> deals only with HTML. The Parsoid team deals with wikitext and they knew
> what they were getting into long before this project started. There was a
> commitment made to support most wikitext. And so it goes.
>
> And as Brad notes, both VisualEditor and Parsoid will have to deal with
> annoying use-cases. (Of all the features, I think {{hidden top}}-type
> functionality will probably be one of the easier features to implement.)
Part of the community - the part that makes parsoid/ve - has a problem with
some template uses. Ignoring the
>
> >* Scribunto has been developed specifically because writing and
> > maintaining templates with more complicated logic is horrible, both
> > from a writers/maintainers perspective as well as from a performance
> > perspective
>
> This isn't really an argument against templates. Scribunto is part of the
> solution, not part of the problem. In theory, anyway.
In practice too, but I think that with Scribunto enabled we can maybe start
thinking about deprecating (some) parser functions, or at least throw that
possibility on the table.
>
> >All this together is sufficient to assert we have a template problem.
>
> I think there's a reasonable case to be made against specific uses of
> templates (talk page templates are an easy target, as discussed above).
>
> The steps you laid out here make sense and seem reasonable, but you'll
> have to do a new pass-through of these steps for each general template
> use-case you discover and wish to address. And each pass-through takes
> close to a year in my experience, if not longer. And that's with dedicated
> development resources.
Having a holistic solution would be nice, but starting incrementally seems
viable. Also, fortunately, there are (still?) lots of us. If we can find a
way to streamline and harness even a fraction of the brain- and willpower
of the collective Wikimedia movement, we're golden. That's obviously a big
if though - I definitely agree I can't go this alone, or that the WMF can
go this alone (for various reasons) for example.
>
> One point that you didn't hit on which is an even easier target for
> criticism is that there's currently no easy way of sharing templates
> between wikis (no interwiki templates). We need to shrink the overall
> number of templates by finding common patterns between wikis and smartly
> sharing code _and_ man-power. If you want to make a substantive impact on
> the number of templates, I'd strongly suggest figuring out a way to revive
> interwiki transclusion or an equivalent sharing mechanism.
Great point. iirc cross wiki Lua modules is the most popular requested
Scribunto feature. The same could go for templates, though if we bring
templates back to simply putting a few words in a (localised) text template
and doing everything else in cross wiki Scribunto modules, it might not
even be needed. I think that's the right(tm) way to use templates, but I'm
not sure if we can ever give up completely the template power we have at
our disposal now; they're versatile and very heavily used for some pretty
awesome things. This is definitely in scope of lets improve templates
though, so thank you for bringing it up.
--Martijn
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
Wikimedia-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
