Re: [Wikimedia-l] Big problem to solve: good WYSIWYG on WMF wikis

On 16 June 2015 at 02:53, Derk-Jan Hartman <d.j.hartman+wmf_ml(a)gmail.comwrote: https://lists.wikimedia.org/pipermail/foundation-l/2010-December/063225.html > I just found back this post by David Gerard from 2010 and was struck by how just 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. :-) solvable > 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 ​considering as part of Flow (hence the name). No doubt it ​could 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. of > 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 can 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. Thoughts? J. -- James D. Forrester Lead Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester