Topic on VisualEditor/Feedback

Since the ee dashboard is off, I'm wondering if there is a way to check exactly what percentage of wikipedians uses VE as compared to wikitext editor.

Overall, about 30% of registered editors use the visual editor at least once each month. That statistic is not calculated automatically, but you could get a query to make it specific to any individual wiki. See https://commons.wikimedia.org/w/index.php?title=File%3AEditing_department_–_Quarterly_Review_slide_deck%2C_2016–17_Q3.pdf&page=24 for some numbers.

For the metric that you didn't ask for, about a million edits were saved in the visual editor last month. This represents about 8% of all non-bot, non-Wikidata edits. The other 92% includes Undo, AWB, Twinkle, HotCat, mobile, mobile app, WikEd, etc. as well as the "manual" edits in the older wikitext editors.

Is popularity really the metric that you want?

https://edit-analysis.wmflabs.org/compare/ says that editors who have made less than 1,000 edits are more likely to complete an edit when using VisualEditor at enwiki and plwiki, except that logged-out editors at plwiki (but not enwiki) are more successful in the wikitext editor. (I'm looking at the last six months; that dataset got changed at some point, so the earliest days aren't comparable.)

Well, popularity is certainly one of the factors to consider. There is a huge debate on Polish Wikipedia whether implementing solutions that make editing in code easier, but that make editing in Visual Editor much less fun, is acceptable. Namely, VE doesn't work well with references disguised as templates (say, {{R}} templates, ref grouping and such), yet some wikipedians apparently love it and since there is a script that automatically converts all references to this format, they use it. Anyway, I was wondering how many Wikipedians would actually be affected if we followed the logic that convenience of those who use code editor is more important than convenience of those who use VE.

Also, is there an example query somewhere to customise?

The story seems to be that if you want this data, then you probably need to file a Phab task to request that someone pull it for you. Also, they apologize, because apparently someone was supposed to re-create the old dashboards on the new data system, and it hasn't happened yet.

@Whatamidoing (WMF) Like this?

I thought that plwiki had decided to stop using those templates in 2013, when VisualEditor was first introduced. (It'd also make Content Translation harder.) Perhaps I'm mis-remembering this; User:Tar Lócesilion could probably correct me.

I'm not aware of any query, and both of the people that I'd normally ask are out of the office today. But I'll ask around, and I'll let you know if I get something useful.

A different question: How do editors at the Polish Wikipedia usually add references? Are citation templates common? Is the citoid service working out? I know that the services that citoid relies upon have a bias towards English-speaking sources.

Citoid works great, together with the pretty universal {{Cytuj}} template wrapped in standard <ref> tags. Sure, there aren't that many Zotero plugins for Polish sources, but the service itself works great and I love it (which is why I implemented it :) , with a lot of help from you guys that is).

The standard way is wrapping reference templates in ref tags, much like on other wikis. Cytuj template for all sources works great, but there's also earlier templates still in use, that is Cytuj książkę (our version of Cite book), Cytuj pismo (Cite journal), Cytuj stronę (Cite web), and so on.

However, there's also a sizeable group of Wikipedians (a minority, but a visible one) who prefer to use {{r}} templates together with this script. The group is particularly strong in biological topics, where such nested refs paired with a template are pretty much common. To make things even more complicated, there is a script to convert existing ref tag refs to {{r}} templates, but not the other way around. Which means you can make VE's citation engine useless with one click, but it's considerably harder to undo the damage.

Finally, in FA and GA class articles the {{odn}} templates (our version of sfn from English Wikipedia) are common. VE doesn't work to well with them either (the engine is useless, plus when adding the template to articles, VE adds empty lines before and after; there is a workaround though, you have to type the code of the template, say, {{odn|Kowalski|2017|s=12}} somewhere else, for instance in the search box of your browser, and then Ctrl+V it in place.

It is unlikely that the visual editor will ever support {{sfn}} fully. (There are technical reasons for this situation, but I don't understand them, so I can't explain them to you.) If the {{r}} template is similar, then I think we could reasonably predict limited support (at best) for that template, too.

@Matma Rex, have you ever considered writing an "undo the {{r}} templates" script? Would it be significantly more complex than the existing one?

As a volunteer, I'm a little worried about using this template in biological topics, at least to the extent that biological topics include medical topics. Medical articles often get translated, and the more templates that get used, the worse the result is.

The script lives in my user namespace, but I don't maintain it anymore. The part that does the actual conversion has been since rewritten by Peter Bowman and lives on tool labs (http://tools.wmflabs.org/pbbot/pretty-ref).

Note that the script really does two separate things:

1. Move references contents out of the <ref>…</ref> tags in the main body text to <ref>…</ref> inside the <references/> tag at the end. This should not be a problem for VisualEditor, and it would still be an improvement for people editing in wikitext.
2. Change the resulting <ref name="…" /> tags to {{r|…}}, and the <references>…</references> to {{Przypisy-lista|…}}. This is the part that VisualEditor doesn't like. (In general, VisualEditor doesn't like things that are simultaneously templates and something else, e.g. template-generated table cells or template-generated references).

Changing the script to only do 1 without doing 2 should not be very difficult, it would just be a matter of adjusting the script's output. But I don't maintain this code anymore and I'm not familiar with the current Java version of it – please ask @Peter Bowman about making and deploying any changes to the labs tool.

But anyway, in my opinion it should be entirely possible to make VisualEditor handle template-generated references better, and I'm sad we're not putting more effort into it. :(

Oh, and there's another local bit: Polish Wikipedia absolutely hates the </references> tag, it's being replaced with {{Przypisy}} on sight by basically everyone, and their mother too. Which often leads to weird results if they forget to add an empty line before the template and it breaks. But this one is not a huge problem. Nested refs are.

It was announced that any further use of those templates is discouraged, but not everyone knew it, not everyone agreed, and now, still doesn't agree.

As for the refs, the standard are citation templates and a template (References) at the bottom. In fact, Citoid works well. However, it's considered OK as long as it produces templates that look like they were added manually in wikicode. Our community loves sticking to the only standard.

Could you dig the link up for me?

It doesn't look like  {{Przypisy}} has been updated to use the new responsive layout feature. People might be happy with the result. It's possible that the easiest thing to do is to request a config change. (File a subtask at https://phabricator.wikimedia.org/T159895 .)

There's a pretty easy way to get pretty good statistics. Open the recent changes page. Show Human edits, filtering bot edits and logged actions. Manually change it to display the last 5000 edits (the maximum). Then just search the page for (Tag: Visual edit). I suggest using Chrome, as the ctrl-F search displays how many hits there are.

Here's a link for Polish recent changes.

On EnWiki 2% of edits are VE edits.

Since you're focused on Polish, I'll give a detailed breakdown of my findings on Polish.

• 10% of all edits use VE.
  • 6% of registered-user edits use VE.
  • 43% of IP edits use VE.(*)
• 8% of 'Very likely good' edits use VE. (Using the new automated scoring system.)
• 12% of 'Very likely problem' edits use VE. (Using the new automated scoring system.)

(*) Note: Polish is one of the few Wikis converted to have only have one edit link, dropping IP editors directly into VE. So after VE loads, a majority of IP users are actively taking steps to get out from VE. Based on the overall figures it's pretty clear that this IP percentage largely represents who haven't yet learned how to escape from a bad default setting, and that they largely switch as they learn they can do so. In fact some IP editors have found their way to Polish's version of Village Pump to complain that the default needs to be changed to wikitext.

Hmmm, not sure if this way would really be representative, as percentages could be dramatically different every time you check. Plus you'd have to exclude namespaces where visual editor doesn't work at all. Plus, recent changes would still include all kinds of administrative tasks that are neither code nor VE edits (yet are not marked by any special tag), such as rolling back vandalisms and bad edits (which happens a lot on pl.wiki since we have reviewed versions on), code cleanup scripts, adding categories using HotCat (enabled by default on pl.wiki), semi-bot edits (such as this one) and perhaps many others. But still, it seems like a decent basic stats prosthesis until we have anything better, but one has to bear in mind that the results may vary considerably. I'll fiddle with the method for a while.

As to other stuff you mentioned, that's not how single edit tab works on Polish wiki. Basically every IP editor is asked whether he/she wants to start with VE or Code editor, it's a simple window with two buttons, you either chose the VE or code editor. So your assumption that 43% of IP editors simply don't know how to escape from VE is both wrong and unfounded. Wrong, because you have to manually pick the editor you edit with. And unfounded, because you assume that what every single IP editor truly wants is editing the code. For registered Wikipedians the default is "last used editor".

you assume that what every single IP editor truly wants is editing the code

I just saw this, as well as your claim on PolishWiki that I was trying to "exclude VE". I insist you strike that claim on Polish Wiki.

I don't know if you misunderstood the discussion there (and at phabricator T159032), or if you are knowingly making a strawman of my position. I am not trying to exclude anyone from using VE.

The issue is which editor loads first. The issue is which popup button goes to which editor. The "Continue editing" button continues in the first-loaded editor. The "Switch" button loads the other editor.

Jdforrester gave repeated assurances that the Wikitext editor would load first. Then he made it into a battle. Several of us on EnWiki had to go to the Executive Director over this issue. We had to write a patch for the site-wide javascript that would reverse it.

English Wiki is now set to Wikitext first, and the switch button goes to VE. Polish Wiki is set to Visual Editor first, and the switch button goes to Wikitext.

Having Wikitext-first gets to the popup faster - sometimes a LOT faster. The editing statistics clearly show that the vast majority of users end up preferring Wikitext. The WMF's research on VE shows that it provides no benefit for new users. People who prefer VE can choose it, but the first-load default should obviously be the one that better serves the vast majority.

@Alsee, nothing to strike out there I believe. Here's my speedy translation of the relevant part:

Now seriously, I took part in this discussion only because someone on Phabricator tried to present the couple of voices above as a consensus of Polish wiki community in favour of turning VE off. As far as I'm concerned, there's no such consensus, and such a change would be for worse, especially that it would be based on bad data (such as your alleged list of VE errors, which turned out to be 100% unrelated to VE.

In context (the entire thread) it's pretty clear that it doesn't really matter what your proposal was, I merely explained why did I take part, the context explains what "turning off" means. I can put a footnote there if you please, but it wouldn't really matter I believe.

From what I understood, your proposal was to stop forcing people to chose VE as the default editor. I say done, case closed, as nobody is forced. A nice little window appears asking people which one do they want. Same as on en.wiki I believe.

However, since your proposal apparently is to change whichever editor is used as a background image for the window where one chooses which editor to load, I'd say we need some more recent statistics. Not based on a version from two years before, and not based on - apparently flawed - recent histories. If the main argument is speed - then we need to measure it. If the main argument is popularity - we need to know what exactly it is. Same problem as using the discussion at Polish Wikipedia's technical support as consensus for anything: we have a list of bugs, barely any of which are related to VE, but it's hard to make any decision based on that. In short: we need ee dashboard.

I'm not sure where you got "turning VE off" from. Perhaps the phabricator task was unclear because it was aimed at developers familiar with SingleEditTab, perhaps something got confused across the English-Polish translations. However I would appreciate it if you did strike out (or otherwise correct) your misunderstanding that "someone on Phabricator tried to present the couple of voices above as a consensus of Polish wiki community in favour of turning VE off".

I also didn't quite call it a 'consensus'. I recognize that it was an informal discussion. However given that the discussion was unanimous (until you objected based on a misunderstanding), and given the minimal difference between swapping the two popup buttons, and given that the WMF already acknowledged community consensus on EnWiki would be Wikitext Primary, and given that there is a clear case for one side and zero counter argument(*), I really hoped the WMF wouldn't pointlessly battle over it.

(*) Saying the percentages might be off by a few points is not a counter argument when it doesn't change the result.

I have one key question for you. What do you expect the result to be if a Formal Consensus is established on Polish Wiki? I'm not a Polish-local, but I would estimate 75%-95% consensus in favor of loading Wikitext first. Do you have a good faith belief that the result will go in the opposite direction?

Alsee, I can't add footnotes specifically for people who don't read the entire thread and instead prefer to take my comments out of the context. From the entire discussion it's clear that by "turning off" I meant what was mentioned above a couple of times, not "turn it off completely". OTOH you wrote that you stumbled across a Polish wiki request open unanimously requesting this change and that Polish wiki should clearly be changed as a community request, both of which were false. You did not call it "consensus", but you did mention "unanimous support" and a "community request". Which is basically the same thing, isn't it. So in the end it's a good thing I got involved and let everyone know.

As to your other questions - I believe in order to make an informed decision, we need current, verifiable data. Not someone's interpretation of data from way back when. For instance: in 2015 apparently VE loaded much, much slower than code editor. Is the difference still significant? Cause if it's not, then it's what we call a storm in a glass of water. If it is however, then perhaps such decision should be taken. Another issue: what percentage of wikipedians use Visual Editor? Unless we know that, we can't really decide, can we. And your method, while tempting, has obvious flaws. Which means the percentages might be off by 50% for what it's worth, we simply don't know.

I have a good faith belief that a) the problem is basically non-existent and b) we have no data to base a decision on.

For instance: in 2015 apparently VE loaded much, much slower than code editor. Is the difference still significant? Cause if it's not, then it's what we call a storm in a glass of water.

It's more than significant, it is serious.

I'm surprised that you weren't aware. This is one of the reasons everyone else in the discussion considers the SingleEditTab-default to be an important issue. VE is very sensitive to the size of the page, and some users are more severely impacted than others. Using the article en:United States as a test case: The Wikitext Editor just gave me a load time of 3 seconds, Visual Editor just gave me a load time of 40 seconds. That is not the worst case. Many people have been reporting browser time-out errors and load times upwards of two minutes on our largest pages. The WMF is well aware of the issue.

This isn't a tempest in a teacup. The storm threatened to engulf the house. The EnWiki community wrote, and would have deployed, a hack for the sitewide javascript to override the SingleEditTab default. There clearly would have been consensus to deploy the javascript, and the WMF didn't want to repeat the Superprotect incident, so the WMF finally agreed to fix the default on their end. Phabricator T159032 is entirely about the fact that it was only fixed for EnWiki.

If a formal Polish Wiki RFC is opened, do you have any good-faith belief that the result would be anything other than support to set Wikitext-primary?

Well, I'd love to see some stats on that too, especially for some average article, not the longest and heaviest article on any Wikipedia (do you really believe that the extreme is a good test scenario in this case? the article is 97kb long! it's 15600 words of readable prose, excluding the references!). But let's stick with the extreme example for a second.

First of all, you should decide if it's the single edit tab at stake here, or the VE in general.

Using external tools it seems both VE and CE load in under 3 seconds (1.97 vs 2.71) but I guess the results are flawed by the fact that the article's semi-protected (whatever crawler they use, it's highly unlikely it is registered and auto-confirmed). So let's take another scenario, the article on Plug-in electric vehicle. It's not identical, actually it is even larger: more tables, 21k words of readable prose, 130kb, but it's unprotected - and an anonymous editor could open it up. The results are... 1.69 s vs. 1.99 s.

See what happens there? Both measure not the editor loading time but rather the Single Edit Tab window pop-up time. Which is what really matters here. If you (as an anonymous user, obviously) chose CE at that point, it would take another couple of seconds for the CE to load. It seems the longest step here is the decision time, not the loading of the Single Edit Tab window. Sure, if you chose to load the VE, it would take more time to load, since it's more resource-intensive. But since you believe an average user prefers the code editor, they would chose it anyway. Also note, that from that point the difference between Polish and English Wikipedias would be negligible: since CE loads fast anyway, it would probably be 3 seconds on en.wp and 5 on pl.wp. Not a big deal, if you asked me.

As to your underscored question - sorry, I left my crystal ball in the other jacket. But of course there would be plenty of people voting against anything related to any gadgets or innovations, whether they influence them or not, whether they understand them or not. Which is also why I would rather see some better statistics than base the decision on data from years ago.

1. First of all en:United States was not an extreme test. The United States article is representative of some of our most important, most viewed, and most edited articles on core topics. We did do "extreme" tests with our largest article, VE generated browser errors and load times over two minutes.
2. Your en:Plug-in electric vehicle tests unsurprisingly got  1.69 s vs. 1.99 s because you tested the Wikitext editor both times.
3. You should have noticed that tools.pingdom.com is giving you garbage data. VE's loading problem is because the freakish javascript causes the browser to choke and freeze any screen rendering. Most testing sites, including tools.pingdom.com, assume the extended lack of screen updates means the load completed. They quit the test early when VE freezes the screen. That's why the screen capture in 2.71 shows that VE hasn't loaded. In other tests you'll often get a test-quit with screen capture showing VE's blue progress bar frozen part way through.
4. You grossly disregarded the fact that stated I had just gotten hit with a 40 second load time on United states, and lots of other people have recently reported similar times for the same article. 30 seconds, 75 seconds, various different times, but consistently seriously worse than Wikitext. People are in fact experiencing gross problems, and you don't care. It doesn't exist if it contradicts your agenda here.
5. It's hard to find online sites that can actually test VE's gross loading behavior, but here's some that I found:
   • I put VE-mode Plug-in electric vehicle into Google's testing site. It turns out this site doesn't report exact times, but that doesn't matter. It was so slow that Google's test site crapped out with a time out error "Uh oh! Your site took too long to analyze". Google rejects VE as unusably slow for testing, much less for actual use by humans.
   • Monitis speed test reports over 25 seconds for Plug-in_electric_vehicle in VE.
   • Gtmetrix test site managed to get to 16 seconds before it quit. The screenshot shows significant load time remaining on the frozen progress bar.

First of all : https://xkcd.com/882/.

In any case, Halibutt is quite right here that interpreting those results without a good insights into the overall data will lead to incredibly inaccurate findings, just like the xkcd above.

By looking at VisualEditor tags one will be mislead into misinterpreting the difference between wikitext and visualeditor edits. Aside from the information already shown in this thread, people could be editing using a fully featured desktop application without ever coming to the site, so simply looking at recent changes makes 0 sense, because, as academics often say, there are too many nuisances that may invalidate anything recorded. A simple example is this very thread in which many people are in essence using VisualEditor (within flow) but this will not be reflected in recent changes.

Some claims about the average time these articles take to load will also be quite inaccurate because with more than 1 million articles the chances are that most edits will be to an average sized article that is less than 1 / 4 smaller than pages like United States or  Plug-in electric vehicle( see Normal_distribution ). There is also the fact that these devices don't have the same level of caching as this test shows(Ehrenamt). The second view (repeat view) is somewhat faster due to less downloaded assets.

Here are some simpler non-representative analysis, and the number 3 row shows the data one of the largest (within top 10000) pages in de.wiki :

#	Page	Time taken (VE)	WE
1		35.827s
2		30.995s	8s
3		8.244s	2.435s

A bit of digging reveals that Wikimedia actually keeps tracks of the average save and load performance of visualeditor (and probably other editors too), see :

https://grafana.wikimedia.org/dashboard/db/visualeditor-load-save?refresh=5m&orgId=1&from=1480768910426&to=1496493530426

According to them the averages for 8 million edits and 1 Million saves between 2016/12/03 -2017/06/03:

Time (average)	VE Load	VE Save
API	691ms	1.50s
restbase	878 ms
Total	2.57 s	1.50 s

It might be interesting though to ask analysts to verify distribution and average size (html & wikitext) of articles that are regularly edited.

It looks like you should probably change 30.995s to 33.143s, and change 35.827s to 39.008s. The site webpagetest.org says those are the figures until the page is loaded to an interactive state. That's probably what we're looking for here.

I have to wonder if the grafana dashboard is giving accurate timings from first edit-click until actual interactive state. Those numbers don't look right, unless loads of edits to very small pages are pulling down the average. Now that I consider it, Flow is probably included in there deceptively pulling the numbers down a bit more. Flow edits are almost all effectively edits to new blank pages. (Question: Do Flow's simulated-wikitext edits get falsely counted as VE edits? I suspect they would.)

It's hard to pin down data on VE load times, especially given how variable it is for different pages and how variable it is based on individual hardware and software. However from a more general "user experience" perspective, it seems to be EnWiki common knowledge that VE load times suck. In fact there was a Village Pump consensus that it would be an blocker to replace the Wikitext editor with a Wikitexte-mode-inside-VE, specifically because it would be intolerable to have those sorts of load times on our primary (wikitext) editor.

I believe the general view is that VE is fine as a secondary editor, and that anyone who chooses to use the secondary Visual mode is accepting all of the inherent pros and cons that come with it.

Alsee, I'll get back to you a little later. Just a quick remark: it's no wonder Google's testing site crashes. It tests mobile friendliness. In other words, you're trying to force a mobile browser to interpret a desktop-only editor. Want to use the tool - try the mobile editor link. But then the tool only checks the first step, until the "you are not logged in" landing page (which is a similar case to measuring time until a SingleEditTab window pops up), but is unrelated to the issue at hand.

Similar problem with GTMetrics: following your link and re-testing I got 9.5 s, and no mention of any crashes (the automagic screenie shows the page loaded halfways through, but that doesn't really prove that the page didn't load for them, does it - neither does it explain what exactly was the state they reached in the end. Was it the article opened in VE? Was it the single edit tab popup?.

Just a quick remark: it's no wonder Google's testing site crashes. It tests mobile friendliness.

Google runs separate tests for desktop and mobile. I ran the test a few more times, and it seems the VE load time for that article is right at the edge of Google's time-out error limit. Google rejects it about half the time. When it does complete the test and return a report, it takes about 42 seconds. The report doesn't say what the page load time was, but it only takes 13 seconds to give a report about a fast web page. That strongly suggests it spent about 29 seconds loading VE. That would fit perfectly with 30 seconds for the time out error.

with GTMetrics: following your link and re-testing I got 9.5 s, and no mention of any crashes (the automagic screenie shows the page loaded halfways through

There were no crashes. VE runs a freakish huge javascript process. This chokes the browser. VE's blue loading bar should to fill smoothly, but the browser is too overloaded to do regular screen updates. The blue loading bar freezes and randomly jumps forwards with each screen update. When the screen doesn't update for a long time, the test site (incorrectly) believes that the page finished loading. It terminates the test and it gives you a terminal-screenshot.

You got a 9.5 second result, and a picture of VE's loading bar, because the test site didn't see VE drawing anything new onto the screen. It mistakenly quit when VE was about 1/3 loaded.

If you run the test multiple times you will get wildly different load times, each one showing VE's blue loading-bar progressed by different amounts.

But instead of fussing over specific test cases, can we just summarize 'yes, there's a serious load time issue'? It's considered common knowledge on EnWiki. A lot of people consider VE substantially unusable, and a lot of people get worse than average load times. VE is an order of magnitude slower on mid to large articles.

Some people do prefer VE, but it's a very small minority. (And load time is not the only reason for that.)

As to the Google site, what you write would suggest that the crawler they use is... logged in with a Wikipedia username and has VE set as default. Otherwise it would test not the VE loading time but the SingleEditTab window, that spawns for anon users. Same goes for all the other external testing sites.

As to common knowledge, sure, a lot of people say the earth is flat. Experience may vary. My experience too confirms that the wikicode editor is quicker to load (especially in longer articles) while VE is quicker to work with. It's all a matter of taste, personal preferences, your browser settings, your user scripts and a plethora of other things. That's why I'd love to see some more objective test results, to know how much is really dependent on the VE itself. Especially that it seems that approximately half of the VE loading time is actually loading the article itself the way it is loaded without clicking the edit button. For such a heavy article it takes some time to load.

But from your words I understand that the issue at hand is related to SingleEditTab, and not VE or wikicode editor at all. Which is what all of the external tools seem to check. And apparently we have no tools - apart from grafana - which show us what happens after the anon user picks his choice in the Single Edit Tab window.

Finally, it seems from the tools you proposed, that the SingleEditTab is not a problem here since the time difference between SET showing in VE link and Wikicode link is usually up to 3 seconds for such a huge article. Let's use Pingdom for a second: they say raw article takes 1.22 s to load (weird, for me raw articles never load that fast, more on that later). When I use the code editor link, the time measured is 1.03 s, the VE link gives 1.51 s. Using webpagetest.org (3 tests for each link, Firefox browser), I get between 6.4 and 9.2 s for the article itself, 2.5 to 2.8 s for the Wikicode editor link and 2.6 to 5.4 s for VE link.

Of course the tools apparently check the SingleEditTab window loading time, not the editor loading time (I mentioned that before) and every time I checked the result was a little different - and the results in Pingdom were nowhere near what I'm experiencing. Sure, there is a serious load time issue after you pick VE as the default editor, but we'd also have to bear in mind that the page itself has a loading issue. It's huge, when I use a stopwatch and open the link to the article in a new window in incognito mode, the article itself takes some 11 seconds (give or take 2 s) to load (which is consistent with webpagetest results shown above). Should we substract that from the overall VE loading time for logged-in users who set VE as their default? Does it influence the SingleEditTab loading time? We don't actually know, do we. We don't even know how small the VE minority is, or whether it actually is a minority. Plus what @197.218.81.134: wrote above.

All in all, the purpose of this topic was for me to ask for some better stats. @ Whatamidoing (WMF) pointed me in a good direction, let's see where it gets us.

Halibutt please stop. I explained that you are posting invalid data. Maybe I explained it badly. Maybe there's a language barrier. Maybe you didn't carefully read my post because you dislike my position on the SingleEditTab default. But all of the data you posted is worthless.

1. Log out.
2. Clear Wikipedia cookies from your browser. This is necessary.
3. Go to the Polish Wikipedia article for United States.
4. Attempt to reach the Wikitext editor:
5. Click edit
6. Watch VE loading bar. Watch VE loading bar. Watch VE loading bar. Watch VE loading bar.
7. SingleEditTab popup appears.
8. Click the "Switch" button.
9. Wikitext editor loads almost instantly.

The result is half a minute, and much worse for many users.

The problem isn't VE. VE load time sucks, but if you want to edit visually then you get all of the pros and cons that come with it.

The problem isn't SingleEditTab. SingleEditTab imposes almost zero delay when it's it's configured Wikitext-Primary.

The problem is setting a VE-Primary default on SingleEditTab. It pointlessly, disruptively, and borderline-maliciously sabotages the wikitext editor. It pointlessly, disruptively, and borderline-maliciously sabotages the vast majority of users.

Phabricator task T159032 would fix that problem. It gives unhindered access to both the Wikitext Editor and Visual Editor, without imposing any unnecessary delays.

Alsee, stop what exactly? My result in the test you described above was between 5 and 8 seconds for the SET window to load (4 tests). Not half a minute. And then 7 seconds for code editor to appear (unless I chose VE, which then loads instantly). I can record a screencast for you if you don't believe me.

But still, it is not data. It's anecdata: my experience is drastically different than yours, it's hard to judge the library by two randomly-chosen pages. Unless we know whose experience is closer to the experience of an average user opening an average article, we can't really tell that, can we.

All I really ask for is some reliable data, which apparently neither of us have access to. Why exactly should I stop that?

Alsee, stop what exactly?

All of the online VE test results you've posted have been faulty, and you should have spotted it. Especially after I explained why the first set you posted were faulty. Here are the last two you posted:

• In one you said you got 2.6 to 5.4 s for VE link. If you had checked the screenshot you'd have seen that the wikitext editor loaded. You gave the test site a broken URL. The Wikipedia link you used contained &veaction=edit&action=edit. Wikipedia.org happened to resolve that broken URL as the Wikitext editor.
• For the other you said the VE link gives 1.51 s. If you checked the screenshot, you'd have seen the VE loading bar. The test aborted early. I explained this problem with the earlier tests you posted, and you repeated it. The massive javascript chokes the browser. The browser can't find enough CPU cycles to update the screen. The blue loading bar stalls. The screen isn't changing so the automated test site assumes loading is finished.

My result in the test you described above was between 5 and 8 seconds for the SET window to load (4 tests).

That would be much more tolerable load time, though still significantly slower than the consistent 3 second loads I get for Wikitext. BTW, the test I described was to get to the Wikitext editor, so I guess you're saying 9-12 seconds to go through SET to Wikitext. (1 sec to click Switch, 3 to load.)

I tried around 8 or 9 online online testing sites, and none of them can reproduce the loading times you report. Monitis reports 21s and 25s. Every other online test site craps out early showing a stalled loading bar. Gtmetrix shows the loading bar was still up at 16s.

My best VE load time for that article was 15s, and my worst was 70 or 80 seconds when the system particularly choked on the heavy javascript.

I have an odd question. Do you have a Mac? That might explain a lot. A bunch of recently collected community-reported load times all resemble my load times, and there's a weird pattern where only people working for Wikimedia report lowish load times. One theory floated is that staff almost all use Macs. I doubt any of the web testing sites run Mac, so that theory would fit with them all choking on VE.

That's the link I copied from my browser window. Sure, we can change it to this one, I get 12-15 then. Still, we have no idea what the test shows. For the other one, you assume that the screenie shows that the engine crashed. I don't know that, you don't know either. It could be an automatic screenie scheduled to show the site 3 seconds into the operation, no matter what, for all I know.

so I guess you're saying 9-12 seconds to go through SET to Wikitext. (1 sec to click Switch, 3 to load.)

Yup, probably even longer as it depends on clicking time, on whether I use keyboard or mouse or touchpad, on a plethora of other factors. Yes, SET window is a major unknown here as well.

As to the test you proposed, I'm glad you see your experience might not exactly be typical. Or mine, for that matter. We simply don't know, do we. But since you might get an impression that I'm lying here, here you go with my tests:

• 7 seconds til SET (going for code)
• 5 seconds til SET (going for VE)

I tested it a couple more times, both on Chrome (clean install just to record the screencasts) and Firefox (my go-to browser), all results were consistent. All tests on a laptop PC, Win10 x64, unboosted (battery mode), Wi-Fi connection to a very old router (speedtest.net gives me between 15 and 17Mb download and about 10 MB upload speed, ping to their nearest server is 8ms). Sure, I guess the machine I use is rather on the higher end of the spectrum (6GB RAM, i7 processor; not sure if 6GB is average these days or not), which might probably influence the outcome, I don't know. I guess experience on a 2GB RAM machine or weaker might be diametrically different. Or a Windows 3.1 machine. Or not different at all. But I definitely don't use Macs, they're way above my price range. :)

you assume that the screenie shows that the engine crashed

I never said anything crashed. I explicitly said There were no crashes.

Different test sites use different methods to try to detect when the page is done loading. The test sites deliberately end the test when they think the page is done. VE is not a typical website. Automated test sites have difficulty identifying when VE has finished loading. They end the test too early.

Webpagetest.org is a very good site because you can view a slideshow or video of the load. Ignore the video, it ends too early. Ignore the default-mode filmstrip, it also ends too early. You need to set the filmstrip's "Comparison End Point" to "Fully Loaded". I'll give you direct links for filmstrips:

• For Tammese, a tiny one sentence article:
  • Median test run to Wikitext without a SET popup, the edit area goes live at 1.6 seconds.
  • Median test run with SET popup and Wikitext primary, the popup begins to appear at 3.3 seconds. (This is the same filmstrip as the 'without SET' above.)
  • Median test run with SET popup and VE primary, the SET popup appears 4.2 seconds.
• For Plug-in_electric_vehicle:
  • VE median test run continues up to 27.5 seconds, and VE's edit-surface still hasn't appeared.
  • Wikitext median test run the edit area goes live at 4.4 seconds. (The filmstrip continues until 11.9 seconds due to irrelevant background activity.)

I'm glad you see your experience might not exactly be typical.

We don't know what the media experience is, but that doesn't matter. What matters is that we have enough reports to know that my experience and your experience are both reasonably common. The load time is a problem, regardless of whether 30% or 70% of people share my experience.

My computer specs are very similar to yours. I have a desktop, 6GB RAM quadcore x64 AMD Win7 with good broadband internet. There are a lot of people out there with significantly lower computer specs, especially in the Global South. The Global South is a priority userbase we want to reach. One of the community reports, I think from the Global South, was 13 seconds to load United States in Wikitext and 75 seconds to load it in VE. The 13 second wikitext time strongly suggests limited bandwidth, and the 75 second VE time strongly suggests limited CPU/RAM in addition to the bandwidth delays.

EnWiki reached almost 90% formal consensus to block VE's wikitext mode as a replacement for our primary editor because of load times. And VE's wikitext mode has faster load times that ordinary VE. These load times are not acceptable in a primary editor, even if 30% or 70% of users share your experience.

> It's hard to pin down data on VE load times, especially given how variable it is for different pages and how variable it is based on individual hardware and software.

Looking at the grafana dashboard one would note that it includes a median and a "p95" which is likely the 95  (of 8 Million sessions) meaning that 95% (and lower) of VisualEditor loads take less than 18 seconds (max 31) and the median is around 2.88.

> I believe the general view is that VE is fine as a secondary editor, and that anyone who chooses to use the secondary Visual mode is accepting all of the inherent pros and cons that come with it.

It varies per wiki. The more complex markup used on wiki pages, the worse the performance will be, and the more likely it is that the wiki will make heavy use of logged out bots and that significantly distort the statistics (it might be worth having a tag for API edits).

One interesting statistic they seem to have is for the Portuguese wikipedia, which for example, seems to have had an anomaly at one point indicating that more than ~34% of all edits were made using VisualEditor (Quarterly_Review_slide_deck,_2016).

Looking at the grafana dashboard one would note that it includes a median and a "p95" which is likely the 95 (of 8 Million sessions) meaning that 95% (and lower) of VisualEditor loads take less than 18 seconds (max 31) and the median is around 2.88.

The results on that page are pretty much garbage for tracking actual user-experience load times. They're only really good for catching spikes, like if there's a bug in the latest deployment. The data being collected there doesn't track VE's full load time. If you examine a VE load for a tiny one sentence article, the final web request is en.wikipedia.org/beacon/statsv?ve.mwTarget.performance.system.restbaseLoad=60ms&ve.mwTarget.performance.system.apiLoad=366ms&ve.mwTarget.performance.system.activation=2108ms reporting 2.108 second load time back to the server. If you check the filmstrip for that load, you'll see that VE doesn't reached a usable state until at least 3.9 seconds. The true load time is at least 1.8 seconds higher than the stats being collected. That is a massive 86% error.

If you look at this run, the final web request is en.wikipedia.org/beacon/statsv?ve.mwTarget.performance.system.activation=20556ms reporting 20.556 second load time back to the server. If you check the filmstrip for that load, you'll see that VE has not reached a usable state at 35 seconds. The true load time is at least 12.5 seconds higher than the stats being collected. That is at least 70% error.