Wikipedia:Visuele tekstverwerker/Feedback/Archief/nov 2015

Analysis

In 2013 we performed an analysis of the way the Visual Editor works and based on that analysis the community voted against the implementation of the new editor. Now we do a new analysis to see what the status of the Visual Editor is today.

Templates: infoboxes

Let's test some basic functionalities of template dialogue for infoboxes.

• Test: is the issue with strange box in infobox fixed?
  • Purpose test: In 2013 this issue was noticed and reported, this should be fixed by now. The strange box is only shown in the Visual Editor.
  • Result (link): it is still there...
  • Importance level: low
  • Phabricator: unknown

• Test: adding new wrong parameter to see warning
  • Action: click on button "Meer informatie toevoegen" (en) and add new parameter.
  • Purpose test: As it surprised me to see that the software showed a button (+ after clicking a box) for adding a new parameter (in the template dialogue), and I wanted to see if the software gives a warning that the parameter is not defined in the infobox.
  • Result (link): no warning that parameter is not defined. If this is enabled for everyone, no help is provided, and many new fake parameters are added because of the VE suggesting something strange. They go question themselves why this adding does not work. New users expect with a button "Add more information" that they really can add more information instead of dummy fields that do not work.
  • Importance level: mediate-high
  • Phabricator: unknown

• Test: adding new parameter in appropriate place
  • Action: click on button "Meer informatie toevoegen" (en) and add new parameter.
  • Purpose test: To see if it adds the parameter in an appropriate space.
  • Result (link): parameter is added at the bottom, but on the same line as the }}. We have noticed in the past that if we do not add the }} on a new line for infoboxes (vertical templates), users loose an overview where the infobox ends and the text begins.
  • Importance level: mediate-high
  • Phabricator: T117891

• Test: adding new infobox
  • Action: click on "Invoegen > Sjabloon" (Add > Template)
  • Purpose test: To see if infobox is added in a good way.
  • Result (link/2): the infobox is added with all parameters cluthered on the same line all together. For years we have worked on getting all infoboxes added in a good way so it is for editors easy to have an overview of the parameters and can easily fill them in behind the =. The way the VE adds this infobox is just crap, there is no other word for to describe this. And even worse, it sticks new text lines behind it instead under it. A big complaint from the past was that templates and text were too much cluttered, and now this is introduced again.
  • Importance level: mediate-high
  • Phabricator: T111674

• Well:
  • It ads the parameters in the predefined order.

• Remarks:
  • The number of times I mistakenly click on "Wijzigingen toepassen" (Apply changes) is high, and is annoying as I have to start again.
  • With adding a new infobox, each parameter has to be added by hand and the adding of all those individual new parameters is annoying.
  • The various parameters have a description but this description is not shown next to the parameter. Many parameters have instructions how to enter data to them, those are not shown. Only when the cursor is put in a field, the (i) is shown and it is not easy clear that that is for info about this parameter.
  • There is no button to add an empty infobox with predefined parameters to a page.
  • I am surprised that adding links in an infobox is still with brackets.
  • The button "Opties weergeven" (Display options) is not clear when it should be used.
  • The icons on the bottom of this side screen are not clear what they mean, especially "Inhoud weergeven" (Show content) and "Meer informatie toevoegen" (Add more information). When I add something to the last one it appears before the article text...? (example: The "Info added in "Inhoud" field" I added to the "Inhoud toevoegen" field.)
  • The dialogue screen is way too small on my screen to use it effectively with infoboxes with 10+ parameters.

Technically it works for a part, but the dialogue screen for adding templates is a failing design. And adding infoboxes or parameters creates not nice results in pages. The template dialogue is not ready for the general public.

Templates: other

• Test: adding a quotation
  • Action: click on "Citeren" (Quotate) to add a quote of someone to the page.
  • Purpose test: to see how it works.
  • Result: it does not add a "Citaat" (Quotation) but a reference. Button is wrongly labelled. Also the header of the dialogue is wrongly labelled.
  • Importance level: low
  • Phabricator: unknown

• Test: adding a navigational template (dialogue)
  • Action: insert template and then choosing a navigational template
  • Purpose test: works the dialogue well
  • Result: When I want to add a navigational template (without parameters), I get a box where I can add a "Veldnaam" (field name). This is strange, this template has no field names. I would expect here at least a message that no field names have been defined, or something like that.
  • Importance level: mediate
  • Phabricator: unknown

• Test: adding a navigational template (source)
  • Action: insert template and then choosing a navigational template
  • Purpose test: to see if the template is properly added
  • Result (link): the navigational template is added behind the already existing template, something that is not visible with editing in the VE. Also before the second template. We have been working years to get articles organised and having a clear overview by having the navigational templates all on their own row, and for no reason this is messed up in VE.
  • Importance level: mediate
  • Phabricator: unknown

Other remarks:

• Adding the coordinates template goes pretty well, but can't handle the 9th parameter for type, scale and region which uses the Geohack setup.
  • Importance level: low
• Why is there still no option in template data for multiple choice? Or an overview of default options users are recommended to choose from.
  • Importance level: low
• One of the most used templates (Appendix) can't be used properly, without messy results (link).
  • Importance level: mediate

References

• Test: adding a reference (auto)
  • Action: clicking on reference** button
  • Purpose test: to see if it works
  • Result (link): adding a reference to a regular used source works, but with 3 issues:
    1. Why has the title a subtitle (the part behind the - ), I would consider that part not suitable for Wikipedia.
    2. Why does it add a link to the Google Plus account of the publisher?
    3. Why does it add as language nl-NL? This is just wrong, the template only accepts the ISO 639-1 codes for languages, because of our underlying template system.
  • Importance level: mediate-high
  • Phabricator: unknown

• Test: re-using an reference
  • Action: clicking on reference** button and re-use other reference
  • Purpose test: how does this work out
  • Result (link): it seems to work pretty well, besides one detail: why the strange reference name is issued? ":0"
  • Importance level: low
  • Phabricator: unknown

• Test: adding reference (manual: website)
  • Action: clicking on reference** button and use manual option + website
  • Purpose test: how does this work out
  • Result: Seems to work. Only why is there still no button to easily add the date of today for date fields? Then users can easily click on this or choose another date
  • Importance level: low
  • Phabricator: unknown

• Test: adding reference (manual: basic form)
  • Action: clicking on reference** button and use manual option + basic form
  • Purpose test: how does this work out
  • Result: some parts work pretty good, some parts are really strange. Some issues:
    1. This dialogue is not clear to understand. With a basic form I would expect are more simplistic dialogue, this one is more complex in usage in comparison with the other dialogues for references.
    2. I have the option in the "Invoegen" (Insert) menu to add a gallery to a reference... This should never never be used. Media? Hieroglyphics? ..., etc. And even the media is a primary suggestion!! This is not right.
    3. Adding a "Opmerking" (remark) apparently adds text between <!-- and -->, what I only understood when I saved the page and saw the outcome. I can imagine that adding a "Opmerking" is interpreted differently.
    4. The part of Options is completely not clear.
    5. If I select "Use existing reference" it works fine and I get a "back" button. This button I miss for the Reference dialogue in general. If I want to return to the options for references I have to close this one and open it again. After some 3 times the VE isn't showing me the dialogues any more, but is stuck.
    6. Adding a link works strange: first I have to enter the url, then I have to insert it. Then I need to select the link again (that was shown as [1]), + clicking edit + there I can click on the button "Add label". Adding a label should always be used and not been hidden so far away in the dialogue.
  • Importance level: low-mediate
  • Phabricator: unknown

Tables

• Test: editing tables
  • Action: in VE clicking in table to add information
  • Purpose test: Is it possible to add things to a table
  • Result: clicking in a table does only select a cell, but does not allow to edit the table. Only after quick double clicking editing is possible.
  • Importance level: very low
  • Phabricator: unknown

Files

• Test: handling largethumb template
  • Purpose test: Largethumb is used on many pages and is recommended for years, should work properly. Is already reported two years ago.
  • Result (link/2): still can't handle Largethumb (minor issue). However it creates on pages with multiple files with Largethumb big white space in articles, which will be removed by users, resulting in images being deleted from articles without the user having such intention. And then other users can clean up this mess and restore it.
  • Importance level: high
  • Phabricator: unknown

Other remarks:

• Why are there so many options for files? Including some that are never used and have no actual use.
  • Importance level: mediate
• Why is it made too easy to adjust the file size? The MediaWiki software has been designed in such way that people with bad eyes, large screens, etc, can adjust the file size of thumb files as long as there is not manual px value is entered. As soon as px are entered, they can't adjust it any more in their preferences. On this wiki we value the idea that people with vision issues can adjust, and the current setup, with no explanation or warning whatsoever, does break a basic value.
  • Importance level: mediate

Categories

• Test: categories
  • Action: add/change categories
  • Purpose test: basic functionality should work, all articles need proper categories (convention) and are required.
  • Result: the categories are not shown on the bottom, can't be edited there, but all normal articles have there categories. Apparently the categories option is hidden under the Options menu. For such a basic functionality not a logic place.
  • Importance level: low
  • Phabricator: unknown

Other remarks:

• Why can't the Defaultsort not be added above the categories as this is common, custom and the fixed spot where they are normally added, instead on the bottom?
  • Importance level: low-mediate
• Why is it possible to add categories to user pages, categories only intended for articles?
  • Importance level: low
• Why is there still no basic functionality that add the {{Nocat}} template to articles without article categories?
  • Importance level: low-mediate

Other

• Test: strange codes
  • Action: adding "test" in a table behind a link
  • Result (link): with adding "test" behind a word, normally that should give a link or with a space no link. Never his kind of codes in articles, those make articles unnecessary complex.
  • Importance level: low-mediate
  • Phabricator: unknown

Other remarks:

• Why are there the options to hide the contents table? This is not something that should be used that much, only in rare cases the contents table should be hidden, and in most cases that is done by a template automatically. Having a Inhoud abc contents table is not possible in VE.
  • Importance level: low-mediate
• The option to add span codes with language to articles is not common here. It is a basic rule that we do not want to add codes in sentences as they make editing to difficult.
  • Importance level: low-mediate
• Why is there an option in the menu to remove the edit buttons next to headers?
  • Importance level: mediate-high
• Why is there an option in the menu to add DISAMBIG? This should never never be added this way.
  • Importance level: high
• Why is there an option in the menu to add a REDIRECT link to the top of the page? Even if the pages has contents? (Not to mention the confusing labelling.)
  • Importance level: mediate-high
• Why is there an extra option to mark a page as static redirect? We do not use this on this wiki. The description says it is for rare cases, no reason to add this to the menu.
  • Importance level: mediate-high
• Why is there an option in the menu to prevent articles to be indexed by search engines? This should not be possible.
  • Importance level: high
• Why is there an option in the menu to add a new section link to the tab bar? This should never done in articles.
  • Importance level: mediate-high
• Why is there an option in the menu to give a page a different displayed title? This should not be possible.
  • Importance level: high
• I am surprised that there is still no option to tag a sentence with Source?
  • Importance level: low

Until so far the first part of the analysis. Based on this it is very safe to say that the VE is not ready for full implementation. Romaine (overleg) 28 okt 2015 06:52 (CET)

Thanks for your work. It's much appreciated, particularly where it details pain points which may be specific to this wiki, like the attention to some graphic detail or an issue with a template that may be not available elsewhere. In some cases, fixes may be possible at a local level (that is, a change in template code, Template Data or translation may be all it's needed), which is good news. I think that several topics may be better discussed elsewhere as those are very generic enquiries about the product design or functioning. Eventually all the points you raised are/can be put in Phabricator, of course, and me providing my angles doesn't prevent that from happening :) While James and others can address other technical points, I'd like to chat with the Dutch community about other, more general aspects in the meantime, before we dive into discussing each problem separately. (For background, I've been processing communities feedback re: VE since 2013 on several Wikipedias and supported almost all its rollouts so far, so I hope that my experience can be useful to others.)

For some reason, sounds like you expect that launching VisualEditor here would cause a huge mess :) It is a common feeling - for me as well! - around this kind of rollouts, until you do it and find out everything goes quite smoothly actually, as also confirmed by the recent rollout to en.wiki I’m mentioning below. First, enabling VE on the Dutch Wikipedia at any time would not mean that editors would use it (and certainly they wouldn't be forced to). It would only give them a real choice to launch it, if they want to. On the top of this, some types of rollout, like making VE available to users who register an account after a given date, can be made progressive (a certain percentage of editors each week), so anyone has time to check how things are going, and active editors (like patrollers, or newbies' helpers) have the time to adjust, understand what's happening, support editors better. Of course, Foundation people would be here all the time as well, that goes without saying ;) What we saw at the English Wikipedia recently (you probably know VE was launched to new editors there some months ago) is that the gradual rollout was basically undetectable from the community side (if it wasn't for our announcements and updates, that is).

I think many may want to understand what the editors who may need VE here may struggle with, rather than why it doesn't work for those who may not choose it anyway (I do care about this aspect as well: I just need to prioritize stuff now). I see that you've spent quite some time digging in advanced functions. That's OK of course, IMhO it just doesn't cover precisely what many people will actually do while in VE. Common editing is what most people are already doing here (and it'd be even more basic if unexperienced people had it, but that eventually depends on what the editor wants to do). This said, that VE may not be the favorite/suitable tool for editing for someone who registered over 10 years ago and has hundreds of thousands of edits, that's... understandable. It's also understandable to struggle with some things the first time you see them, especially when one is a very experienced editor who has very precise expectations on what editing is and how it should be done.

I'd also like to understand what would make nl.wiki editors special and more prone to confusion, to make mistakes and to misuse VE, because that's another thing that you seem to be expecting here. Whatever people are already able to do in the wikitext editor, they should be able to do that as well in VE. Whether they'll do the right thing with it, that's up to the users in the end (and partly to components like good documentation and/or good support that allowed them to know what to do, and how). Like anything, it can be misused, exactly like I could easily add wikitext here which doesn't work, doesn't make sense, breaks the page etc. (a lot of this is simply possible by clicking randomly on stuff available in the toolbar or somewhere else on the page). Well, VE has been available on several big wikis for years now, and while several horrible scenarios are indeed possible... they're just not happening. I'm not saying VE is perfect and everybody loves it; just, there's no epidemic of broken edits or anything, and I thought some may want to know.

Finally, I'd like to understand which bugs other editors consider really relevant here, because if we want to discuss about a launch soon-ish, we need to identify all the real blockers. If there's a reasonable number of those that we can list, I can make a case with WMF and ask that the fixes to those issues are prioritized and we can agree on an estimated deadline to fix others after the rollout (for example). Sorry if this is long, and thanks a lot for your help with this! Elitre (WMF) (overleg) 29 okt 2015 14:43 (CET)

I think most issues I have described are for multiple wikis the case and so far the developer team hasn't taken the needs of multiple wikis into account. I do not know any Wikipedia where it is appreciated that software adds crap to articles. That so far no wiki has publicly (aware) reported that they see this as a problem, doesn't mean it is not a problem. Further I think it is also the responsibility of the developer team to come with decent software, and actually starts caring for the contents of the wiki.

"sounds like you expect that launching VisualEditor here would cause a huge mess" -> We are already every week cleaning up the mess the Visual Editor creates in articles. If software is adding <nowiki/> (and others) it is clearly malfunctioning. And this issue was even the original cause of the earlier voting, because reports from users that such was added has led to a clear voting: no, no implementation yet, fix it first. And still this is not fixed after two years, as we notice with this article from a couple of days ago. Two years ago we already said that the Visual Editor is making wrong actions much easier than with the normal editor, and over time this has gone worse!

Also other large issues from 2 years ago are still not fixed. The voting from two years ago was clear: basic quality level of what the community expects from the software is way higher than what is delivered, and is sadly still the issue. And it really starts to get annoying with each newsletter, a lot of functionalities are added, besides the basic quality level that is asked for. The Dutch community cares very much about their articles and have worked the past years hard on getting a lot of code crap and unnecessary codes and templates out of articles, and this is not something that is given up. I do not want to be told that the VE is not intended for experienced users who work on the wiki for 10 years. The community asks for software that does not distract them from normal editing, as they do not want to clean up the mess that the Visual Editor leaves behind. I give many workshops to new editors and know what they want, and I am aware of what the purpose of the VE is.

You can talk about new editors, and ways of implementation, but the community said a clear no in the voting towards implementation as long as the major issues haven't been solved. And checking those issues that we faced two years ago, almost all of the major issues still are there nowadays and we have noticed even more negative effects of the VisualEditor. So no, we can't talk about implementation unless the major issues are fixed. Romaine (overleg) 2 nov 2015 03:19 (CET)

PS: And I think I understand why the users of this wiki do not do much with TemplateData: the community had wished for years for a good working Visual Editor, and when the Visual Editor got implemented two years ago it disappointed almost everyone with the poor quality it delivered. And still after two years the quality is still too low. Romaine (overleg) 2 nov 2015 03:19 (CET)

I think I gave with the analysis (again) a nice overview of (certainly from nl-wiki perspective) high priority issues to be fixed as soon as possible. For 2,5 years we are told that the developers work on them, but still we haven't seen results. Words do not convince us, we need actions in software changes, finally. Romaine (overleg) 2 nov 2015 03:28 (CET)

Hi again. I summarized what look like the most pressing needs below. I still invite everyone to keep contributing to this effort, as this kind of activity needs to be as much of a group effort as possible. "Ten people asked me about this" has a stronger impact than "one person asked me about this" ;) If there’s anything you want me to do here to be finally able to hear from more voices, I’m all ears.

1. "Alert when adding parameter not defined by TemplateData" is now https://phabricator.wikimedia.org/T117890;
2. "Templates’ closing curly brackets to be placed on a different line than the final parameter" is now https://phabricator.wikimedia.org/T117891;
3. Templates appearing all on the same line is https://phabricator.wikimedia.org/T111674, which was recently marked as high priority;
4. Re: Citoid, the imperfect return of metadata from Zotero is to be fixed locally (see related info on mediawiki.org), while unsupported language codes being added is https://phabricator.wikimedia.org/T115326 (a workaround which can be implemented locally is also linked there);
5. Issues with “Largethumb” have been worked on in time, as per https://phabricator.wikimedia.org/T51400 . A more complete fix is possible, but it’s not an easy fix, and therefore requires a lot of work.
6. For the various enquiries around advanced page settings, in most cases user education will help with them, and labels/descriptions can be of course customized locally.

Given the lack of a different evaluation, I consider number 3 and 5 to be the real blockers here. Both the Parsoid and the VE teams have already committed to fixing them, although there may not just be enough time to do so in, say, a couple of weeks. As you know, teams plan their work through quarterly goals, and these items were not originally planned for this quarter. I can certainly push for the tasks to be fixed ASAP, but the outcome of that needs to be that VE is launched here for at least some user groups. It should go without saying that I can't really ask these teams to fail their official current quarterly goals (that is, general work which doesn't accommodate just one wiki) while not even accomplishing a launch here on the top of that.

Other bugs in the list can certainly be identified and addressed during, and even after the deployment, and I already have answers to post. There may be some very general topics though, like expectations on what VE actually is and should do, which may be better addressed with a conversation, rather than through tasks in Phab. If you have ideas about how to tackle them, I’d be happy to accommodate: my suggestion is a dedicated IRC office hour, or a triage meeting.

It doesn't really matter when the rollout happens, although I know that you would like this to be done before some upcoming events. Before then, there needs to be a much clearer list, similar to the one I provided above (as feedback needs to be actionable, and to live where devs can actually see it). The list also needs to be "frozen" - we make sure the teams acknowledge what's in it, and then no more blockers can be added to it. The bar needs to be set only once, hence why it is important that several people agree on it.

So, let's do this together? Thanks, Elitre (WMF) (overleg) 6 nov 2015 10:41 (CET)

Cite, citeren, citoid

Citoid levert magic, soms. In de visuele tekstverwerker een referentie toevoegen met "Citeren" levert op de Nederlandstalige Wikipedia bij invoeren van https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0030091 een armzalig {{{title}}} op, zie mijn edit hier, terwijl op de Engelstalige Wikipedia via dezelfde handeling er " Yasseri, Taha; Sumi, Robert; Kertész, János (2012-01-17). "Circadian Patterns of Wikipedia Editorial Activity: A Demographic Analysis". PLoS ONE 7 (1): e30091. doi:10.1371/journal.pone.0030091. PMC 3260192. PMID 22272279." uitkomt, zie mijn bewerking daar.

• tl:dr; cite or citiod does not always work, see the cite journal example above. On English Wikipedia it does given the url as input, on Dutch Wikipedia it doesn't. Ad Huikeshoven (overleg) 16 nov 2015 21:41 (CET)

Deze edit in sjabloondocumentatie lost het op. Ad Huikeshoven (overleg) 16 nov 2015 22:09 (CET)

"format":"block" parameter kan nu met druk op knop toegevoegd worden aan sjabloondocumentatie

Bij toevoegen van een sjabloon met de visuele tekstverwerker komen alle parameters achter elkaar, in plaats van iedere parameter op een nieuwe regel. Met de TemplateData manager kan nu met een druk op de knop de format parameter op block gezet worden in plaats van de standaard inline. Het is onbekend wanneer het Parsoid team ervoor zorgt dat het ook gaat werken. De infoboxen plaats in land zijn van de format:block parameter nu voorzien. Ad Huikeshoven (overleg) 24 nov 2015 22:16 (CET)

En je hebt er een klerebende van gemaakt, alle toevoegingen kunnen gerepareerd worden. Als dit de kwaliteit is van je bijdragen kun je er beter van afzien. Romaine (overleg) 24 nov 2015 22:29 (CET)

Deze actie is niet heel zinnig, templatedata is primair om de parameters te beschrijven en deze leeg toevoegen is niet erg productief. Wat ik net zelf wel gedaan hebt (nou ja, mijn bot), is alle infoboxen die al templatedata hadden de "format": "block" toegevoegd. Akoopal _overleg 24 nov 2015 22:55 (CET)

Let's take a baby step?

Hey everybody,

I've got this crazy idea, and thought I would talk to you about it.

The Erasmus prize is coming up, and press coverage will be intense, and many people will (re)discover Wikipedia then (yay!).

How about we give these people the editing experience they'd expect? Let's make VisualEditor available, only for newly registered editors, now. We're really talking about a few hundred people here. Most of them will only make one edit, so it might result in 10 to 20 edits in VisualEditor each day. Let's observe closely their behavior during these few weeks left in 2015 – there's even a tool for that if you'd like to go in depth. We may even find out about language-specific bugs still unreported, and that'd be truly invaluable. What do you think? Elitre (WMF) (overleg) 17 nov 2015 15:52 (CET)

•  Voor - I would be completely in favour of this. I've given dozens of Wikipedia workshops; the first thing i do is switch on visual editor on new accounts. It's just a far more gentle introduction to editing Wikipedia than the text editor. Husky ^(overleg) 18 nov 2015 11:18 (CET)
•  Voor - same reasons as Hay; I do the same during edit-a-thons. AND I've also mostly switched to Visual Editor for my own edits. For quite some time now, and I've noticed considerable improvements. Like every software, it has some bugs and I'd like some more functionality in it (mostly related to the finer editing of tables!). But in general it really works pretty well for me (I'd give it a solid 7.5/10 in functionality and user experience) and is so much more pleasant than fiddling with wikicode. (And to be honest, I'm a bit baffled to hear that nlwiki is one of the few Wikipedia's with Latin script not enabling VE by default yet. To repeat myself a bit: the benefits far outweigh the costs.) Spinster (overleg) 18 nov 2015 13:02 (CET)
•  In favour, what would be required to take this forward? -- I would like to see some more buy-in from the Wikipedia-NL community as a whole than just the 4 or 5 of us here, though. --Frank Geerlings (overleg) 18 nov 2015 13:08 (CET)
  • To take it forward I think it would be best to start a poll at Wikipedia:Opinielokaal. Give specific timelines, for example, will this last for ever or for a few months, how do you evaluate succes or failure, etc. If a test is well thought out, I see no reason to object and try. Sincerely, Taketa (overleg) 18 nov 2015 13:45 (CET)

I am sorry to say, but the community has spoken clearly: first solving the basic problems, and when those are solved the baby steps can be taken. It is really annoying that the community is not taken seriously. Romaine (overleg) 18 nov 2015 13:09 (CET)

That poll was token over two and a half years ago. Things have improved considerably. Can you give examples of things that are blocking in respect to new users? Husky ^(overleg) 18 nov 2015 13:17 (CET)

Recent tests show that the issues described in the voting from 2 years ago are still currently existing. The basic problem is that the community does not want to clean up the mess because the visual editor doesn't work properly and encourages wrong actions. If bots would have done similar edits, those would have been blocked! Romaine (overleg) 18 nov 2015 13:31 (CET)

PS: My Wikipedia class started editing Wikipedia past Friday and they tried out the visual editor, but most of them got stuck in the VE and switched to the normal editor as that one works properly as it is supposed to. I am a fan of a visual editor, but it should work as properly as the normal editor. Romaine (overleg) 18 nov 2015

13:31 (CET)

Do you have a link to a page outlining those recent tests? Obviously, the community shouldn't 'clean up the mess', but i'm curious what this 'mess' exactly is. Husky ^(overleg) 18 nov 2015 15:13 (CET)

The recent tests are in a comment by Romaine on the page you're currently reading (see #Analysis above), in a very large and (in my opinion) hard to interpret list. The community has not spoken on the proposed 'baby step' suggested by Elitre and Romaine would do well to read her proposal again if he feels we did. I think it's rather odd that two people that assist newbie editors in-person in live events have positive experiences with newbies and the Visual Editor, and one has very negative experiences in comparable circumstances. What could be the cause of this? --Frank Geerlings (overleg) 18 nov 2015 15:29 (CET)

•  oppose for now. Per Taketa. Unless those conditions are met it should not be implemented by default. I also agree with Romaine. The community has spoken and this should not be overruled once more by the WMF. Natuur12 (overleg) 18 nov 2015 13:51 (CET)
  • To be clear: this has nothing to do with any 'overruling' from the WMF. If the community doesn't think it's a good idea, it won't be done. Husky ^(overleg) 18 nov 2015 15:11 (CET)

Thanks for your replies. To address quickly some of your points:

@Frank Geerlings: please feel free to spread the word about my proposal (more engagement is something I have already asked for here, but I don't know enough Dutch to go and bother people elsewhere. Or to buy a stroopwafel, for that matter).

@Husky: "cleaning up" has always been a task that every community does - namely patrollers, who review and fix any kind of edits. If you don't consider vandalism, in most of the cases you're left with the mistakes that people can do in good faith when trying something new or when they're in a hurry. Think of when someone forgets or fails to “close” a template, a link, or a table, or uses apostrophes which do not match and extend the annotation to entire paragraphs. (These are things that, by the way, don't happen with VisualEditor.) So this is just really about having to deal, in case, with a different set of problems than the ones we’re used to.

(Data tell us that the burden on current Wikipedians is sliiightly lower with VE, and I suspect this finding had a role in the recent decisions at the English and Spanish Wikipedias to enable VE for some user groups. I confirm we'd be talking about a few dozen edits per day from new editors in nl.wiki's case.)

Also, you are reading my proposal correctly. It's only up to you to decide if you want to make this happen or not! All I can add is that it would probably make a difference in the amount of staff time and energies I can try to request for VE at this wiki in the next quarter.

Some may not realize that this is just an attempt to yield to community's wishes. We're aware some hoped to have VE somehow available in time for the Erasmus Prize, whose ceremony is scheduled for next week. I made a related search today. Wikipedia is already mentioned in the snippet for the official site (second result). This instead is the press starting to cover the event. I don't think there's time for a full poll at this point, and agreeing to my proposal doesn't prevent any kind of adjustments, conversations, votes or other activities from happening in the future.

For your particular situation, I made a very specific, unprecedented, one-time offer with several limits, related to time and user group involved, which would only impact a tiny fraction of users. Hence why I think you can be “bold” - it's not a contract you're signing with blood. It's a very casual pilot in my mind, and there are several ways to watch closely how things would go, of course (and I just installed a user script here in case someone wants to review VE diffs, for example). In case of widespread, unforeseen problems, you wouldn't even need to ask to disable it. All you need to do now is filing a request similar to this one, adding the "VisualEditor" project and linking back to this conversation. If it's not on Phabricator by Monday, then I'll assume you're not interested. If you'd prefer me to file one for you, just ping me. Thank you, Elitre (WMF) (overleg) 19 nov 2015 22:51 (CET)

I have expressed many months ago my wish that the visual editor would be ready and implemented, but the criteria what is needed for that are not full-filled. We have indicated what our problems are with the visual editor, and they still exist - we are waiting to have those fixed, then it can be implemented.

The visual editor was rushed in 2013 - something that led to massive criticism in 2013, let's not repeat that. And let us certainly not call a big step as proposed here under this header a "baby step". This proposed step I consider the largest step at all in the whole process. Calling it such is not helping to get the situation improved.

I think it is time that WMF shows some serious efforts and improvements, and shows commitment to make the visual editor better in the way it has been asked for multiple times over the past years. The criteria for a good working visual editor should be determined by the community, not by WMF, as it is the community who faces the every day's output.

The faster WMF fixes the problems, the faster it can be implemented. We are waiting for WMF to finally solve the issues. Romaine (overleg) 22 nov 2015 10:40 (CET)

•  In favour Sorry, I'm a bit late/slow. I really think it's a good idea to give it a go now. Of course there will be some problems, but I'm pretty sure that we can solve them. We must continue to invest in making Wikipedia more easily accessible. Greetings, --Dick Bos (overleg) 21 nov 2015 20:53 (CET)
•  In favour Privately I'm in favour. As board member of Wikimedia Netherlands responsible for international affairs and community I do have to add a few remarks. Wikimedia Nederland isn't responsible for this wiki, there is no board resolution about Visual editor, neither can the board of a chapter resolve this issue. What the chapter can do, or for my part as individual board member, is canvas volunteers who act as trainer, to speak themselves out. The coming week I will meet a lot of Wikpedians face-to-face and will reach out to them. In this discussion there are 'friendly space expectations' which set high standards for civility, assuming good faith and so on. The community of the Dutch Wikipedia consist of a few very dedicated and very committed volunteer contributors amongst hundreds of active editors and even more less active editors. The wider community also consist of offline volunteers, volunteer developers in the Netherlands, chapter staff and also staff of the Wikimedia Foundation and some more volunteer developers across the globe. All these people support the mission of our movement in the best way they can. The movement recognizes and appreciates the contributions of all these people. The Erasmus prize is in recognition of the Wikipedia Community globally, which include a lot of people. The community is taken very seriously, and in particular the community of the Dutch Wikipedia. Multiple teams at the WMF have worked hard the last couple of years to address specific issues brought up by Dutch Wikipedia and continue to do so.
  
  Elitre addressed the community of the Dutch Wikipedia with question to take a small steps. Existing logged in users will continue to use the wikitext editor in her proposal. Visual editor will remain hidden for logged in users who didn't opt in. I'm privately in favour to unhide visual editor for future newly logged in users. We can try that for a limited time, say a couple of weeks after which visual editor will be hidden again, unless there is consensus to reopen. Ad Huikeshoven (overleg) 22 nov 2015 22:37 (CET)
  • You try to canvas volunteers who sometimes act as training, just purely you try to bypass the voting from the community? This is unacceptable. And this shows that you certainly do not take the community seriously.
  • And the concerns why the visual editor is not implemented for anonymous users is because they form the highest risk of causing problems with the visual editor. Opening the visual editor for all anonymous users is a big step. Romaine (overleg) 23 nov 2015 15:08 (CET)

Thanks Ad for filing https://phabricator.wikimedia.org/T119347. Here are the options, based on the current situation:

1. enable VE to newly registered users ASAP for two weeks, to capitalize on the Prize momentum; or
2. give the community a week to discuss this further, and eventually enable VE to newly registered users for the month of December.

San Francisco is asleep now, but if there's a request we should act upon later today, please let us know. Thank you. Elitre (WMF) (overleg) 23 nov 2015 09:12 (CET)

Like Taketa said, this needs a vote so none of those options are acceptable. Natuur12 (overleg) 23 nov 2015 11:20 (CET)

It would have been nice if Ad had informed the community about his official request. He requested it on behalf of his membership of the board of Vereniging Wikimedia Nederland and not on behalf of the community and he states that Vereniging Wikimedia Nederland has no saying in this. Then why log a ticket and not inform the community who has a saying in this? It's a wrong approach and will lead to negative feelings about WMF and WMNL (and some people already have negative feelings about WMF and/or WMNL). So option 1 is absolutely not possible, option 2 would be an option if someone starts a poll today. Mbch331 (Overleg) 23 nov 2015 11:39 (CET)

Well, we probably need a little more time for a poll since people always want to have a change to give feedback about the format of the poll. Natuur12 (overleg) 23 nov 2015 14:40 (CET)

Ad is just bypassing the community because his wishes are apparently more important than the rest of the community.

Earlier the community has spoken clearly about the status of the visual editor. If anyone wants to ignore the big problems addressed by the community, the community should anyhow give their say in a voting before and agree with implementation in this broken stage, before it can be implemented at all. Romaine (overleg) 23 nov 2015 15:20 (CET)

• •  impossible - the community has spoken, problems are still there, no wish for change has been expressed since from the community at all. This simply is neither wished for nor wanted for at all. MoiraMoira _overleg 23 nov 2015 15:38 (CET)
  •  Tegen - per Taketa, Romaine, Natuur12 and MoiraMoira. I am all for taking steps forward but conditions are not right yet to take this step. I trust in Romaine's judgement whether the technical hurdles have been resolved. I hope developers will keep cooperating constructively and search for solutions together with the local community, in the true spirit of Wikimedia. Woudloper _overleg 23 nov 2015 16:52 (CET)

I have declined the request on Phabricator. Thanks everyone for your interest. Elitre (WMF) (overleg) 23 nov 2015 17:17 (CET)

I offered my help setting up a poll/vote. This could have been done in let's say 10-14 days. (This includes 1 week of voting time) Why didn't you take the offer? Okay, it would not fit the ideal timeline but it is better than nothing. You can blame the community for this but it is not our fault that you didn't bring up your proposal in time. Natuur12 (overleg) 23 nov 2015 18:05 (CET)

Also in spring this year I suggested that if the VisualEditor is wanted to be active with the Erasmusprize, improvements are needed, but apparently nl-wiki is not important enough to make that happen in time. (Not to mention we wait already two years.) So, sorry that we are not enthusiastic about your proposal, but we finally like to see results. Romaine (overleg) 23 nov 2015 18:17 (CET)

Hey Natuur12, I hope what I'll say clarifies things a bit. First of all, let's all be on the same page that there isn't and there has never been any timeline, beside, you know, the actual date for the Erasmus Prize, which is in 2 days ;) But getting VE on by then is a desire we heard from the community, it isn't a WMF plan. You can see at the top, in the archives or in the history of this page all the attempts to gather feedback and support this community I've been doing here for months (and I'd like to thank again everyone who's helped so far, including you). You can also see that above there's a long list of issues which, with some difficulties, we were able to narrow down a bit to the most pressing ones. Since then, WMF has worked and is still working on those: one has even been fixed some days ago, with some work left to do on its blockers. But I hadn't heard anything else for a long while after that. We were told that all those issues are blockers for wide deployment, and those can't all be fixed "now", so there would be no point in discussing the type of deployment that each other wiki has had so far. I did the only thing I could do to try and make that community wish happen to some extent, that is, suggesting a very limited trial. But you know, the ceremony is this week, so there won't be much press attention (and many new people discovering Wikipedia from the media) after that. I know this is something some may not realize - I have already walked an extra mile to be able to make that proposal in the first place, and it was all I could do to facilitate you and actually show appreciation for the preparation work that has been done so far. The proposal itself was already "better than nothing". I can't get those blockers fixed in no time - they require significant efforts: but at least, if the proposal got accepted, I could make a case that the community had agreed to a test, so I could put some pressure on the VE team to make them an official priority for the quarter starting on January 1st. Back to us now. The fact that that Phabricator task is closed doesn't mean we should now all go doing something else and forget about VE though! Please, by all means, do whatever you see fit to discuss this further with the Dutch community. Do have a poll now anyway. You need to find out whether the community is OK with having new editors get the VE tab "at some point". (It's when all the blockers are fixed and VE is given to its intended users that the real bugs come out ;) ) When you have reached consensus on something, whether it is in 2 days, 2 months or 2 years, let me know and we'll see what we can do then. In the meanwhile I and others will still be here: as I wrote in my very first message almost one month ago, several "issues" can actually be fixed locally, so we'll focus on that in the meantime. Best, Elitre (WMF) (overleg) 23 nov 2015 20:14 (CET)

Thanks for the clarification Elitre (WMF). Earlier today I wrote a comment in the task "Probably best is to wait until Wednesday wikimeet after the award ceremony before deciding on anything." And in my humble opinion according to this page over seventy community member will gather for a wikimeet which allow face-to-face consultation of community members about a time limited (one or two weeks) trial for newly registered users only. As I wrote, wait until Wednesday wikimeet before deciding anything. The outcome of the wikimeet might be that there will gathered enough support, for example for setting up a vote. Natuur12 thanks for your offer to help with setting up a vote, I appreciate that. Will you join Wednesday wikimeet? Ad Huikeshoven (overleg) 23 nov 2015 20:43 (CET)

Na de bijeenkomst gisteren is de stand van zaken nu om nog even niets te besluiten en nog geen peiling of stemming op te zetten. Justus de Bruijn gaat op verzoek van Frans Grijzenhout i.i.g. met Romaine praten. De uitkomst van die gesprekken is een helder overzicht van de bezwaren van Romaine. Ad Huikeshoven (overleg) 26 nov 2015 21:47 (CET)

Perhaps I am missing something but since when do some people offwiki decide if there will be a vote or poll or not? Natuur12 (overleg) 26 nov 2015 21:51 (CET)