On 16 June 2015 at 02:53, Derk-Jan Hartman <d.j.hartman+wmf...@gmail.com>
> I just found back this post by David Gerard from 2010 and was struck by
> dead-on the discussion and analysis was and how far we have actually come
> with VE 5 years later, even though we still did not pass the finish line
> yet.

Yes, I agree. I think there's a lot of interesting areas we can consider
for VisualEditor as a technology, and more importantly "editing" as an
area; thank you for raising this. :-)

> Also interesting is some of the follow up to it, which points out that the
> usability of Templates is also a real problem in itself, not easily
> with WYSIWYG, but probably just as important.
> I think VE is really close now to being usable in production, but I think
> that we are FAR from done on this front. Like was stated, templates are a
> real problem. A UI problem, and one that VE doesn't really solve. Citoid
> sort of does, but just for one small subset of templates.

Agreed. There are several layers of answer to this question, precisely as
you say based on what levels of vision we're trying to achieve. Here is
mine (TL;DR: lots to do):

Mostly this comes down to what templates (and now of course, Lua) are used
for. My mental categories are:

1. Standardised "workflow" notices – "this needs a reference", "this
article is poorly written", "this list needs expanding", "this file should
be expanded", "please delete this page", "this page is protected", "this
suggested edit needs reviewing", "please don't edit this discussion because
it's archived", "I am warning you not to be disruptive in your editing or
you will be in trouble", "this user is blocked", etc.

2. Standardised visual formatting of content – citations (templated
references), infoboxen, stub notices, succession boxes, media licensing
data, Wiktionary's etymology templates, Wikisource' and so on.

3. Standardised conversion or expansion of content – unit conversion, date
conversion, links to sister project pages on the same title, annotation
markup (e.g. setting lang="fr" around some content, or marking it up with
hCard data; adding an HTML anchor to the page; etc.).

4. Standardised fetching of content – we frequently pull images from
Commons (and people don't even think of it as fetching content); beyond
that it's not yet hugely common, though some infoboxes for example pull
data from Wikidata.

5. Un"standardised" sharing of identical content blocks (the original
intent for templates) – most often used as "navboxes", and sadly sometimes
also used to hide complex wikitext e.g. for infoboxes or graphs from the
"regular" users who might break it, which speaks to how much VisualEditor
is needed.

Of course, to make things 'easier' a lot of templates do multiple versions
of these, and/or are parameterised to do almost the same thing but slightly
differently based on some of the inputs (e.g. a species infobox which adds
a 'fix me' category, sets a different background colour if the status is
'endangered', pulls three of its values from Wikidata, and converts range
from hectares to square kilometres). There's also meta-templates for other
templates like notices, but I'll ignore those for now. :-)

My broad attitude is that the need for the first four of these categories
can be replaced by real software support; the need for the fifth is not
something I foresee a better solution for than community-shared templates,
though I'm willing to be proven wrong.

I understand that everything I mentioned in group one (workflow stuff) is
potentially in scope for the work that the
​ excellent​
Collaboration team are
 as part of Flow (hence the name). No doubt it
 also cover a number of areas of work of which I cannot yet conceive; this
is how templates themselves have grown from their original intent into the
sprawling, complicated and confusing morass that they are today. This
workflow stuff is
​deeply hard to get right, however, and I've seen how badly doing workflows
in systems can destroy the communities, so I imagine this will move slowly.

For many of the use cases in groups two and three (visual and
machine-readable formatting/re-formatting), I think that broad swathes of
our content uses
​of templates ​
would be
​ better
 supported through use-specific systems at three levels:

* structured – storing information in a proper, machine-readable manner,
with a single way of both storing and representing the same information for
all instances on that wiki, but differing between wikis;

* standardised – the above, with the harmonisation of the structure and use
of that content type across all Wikimedia wikis; and

* centralised – the above, with all the content stored on one central
'wiki' (or whatever) rather than local versions of the content.

For example, references are currently semi-structured on many wikis using
citation templates; storing this in structured data is a clearly useful
step, and it's probable that setting a single standard for all our wikis to
say what meta-data about a reference is worthwhile, but I am not completely
sold on the idea of having this data stored on a single new "Wikicite" or
whatever project.

For another example, infoboxes are currently subject to significant
editorial discretion on the per-page level, and with sub-wiki variance on
themes (e.g. a standard for infoboxes about military battles might exclude
information that infoboxes about political uprisings would consider vital,
and vice versa), let alone when comparing between wikis. Though I think
there is likely to be a lot of value in sharing the structure to represent
the layout of what should be shown
​, this would be something of a departure for the level of freedom our
different pages' editors have​ compared to the wikiprojects or wiki
communities that would define them.

As a final example, factual data makes total sense to be centralised,
rather than just standardised – which is good, because this already
underway doing that with Wikidata. :-) Note that "data" potentially goes so
far as the scope of Wiktionary, Wikiquote and possibly even Wikisource,
though each of these are worth very serious conversations and planning. The
fetching and display of the data might well need software support and
configuration on a per-wiki or per-language basis. For example, for Chinese
language readers it might make sense to represent distances in 里
automatically converted from metres; for American English readers, show the
dates the 'wrong' way around (;-)); for some readers, the ordering of the
cases for nouns might be varied based on what they'd expect (so accusative,
genitive, dative and then ablative for some readers but accusative, dative
and then genitive for others); for some language Wikipedias, it might be
felt important to highlight someone's political affiliation in a different
way in an infobox based on what the community decide is the 'right' manner
to explain things to their users. No doubt dozens of other specialisations
can be dreamt up.

For items in group four, we probably can fold these uses into the automatic
uses discussed above in many cases, and for others we already have the
means to embed them using wikitext directly for media (as is now old-hat)
and data (as the Wikidata team have and continue to develop access tools).
I'm not sure there's much to do here, except note that as VisualEditor
becomes more widespread we may find that we need to use templates less to
hide the intricacies of wikitext from errant users, because everyone except
the die-hard might be avoiding needing to look directly at the wikitext.
We'll see.

> I think it is important to remember that VE is a framework. The piece that
> will open up other possibilities, but that we will need to still do a lot
> work to find what those possibilities are, how they can make page and
> article authoring more usable etc...
> The post starts with a quote of Fred Bauder:
> | "There has to be a vision though"
> So I'm asking: What is the vision for this next step ?
> - What ideas do people have with regard to usability and templates.
> - What examples of good editors can we find that also deal with templates/
>   objects etc.
> - What are our unique challenges ?
> - What kind of research and development would be needed to deliver this ?
> I would love it if we could end up with a discussion and summary as we had
> back then. A guide for us towards solving this next problem within another
> 5 years. We and the WMF can probably not start on this tomorrow, but we
> start thinking about it.

There are a number of changes we can make that seem obvious, but I worry
that are anti-patterns which would embed current thinking at a cost of
making progress harder, or less appealing in the short term.

For instance, we could add an extra "insert clean-up template" button in
the VisualEditor toolbar with five or six specialist (per-wiki) tools to
insert {{cn}} or {{wikify}} or whatever. See
https://phabricator.wikimedia.org/T55590 for some discussion of this.
Making this configurable, scalable and yet sane is a lot of work, and
immediately appealing – but I fear it would be solving the wrong thing, and
doing so in a way that distracts us from the end-goal.

Another superficially attractive, and oft-discussed, piece of work is
"global templates". I worry that these would very much try to expand the
symptom rather than solving the problem, making simplicity of understand
how things work and the flexibility to change them ever further out of
reach for all but a few of our editing communities.

The overall vision might even be right, but it's only worthwhile if we turn
it into reality. Certainly, I don't have a magic bullet. It's going to take
a huge amount of careful thought and discussion on each of the three dozen
or so proposals I implied above, and it's a worthy challenge, I think.


James D. Forrester
Lead Product Manager, Editing
Wikimedia Foundation, Inc.

jforres...@wikimedia.org | @jdforrester
Wikimedia-l mailing list, guidelines at: 
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, 

Reply via email to