Jump to content

Wikipedia talk:VisualEditor/Archive 4

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 2Archive 3Archive 4Archive 5Archive 6→Archive 8

With this you will conquer the world.

Really. I've been waiting for this forever. Not for me, but for other humans. 77.49.33.110 (talk) 10:24, 18 July 2013 (UTC)

Don't you mean == With this|}
you will conquer the world♙ --108.38.191.162 (talk) 19:17, 18 July 2013 (UTC)

A/B test results

What were they? Adam Cuerden (talk) 23:41, 12 July 2013 (UTC)

Presumably they will be posted at meta:Research:VisualEditor's effect on newly registered editors whenever they are available. I assume that if there had been anything really dramatic in there, that we would have heard about it already. Whatamidoing (WMF) (talk) 01:24, 13 July 2013 (UTC)
Can you post them here please.-- Clem Rutter (talk) 13:16, 13 July 2013 (UTC)
They will be posted to the meta page, and also to the enwiki subpage on quantitative data. I have asked Philippe for permission to do so, and am waiting for his response. Okeyes (WMF) (talk) 14:49, 13 July 2013 (UTC)
Just to confirm, does this means that the results of the A/B tests have been finalised, just not made publicly available? - Bilby (talk) 12:57, 14 July 2013 (UTC)
The results are known but need to be written up, basically. Okeyes (WMF) (talk) 13:07, 14 July 2013 (UTC)
No problems. It's just that I was told that they would be considered before rolling out VE to IP users. - Bilby (talk) 13:11, 14 July 2013 (UTC)
You say the results are known. Point-blank question: Are any of the results negative for VE? If so, which? Adam Cuerden (talk) 09:29, 16 July 2013 (UTC)

Part of the results are now apparently available here: meta:Research:VisualEditor's effect on newly registered editors/Results. Summary of the results:

It appears that issues with VE that prevented newcomers from using it to complete edits had a significant effect on the experiment and the analysis. Newcomers with VE enabled performed less wiki-work and spent less time editing overall. They were also less likely than users with the wikitext editor to eventually save an edit.

--WS (talk) 15:15, 19 July 2013 (UTC)

Enable visual editor for me

When I go to https://wiki.riteme.site/wiki/Special:Preferences#mw-prefsection-editing , I do not find the "Enable VisualEditor" option. Whenever I edit an article, I am still taken to the old editor. विश्वासो वासुकेयः (talk) 04:38, 19 July 2013 (UTC)

Do you have an older computer? Does Javascript work for you? VisualEditor requires Javascript and does not work on some, usually older, web browsers. Whatamidoing (WMF) (talk) 16:03, 19 July 2013 (UTC)

Can there be an option to make Edit Source permanently visible for sections?

Tracked in Phabricator
Task T52540

I usually want to edit the source. I am a programmer and find it easy to work with the wiki source.

It slows things down when you have to keep waiting for the "edit source" link to come up.

If you click Edit by mistake, easy to do, then the "edit source" never appears and you have to go back and refresh to see it again.

I understand that most users probably don't want "edit source" to be always visible. But can it be an option in the preference tab? I.e. to set the time out before it appears to zero.

When always visible, is it possible to make it visible also after you click on Edit (I can understand if this second request is programaticaly hard to do, just mentioning in case it happens to be easy).

Thanks. Can't really comment on the visual editor as I use edit source so far, but glad you are making the tool available for users who want this feature, and I may find it useful too some day. Robert Walker (talk) 17:31, 10 July 2013 (UTC)

Adding the following to your personal CSS page will disable the animation.
.mw-editsection-link-secondary { visibility: visible !important; }
.mw-editsection-divider { visibility: visible !important; }
.mw-editsection-bracket { visibility: hidden !important; }
It has the side effect that the bounding brackets, i.e. [ ], no longer appear on pages editable with the Visual Editor, but personally, I regard that as an acceptable loss in order to remove the annoying animation. Dragons flight (talk) 18:15, 10 July 2013 (UTC)
Thanks Dragons flight, that fixed it, great help!
I realized after my post here that I misunderstood how it worked. I thought it was a time delay. Actually it appears instantly when you hover the mouse over the title of the section or the edit link.
So was usable after acclimatization. Still meant that instead of clicking straight on the link you move the mouse to hover over the title first and then click with a kind of zig-zag motion. Is much simpler for source code aficionados to have it visible all the time :). The []s are fine by me :). — Preceding unsigned comment added by Robertinventor (talk • contribs) 18:33, 10 July 2013‎
Thanks also! Now how do I get rid of visual editor altogether? LOL. -- Jodon | Talk 18:48, 10 July 2013 (UTC)
The easiest way to bypass VisualEditor is simply to click on the [Edit source] link whenever you want to edit a page.
There is also a way to hide VisualEditor's [Edit] button from yourself, in Special:Preferences under Gadgets. There is no way to truly "get rid of it", but since VE's initial set up is tiny (~2% of the page, maybe less now that Universal Language Selector is turned on), this is unlikely to be a significant problem for the typical editor. Whatamidoing (WMF) (talk) 19:58, 10 July 2013 (UTC)

Good to see this was already brought up. However, the seemingly clever thing where [edit] expands into [edit | edit source] is unnecessarily complicated and not a very good idea. Why not just get rid of it and have it always display as [edit | edit source], for everyone, regardless of whether they've set something in their preferences? The animation really should just be removed. I suspect it relies on javascript, so it may alienate users who have javascript disabled - and it's just confusing. It would be clearer what was going on if the timeout were set to zero by default. And then there are touchscreen users. The VFD of Template:Citation needed span had several keep votes that mentioned how using the regular template and indicating the unsourced text with mouseover text was a bad idea because touchscreen users would not be able to see the mouseover text. If touchscreen users cannot see the mouseover [edit | edit source] bit, it should be set to always display for this same reason that Template:Citation needed span was not deleted. Cathfolant (talk) 22:21, 12 July 2013 (UTC)

Something I find a real pain is that on my iPad, I have to make two presses to edit the source, because I am using VE "on an unsupported browser". -- t numbermaniac c 08:10, 17 July 2013 (UTC)

The text should really be two links [ Edit | Source ], both always visible. There's no need to have the now redundant "edit source" in the second link, that would be obvious after the first time the link is used, or reading the tooltip. Diego (talk) 14:01, 18 July 2013 (UTC)

Don't hold your breath. This is the current Bugzilla 50540 request, filed July 2 and last updated today. It also refers to an earlier request from June 15 that went mowhere. Iow...the techies don't care we can't edit properly because it's more important (to them) to use Java Script and popups and the rest of their rubbish, making it take forever to load even if you use a browser that works with it (e.g., Chrome for iPad). Because They Can. Looks like we're victims of a bunch of control-freaks who despise editors. 184.78.81.245 (talk) 19:44, 20 July 2013 (UTC)
The sad thing is that VE can't edit sections in the first place at the moment, meaning the default is nonfunctional. Adam Cuerden (talk) 20:27, 20 July 2013 (UTC)

Two percent

I have received further information about the 2%: that's two percent of the Javascript, not of the whole page, and it only happens on the first article you read. After that, it's in the cache (typically for a week). In other words, this is not actually going to have an effect that can be seen even if you're using a stopwatch to time your page loads. Whatamidoing (WMF) (talk) 21:40, 15 July 2013 (UTC)

That's good, but I still see no reason why not to let people turn VE off fully, when it was already coded. Could you explain why that was removed? Adam Cuerden (talk) 21:48, 15 July 2013 (UTC)
Hi Adam - that question was answered in the FAQ, I believe... "Why does no standard user preference to disable VisualEditor exist?". That's accessible from WP:VisualEditor/FAQ. I recognize that answer won't thrill you to pieces - and trust me, I wish I could give everyone the answers to questions that they want to hear - but the answer does exist on that FAQ. Thanks. Philippe Beaudette, Wikimedia Foundation (talk) 22:00, 15 July 2013 (UTC)
With all respect, that is a terrible, terrible answer. "We would rather make VisualEditor's availability through the UI interfere less with the experience of power users rather than introduce a new preference." - the preference had already existed for at least a few months. It was removed at time of launch. And "We hope to hear from users who could never imagine using VisualEditor as their default editing environment. [...] we highly appreciate your feedback on what improvements could make it so." - A gadget was made to get around the lack of preference. Your [WMF, not you] plan was well-meaning, but was clearly the wrong choice. Adam Cuerden (talk) 22:24, 15 July 2013 (UTC)

Sorry this leaves my head shaking "However, to encourage continued testing of VisualEditor as it develops, completely hiding it from the user experience will remain a non-trivial task." Doc James (talk · contribs · email) (if I write on your page reply on mine) 08:13, 16 July 2013 (UTC)

Ack. This is a bold move. The VE will remain in sight of its critics with every edit thy make. This will probably make them raise their opposing voices more loudly.-----<)kmk(>--- (talk) 23:46, 20 July 2013 (UTC)

On the idea

I believe the main drawback which reflects the fact that probably the developers did not edit Wikipedia themselves is the assumption that everything should be done from scratch. It is not so. In real world editing starts from copying an example and changing it to your needs. Copying and pasting should be the number 2 concern after math. From what I tried it does not work properly, for example references become just [1] instead of a reference. --194.44.219.225 (talk) 12:17, 17 July 2013 (UTC)

The team Product Manager has been editing since 2001. But, I agree, copy and pasting is something that needs work, and something that is actively being worked on. Okeyes (WMF) (talk) 15:19, 17 July 2013 (UTC)
194, your statement is true, but only for non-Aspies. This has been pointed out to WMF numerous times, including suggestions to include that (rather obvious) technique in the various How to edit materials, but Every Single Time the silence has been deafening - and that includes direct appeals to Jimmy Wales and Sue Gardner. Wikipedia has become of, for, and by Aspies. I think they see it as a major opportunity to make everyone else conform to their ways of thinking and doing, or get out so they can run it unimpeded. iow...deal with it and don't waste your time and effort complaining to them. All you'll get is their usual non-answer (see directly above). 184.78.81.245 (talk) 19:49, 17 July 2013 (UTC)
"We're fixing it" isn't a non-answer, imo. Can you give an example of an answer you'd find more acceptable? Okeyes (WMF) (talk) 20:23, 17 July 2013 (UTC)
Since when does "the WMF" write the community's own documentation? Any WP:AUTOCONFIRMed editor can change Help:Editing, and if you don't want to get an account, then you can use {{Edit semi-protected}} to request the changes you would like on its talk page. If you think that the editing documentation has a problem, then you should {{sofixit}} yourself instead of asking some manager or fundraiser to do it for you. WhatamIdoing (talk) 18:42, 18 July 2013 (UTC)
WhatamIdoing, I understand you already have your hands full here. Perhaps, taking a step back, you might see that the IP has a bit of a point about documentation. Your first sentence "Since when does "the WMF" write the community's own documentation?" is true, but then again, I can't recall a situation where "the WMF" has made a change that requires the rewriting of just about every help page created and curated over the last 10 years. I'm not griping about this; it's simply one more point to add to the "things we learned from this deployment that we might want to do differently" file. Help pages are hard enough to write using the language level and clarity that is needed for uninitiated editors, even when the author is very familiar with the subject matter; it's a lot harder when (a) people are just getting familiar with the new interface and (b) lots of things keep changing/improving, thus rendering yesterday's help page out of date today. I do hope that WMF folk are indeed tracking these sorts of issues. It took the community 10 years to build those pages; we can't afford to take 10 years to build the VE versions of them. Risker (talk) 02:33, 19 July 2013 (UTC)
In most cases, all that needs to be done is to copy the WMF-provided instructions from the WP:VisualEditor/User guide to the pages that the IP is concerned about, or to add a link to the VE documentation.
My point is that the IP has picked a silly method of trying to get this work done. I cannot imagine why anyone would expect the Executive Director or a Board member to do these things. This is about as silly as phoning the CEO's office at an airline because your baggage got lost: the CEO's office does not find lost luggage, and the Board's job does not include editing help pages. WhatamIdoing (talk) 16:07, 19 July 2013 (UTC)
Or provide a direct link (or a template) with "If you have come to this Help page needing help with a Visual Editor issue, please consult WP:VisualEditor/User guide." That at least would convey the information without having to rewrite all Help/Doc pages & could be a stopgap measure while WP is in this VE transition-phase... Shearonink (talk) 16:19, 19 July 2013 (UTC)
{{VE documentation}} is one such template. I don't know if others have been created. Whatamidoing (WMF) (talk) 23:24, 22 July 2013 (UTC)
Is this sarcasm? We might as well replace all help pages by RTFM.-----<)kmk(>--- (talk) 00:04, 21 July 2013 (UTC)
See Wikipedia:Village_pump_(proposals)#Visual_Editor_clashes_with_instructions_on_help_pages_and_the_like for a few editors who are trying to get and keep the ball rolling forward on this. –Quiddity (talk) 17:44, 19 July 2013 (UTC)
Here's a question: Is there any technical means to show different editing instructions to a VE edit than a regular edit? Adam Cuerden (talk) 17:55, 19 July 2013 (UTC)
I'm not quite sure what you mean. Within VisualEditor, you can get links to WP:VisualEditor/User guide (click the ? button next to "beta"), but outside of it, there's no way for the software to know whether your next edit is meant to be in the old editor or in VisualEditor. Whatamidoing (WMF) (talk) 23:24, 22 July 2013 (UTC)

Broken edit

I just made this revert. The probably incorrect change to the text aside, the code added was so broken that I didn't know what was intended. There was also an extraneous nowiki tag. Cathfolant (talk) 03:08, 20 July 2013 (UTC)

I've been doing the same over and over as of late. I've been reverting as test edits using WP:HG, which warns the user, before I finally realized this is a bug in the Visual Editor. I see the error more often with simple wikilinks, the user makes a change somewhere near the link and it mysteriously wraps a nowiki tag around the link. Not good. This has to be fixed. — MusikAnimal talk 18:04, 22 July 2013 (UTC)

Web Content Accessibility Guidelines

I've made the following change pending discussion of the issue.

First, do the Web Content Accessibility Guidelines require that all tools be equally accessible to all users? If not, is there a reason why the inability of some users to access one aspect of one would "put Wikipedia in violation", particularly when they can still edit the page using the "edit source" tab at the top of the page? If so, are all other tools already equally accessible to all users? If not, then VE would not be the tool that "put Wikipedia in violation." --Maggie Dennis (WMF) (talk) 17:59, 21 July 2013 (UTC)

Can we keep this discussion in one place? Wikipedia:VisualEditor/Feedback#VisualEditor_causes_Wikipedia_to_violate_the_Web_Content_Accessibility_Guidelines. Adam Cuerden (talk) 18:02, 21 July 2013 (UTC)
Sure. This is the page for discussing changes to this document. That is the page for bringing issues to the attention of developers. --Maggie Dennis (WMF) (talk) 18:03, 21 July 2013 (UTC)
Fine. I'll copy this here: For examples of specific requirements broken, [1] [2]. Obviously, the requirements are written in general webpage terms, not wiki-specific ones, but it's clear that this violates both.
The nature of this project may make some WCAG guidelines more difficult to fulfil than others, but there's absolutely no reason to violate them to no benefit. VE can't edit sections, after all, it has to load the whole page. Adam Cuerden (talk) 17:41, 21 July 2013 (UTC)
(edit conflict) ::::The question isn't whether it is best practice - the question is whether all tools must be in complaint to avoid "putting Wikipedia in violation" and, if so, whether all other tools are already compliant. If not, the expression of the issue is incorrect. --Maggie Dennis (WMF) (talk) 18:14, 21 July 2013 (UTC)
That's semantics, at best. That aspect of VE, at the very least, puts Wikipedia far more in violation. If that's your only objection, we can change "this puts Wikipedia in violation" to "this is a violation", since it unambiguously is, no matter how many other violations you can find, and this is relevant as Wikipedia has committed to try and uphold said guidelinesAdam Cuerden (talk) 18:18, 21 July 2013 (UTC)
(edit conflict) How do you know that it at the very least does this? :/ That's a pretty sweeping statement to make without evidence. So far as I can tell, every time I mouse over a wikilink I am encountering this. In terms of it putting it in violation, while I'd prefer to hear from more people familiar with that, I note that both of the links you give say, "If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance." That would seem to make discussion of whether or not this violates it sensible. (Discussing the semantics of the page is entirely appropriate - determining the meaning of what we are saying is a critical method of getting it tight.) --Maggie Dennis (WMF) (talk) 18:25, 21 July 2013 (UTC)
There is literally no accessible way to edit a single section under VE, so it's not satisfied in some other way. Adam Cuerden (talk) 18:30, 21 July 2013 (UTC)
No one has a way to edit a single section under VE, Adam. It's just a section-specific link. --Maggie Dennis (WMF) (talk) 18:32, 21 July 2013 (UTC)

I don't want respect because I work for the WMF. I want to have the kind of thoughtful conversation we're supposed to so that we can reach WP:Consensus. It's not my desire to turn this into a battlefield, but simply to ensure that we get this right. If this is a "violation of the Web Content Accessibility Guidelines", then, well and good. But that needs to be established before we publish it. We have all recently seen how much excitement can be generated by adding content here that is mistaken. --Maggie Dennis (WMF) (talk) 18:47, 21 July 2013 (UTC)

I have, after discussion with her, removed a comment I completely retract. I also am satisfied with the current revision - after all, there's a lot of interpretation to be done to apply the WCAG guidelines to Wikipedia. I thank Maggie for her patience and work towards this satisfactory conclusion, and apologise that I didn't quite understand the nuances she was going for. Adam Cuerden (talk) 18:53, 21 July 2013 (UTC)

On a related point, some of the complaints on the page now amount to "The current version is the desktop version! The mobile version has not been deployed yet!"

Last I heard, having a separate mobile version did not violate any guidelines, and there was no requirement to release all the versions at the same time. Has anyone else heard anything different? (There is a separate version being worked on for mobile users, and, no, it won't require any sort of hovering.) Whatamidoing (WMF) (talk) 23:29, 22 July 2013 (UTC)

If you're talking about hovering not being available in tablets, that's irrelevant to the fact that there's currently no accessible way to edit single sections with the source editor in the desktop version (except by using the unsupported CSS workaround) - that function is off-limits to disabled users, who are forced to edit the whole page. Diego (talk) 10:18, 23 July 2013 (UTC)
Technically, VisualEditor doesn't edit sections at all; it always edits the whole page and simply scrolls to (approximately) the relevant point on the page. So everyone who uses VE is "forced to edit the whole page", regardless of disability status or choice of device.
By "disabled users", am I correct in assuming that you mean only the small fraction of our users who use screen readers, as opposed to the far greater number of people with non-visual disabilities? I'd like to have something that works for screen readers, but I'd personally also like something that works for people with multiple sclerosis, Parkinson's, or carpal tunnel syndrome. "Hovering" may not be a good choice for these users, either. Whatamidoing (WMF) (talk) 05:13, 24 July 2013 (UTC)

Note: Section editing, done with Edit source in Safari on an iPad with NO add-ons or anything else. iow, you don't know what you're talking about, so it's not surprising you can't fix the problem. Rather than simply display both edit and edit source, you're now planning on writing a different version. Wow. Just can't admit you made a mistake, can you? Ever seen the picture of the swing created by a committee? That would be WMF. 184.78.81.245 (talk) 15:43, 23 July 2013 (UTC)

  • Disagree as "great idea" because paragraph-level edits would be better: For years, people have discussed just adding "[e]" edit-links to each paragraph, either as one-paragraph only, or to start the wikitext editor mid-page at that spot. Paragraph-level edits would look something like the following:
This is a header     [edit]
[e] This is the first paragraph.
More text here continued at this point here.
[e] This is the second paragraph, to edit as markup
[e] This is the third paragraph where a user wants to click.
[e] This is another paragraph farther down the page
In comparison, the paragraph-level edits would be a truly "great idea" especially with the choice to edit only one paragraph at a click, or merely start the entire wikitext editor at one cursor spot, to then continue editing by scrolling up/down in the wikitext. Anything which distracted from paragraph-level editing, or fixing edit-conflicts to allow partial edits to the same paragraph (edits currently forbidden even on adjacent lines by 2 users), was a "terrible idea" of distracting valuable resources into some expensive extravagance which delayed much-needed improvements to the markup-based editing. Similarly, "edit image 6" would be a great idea, when people know the 6th image-link is what they are editing (each time), and no need to scroll the page up/down to that spot, just always "edit image 6" because it is the 6th image on the page to edit. There are so many powerful alternatives to the VisualEditor chalkboard-simulator, as a primitive point-and-click interface. In formal computational linguistics, the idea to "edit image 6" or "edit portrait" or "edit table 3" is called "nominative selection" versus "indexical selection" to point (indexing) to the item of interest. -Wikid77 13:23, 25 July 2013 (UTC)

"Edit source" is a misleading label and should be changed

Can we get the utterly misleading "edit source" label fixed?

We already have the Visual Editor (VE) as the default as it 1) is to the left of the link for regular wikitext editing (don't discount how much that matters; if given two equal options and one is read first (people read from left to right), people will choose the left one a significant portion of the time), and 2) because for section editing, the regular link is hidden until the "primary" link to VE is moused over. Combine this with the name and you have made wikitext editing a distant option for all but the most astute and exploratory new editors. We even have relatively experienced editors who are used to WikiText editing who can't find it because of the label and therefore think they must use the new scheme.

The problem with the name is three-fold. First, not just computer aficionados but a mass of the public has learned that 'edit source' and similar phrasing, when invoked though their browsers, means to look at what is to most utter gobbledygook – raw code; totally foreign meta tags, wingdings, javascript/pearl/html/, etc. markup, that only a tiny group have a clue how to read and what to do with. Even for people who have never seen the phrase, it implies looking at said computer-expert material just by the natural interpretation one would give to such a phrase. Second, it's not clear it's a verb phrase – does it mean edit the source, or does it mean clicking it will allow one to see the 'edit source'? Third, and probably most importantly, its use in combination with the label given the visual editor, which is just "Edit", makes the other option seem like some other thing than 'edit' or 'edit this page'. That would not be true if we had something like two neutral options that, in combination with each other, imply they are a choice between one method of editing, and another. My suggestion is Visual editor and WikiText editor.

On a related sidenote, I also think we should have a linked note floating above the two options pointing at a short explanation page laying out that there are two editors and what they are, in similar manner to what we have in the interface for some options, like, for example, the linked Edit summary (Briefly describe the changes you have made) above the edit summary field.--Fuhghettaboutit (talk) 15:49, 28 July 2013 (UTC)

Total support. Actually I'm having a hard time myself finding the correct link (I'm used to clicking "Edit" which is agressively replaced by VE which is clearly not what I want to do). This is also why I disabled VE in the end. VisualEditor and Wikitext Editor are two equal ways of editing a page, and that should be reflected by the UI. --Patrick87 (talk) 16:05, 28 July 2013 (UTC)
Also support. Whatever the labels, the present situation where "Edit" sometimes gets you VE and sometimes the wikitext editor is untenable. It is vital that there should be consistency, so that the same tab always takes you to the same editor. This is a really basic usability principle. JohnCD (talk) 16:39, 28 July 2013 (UTC)
Support result. Eventually, VisualEditor and Wikitext Editor will be two equal ways of editing a page. Now, the former frequently generates errors (although the Bugzilla team often calls them unimplemented features or unfortunate side-effects.) (Can we change the links here to VisualEditor to "Edit (experimental)"?) — Arthur Rubin (talk) 16:43, 28 July 2013 (UTC)
Support If shorter names are needed, I'd suggest "Edit (GUI)" and "Edit (text)". Adam Cuerden (talk) 17:17, 28 July 2013 (UTC)
Presuming VE is intended for new users, it should be as clear as possible how to edit the page in the simplest way. I can't think of anything simpler than "Edit". GoingBatty (talk) 22:13, 28 July 2013 (UTC)
Yes- and they go to a talk page and then it means something different. Stability gives them confidence. This is a distraction in German wiki- they are stuck with Bearbeiten|Quelltext bearbeiten. I still go for three fixed buttons : Edit, Beta Visual editor and Disable Beta Visual editor. -- Clem Rutter (talk) 23:17, 28 July 2013 (UTC)
Support. Clear, accurate, and consistently weighted. These proposed renames will aid newcomers and regulars in their editing, and aid any discussions about them by using the common names for each, and make updating the documentation a lot easier. (But, I suggest removing the camelcase from 'WikiText'). –Quiddity (talk) 17:48, 30 July 2013 (UTC)

See also:

It might be best to merge the current threads into a single discussion. Whatamidoing (WMF) (talk) 21:43, 31 July 2013 (UTC)

Permanently disabling

Resolved

Is there a way to permanently disable this feature? I'm sure it's a good feature for most people, but personally, I hate it. Magog the Ogre (t • c) 00:47, 29 July 2013 (UTC)

Go to Special:Preferences, Gadget - Editing and check the "Remove VisualEditor from the user interface". -- Sameboat - 同舟 (talk) 00:55, 29 July 2013 (UTC)
Thanks! Magog the Ogre (t • c) 03:34, 29 July 2013 (UTC)
How is this "resolved" when this information is not on the front page ? Why does one have to search through the talk pages of one of a million a wp: -pages ? resp. look for the option in the most hidden place ? The "temporaririly remove while beta" is where it belongs : in the preferences's editing tab, not somewhere else like "gadgets" or whereever. — Preceding unsigned comment added by Fiiiisch! (talk • contribs) 10:42, 31 July 2013 (UTC)
I marked it as resolved because it was no longer an issue for me. I suggest making a new thread below stating your frustration that it is too difficult to find out how to remove it. Or, seeing as this is a wiki, edit it yourself ({{sofixit}}). Magog the Ogre (t • c) 01:53, 1 August 2013 (UTC)

WikiProject VisualEditor

I think we should, if there is sufficient interest, create a WikiProject for VE, at Wikipedia:WikiProject VisualEditor. Among the tasks that the WikiProject could work on would be:

  • TemplateData:
    • Creating a formal guideline (official help page?) for how TemplateData is supposed to be done. (Currently the main page is, I believe, at Wikipedia:VisualEditor/TemplateData.)
    • Continuing the push to create TemplateData for all needed pages, and also doing formal QA to make sure this is consistent (per the item immediately above)
    • Creating a place to post comments/suggestions about problems with existing TemplateData.
  • Documentation:
    • Updating the VisualEditor User guide as the VE software (eventually) changes to add functionality, and as the UI/UX changes.
    • Creating a strategy for adding VE information to other (or parallel) help/documentation pages at Wikipedia.
  • Tracking:
    • Tracking what is happening at other Wikipedias (for example, after a strong vote at the German Wikipedia against VE being opt-out, the WMF agreed that they would have VE as opt-in).
    • Compiling data on VE usage (say, by week, rather than just using the WMF dashboards, which track by hour), the number of editors who have opted out, and errors (code 550) flagged by the Edit filter (Abusefilter).
  • Design:
    • (Re)Design specifications for VE, possibly including our prioritization (as compared to that of the WMF developers)
    • Decisions about (re)naming elements (labels/textstrings) of VE that are under the control of individual Wikipedias. (Which, it appears, does not include en.wiki; apparently "English" is what we get, and WMF controls what "English" textstrings are: see Translating talk:MediaWiki.)
    • Discussing whether it makes sense for VE to be able to do everything that the wikitext editor does now, or whether VE should be aimed at providing 80 to 90 percent of existing functionality, for beginning in intermediate editors.
    • Engaging the WMF in major design decisions regarding VE, and wikitext in general, before the WMF has spent significant resources going in a problematical direction. (For discussions about, for example, eliminating the current format of diffs, see meta:Metrics and activities meetings/Quarterly reviews/VisualEditor-Parsoid/July 2013.)
  • Other:

-- John Broughton (♫♫) 20:11, 29 July 2013 (UTC)

I second that emotion, and wonder if each of these topics could be on a separate subpage - it's awfully hard to follow all the conversations in various places. GoingBatty (talk) 23:01, 29 July 2013 (UTC)
I'll share it with you - it's a Miracle that anyone noticed.  :-) GoingBatty (talk) 01:36, 30 July 2013 (UTC)

Call for audit and rollback

I call for an audit of this project and a rollback to the previous state of Wikipedia. It is abundantly clear that enough editors have issues and problems with its handling and rollout that for the sake of Wikipeida, it should be rolled back. Please respond with Support, Oppose, or Neutral and provide your reasoning.--Paul McDonald (talk) 15:51, 5 July 2013 (UTC)

Paul, please read WP:CONSENSUS; votes and RfCs are not binding on technical matters. Okeyes (WMF) (talk) 15:52, 5 July 2013 (UTC)
I've read it. There is nothing in WP:CONSENSUS that prevents anyone from calling for an audit. We can discuss anything, including failures by projects not subject to consensus such as this one.--Paul McDonald (talk) 16:13, 5 July 2013 (UTC)
Totally, but it does prevent it for being a worthwhile use of your time. What would an audit look like, exactly? Okeyes (WMF) (talk) 16:26, 5 July 2013 (UTC)
I am not sure what Paul McDonald means by an audit, but I think that a Lessons Learned review would be a very good idea, so that we can publicize what went wrong, so that we don't make a massive technical mistake again in the near future, like the roll-out of this poorly tested user interface. Robert McClenon (talk) 17:08, 5 July 2013 (UTC)
For starters, we would review the decisions made and how we got here. We would look at mistakes made, we would look for ways to improve, and admit failures. We would recommend reversal of severe errors and provide training to those affected. In short, a sotftware development audit. If anyone doesn't know what a software development audit is, they probably shouldn't have been involved in the first place.--Paul McDonald (talk) 17:21, 5 July 2013 (UTC)
I mentioned this in another place, but in this case, it would have been wise and fully within the realm of ignoring all rules to drop the WP:CONSENSUS clause here as it directly affects the improvement of the encyclopedia. WMF keeps hiding behind the fact that WP:CONSENSUS states that technical matters are exempt from that, but obviously that isn't working. Jguy TalkDone 17:57, 5 July 2013 (UTC)
There are reasons why technical matters should not be subject to consensus. Most editors do not have and are not expected to have enough technical knowledge to be involved in technical decisions, such as when to roll out Visual Editor. The problem here is that people who did have technical knowledge used poor technical judgment, rolling out Visual Editor in mainspace before it was ready. On the one hand, a survey is not appropriate, because it would be seeking consensus from a non-technical community. On the other hand, I agree that technical mistakes were made that should be reviewed. I think that part of the problem is that the technical decisions were made heavily by developers with too little involvement by software testers; that is my opinion. In any case, I think that lessons learned should be reviewed. Robert McClenon (talk) 18:22, 5 July 2013 (UTC)
@Okeyes (WMF): I searched WP:CONSENSUS for the word technical; it's not there. I believe that you're referring to WP:CONEXCEPT, which exempts "the community of MediaWiki software developers". I make lots of technical edits, and none of my edits are exempt. My bots were subject to a lengthy period of scrutiny and were not given bot flags until it was determined that they were of very high quality. I know of one editor with impressive technical abilities, but whom was found by consensus to have poor quality control for his bots and automated edits; he has been banned by consensus from all editing for a full year. I'm fairly certain you know who I'm talking about as he was given a high-profile write-up in the Wikipedia Signpost. Wbm1058 (talk) 18:51, 5 July 2013 (UTC)
Sorry, yes. Okeyes (WMF) (talk) 19:32, 5 July 2013 (UTC)
  • Comment The VE has great features and I congratulate the WMF and the VE team on its deployment. I have waited for a long time for its deployment and I have no doubt that it will prove to be a boon to Wikipedia as an encyclopedia project, and Wikipedians as a community. I do not think some bugs could be a good reason for pressing the panic-button. It is usual for new software to have bugs and we should all show some patience and understanding here. Actually it is good that bugs are being found -- they are getting fixed now. I fully trust the WMF to be able to assess the VE deployment and do not see any use for auditing by the community. In fact, I think such an audit would only hinder progress. Some things are best left to experts. Thanks and regards.OrangesRyellow (talk) 05:24, 6 July 2013 (UTC)
  • Comment I too like the basic concept of the visual editor and some of its features. However, I also find it is a great pain at times, as it is quite buggy, and some of the features need development before full deployment. Deployment for users was very helpful, as it is a good way to test for bugs and receive general feedback. However, I would suggest holding off on implementing VE for all editors, as I forsee major problems occurring, unless all features are deployed and the bugs fixed. Referencing needs to be simplified greatly (perhaps a drop-down list or similar feature that provides a list of reference templates without editors having to look up "transclusions" and the like), and the ability to edit tables should be implemented before I would recommend deployment. This thing needs to be really, really dumbed down before it is the default editor for anons.--¿3family6 contribs 15:59, 8 July 2013 (UTC)
  • Comment - I support disabling it until some of these problems are fixed. After everything I have seen its obvious that the WMF is not going to admit the VE is the epic failure that it is so continuing to ask them to remove it is just a waste of time. At this point, they may as well just go ahead and turn it on for everyone. Let the problems keep flowing and they can continue to just write them up and get around to them whenever they feel like it. The only positive is that so many browsers are excluded that the impact is minimal. Additionally, with the majority of users either ignoring it or disabling it completely the only significant impact to the project is the load on the servers and the time being wasted on all these discussions rather than building an encyclopedia. Unfortunately the IP's can't just disable it like the editors with accounts can and will be forced to use it, which will create a lot of work for us and drive a lot of them away in frustration, blocked due to errors, etc. So at this point, I don't see any reason to continue to debate it, just flip the switch and open the flood gates. There is no longer a need to test it, to submit problems or clean up the mess. The WMF can do that IMO. Personally, I am just going to reduce my editing to the minimal possible levels until the WMF fixes this mess. Maybe after a month or so I'll go back to editing. Kumioko (talk) 16:32, 8 July 2013 (UTC)
Support audit and rollback. 24.0.133.234 (talk) 17:45, 8 July 2013 (UTC)
  • Oppose. I think. This is not necessary. Yes, it is buggy, but the problems can be fixed - at least in theory. There are extremely sensible arguments for why we should have this. Enabling it for IPs as well would pose some rather unsolvable problems as Kumioko pointed out, but it should be ok to have it for registered users. We need to keep in mind that some registered users do actually find the visual editor easier to use, and it may be only 5% but we want to improve retention rates, do we not? In any case, if we do not roll things back, someone should still be keeping a close eye on things to make sure it really is not raising vandalism rates. I may do this from time to time but I may not be around enough to find any especially useful information on it. If it does raise vandalism, or if no one is willing to find out if it does (or if the bugs don't get fixed within a reasonable amount of time), I would support the audit and rollback. (P.S. 24.0.133.234 - do you have an account? Not that I think you should have to log in, but if you haven't got an account you wouldn't have tried Visual Editor. I'm just a bit puzzled.) Cathfolant (talk) 22:02, 12 July 2013 (UTC)
  • Strongly Oppose. How can bugs be found and fixed if nobody are using the software? I haven't had any issues with VE, apart from learning how to use it. I have made 20+ edits using it, and it's great. Editing articles is much faster and easier now. The "old" source editor contained too much irrelevant text and was chaotic. LiquidWater 10:41, 16 July 2013 (UTC)
  • Support - this was too radical a change to be considered purely a technical/QA management issue; given the apparently offputting effects on new users, there will be many lessons to be learned. --Cedderstk 18:40, 22 July 2013 (UTC)
  • Support with caveats - I'd prefer if it was turned back to opt-in, but it would need a sitenotice explaining how to turn it back on. This would set up a situation where it could be improved and relaunched later, hopefully aftera actually taking on community feedback, and abandoning the stupid claim that supporting basic wikitext ('''bold''', ''italic'', [[Link]]) would somehow be a step backwards. Adam Cuerden (talk) 07:14, 27 July 2013 (UTC)
  • Comment I hate everything about VE, and I haven't even used it enough to notice any bugs. I do not consider it to be usable even when it's working. I'm okay for now since I've clicked that I don't want to use it during BETA in my preferences, but the simple fact of the matter is I don't want to use it EVER. That, alas, is not yet an option in my preferences. Rwflammang (talk) 03:22, 1 August 2013 (UTC)
  • Support and I'm aware that unfortunately we can only politely call for this rather than instruct the devs to do this. This was in Beta testing, there were many known bugs to work on, but regrettably it was implemented before it was ready. It should be switched off and only go back into beta testing when enough bugs have been fixed to justify a further round of testing. If and when someone tells me that they've fixed the bugs I reported in May then I might even do some more testing myself. But it is now August, and there are major serious problems that have been known about since at least May. This software is not going to be fit for purpose for some considerable time and it is an annoying distraction to the whole community to have it live until it has passed a proper beta test. ϢereSpielChequers 11:16, 1 August 2013 (UTC)
  • Support. While I understand the goals behind this attempt, and they were certainly aimed at solving a real problem, the Visual Editor is simply not a workable solution at this point in the project's lifecycle. Wikipedia is built out of wikicode, which is inherently complex; no editor is going to be able to do everything which wikicode did without becoming equally complex itself. Therefore we'll always have to support wikicode, which means that the visual editor is always going to be locked in a struggle with it -- visual editor users won't be able to edit things that require wikicode, and will often damage them due to not being able to see them at the wikicode level of granularity. While it may result in "at-a-glance" simplicity, users who try to edit with it extensively are always going to run up against frustrations in the long run, which will lead to reduced retention and which will become a barrier blocking new users off from vital types of contributions which will always require wikicode. Such an editor might have been reasonable if it were Wikipedia's sole edit method from the start, but implementing it now is a terrible idea, and even if it is appealing at first glance it will ultimately drive users off -- especially users who might otherwise have learned wikicode from simpler edits and eventually transitioned into the sorely-needed users capable of more intricate markup. It's not enough to retain users after their first edit; we need to make the entire Wikipedia-editing experience more fun and friendly, and even if the visual editor was absolutely perfect and free of bugs, the fact is that it sets anyone who uses it up for inevitable frustration when they encounter things that it cannot handle. --Aquillion (talk) 15:30, 1 August 2013 (UTC)
  • (Please read before writing here :) I am moving this at the end of this thread because I feel it would be useful to know that there might be now a better place for this kind of concerns to be heard.) This thread was opened at the beginning of July. In the meantime, many things happened, a few RfCs were launched... So you might want to take a look at James Forrester's proposal here (posted earlier today) which now addresses some common requests (it also provides some insights about how VE is benefiting "from a large and diverse pool of users making real world edits"). Please leave your comments there. Thanks! --Elitre (WMF) (talk) 11:38, 1 August 2013 (UTC)

Management-driven project failure

VE. as currently implemented, is a terrible Windows 8-style fiasco. In principle a great idea -- and one in which I still believe -- its implementation has been rushed, and forced on the existing userbase it its unfinished state against great resistance from the old-timer userbase who actually form the backbone of Wikipedia. All complaints are met with stonewalling or denial. All of this might perhaps have been justified, if the VE had brought a sudden influx of edits and new editors: not only has it not done so, but early statistical results suggest that it actively inhibits new users from making edits. This is pretty much a textbook example of dirigiste management-driven project failure.

This is not about assigning blame or finger-pointing. I've been in similar situations myself. I have no doubt that those in management who pushed these changes through were acting in good faith, and I applaud the hard work of the developers who have done wonderful work against very tight deadlines on a project with pathological technical requirements, but as of now the VE is not fit for purpose.

None of this is unfixable. My experience, based on decades of being both a developer and a manager, is that this sort of management-driven failure can be fixed easily, in the early stages of this sort of fiasco, by changes in management policy that are based on acknowledging the reality of the situation, without regard to how painful that might temporarily be in terms of loss of face.

The VE has quite simply been released too soon, unfinished and without feature parity against the traditional means of editing. As of now, the software is beta-release standard. The right thing to do now is therefore to put the VE back into beta. VE should be an optional choice for all editors, clearly labeled as "Visual Editor (experimental)", with the traditional "edit" link as the default. A call for participation should be made, to both new and old editors, to try out this new experimental editor as beta testers, and proper beta testing performed at the same time as work is performed on finishing the software, both in terms of feature completeness and lack of bugs. When everything is properly finished and debugged -- a task I estimate will take at least three months -- then we can consider putting it out to the general userbase, once the community thinks it is ready.

I'd be very interested to hear any comments WMF management might have to make on this.-- The Anome (talk) 10:00, 25 July 2013 (UTC)

I completely agree, and I would go a step forward. Unless this VE madness is abandoned soon, it will prove to be Wikipedia's undoing. 130.225.113.254 (talk) 17:11, 1 August 2013 (UTC)
Surely you can't be serious. <nowiki></nowiki> There was a first test six months ago and nobod}}y participated in testing (it has nothing to do with the first release having <nowiki></nowiki> almost no functionality). The <nowiki>only way to test the new features that have been just created is to </nowiki> make the <nowiki>[[VisualEditor]]</nowiki> the default for everyone and remove all methods to hide it. Also the developers are placing an enormous eff]]ort to fix a huge amount of bugs. Diego (talk) 11:10, 25 July 2013 (UTC) Wikitext markup detected. You are using VisualEditor - wikitext does not work here. Click “Edit source” to edit the page in wikitext mode — unsaved changes will be lost.
It is a perfectly serious and logical response. I was one of the people testing this in May - it got deployed on schedule but without fixing enough of the bugs that I and others had been reporting. Best response now would be to accept that this failed beta testing, undeploy it and start a new round of beta testing in a few months when the devs have fixed enough of the bugs to justify a new round of beta testing. Then eventually if and when it passes the test phase we should deploy it, though hopefully not on en Wiki until we have seen it working on a few other languages. ϢereSpielChequers 20:53, 27 July 2013 (UTC)
I must say, it's been disconcerting seeing "power users" used as a snarl word - David Gerard (talk) 12:45, 25 July 2013 (UTC)

Management? What management? They never believed they needed an MBA or anyone with actual training and experience, and you can see the results. Read the opinion/decision of Erik Mueller, Deputy Director of WMF: "We don't love the [ edit ] [ edit source ] static links, because it feels cluttered and not the kind of user experience that we want to support." Translation: actual editors believe Form Follows Function. The WMF believes Form Trumps Function and the opinions of the "little people", the actual workers, are stupid and irrelevant. I'm amazed that people are surprised by this, as it's been the problem for years. I expect it just didn't effect enough people directly before. Stay tuned and you'll hear some nonsensical excuse as to why losing existing editors is actually a step forward. Go read Animal Farm if you want to know how this ends up. 184.78.81.245 (talk) 15:49, 25 July 2013 (UTC)

The big issue here is that, at the moment, the entire raison-d'etre for the project, which is its ability to boost the editor base, is in question, from the results of the very A/B testing which was intended to prove its worth. The problem with reality, unlike criticism, is that it doesn't go away when you don't believe in it, and no amount of fiat will make that change. The big question is what happens once you accept that your Metro interface is not well loved, or your antenna doesn't work well when gripped too tightly. Successful companies address these issues, and fix them. Admitting problems is not admitting weakness; taking advice is not losing authority. I've still got great hopes for the VE if that can happen. Let's get the VE done, and done right, so that it can achieve its original goal of furthering the encyclopedia. Stepping back from the current aggressive schedule of live deployment can actually speed that goal, by taking pressure off the devs, who must be between a rock and a hard place on this one. -- The Anome (talk) 16:36, 25 July 2013 (UTC)
Also, by launching before it's ready, all you do is get people used to avoiding editing under VE at all costs, and make them disinclined to believe you when you attempt to tell them VE is ready and sufficiently functional. Adam Cuerden (talk) 16:43, 25 July 2013 (UTC)

(moved from wp:VE/F) VE can be treated as an inspiration to write about WYSIWYG or other related topics. Now many people can see how difficult, and expensive it can be, to write custom-tailored WYSIWYG software based on partial understanding of the customers and issues for knowledge workers. I think these discussions are interesting, and this is a goldmine opportunity to get people writing articles about all the related issues: WYSIWYG interfaces, "creeping featurism", "can of worms", macro scripting languages, power keys to set text formats, "customer-driven management" versus "Management by Objective" (MBO) or Management By Wandering Around (MBWA), "customer-driven quality", "crisis management", "software disaster", "computer mouse fatigue", "carpal tunnel syndrome", "paralysis of analysis", "secretarial pool" of typists, "nominative selection" of images to edit, etc. Plus, in combining the edit-counts for new usernames and long-term usernames, there is the need to explain a "mixture problem" in algebra. As for the users, most will eventually find a way to update pages, perhaps using a combination of different tools, or asking others to do some of the work when too frustrated. Then there are the issues about encouraging the passing strangers to write articles, upload a photo from the phone used to edit a page, and the "Facebookization" of a scholarly computer system. Writing articles can be much more productive than anger, frustration, or rehashing the same problems with limited results. -Wikid77 13:23, 25 July 2013 (UTC)

Don't forget to put "change aversion" on your list. Whatamidoing (WMF) (talk) 20:11, 25 July 2013 (UTC)
You've been racking up a remarkable list of personal attacks and snide remarks in your official capacity. Please desist - David Gerard (talk) 20:54, 25 July 2013 (UTC)
Well, "change aversion" prompts the responses, "changing horses midstream" and "fascist denial" as closely related terms. Wikid77 11:51, 26 July 2013 (UTC)
Haven't you read his page? His job, as a "consultant", is to shove this down everyone's throat. So why be surprised with he resorts to ad hominem attacks on people with legitimate issues? On his Talk page he refers to "emotional problems with VE". This is our "Community Liaison"?! A fish stinks from the head down, and WMF only listens to, and apparently hires, people who agree with their very odd views. At least odd in the sense of being at odds with what is purportedly the core competency of Wikipedia: editing. 184.78.81.245 (talk) 14:16, 26 July 2013 (UTC)
Actually, my job is to take problems and ideas from the community and put them in front of the devs. I realize that most of that isn't transparent to you, because most of it happens offwiki, but it does happen.
And, yes, she is aware that some of our 121,689 have a strong emotional reaction to VisualEditor. It's a big community, and the members are quite diverse. Some of them truly love it (despite VE not deserving that love in its current state) and some of them deeply hate it (despite VE probably not deserving that hatred). Whatamidoing (WMF) (talk) 17:19, 26 July 2013 (UTC)
As with any change, I accept that some will really love it, and some will really hate it. But, in spite of it now being the default editor, only a tiny minorty of editors are using it. That's not a small minority hating it. That's the majority of editors disliking it enough that they think that even wikitext editing is preferable, even if they have to search around for an "edit source" button. -- The Anome (talk) 10:47, 27 July 2013 (UTC)
Hi David, I suppose that if you believe "change aversion" is just a fancy way of saying something like "irrational people who are just too stupid to grasp the developers' fabulous vision", or if you simply see me as the enemy and therefore put the least pleasant construction on anything I say, then you might think that was a snide comment.
But it's not snide, and it's not an insult: A major component of change aversion is people rationally and intelligently recognizing that the cost of the change to them exceeds the cost of the benefits to them. VisualEditor provides us with an excellent example of this: the cost of learning a completely different system will exceed the benefits (even if you count the benefits very generously and over a long period of time) to a fraction of our experienced editors. I would especially put editors who have an expert understanding of wikitext but are currently rarely active into that category: if you're only editing articles for an hour a month, it will take a long time to make learning VE truly worth your while.
Change aversion is why I have a cell phone that is nearly ten years old: until it actually breaks, there is no benefit that a new cell phone can provide to me that will exceed the cost of buying and learning how to use a new one. Being change averse is often a good thing. Whatamidoing (WMF) (talk) 01:23, 26 July 2013 (UTC)
Hi. Thanks for that. I'm glad you can see that the comments here are not from "irrational people who are just too stupid to grasp the developers' fabulous vision" -- we're passionately committed to Wikipedia and the WMF's goals, and many of us not only have significant software development and project management experience, and are used to working in a commercial environment where there are objective measures of success and failure, and consequences thereof.
There's no dubt that the VE's deployment has caused significant annoyance to a considerable number of the old guard. The issue is whether the corresponding gains make that worthwhile. The big question here is whether the VE is showing any measurable, statistically significant, improvement in achieving its main goal of making editing easier for the uninitiated, and increasing the rate of new editor recruitment. As far as I can see at the moment, the answer is "no", and, if that's the case, then the VE needs a major project review to address the reasons why it is not succeeding in that goal, and a new strategy regarding VE deployment and development that attempts to address those problems. In particular, it should consider whether the higher-level management processes that allowed this to happen are themselves part of the problem. To that end, I'd like to see more of the WMF's internal statistical data and analysis regarding this. -- The Anome (talk) 07:25, 26 July 2013 (UTC)
Given I've just been told by Eloquence that using wikitext as shortcuts in VE would be "moving backwards", I for one see this as a white elephant that will never catch on. If it can't integrate the best of what came before - not even the simple stuff like links, italics, and bold, then the vision of the VE team for Wikipedia's future is one that is fundamently rejected by most Wikipedians. Adam Cuerden (talk) 07:35, 26 July 2013 (UTC)
The big question is not whether this would be "moving backwards", but whether the VE in its current state can be regarded as as a move forwards. If it is, we can start to think about how the VE and the existing source code editing mode could be brought closed together. The problem is that there is, as far as I can see, no evidence that it has been effective in the way it was intended. -- The Anome (talk) 07:46, 26 July 2013 (UTC)
And the users remind us how "95/100" is also a fraction, as the fraction of long-term users who run the wikitext editor instead of VE. However, "white elephant" is also a closely related article. -Wikid77 11:51, 26 July 2013 (UTC)
The Anome, I don't think we really need a major project review to understand why it's not popular at this point: in addition to being entirely unfamiliar, it's too slow and it's too awkward to use templates and to cite sources. There may well be other reasons, but these are such big ones that even fixing everything else would IMO result in a still-unpopular product. I can recommend a review, if you think it's important, but it seems to me that it might be better to fix the patently obvious problems and then go looking for more. Whatamidoing (WMF) (talk) 17:19, 26 July 2013 (UTC)
Hi, Whatamidoing, I'm glad you can see that the drawbacks of the VE in its current form are obvious. The majoe problem with the VE is not the concept -- I'd be happy use a good, working VE that had 100% feature parity with Wikitext! -- but the handling of the project.
The thing which needs reviewing is not your software, but your management processes. If it could be easily seen that the editor was unusable in its current form, why was it released as default editor before it was ready? When it was seen that this strategy was not not working, why was it not reversed, and the VE put back into beta for further development? And so on. This needs a thorough management review -- and if the policies were driven right from the top, and senior management are unable to review their own performance impartially, I suggest that the external board members be brought in to perform that review.
What is needed to make the VE a success? Well, here are some suggestions:
  • Firstly, put the VE back into beta, and make wikitext editing the default again, while retaining a very visible option to use the visual editor for all editors, logged in or IP, so that the minority who currently like it, and any new editors who wish to try it, can still use it -- if I were a newbie on a site, I'd try an option called "Visual Editor", wouldn't you?
  • Secondly, announce publicly that the VE project is undergoing a review, and solicit feedback from the community about how it might be improved. Making an annoucement like this would go a long way towards clearing the air. (Talk about "pushback", for example is enormously offensive: it implies that editors are fools who need to be led by the nose by WMF leadership. This sort of arrogance is perhaps excusable when you're right, and your product is indeed better by far in every way to the alternative -- it's not when it isn't, and will just generate bad feeling at best, and outright mockery at worst. See Windows 8 for a very clear example of this in action.)
  • Thirdly, set a clear set of goals for the VE that will be met before it is taken out of beta: I suggest at least the following:
    • 100% feature parity with Wikitext editing -- ie. full editing and display roundtripping of every feature of Wikitext in the UI
    • VE loading time comparable with Wikitext edit page loading time
    • VE save time comparable with Wikitext edit page save time
  • Fourthly, promise not relaunch it without the community buying into it first, and make a clear commitment to involve the community in the design of any development of new markup or editing modes, and a commitment to support Wikitext editing and markup for at least a substantial (three year? five year?) transition period before turning it off. The current "we have no plans to retire Wikitext" uncertainty has a chilling effect -- bot operators have a major commitment to Wikitext in their code, and much of the software that maintains Wikipedia actually resides on their machines.
I think if you did these four things, you'd be well positioned to come back in, say, six months time, and relaunch the VE as default, this time by the general acclaimation of the editing community, instead of against "pushback". If you don't think they are a good idea, please let me know why. -- The Anome (talk) 10:35, 27 July 2013 (UTC)
Another option is to state that VE is designed NOT to have 100% feature parity with Wikitext editing, but instead state that it's a tool intended to entice new users to make certain kinds of edits. For example, HotCat makes it a lot easier to add/update/delete categories, but you have to use the good old fashioned Wikitext editor to reorganize categories. GoingBatty (talk) 03:24, 28 July 2013 (UTC)
I understand that VE is meant to have 100% feature parity–eventually. From some of the comments from devs, I believe that "eventually" is defined as "more than a year from now".
User:The Anome, I'm thinking mostly about your fourth recommendation. Can you give me an example of this actually happening in the last, say, three years here at the English Wikipedia? (By "this", I mean the community buying into a visible software/user interface change at any point before everyone had spent a while getting used to its existence. I'll accept examples of community buy-in before the change or at the time of the change—assuming that the community "stayed bought", rather than saying yes beforehand and then saying no once it appeared—but I exclude acceptance after a week or more of complaining.) Whatamidoing (WMF) (talk) 21:32, 31 July 2013 (UTC)

I think you're looking at this in the wrong direction, Whatamidoing (WMF). The norm needs to change from "we just changed something on you, live with it" with weeks of trying to get it to work properly and being belittled for having the nerve to complain when functionality declines, to "We're looking at doing this, what do you think? We really need your opinion here, what are we missing?" It took two minutes after rollout of Notifications for someone to point out that it didn't accommodate IPs; that should have been identified before rollout, and should have resulted in a rollback until it was corrected. This is how it works outside of the walled garden of Wikimedia projects. Risker (talk) 21:53, 31 July 2013 (UTC)

Hi Risker, I'm just looking for credible evidence that if this approach were taken here, that anything could ever be changed. So if I go to the WMF today and say, "Put this back on opt-in until the community agrees to change its status", they would IMO be justified in responding with something like, "So first tell me what your watchlist looks like these days, and then we'll talk about it." I was involved in that incident, so I'm vulnerable here. I need evidence, not just a confident smile and an assertion that of course editors will embrace VisualEditor as soon as the bugs are solved. If I'm going to propose this to them, then I need evidence that the community here has actually approved of UI changes in the past, and I need evidence that the handful of editors who oppose VisualEditor because of their belief that a rich text editor will attract "stupid people" and "the wrong type of editors" and people who "aren't dedicated enough" are just a tiny minority.
I think I can manage the second issue, but I am dubious about the first. We—and by we I mean highly experienced editors like those of us who frequent these pages—have a strong history of rejecting even trivial UI changes at the English Wikipedia. VisualEditor is a major UI change. Do we have any history of accepting UI changes in the last few years without first living with the changes for a while? Is there anything that I could point to, that shows the English Wikipedia supporting a UI change? I've got a couple of good examples of people loudly rejecting the change but then coming around later after they've had time to adapt; I've got a good example of people saying that they accept them but then rejecting them later; I've got several examples of people rejecting a change and the change therefore not being implemented. Have you got a good example of change really being accepted and endorsed by the community at the English Wikipedia before its deployment? Whatamidoing (WMF) (talk) 22:24, 31 July 2013 (UTC)
The problem here, Whatamidoing (WMF), is that historically this route hsa not been taken very often. The closest I can think of is pending changes, which was largely community driven. The software was accepted by the community. (I know, I know - I argued after the trial that it should be shut off, because that was the original agreement for its testing. It's still crummy software, and if you ask some of the developers, some serious rewriting is in order.) The rejection was only partly because of the engineering of the extension; the main reason for its rejection was that the community did not feel it was fundamentally ready to make such a huge leap in changing its core philosophy. And this, I think, is part of the reason that there are so many disagreements about changes: they're not just about the editing interface. They're about the socialization of new editors, and interpersonal communications, and core organizational philosophies like usability and verifiability. We have some stars on the developer team (both staff and volunteers), but in many cases their strength is not in understanding that their work is as much social engineering as it is technical engineering, or in communicating in a way that effectively reaches the goal. In the case of VisualEditor, I think one of the strongest points here is how many people have said (in various venues, including mailing lists) that it's heading in the right direction but is just not up to being deployed as the default yet. We both know it's going to take months to fix some of the really key problems. Risker (talk) 22:37, 31 July 2013 (UTC)
PC is not a UI change, and it took what, five years, if you count start to finish? For a good deal of that time, the discussion was essentially a full-time job for the volunteers who supported it. That is really not going to be a convincing argument in favor of disabling VisualEditor by default until the community decides to allow all users to see it by default. Whatamidoing (WMF) (talk) 22:53, 31 July 2013 (UTC)
Most editors do not differentiate between whatever kind of change PC was and user interface changes; they're changes in the way that they do things, either way. I think the reason you can't find any examples is that there has never been a good example of the community being heavily consulted in advance of a major UI change since either of us started editing. In the old days, there weren't many UI changes, and almost all of them were done because of community requests. Then we had Vector come in as default skin, and it only had a few bugs that were resolved fairly quickly; there was community participation there.

The problem is that this should NEVER have been deployed as the default editor, a fundamental error of judgment on the part of the Engineering Department; it just wasn't ready. Beta testing it, yes; there were lots of people waiting to test it once the referencing and template features were added, but they never had the chance. It has months to go before it is fit for default deployment; January sounds about right. I think what might be best is trying to establish agreement on what features must be fully functional before deployment; I'm hesitant in saying that, though, because that was supposedly the criteria before *this* deployment, and look what we wound up with.

I just think how different this all would be if we'd had a well-announced, short-term default deployment with the understanding that it would be shut down after, say, 5 days of bugs, some A/B testing and some data collection. I actually don't understand why it wasn't pulled back after that time, when it was obvious that there was no way the VE team was able to keep up with even the simpler bugs being reported. Risker (talk) 23:21, 31 July 2013 (UTC)modifying my earlier comment

So, I went and made a cup of tea, and I think that might actually be not far off from what would work here. Establish three major milestones that need to be reached (performance and improvement of the template/referencing process would be two, tables possibly the third). As each one is coming close to being reached, have a well-announced, temporary, full-scale deployment with the understanding that it is intended to be a community-wide feedback period. By the end of the third one, it might well be possible to make it "we'll revert to opt-in on a community RFC with 70% support and more than 500 editors participating" or something like that, if the first two go well. It means that the WMF has to come up with the goods, really *does* have to do the work to make this a practical reality. And I believe that a lot of the other EE projects should be set aside and everyone available should be working this particular patch. But this might work better than what's happening now, since it's obviously impacting the project in ways that aren't okay. Risker (talk) 23:34, 31 July 2013 (UTC)
Hi Risker, When you say "community RFC with more than 500 editors participating", you are implicitly defining "the community" as being only those people who are willing and able to express an opinion at an RFC. That's not really "the community"; that's something much closer to "the metapedians"—people like you and me, but not people who show up for an occasional edit and have never made an edit outside of the main namespace (and, if they're new and used to use VisualEditor, might not even know how to comment at an RFC). Are people like you and me the only editors whose opinions should be counted? I talked to someone who'd done user research on Wikipedians last summer. He said that each day, about five people make their 1,000th edit, and many of them have never interacted with "the community" or made a single edit to the Wikipedia: namespaces. It was a couple of months before your first edit to a Wikipedia: page. Do you remember that far back? At that point, would you have appreciated someone else deciding, without considering your opinion, to take away the only Wikipedia editor you were used to and to revert to the previous one?
I think if we're going to have a survey of opinions, we need to include a representative sample of all the affected editors, not just the people like you and me. Does that seem appropriate to you? Whatamidoing (WMF) (talk) 18:04, 1 August 2013 (UTC)
I do remember that far back, Whatamidoing (WMF), and I expect that the vast majority of Wikipedians do too. I also know that I read noticeboards and other public venues right from the beginning (even before I registered), but chose not to participate there; my first edit as a registered user was to an article talk page. Give me a break, WhatamIdoing: even the current RFC has editors whose names I've never seen before; the site notice made a big difference there, and is drawing in people who aren't Metapedians. Given that lots of people can hit 1000 edits in a week or less, I don't think the "lack of interaction" based on edit count has much meaning; I'd consider lack of interaction over time to be more realistic. As to the RFC, I'm taking my lead from Erik, who respected a DE:WP community RFC of that nature. You know, this project has gone out of its way to not beat up on VisualEditor, and now we're being penalized for not going at it with pitchforks and torches. The WMF, by taking a month to pull back on their aggressive strategy, has caused very serious damage to its relationship with this community. And yes, I mean new editors and IP editors too: their edit rates have dropped since this started. It is pretty clear that Erik and James believe that this was an acceptable way to introduce new software to the community. We're saying, no it's not. Risker (talk) 18:18, 1 August 2013 (UTC)
I haven't seen the current numbers, but since active editors dropped about 11% in the two years from June 2011 to June 2013 (a fact not affected by VisualEditor at all), it would be surprising if the post-VE numbers hadn't fallen similarly.
The question isn't whether we reach some newer editors. Almost every RFC has names that I don't recognize. The question in my mind is whether the people most significantly affected by the decision, which are the users who use VE as their primary or only editor, are the ones who will get the primary say in the decision about what happens to their account settings. A survey like the editor survey might reach them adequately. An RFC probably won't. Whatamidoing (WMF) (talk) 18:46, 1 August 2013 (UTC)
Given that the last editor survey done over a year ago still hasn't been released (and as far as I know hasn't even been analysed), it's a much poorer solution than an RFC. I am not suggesting that VisualEditor be booted and, in fact, I've explicitly said that I don't see much point in removing it as default (in posts to Wikitech-L). And I know that you personally (and your fellow CAs and CLs) had no decision-making power in any of this. My points are about how to introduce new software to a community. The way this was done was directly in opposition to the very project management philosophies that we keep hearing batted about; not one of them even hints at the idea of making an un-debugged beta as a default. Given how major some of the defects currently are, and how much other extensions and software have to be worked on as well, it's going to take a good six months to even get to what it should have been before the July 1 deployment. If there isn't a demonstrated understanding that this was a poorly done deployment, and there is unwillingness to consider any other way to deploy similarly major software changes, then it confirms that the English Wikipedia community is nothing more than a bunch of lab rats to Engineering. Unlike the communities on some other projects. Risker (talk) 19:00, 1 August 2013 (UTC)
"Hi Risker, I'm just looking for credible evidence that if this approach were taken here, that anything could ever be changed." - well, is that truly important? Do we have to change something, without caring, what is going to be changed? The idea is simple: the users must make the decision to use something or not to use something. Not WMF, unless they are actually going to act as our servants and representatives.
"If I'm going to propose this to them, then I need evidence that the community here has actually approved of UI changes in the past" and "Do we have any history of accepting UI changes in the last few years without first living with the changes for a while?" - well, I can think of a change in Lithuanian Wikipedia, where a user has inserted additional buttons in the toolbar. But still, one should remember that by now the UI is actually not that bad, just like the internal order of Wikipedia. It is only natural that a vast majority of proposed changes are bad and should be rejected (look at Wikipedia:Village pump for many bad proposals). Oh, and one should not confuse adaptation with liking the change. As a Lithuanian saying goes, "A dog even adapts to being hanged."...
"I need evidence, not just a confident smile and an assertion that of course editors will embrace VisualEditor as soon as the bugs are solved." and "I think if we're going to have a survey of opinions, we need to include a representative sample of all the affected editors, not just the people like you and me." - we have to use the data that actually exists. There are several RFC that show that more experienced editors do not like the change and A/B test that shows that new editors also are not encouraged by this change. Where do you see anything hinting that majority of actual users (not just the ones working with WMF) like the change..? So, WMF should stop the wishful thinking about imaginary majority of users who like the "VisualEditor". --Martynas Patasius (talk) 21:44, 1 August 2013 (UTC)
I have never said that a majority of users like VisualEditor. We know that a small minority do like it, because they have publicly posted this. We know that a larger group of new users have only used VisualEditor in articles. This might be because they prefer it or because they didn't notice the alternative. But I have never said that a majority of editors, nor even a majority of any significant subgroup of editors, likes it. Whatamidoing (WMF) (talk) 22:45, 1 August 2013 (UTC)
Yes, you have never said it. But statements like "Are people like you and me the only editors whose opinions should be counted?" or "[...] we need to include a representative sample of all the affected editors, not just the people like you and me." ([3]) make little sense if you accept that opinion of almost all important groups is going to be mostly the same. In that case it just looks as if you (or WMF) are trying "Forum shopping"... --Martynas Patasius (talk) 00:25, 2 August 2013 (UTC)
I don't believe that anyone at the WMF believes that a majority of editors likes VisualEditor in its current state. I equally don't believe that anyone at the WMF, or indeed anyone who's thought about it for a while, believes that people like Risker and me are average, typical, representative editors. If you put VisualEditor into an opt-in mode, it will affect my editing by exactly the amount of time that it takes to turn it back on. If you put VisualEditor into an opt-in mode, it will confuse many of the people who have been editing successfully with VisualEditor for a month now. But we're not effectively asking those people for their opinions. In fact, the RFC is drawing some comments from new editors who say that they can't answer the questions because they don't know what the name refers to. Someone just posted a basic description. Maybe we need screenshots, too. Whatamidoing (WMF) (talk) 01:01, 2 August 2013 (UTC)
Just to note, it was a new editor who uses a blacklisted browser, and thus he had never seen VE screens. Risker (talk) 02:01, 2 August 2013 (UTC)
"If you put VisualEditor into an opt-in mode, it will confuse many of the people who have been editing successfully with VisualEditor for a month now." - OK, so, how many editors are you talking about..? Do you have any statistics? Are you sure a post on their talk pages wouldn't be more than sufficient? Or do you think that "Wikipedia:Notifications" (another not-too-well-thought-through novelty of the same WMF) will not do a sufficiently good job..?
Also: "If you put VisualEditor into an opt-in mode, it will confuse many of the people who have been editing successfully with VisualEditor for a month now. But we're not effectively asking those people for their opinions." - well, did you ask what everyone else thought about this "VisualEditor" before enabling it..? (No, it doesn't count as "asking" if you ignore the answer.) And WMF could have reduced this confusion by giving up earlier. Also, it is exactly the "Forum shopping" I was talking about: it appears (truly or falsely) as if you (WMF) are just looking for some group to hide behind - that the prevention of loss of face is the goal and protection of some interests of a tiny minority (while ignoring the analogous interests of a vast majority) is just a pretext... So, if you have learned your lesson (are truly concerned about the users, understand that change causes confusion and thus - by itself - is a bad thing etc.), you'd better show that... --Martynas Patasius (talk) 01:59, 2 August 2013 (UTC)
  • Back to previous questions, you must remember Whatamidoing (WMF) that the WMF made it excruciatingly clear that the English Wikipedia community's desires with respect to opt-in/opt-out of *any* user group was unimportant to the WMF and would not be acted upon in any way, shape or form. It was only after over three weeks of lobbying that we managed to get an opt-out button for registered users, and that was when the volunteer and staff developers pretty much shamed them into it. English Wikipedia has every reason to be extremely wary of anything the WMF says about this anymore, especially after the WMF inconsistently respected the decisions of other communities but is still strongly pushing to not respect the decision of this community. I just feel so disappointed that the desire to meet the July 1 schedule was put ahead of any sensible deployment process. There is no grounds at all to think that staying opt-in for long enough to work out the big bugs on referencing and templates would have negatively affected this project; in fact, there's considerably more grounds to believe that it would have positively helped it. People were standing by to test those features out; for the previous six months there was nothing really to test. Instead, the WMF made it the default without any debugging at all on these major features, and managed to alienate the majority of the editing community. That is not, incidentally, agile management or any of the other types of project management that's being bandied about; those call for properly debugged products to be deployed. The message the WMF is giving out, even down to Erik's op-ed, is "we'll pay attention to you when we want to (and ignore you when we aren't hearing what we want to hear), and we're going to constantly experiment on you without considering any alternative processes." It's not like we're just wikipedians here: there are hundreds of experienced developers and project managers too. We know what we're seeing here. Risker (talk) 02:23, 2 August 2013 (UTC)
Hi, W. If you think the VE's learning curve is the only thing that fuels veterans change aversion, you're missing the core root of the problem experienced editors are facing. There's a blind spot in the way the WMF is approaching the design of the visual editor. Every time someone in a the Foundation says how wikitext is obsolete or hard to use, I die a little death inside. The Foundation is seeing only the drawbacks of using wikitext, but you're missing all the advantages that it provides, and we're terrified that many of them will be discarded in the transition. Following your cell phone metaphor, is like being used to a device with a battery that lasts several days without recharge, and suddenly being forced to use a shiny smartphone that is depleted in a few hours. It's that bad.
The template and references interfaces (the very first improvements that the community requested as indispensable) are a good first step, but as of today those are not designed for efficient handling by experts, and it's unlikely that they ever be as efficient as simply typing the desired code. A real solution should provide ways to make editing semantic code friendlier to newcomers (with autocompletion, easy discovery of features, self-documenting interfaces...), not completely shielding them from it by hiding all the semantics existing behind Wikipedia articles.
The difficulties faced by new editors are not solely because of wikitext syntax, which is terse and easy to touch-type; most problems are created by the complex layer of templates, categories, and community guidelines that one must fulfill, and those are not going away. By the time the VE is able to support all tasks that wikicode support today, it will be nearly as complex as wikitext, and much less welcoming in many ways (some complex tasks are made more discoverable, but much less efficient by the new interface). Veteran editors can edit wikitext by hand, but they will need special tools to edit the new proposed HTML backend - anything that the tools can't handle will be out of reach of editors and impossible to do. The new proposed architecture will take control away from editors; that's why we're opposing it, not because of an unwillingness to learn the new tool. Diego (talk) 08:57, 26 July 2013 (UTC)
Well, wikitext is an unspeakably horrible disaster on several levels, and I think it can reasonably be called "disastrous" as its needless complication has delayed a visual editor for literally several years. We absolutely need a VE of some sort. The one we have, however, is experiencing a number of problems - David Gerard (talk) 16:15, 26 July 2013 (UTC)
I don't know what it will take to convince people: There are absolutely no plans to remove wikitext editing. By "absolutely no plans", I mean "nobody, not even in some secret conspiracy room, has a plan to do this".
Will wikitext editing someday be replaced? Sure. It'll probably be replaced sometime between now and the heat death of the universe. I expect VisualEditor to go away during that timespan, too. Also the entire human race. Could somebody make a plan to replace wikitext editing at some point? Sure. You can make all kinds of plans. My guess is that wikitext editing will go away when editors stop using it. That will probably be sometime before our youngest current editors all die, but it is not likely to be while most of our current editors are still actively using it. Whatamidoing (WMF) (talk) 17:19, 26 July 2013 (UTC)
"I don't know what it will take to convince people: There are absolutely no plans to remove wikitext editing." - easy. For example, promise that you (that is, WMF) will prefer to cancel "Flow" rather than deploy it without making it fully compatible with existing wikitext. Or promise that final decisions about major deployments (for example, "Flow") will be done by community and not developers or WMF. At least say you (personally or WMF) are sorry for, well, something (you clearly have many options here - for example, creating an impression that you and the rest of WMF do not care about users - [4]). Just add sufficient details (or modify the statement accordingly - although some modifications will not alleviate our concerns) and be honest (obedience to community that WMF is supposed to serve would also help). As far as I know, so far you have evaded such opportunities, claiming that you do not understand what is being asked for ([5], [6]) - and that just creates an impression (true or false) that you do not really want to...
Also, speaking about this... Aren't you paid to find a way? At least, that's what your user page ([7]) seems to imply. If you really do not feel capable of doing your job well, maybe you should just quit..? Although in that case it would probably be better to do that without getting a reputation (deserved or undeserved) of "an enemy of customers and constituents" ("constituents", as Board of Trustees is partially elected by the users) or even someone "insensitive to customer concerns"... Potential employers might not like that (speaking of the articles, "The customer is always right" comes to mind)...
Oh, and, by the way, "There are absolutely no plans to [...]" does not help. Trouble can come without separate planning. Mere incompetence or recklessness will suffice (that's why we have WP:AGF and WP:COMPETENCE, remember?). --Martynas Patasius (talk) 18:55, 26 July 2013 (UTC)
Do you really believe that a corporate "promise" is enforceable? What if someone at the WMF promises that wikitext editing will exist forever, and then it's removed at some point in the future anyway? What exactly would you do then? I suppose you could say something like, "But you (or your predecessor, or your predecessor's predecessor) promised me!", but what could you do that would actually be useful in that situation?
I'm not sorry about being rationally skeptical of the value of any "promise" from any corporate organization. Corporate promises are truly valid so long as the current actors in the corporation actively believe in the idea. Any promise made by one employee can be un-made by the next person in that position or by that person's superior. Any policy set by the Board today can be revoked by the Board tomorrow. Breaking a popular promise would hurt the organization's reputation, but it can be done, and, in corporate history, it has been done millions of times. It's also possible to comply with the technical letter of the promise and still subvert its intention, e.g., the wikitext editor is available, but is slowed down, or available, but some new feature doesn't exist in it. Therefore IMO any such promise is worth no more than the pixels it's displayed on. Do you still see a point to having some completely unenforceable words officially pronounced? If you would like me to request an essentially worthless "promise", I can do this, but I honestly don't see the point.
If you want full support for wikitext editing to exist in Flow, then, in practice, you either need to convince the people working on Flow that it's a good idea, or you need to get the Board to order it. I recommend starting with the first option. I repeat, in the interest of clarity, this practical fact: If you want a non-VisualEditor editing system in a non-VisualEditor product, then your most effective avenue is not talking to the VisualEditor team. Whatamidoing (WMF) (talk) 20:55, 26 July 2013 (UTC)
In regard Flow, the first option has been unsuccessfully tried. It's been explained why the option for the same editing (including wikitext editing) allowed in article space be allowed within Flow messages is necessary. Perhaps the second option should now be tried. I almost agree that the comments about Flow are inappropriate here — I say, almost, because @Jorm (WMF): has stated that the editor in Flow will be VisualEditor. — Arthur Rubin (talk) 21:23, 26 July 2013 (UTC)
@Arthur Rubin: I've tried to summarize that issue (from the scattered threads at each wiki) at the end of the Wikipedia talk:Flow#Supported Wikitext thread. Hopefully that will clarify everything. (And note, they do have to support editing wikitext in Flow, because of people without javascript, and people who use screenreaders, and etc. We will collectively and legitimately demands rolling-heads, if Graham87 isn't able to contribute happily! He's a wonderful example.) Examples always help, hence I collected all those. –Quiddity (talk) 22:10, 26 July 2013 (UTC)
In other words, you cannot promise (an article!) anything, but want us to believe you anyway. You also are not going to take back the words that are perceived almost as insults (an article!), nor to give some explanation that would soften them, but want to be treated as a friend anyway. Sorry, but the basic social competence (another article!) should tell you that such things, er, are not very realistic...
Oh, and your user page does not say what projects you are working with ("with some of the upcoming major changes to the software at the Wikipedias" would indicate that you work with all of them). If you do not want to be blamed for something you do not influence, you should probably correct that. And the list of names (or usernames) of the ones who could be thus "confused" with you would also help to deflect some possible problems. --Martynas Patasius (talk) 21:55, 26 July 2013 (UTC)
David, I think you need to examine your statement. Well, wikitext is an unspeakably horrible disaster on several levels, and I think it can reasonably be called "disastrous" as its needless complication has delayed a visual editor for literally several years. We absolutely need a VE of some sort. Firstly we should say the wikitext is a remarkably efficient markup language that has produced the greatest encyclopedia the world has ever known, infinitely subtle and tailored to writing referenced text that can be rendered in multiple skins on multiple devices. The editor compares favorable with many, and requires minimum download time allowing for the widest user base. It does the basic processes well c&p, saving without corrupting other text. Yes, it could be improved by becoming modal, switch between a wikimarkup/just visible text. It could even do predictive text with in templates/infoboxes-- or provide a predictive hand-holding mode- or even cache the input buffer so you don't lose your text on leaving the page. But any enhancement needs to preserve the stability that the wikitexteditor provides- it mustn't mangle the unedited text. What you see is what is saved. Any enhancement needs to preserve the flexibility that the wikitexteditor provides. After that lets put together a team to produce the functional specifications- put them out to this group to discuss and refine. Write the documentation explaining how the new editor works and then engage a programming team to make it happen. One of the skills of developing successful software is to know when to pull the plug, and rewrite from scratch, learning from the experience gained. Bugzilla becomes the enduring asset. My analysis was clear in June- VE has no software engineering core. It is coder led, not user led. The team has lacked leadership from the start. When constructive advice has been given- it has been ignored. Constructive advice has been seen as personal criticism, and instead of saying oops- buzzwords have been launched and the line you don't understand. Lack of structure was seen as good because it was Agile Programming Methods, had anyone read about the stakeholder involvement requirement in the Agile manifesto? Can you identify the one principle out of the twelve that seems to be working? The reason that WP is not gaining new editors is partially because all the easy articles are written, the editing bar has got higher because we are no longer a joke, but in the main the trusted source of first reference. The second off-putting factor is we have more policies than the United Nations. Getting round these facts are unsolvable- designing a new flashy editor is false seen as the easy fix. And this one just doesn't work- and if the technology needed to do section edits won't be available for a year the wrong data structure was chosen- and it will never work. Re-structure the management team, adopt an appropriate programming paradigm and rewrite.-- Clem Rutter (talk) 22:15, 26 July 2013 (UTC)
Clem - no, you're actually wrong about wikitext's properties. All the good things you note about it could have been achieved by something that had been constructed with the slightest attention to being able to be put into EBNF, rather than having been literally "whatever the PCRE parser that happens to be included with our version of PHP happens to produce". The all-but-uncomputability of wikitext did literally delay a visual editor several years. There are no independent implementations of wikitext - the parsoid is the first one. It has been a hideous disaster in every way that makes it distinct from any other wikitext form. The only reason it has not been thrown away is ten billion words of legacy content, which is actually a pretty good reason not to. But really, there is no reason to love the present form of wikitext and very good reason to curse it - David Gerard (talk) 22:28, 26 July 2013 (UTC)
You've got a point, there; and Parsoid might reasonably be introduced as an alternate version of Wikitext. However, the basic algorithm to convert Wikitext (including template processing) into Parsoid needed to be done before an editor, such as VE, which attempts to do it from time to time, is introduced. You (WMF) are still releasing "beta" software with the basic algorithms not yet in alpha. — Arthur Rubin (talk) 23:08, 26 July 2013 (UTC)
In "It has been a hideous disaster" I meant MediaWiki wikitext was a hideous disaster, not Parsoid (which I have no idea about the guts of) - David Gerard (talk) 01:24, 27 July 2013 (UTC)
Any system that is required to satisfy a sufficiently large number of use cases will become complicated and have aspects that are hard to work with. With good design and planning one can help control where the difficulties start to appear, and make important use cases as easy as possible, but no amount of planning can save you from the fact that some things will remain hard. Wikitext is good for some contexts, hard for others, and very hard for a few. VE and the associated changes with Parsoid and the HTML+RDFa backend will undoubtedly change that balance. Some things that are hard today will become easy, and some things that are easy today may become hard. However, we need to be careful about how we find the right balance. Personally, I don't tend to view technical tasks like computability and parser closure as high priorities. Yes, doing them well opens some possibilities, but most user needs for reading and editing are far less technical than that, and I don't think anyone would want to see the pursuit of technical goals make Wikipedia harder to maintain and grow. We need a good balance. Dragons flight (talk) 01:44, 27 July 2013 (UTC)
Diego touches upon an important point here. One problem with VE has nothing to do with the quality of the software, but the fact that it is a change being forced upon the community who are expected to accept it, willy-nilly. Although the official line is that Wikipedia is community-driven, I've seen repeated episodes where someone attempts to exert dictatorial power on the community, is rebuffed, & either learns the important lesson that only change backed by consensus is durable or that person leaves. (And by "someone", I'm not looking at any specific person as I type that: many individuals have tried this & either learned the lesson or left.) However, the Foundation does have the clout to overcome community resistance to this, which leads to the other possible response -- the community votes with its feet. Core contributors stop editing either entirely or for the most part, housekeeping tasks go undone, & bots stop running. Vandals & tendentious editors run wild, overwhelming the volunteers left, who then leave in turn, causing a vicious cycle of decline.

I'm writing this as someone who has been around Wikipedia probably longer than anyone else in this thread, who has watched many valuable contributors go thru the life cycle of novice/experienced/veteran/cynical old-timer/burnout. In some cases, burnout was inevitable; in other cases, it could have been avoided & the institutional memory has learned to handle this better. But so far Wikipedia has survived the departure of these core members because a new supply of volunteers was entering & becoming proficient at the right speed. But this supply has been drying up not because of difficulty of wikimarkup--which is about as difficult to master as HTML--but for reasons no one has yet determined. (My theory is that the number of people who think writing an encyclopedia is fun is much smaller number than the PTB think, & most of these people either have been contributors or currently are.) I can see Visual Editor killing Wikipedia by the clumsy & callous manner it has been deployed so far, a manner that threatens to drive away the core contributors who do most of the work here. -- llywrch (talk) 22:23, 26 July 2013 (UTC)

David, I can feel the pain. The point is from the user POV the wikitexteditor is a success and it is the user POV that we need to address. As someone with a strong coding background I concede that if we were doing it again we should never have started with such flakey definitions. To the new user, a lack of a VE was never a problem merely an irritant. They are all used to wacky visual interfaces from buying a U-Bahn ticket, buying petrol, using an ATM- but questioned on why they find WP difficult they name the irritant, as they don't understand why they feeled harrassed by policies etc.
WMF can share the problem though by adopting Agile, or (any other methodology) and do proper liaison with the stakeholder, develop the functional specification together. As it is, because we have Parsoid that nearly works, WMF is repeating the design decision made when the PCRE parser was chosen. We should use it because it is there. Now, put the current project on hold- the first stage is to establish what the all users require from the editor and establish how stakeholders should included into the development teams. Enough from me- this is getting repetitious. — Preceding unsigned comment added by ClemRutter (talk • contribs) 09:11, 27 July 2013 (UTC)
Amen to that. David is right that Wikitext is a disaster -- but replacing it with another ad-hoc half-finished cock-up that's worse is not the answer. And the really galling thing is that the current Parsoid/VE/JS/HTML/RDFa strategy is so ingenious, and so nearly right that it could quite easily be made into something workable, if time out could be taken to do so, instead of adopting a PR-led strategy of shoving it, half-finished, down the user-base's throats, and calling the resulting gagging noises "pushback". It's dispriting. It's like seeing someone launching an otherwise quite well built new sports car with square wheels and blaming the world for not buying it en masse, then rejecting any calls for round wheels as being the ignorant complaints of non-experts. Or, as I've said before, Windows 8.
Wearing my consultancy hat, I'd say the real disaster here is the JS editor component of the system: so bloated, so slow, so buggy, so lacking in features and, overall, so half-finished! If you were to rip-and-replace that, keeping the whole rest of the VE system as-is, you'd probably have a workable system. -- The Anome (talk) 11:06, 27 July 2013 (UTC)
There are longstanding bugzilla requests that would make the existing editor significantly better than it is. Edit conflicts could be greatly reduced in various ways, the simplest being accepting the hash sign as denoting a separately editable thread. All new editors could have auto sign defaulted on on their userids so when they edit a talkpage by default it adds four tildas to their edit. Unfortunately the existing system has been deprioritised for development, though I suspect for a fraction of the cost of v/e some real and worthwhile improvements could have been delivered. ϢereSpielChequers 21:16, 27 July 2013 (UTC)

What is JS Editor?

What is the JS editor component of the system? Robert McClenon (talk) 14:13, 27 July 2013 (UTC)

The javascript software that provides the actual visible visual editor user interface within the browser. It's unbelievably slow and clunky on large pages, and the UI design is less than intutive: until very recently, it didn't even do a particularly good emulation of the standard Microsoft Word-like semantics that most people expect from a web based editor, let alone do a good job at doing anything wiki-specific. If you take a look at Wikipedia:VisualEditor/Feedback, you can see that they're still making it up as they go along, a clear indication that vast amounts of design were simply never performed before launch. It's generally a good idea to have at least a complete conceptual design for your UI before you start writing your implementation, not to try to bolt it on after, and even less so to launch the system before you've even completed the design. This is not rocket science, it's elementary stuff taught in every CS course.
This is such a shame, because it's not at all impossible to do this well, with a good clear design and a well-managed software delivery effort -- compare it, for example, to things like Google's zippy and responsive Javascript-based Google Docs UI, and you can see that there's a world of difference between the two, at every level, even like-for-like between browsers and connections. And the workflow! It's terrible, and they're still hacking at it: almost as if no-one really thought it out properly before launching it.
It's still not too late to fix this. Here's an instructive article, for anyone interested: http://www.codinghorror.com/blog/2006/05/the-long-dismal-history-of-software-project-failure.html
From the article:
"Failing is OK. Failing can even be desirable. But you must learn from your failures, and that requires concerted postmortem introspection and analysis. I'd like to think that a large part of the statistical improvement cited above is attributable to sharp project managers and savvy developers who studied the first CHAOS report. Once you know what the common pitfalls are, it's easier to avoid them."
Really: early failure is OK in software development -- I mean it, it really is, and no-one in this is the bad guy. But not learning from individual project failure is what causes systemic failure, which isn't OK, and generally can't be recovered from without management changes. We have our failed system, and the opportunity to learn from it actually represents a fabulous opportunity for the WMF to improve their software development methodology. The only question now is whether the current process will get pushed through to the bitter end, in order to show higher management that they "were right all along" -- i.e. the process which resulted in shipping the much-reviled Windows Vista -- or whether it can be turned into a success by taking a good hard look at what went wrong, at every level of the process ("did we actually launch before we'd finished the design? Why, why, why did we do that?") take the time to do a complete project review, and this time do it right, no matter how long it took -- the process which resulted in shipping Windows 7, which even I will grudgingly admit was quite a fast, solid, workmanlike OS, and I think in years to come will be recognised as the moment of Peak Microsoft, before Microsoft's technology-driven culture was finally overruled completely by the entirely marketing-driven Windows 8. -- The Anome (talk) 19:23, 27 July 2013 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia_talk:VisualEditor/Archive_4&oldid=1084183866"