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