Testwiki:VisualEditor/Feedback/Archive 2013 9

a sensible way to edit {{div col}} sections

I know this has probably been asked before but a more intuitive way to edit an article containing Template:T1 sections is needed. In a list article like List of topics related to Cornwall there are many sections with lists broken into multiple columns. What I would like to happen is that you just click on the list and add an item. Just like you would expect to happen for a normal list. Having to go through the template dialog with a rather too small edit box is not visual enough. There are quite a few other templates where you really want to edit in-place rather that with a dialog. Quite how this could be done I'm not sure, maybe some hints could be given in the templatedata, maybe some template specific plugin is needed. This is a big problem as it is making a large number of articles hard to edit.--Salix (talk): 07:11, 18 July 2013 (UTC)

Why can't we just have VE accept Wikimarkup? So you'd type '''text''' [[File:foo.jpg|200px|thumb|caption]] and it would automatically add that to the page where you added it? If Wikimarkup was actually part of VE, it'd make templates far easier, as you could just choose to be shown the wikimarkup for them whilst editing, then have them "snap back" to visual mode when done. You could have a toggle to switch between that behaviour and a strict visual mode. Adam Cuerden ^(talk) 08:33, 18 July 2013 (UTC)

I think thats a separate issue. Indeed clicking on the template dialog for a Template:Tl section will allow you to edit the raw wikitext. What I'm looking for is a visual way of editing the content.--Salix (talk): 09:01, 18 July 2013 (UTC)

<thinking-aloud> For multi-part templates (which is what these col-* templates are) that build a single dom structure (a 2-column table in this case), if Parsoid can mark up the HTML that lets VE distinguish between top-level page content or parameters (and hence editable) vs. content that comes from the template (and hence NOT editable), this would be possible. Right now, VE cannot distinguish between editable and non-editable HTML pieces since Parsoid gives it wikitext for top-level content (See Template Content Spec for the gory details). Also, Template:Phab covers the other piece of this puzzle (visual editing of template parameters). Anyway, still some work to be done before this is feasible. </thinking-aloud> Ssastry (talk) 23:57, 19 July 2013 (UTC)

I wonder if there's any way around that, short of doing columns differently than through a template? Tech-people, any ideas? --Maggie Dennis (WMF) (talk) 19:59, 19 July 2013 (UTC)

This is at least related to Template:Phab and Template:Phab, and is a result of VE and Parsoid having difficulty with templates that produce subsets of table markup.—Kww(talk) 20:21, 19 July 2013 (UTC)

See also #Bulleted lists below, which is the same problem. PamD 20:15, 19 July 2013 (UTC)

Visual mode should allow you to edit source

Hi Wikipedia,

I know you're working hard on the site infrastructure. There are plenty of us who appreciate the blood, sweat and toil.

The visual editor looks slick. But please know that people like me would be thrilled to be able to edit source code (C, C++, etc) from the visual editor. Until then I'll probably switch back to editing the page source directly.

Thanks, TMI Themysteriousimmigrant (talk) 16:34, 18 July 2013 (UTC)

As in, things in <code> tags? Being worked on :). (I don't think we'll have a C++ editor and compiler in the editor for a long time, although it would be wonderfully recursive). Okeyes (WMF) (talk) 22:03, 19 July 2013 (UTC)

Visual Editor Userbox?

I took a quick look around, but did not see a userbox which one could append to their user page indicating they are either using or trying to use Visual Editor as their primary editor (vs. Classic). Hmm, could be a parameter taking userbox which would allow one to select either VE or Classic as their preferred editing mode. --User:Ceyockey (talk to me) 23:39, 18 July 2013 (UTC)

There are three userboxs: Pro-VE, Neutral-VE, and Anti-VE.--Dom497 (talk) 00:05, 19 July 2013 (UTC)

Template:Ec I'm not aware of such a userbox either. Wikipedia talk:Userboxes/Ideas is apparently the place to discuss ideas for new userboxes, while Wikipedia talk:Userboxes/New Userboxes is for announcing, discussing and testing newly created ones. 00:09, 19 July 2013 (UTC)

@Ceyockey: How's this? Pseudonymous Rex (talk) 02:06, 19 July 2013 (UTC)

I think Psedonymous' draft userboxes are more neutral in tone than the Pro/Neutral/Anti box set. --User:Ceyockey (talk to me) 10:52, 19 July 2013 (UTC)

Fooling around with indenters

Template:Tracked Using Firefox 21.0

Here's what I tried: Place a colon, semicolon, or asterisk at the beginning of a paragraph in VE. When it saves, the indenter is preceded by <nowiki>, which makes sense. As far as I can tell, the closing </nowiki> tag is placed immediately before the next piece of wiki markup in that paragraph. In some cases, this will be at the very end of the paragraph.

The problem: Upon entering VE again, the first line of the paragraph will be blocked off with the green "no edit" bar, but the rest of the paragraph will appear to be editable, even though it is not. --Cryptic C62 · Talk 03:27, 19 July 2013 (UTC)

This is a known bug, see Bugzilla:50841. Thryduulf (talk) 08:39, 19 July 2013 (UTC)

There are some peculiar side-effects. To demonstrate, prepare a paragraph of text several lines long, with no Wiki markup until a wikilink several lines down, and some further text after that. This test piece is a suitable sample. Test done with Win7/FF22.0.

• In VE edit mode, add five spaces at the start of the first line. They appear on the screen.
• Save the page. The spaces are no longer visible.
• Examine with Edit source. The spaces are present, but everything from the start of the paragraph until just before the wikilink is bracketed by a <nowiki> ... </nowiki> pair.
• Click "Edit". About one space is now visible at the start of the paragraph, with the cursor blinking to left of it. Pressing the right-arrow key to move the cursor skips it straight to the wikilink.
• Try to edit. Moving the pointer over the first line covers it with green stripes, changes the pointer to a red "prohibition" sign, and gives the message "Sorry, this element can only be edited in source mode for now."
• Positioning the pointer (to try to edit) anywhere after the first line but before the wikilink covers the first line with green stripes but does not give a message or change the pointer. Clicking in this area to try to position the cursor has no effect, but if you now type something, everything before the wikilink (the whole content of the nowiki pair) is deleted.
• Editing after the wikilink is normal.

This will all be deeply confusing to a newbie, and trying to indent the first line of a paragraph is not an uncommon newbie mistake.

PS: I see that bug is marked "resolved fixed" so I will try this again in a day or so. JohnCD (talk) 09:39, 19 July 2013 (UTC)

editing Baird's Trogon - problems

Template:Answered so how do I get out of VE? Reefswaggie (talk) 11:58, 19 July 2013 (UTC)

and if I am the Senior Specialist, you guys are in trouble! lol Reefswaggie (talk) 11:59, 19 July 2013 (UTC)

see the FAQ at the top of this page, or the big yellow box when you edit this page Ignatzmice•talk 12:08, 19 July 2013 (UTC)

Yes, we are.—Kww(talk) 14:45, 19 July 2013 (UTC)

Template:Replyto Regarding adding a flickr photo, you need to upload it to Wikimedia Commons; after that, you can add it to a Wikipedia article. (For finding and adding a photo, VE has some advantages in it's search function, so you might think about using VE just for photo adding).

On the left side of your screen, you'll see "Toolbox", and in that section, "Upload file". (A photo is one type of file.) However - and with Wikipedia, there quite often is a "however" - you must own that Flickr photo, or the owner of it must have put it into the public domain, or given it a license (one of the Creative Commons licenses that we accept), before Wikimedia Commons will accept it. All these restrictions are because Wikipedia allows its content to be used by anyone for any purpose - commercial or otherwise. So we don't want to have images at Wikipedia where such sharing-by-everyone would violate the copyright of the image owner. -- John Broughton (♫♫) 16:08, 19 July 2013 (UTC)

Thanks for the information. I think I better leave the flickr photos till I get a bit more experienced. And am I correct in assuming that adding "Wiki VE Sr Specialist" to my CV right now would be committing career suicide? :)

Can't save changes!

See subject 1Z (talk) 14:44, 19 July 2013 (UTC)

Template:Replyto Browser and operating system? Do you have JavaScript disabled, or anything like that? Ignatzmice•talk 14:51, 19 July 2013 (UTC)

external link problem

I cannot figure out how to add an external link to a citation's source in this Visual Editor. -- NewzealanderA (talk) 16:49, 19 July 2013 (UTC)

I'd suggest using wikimarkup for now. VisualEditor is extremely feature-light and buggy just now. To turn it off, go to Preferences (it's a link in the upper-right), switch to the "Gadgets" tab, and look for the one to disable VisualEditor. Adam Cuerden ^(talk) 17:20, 19 July 2013 (UTC)

If you are adding just a plain external link, then you add it in the same way you do an internal link. Just type or paste the url into the box you would put the article title for an internal link. If you are using the reference template, then just type or paste the URL into the "URL" field in the template editor. Referencing does work in VisualEditor, but the user interface to add them does need some major improvement. Thryduulf (talk) 17:35, 19 July 2013 (UTC)

Bulleted lists

I tried to delete one entry and a blue box appeared and I was unable to edit. Also, when I try to do an edit next to a wikilink it links my edited word as well. I'd like to comment too. I've been editing since 2006. I learned to edit by looking to see how others managed to get things to work. Which was not really hard at all. But I can say for a fact that if this system was in place when I started editing I would have never been able to become an editor. I'm not dumb, in fact my IQ is in the upper 5%, but I'm pretty old. I learned to type on a black Underwood. Even if all the bugs were fixed, I'd still not be able to use it except for things such a tweaks and copy edits. Gandydancer (talk) 17:54, 19 July 2013 (UTC)

Bulleted lists do usually work fine. Looking at your contributions though I'm guessing you were trying to edit the one at Lac-Mégantic derailment#See also. If so then the issue is that it is in a two-column layout. VE can't edit multiple-column sections directly at the moment, but it can edit them using the "transclusion editor" (aka template editor). When the blue box appears, you should see an icon in the top right corner of the box. Click that and you are taken to the template editor. In the left column click the line marked "Content" and you can edit the source on the right. I know that's not very user friendly, but it's better than the last time I tried it so progress is being made!

Text being included as part of a link when you don't want it to is known, you can read about it (and comment if you wish) at Bugzilla:51531.

Visual Editor is still very much in development and not all the features are ready yet. The user interface will also be improved as time goes by, but I agree it isn't going to be for everyone and certainly isn't now. You can always choose to use the source editor (the one you've been using since 2006) either by clicking "edit source" rather than "edit" at the top of the page or on edit section links. Alternatively you can disabled VisualEditor in your preferences, details are in the FAQ at the top of this page and in the yellow box above the edit window when you edit this page. Thryduulf (talk) 18:11, 19 July 2013 (UTC)

No the list is at Hors d'oeuvre--you can try it yourself. As for the rest of your advise, and I don't mean to be snarky, but of course I am aware that I have a choice and can use SE--I'm using it right now. I am aware that I can delete it as well, but I do like it for small tweaks and copy edits. Gandydancer (talk) 18:37, 19 July 2013 (UTC)

The list at Hors d'oeuvre is another example of a mutli-column template using divs, so the instructions above do work. The icon to enter the template editor though is placed at the right margin of the window (in this case over the image in the infobox) and so not very obvious. I'm sorry if I came across as patronising at all about turning the visual editor off, but its easier than receiving flack for allegedly trying to hide how you can disable it that I've received on a couple of occasions. Thryduulf (talk) 19:37, 19 July 2013 (UTC)

I was curious and looked at this ... yes, it's a two-column list within Template:Tl, so VE refuses to let you edit the items in the list in any user-friendly manner. Particularly confusing as on my computer it displays as a single-column list when I read the article or edit it in VE, until I try editing the Section in Edit Source and it sets out in two cols (because it no longer has to share width with the infobox). I know I reported this problem a long way back, and it went into Bugzilla, where the developers seemed to say something like "It would be better if xyz (I forget what) was used for multicolumns", rather than taking the problem seriously. Yet another instance where VE does not provide the expected facility to do a straightforward edit: this is a bug, not an enhancement. I'll try and find the Bug number... Yes, Template:Phab. Note comments 3 and 4, and the fact that it's listed as "normal enhancement", although it totally prevents a lot of perfectly normal editing. The tone from the devs seems to be "Well you shouldn't be trying to do that anyway...", rather than "OMG that's a serious problem because there are masses of instances of text being within templates and we need to fix this ASAP." PamD 19:39, 19 July 2013 (UTC)

See also the section "a sensible way to edit {{div col}} sections" above: same problem. PamD 20:17, 19 July 2013 (UTC)

Why can't VE support Wikitext?

Why, if I type, say: * [[Link]]

...can't VE recognise the Wikitext, and simply convert it into graphical display after a, say, 5 second delay, or when the user presses a "convert" button? Since it can already recognise Wikitext being typed, it seems like this should be a trivial feature. Adam Cuerden ^(talk) 19:44, 19 July 2013 (UTC)

It can recognise certain types of wikitext, because it's told to look for it. As I understand it having it converted would require, every time a user types markup, the VE/Parsoid to essentially go through the save and edit renders and conversions. This would be incredibly resource-intensive. Okeyes (WMF) (talk) 20:22, 19 July 2013 (UTC)

So have a button to convert highlighted Wikitext as a temporary step? Adam Cuerden ^(talk) 21:12, 19 July 2013 (UTC)

There might be a case for supporting the main link forms...

• [[wikilink]] and [[wikilink |anchor]]
• [URI] and [URI anchor]

...in a future release. - Pointillist (talk) 21:32, 19 July 2013 (UTC)

Adam, other than requiring a user to manually say "I want this converted" that doesn't seem to solve for the underlying problem. Okeyes (WMF) (talk) 22:00, 19 July 2013 (UTC)

Well, that's about the only way I'd ever want to use it: if it let me easily switch to using Wikimarkup whenever I wanted to. So, you know, figured you'd want to hear what it'd take to get power editors on board. Adam Cuerden ^(talk) 23:46, 19 July 2013 (UTC)

Template:Replyto - Would it really require lots of computing cycles if an editor were able to click a "Wikitext" button, and in the resulting input box, type/paste some wikitext directly, then have Parsoid/VE go through the save and edit renders and conversions process just for that wikitext - inserting the results into the existing VE display? It would be tremendously useful, for example, for an editor to be able to use a tool that generates wikitext for a full citation (see, for example, Wikipedia:Cite4Wiki) and to use that tool's output within VE. Why make editors choose one or the other? -- John Broughton (♫♫) 00:28, 20 July 2013 (UTC)

I just want to leave this here. It is a screenshot from a very early demo where you could have both. Chris857 (talk) 00:45, 20 July 2013 (UTC)

Wikipedia:Village_pump_(technical)#switch_editor.js might at least be a start. I prefer the prototype Chris links - was there ever any polling of anyone but brand new users to see which direction VE should go? Because that should have been the base. The columns'd probably need some work, but creativity could have got around it.

Perhaps I'm wrong, but the only user research the WMF talks about is on new users that have never edited before. What people want in the first 10 minutes may not be what they want later, and so I'm not really surprised that VE has failed to catch on so spectacularly. Adam Cuerden ^(talk) 00:48, 20 July 2013 (UTC)

Creating collapse boxes

I have experimented with creating collapse boxes in VE. Unlike many templates, collapse boxes require the use of two templates to produce one object: Template:Tl and Template:Tl. I have tried a number of different procedures, and have succeeded in creating a working collapse box.

Procedure 1: Hit transclusion. Add "collapse top". Add content "I like bacon." Add "collapse bottom". Apply changes. Before saving, I see Result 1. After saving, the collapse box does not appear. The wiki markup was saved:

{{Collapse top}}I like bacon.{{Collapse bottom}}

which doesn't work because the templates must be placed on different lines.

Procedure 2: Hit transclusion. Add "collapse top". Add content "I like bacon." Apply changes. Move down one line. Hit transclusion. Add "collapse bottom". Apply changes. Before saving, I see Result 2. After saving, success!

Procedure 3: Hit transclusion. Add "collapse top". Add content "I like bacon." with line breaks added before and after the text. Add "collapse bottom". Apply changes. Before saving, I see Result 3. After saving, success!

Two observations:

1. The problem with procedures 1 and 2 seems to be that, without padding the content, everything gets saved on one line. It should be easy enough to have VE do the padding automatically, yes?

1. Regardless of the procedure used, VE does not display the collapse box the same way it actually appears in the article (not WYSIWYG). Procedure 3 is close, but the box doesn't span the entire width of the page.

Using Firefox 21.0 on Windows Vista

--Cryptic C62 · Talk 03:59, 20 July 2013 (UTC)

I think that's a feature, as (1) the Template:Tl and Template:Tl are not supposed to be used in Wikipedia articles, and (2) The templates use unclosed HTML, and are not supported by mw:Parsoid. — Arthur Rubin (talk) 06:18, 20 July 2013 (UTC)

No "Wordstar" editing keyboard shortcuts

Those are in many editor's DNA, therefore every text editor ever made; includes them. One example: highlight desired string, - Shifted Del, Ins -- cuts that text, then puts it back (in effect instantly copies it to memory) ready to be pasted elsewhere (with another Shifted Ins). The keyboard parts takes about 1/8 second, the highlighting or cursor positioning is the time-hog here.

Shifted Del, Ins ...also works to cut (&copy) and past on every image editor I've ever used, as well as between different programs --it's universal. Other "Wordstar," & "Wordperfect" keyboard shortcuts: same-same.
--69.110.90.203 (talk) 14:45, 17 July 2013 (UTC)Doug Bashford

I'm not completely sure I understand what you are saying (I've never extensively used either word perfect or word star), but is bugzilla:33080 the same as your request? Thryduulf (talk) 15:43, 17 July 2013 (UTC)

Shifted Del does *not* work on Macs, for cutting/copying. Also, why not just use Ctrl-C, Ctrl-V? Those are universal across operating systems (Cmd-C, Cmd-V for the Mac) and applications, I believe. (Also, just to confirm, you can't paste images or wikitext into VE, only text, yes?) -- John Broughton (♫♫) 22:02, 17 July 2013 (UTC)

You can't paste wikitext into VE (well you can, but it will just get <nowiki>s around it and it wont function as wikitext). You can't currently paste images in, but I don't know if doing so is something that is intended to be added later or not. Thryduulf (talk) 23:12, 17 July 2013 (UTC)

It is not true that every text editor ever made; includes them; in fact, none of the text editors that I use includes WordStar keystrokes, nor would I want them to. As for Shifted Del, Ins ..., the last time that I used Wordstar the keyboard didn't even have an Insert or Delete key. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:12, 19 July 2013 (UTC)

Personally, I use vi much quicker than wordstar, and available through a firefox extension. My issue with the new editor was that my first edit completely destroyed the article and I got a warning for vandalism whilst I was working on reverting it. Got to laugh. RonaldDuncan (talk) 22:19, 20 July 2013 (UTC)

Modifying a reference

With the exception of minor text changes, modifying a reference should be the easiest of all tasks in a user friendly editor. After many frustrating false starts and a couple of near disasters I have finally worked out how to do it, and I wonder how many newbies and not so new editors will have the same experience. For the record the process that works at present is as follows:

1. Click on the ref hotlink - the ref icon is displayed.

2. Click on the ref icon - the ref dialog is displayed.

3. Click on the ref details - the transclusion (??) icon is displayed.

4. Click on the trans icon - the template details and current parameters are displayed.

5. From here, proceed as for a new ref (within the limitations described in the previous two items)

Downsize43 (talk) 02:45, 19 July 2013 (UTC)

Unfortunately this only works if the existing ref contains "URL=" and "source=" as well as the actual URL and source name. If not the source name is displayed in the ref details as an active link, and the transclusion icon is NOT displayed when the user attempts to select (click on) the ref details. NFA is possible in VE for those links. Downsize43 (talk) 11:36, 19 July 2013 (UTC)

Raised Bugzilla 51725. My guess - Enhancement request or lower priority. Suggestion: Write a bot to find the problem refs and put URL= and source= tags in them. No idea what to do with the other info in them, which is infinitely variable. Downsize43 (talk) 07:06, 20 July 2013 (UTC)

Editor for TemplateData

Editor for TemplateData

Hi, I've translated a gadget created on frwiki for visually editing TemplateData. It's available at User:NicoV/TemplateDataEditor.js. To use it, simply add importScript('User:NicoV/TemplateDataEditor.js'); in Special:MyPage/skin.js. More explanations on how to set it up at User:NicoV/TemplateDataEditor. --NicoV ^{(Talk on frwiki)} 23:03, 19 July 2013 (UTC)

Thanks. I've implemented and will try it out. --User:Ceyockey (talk to me) 01:29, 20 July 2013 (UTC)

I've amended the instruction, since Special:MyPage/vector.js won't work for Monobook (etc.) users. The link Special:MyPage/skin.js automatically goes to the relevant .js file for your current skin. --Redrose64 (talk) 07:18, 20 July 2013 (UTC)

Categorized Citations

Many instructional institutions do not allow the use of Wikipedia articles as valid references, but this may be circumvented by finding the required information on Wikipedia and using the source for the information as a reference. Unfortunately, not all links on Wikipedia are of scientific/academic standards which can make this quite time consuming.

In order to help make this process easier, I would like to suggest that you add a colour change to scientific article in-text citations which meet traditional academic standards for references (such as those with a pmid number or a number in another reputable scientific database). This will allow for the rapid determination of which articles can be cited in academic papers without spending time on those that can't.

A darker blue may be used to make it obvious that it is a reference (for those that don't keep up with updates), but something easily distinguished from the current colour (maybe a lime green or orange) would be even more beneficial. — Preceding unsigned comment added by 184.99.241.125 (talk) 06:28, 20 July 2013 (UTC)

Judging by the lack of responses, I suspect that other editors don't think this posting belongs on this page. It does seem like the sort of thing that could be posted at WP:Village pump (proposals), since it's really not so much about VE as it is about how links are displayed. That's a community decision, not just a technical question. -- John Broughton (♫♫) 00:41, 21 July 2013 (UTC)

Sheesh

You get loads of money and run one of the most well-known wesites in the world, yet when your website changes, you don't have the common sense to update your help file? Sheesh. 86.19.115.227 (talk) 07:12, 20 July 2013 (UTC)

I wouldn't characterize the budget as having "loads of money". My understanding is that most of the money goes to hardware and large-scale meetings, with very very little allocated to content editing. --User:Ceyockey (talk to me) 15:28, 20 July 2013 (UTC)

(ec) There is, in fact, some documentation: WP:VisualEditor/User guide. As for all the other Wikipedia help pages, they are largely or completely written/updated by volunteers (regular editors), not the paid staff of the Wikimedia Foundation. I don't know of any plans to use paid WMF staff to rewrite these.

At the moment, speaking only for myself, I'm not willing to spend much time rewriting help pages (and there are hundreds of these) for software that is in beta, and has had scores of recommendations for user interface changes. When it's less buggy, and the obvious UI improvements have been implemented, then I think there will be a lot more willingness in the volunteer community to improve these help pages. Until then, the User guide and a few other things (I know there has been some work on the Tutorial) are likely to be the only documentation reflecting the existence of VE. -- John Broughton (♫♫) 15:30, 20 July 2013 (UTC)

I'll add that one of the hallmarks of good user interface design is that documentation for basic functions need not be consulted to be productive; rather the primary goal of documentation for self-explaining interfaces is for development and historical decision making purposes. I'm not saying that the current VE is self-explaining, but that the aspiration should be that basic functions should not require consultation to documentation. --User:Ceyockey (talk to me) 15:46, 20 July 2013 (UTC)

Another of the hallmarks of good user interface design is that designs are actually tested with real users, and their feedback informs the next iteration of the software, including making the software as self-explaining as possible. Unfortunately, that didn't happen with VE (or, at least, with many of its important functions - categories, images, templates, and references, for example). The best that can be done at this point is to provide some documentation for the software we have, as opposed to the (self-documenting) software we should have. -- John Broughton (♫♫) 19:38, 20 July 2013 (UTC)

Some performance notes

Looking at the last two days (16 and 17 July) we see:

All registered user article edits using source (wikitext) editor	118,380	91.1%
All registered user article edits using VE	11,464	8.9%
New user (registered on or after 1 July) article edits using source	6,610	64.2%
New user article edits using VE	3,678	35.8%
Anon article edits using source	62,101	88.4%
Anon article edits using VE	8,153	11.6%
Older editor (registered prior to 1 July) article edits using source	111,770	93.5%
Older editor (registered prior to 1 July) article edits using VE	7,786	6.5 %
Change in total (daily) article edits since before VE became default on 1 July (comparison: 18-30 June)	-4.5%
Change in registered user article edits since before VE became default	-2.2%
Change in anon article edits since before VE became default	-8.6%

As shown, the individuals most likely to choose VE are newly registered user accounts. Anons are only a little more likely to use VE than registered users. This suggests that many of the individuals who edit anonymously were actually familiar with the source editor and continue to prefer it even though they edit anonymously. (That's rather surprising to me.) Even though new users are most likely to choose VE, they still go with source editing 2/3 of the time. Since the introduction of VE, article editing rates are down slightly. For the length of time considered, a change less than about +/- 6% is consistent with random variability, so these fluctuations are not necessarily indicative of anything. However, it will be interesting to look at changes over a longer time period. Whether or not there is a meaningful drop, we can probably rule out the possibility of any large immediate editing surge as a result of VE's introduction. Of course, this only looks at the short-term reaction to VE. Only time will tell whether VE ultimately becomes popular. Dragons flight (talk) 03:56, 18 July 2013 (UTC)

This is consistent with my cynical view that 64.2% of all new accounts and 88.4% of anonymous edits are sockpuppets.

On a serious note, if WMF's theory about the utility of VE holds any water, we should see a dramatic upturn in people with a low edit count, as people that previously gave up when presented with a screen full of wikitext instead proceed to make productive edits. Detractors would say that by the time an editor is making his fifteenth or twentieth edit, he's figured out how to get to the source editor because no one could survive to their fifteenth edit using VE. Can your data analyser sort people by edit count and place them in some kind of rough bands?

That -8.6% change in anonymous edits is interesting, though. I wonder how it corresponds to the A/B test results.—Kww(talk) 04:25, 18 July 2013 (UTC)

Another interesting thing to find out (but I suspect it would require WMF help to find out) is how many of those new users using the source editor are people that previously edited anonymously, but created an account solely in order to disable VE using a gadget. That would contribute both to the strong preference for new accounts to use source and the decrease in anonymous edits.—Kww(talk) 04:31, 18 July 2013 (UTC)

Thanks for the information. Would you define "new user", and what is the comparison period (dates)? -- John Broughton (♫♫) 04:33, 18 July 2013 (UTC)

New user means user names created on or after July 1st (when VE was launched). Last two days means July 15, 22:00 UTC to July 17, 21:59 UTC. The baseline edit rates to measure the change since rollout are taken from June 18th to June 30th. Dragons flight (talk) 04:47, 18 July 2013 (UTC)

Can you please measure bytes added instead of just edits made, as additional columns? I have a feeling that people doing the most actual work are using the VE even less than people making small edits. EllenCT (talk) 04:49, 18 July 2013 (UTC)

I don't have any easy way to do bytes. I might look into it later, but not soon. Dragons flight (talk) 04:51, 18 July 2013 (UTC)

You can get a rough sample of magnitude byte changes with this unix shell command:

$ curl -s h'ttp://en.wikipedia.org/w/index.php?title=Special:RecentChanges&limit=5000&namespace=0' \
  | grep class=.mw-line- | sed 's:^.*">([+-]\([0-9]*\).*userlink"\([^<]*\)</a>.*User_talk\(.*\)$:\1 \2 \3:' \
  | grep '^[0-9]' | awk '{if (/redlink/) {r=1; ru+=$1} else {r=0; bu+=$1}; if (/VisualEditor/) {ve+=$1; if (r) {rve+=$1} else {bve+=$1}} 
          else {se+=$1; if (r) {rse+=$1} else {bse+=$1}}} END {print ve, se, ru, bu, rve, bve, rse, bse}'

I've been looking at that over the past day and it shows that the magnitude number of bytes is about the same as the number of edits, with about 10-13% in the visual editor depending on time of day. The detailed statistics aren't particularly interesting. 97.124.165.240 (talk) 01:51, 19 July 2013 (UTC)

Template:Ping While VisualEditor is now enabled for IPs, it will only show up on pages whose cache hasn't been purged yet (via edits or otherwise). That's why IPs often still see the wikitext editor. The plan is to observe VE usage by IPs and potentially trigger a rolling cache purge if things seem reasonably stable. Also keep in mind that VE isn't enabled on all namespaces. Finally, browser blacklisting (IE etc.) affects this data. We've got a few dashboards in the works that track this data on an ongoing basis - let me confirm that these are sufficiently audited for accuracy to share. Eloquence* 06:11, 18 July 2013 (UTC)

Erik, as noted above these are restricted to article edits, which should address the namespace issue. Also, are you sure about the caching? Isn't default Javascript cached separately from individual page HTML? I tried logging out, loaded 30 random articles, and didn't see a single example where VE wasn't present. Dragons flight (talk) 06:42, 18 July 2013 (UTC)

I logged out and loaded 30 articles from special:recentchanges, and they all had the VE edit button. John Vandenberg ^(chat) 07:11, 18 July 2013 (UTC)

I also run ?action=purge on these pages, and the VE edit button is still there after the purge. Is there anything else I can do to help test? John Vandenberg ^(chat) 07:22, 18 July 2013 (UTC)

Template:Ping, do you have an estimate on how many pages on English Wikipedia have had their cache purged and therefore now have VE enabled for IPs? I've seen elsewhere that lots of pages have been purged by null edits to templates, which might help explain why we're seeing VE on almost every page we can find, including pages that havent been edited for years. John Vandenberg ^(chat) 04:03, 22 July 2013 (UTC)

New users won't come without a huge promotion campaign. I don't see any yet and I suspect they suspect that not everything is ideal. --194.44.219.225 (talk) 09:07, 18 July 2013 (UTC)

I've done some rewording of the table, for clarity, and also calculated what "older" registered editors did ("older" is total registered minus registered "new" user).

What's interesting to me is:

• The "uptake" for "older" registered editors is only 6.5%. Yes, that's affected by those using IE and other web browsers who won't see VE at all, but if they represent 30% of all "older" registered editors, and would edit with VE at the same rate as other web browser users, the 6.5% would increase only to 10%. And offsetting that 6.5% (or 10%) is the number of edits (in the hundreds per day?) that older editors are doing, in VE, for testing/experimental purposes. That's a vote, in my opinion, that most editors either don't find wikitext editing so difficult, or that all of the existing defects of VE (including UI/UX mistakes) make it a poorer choice than dealing than just dealing with the learning curve for the (non-buggy) wikitext editor.

• As pointed out above, the use of VE by anon (IP) editors is so low, barely more than by registered editors. If you put that together with the drop in IP edits, perhaps that means that a lot of IP editors, when introduced to VE, find it so intimidating that they either figure out how to get to the wikitext editor, or decide not to edit at all? Or, alternatively, IP editors aren't, as we usually think, mostly brand-new to Wikipedia? -- John Broughton (♫♫) 22:15, 18 July 2013 (UTC)

• My experience is that the IP editors are generally quite experienced. They edit anonymously by preference.—Kww(talk) 22:41, 18 July 2013 (UTC)

Do the stats differentiate between browser 'edit source' edits and other edits from Huggle/Twinkle/AWB/bot/API, or does the headline 91% include all of those? Rjwilmsi 21:48, 19 July 2013 (UTC)

Flagged bots were excluded from all counts, no effort was made to differentiate other kinds of tools. Dragons flight (talk) 17:58, 20 July 2013 (UTC)

• It is really badly broken. Could you produce stats for the number of articles that immediately had to be reverted after being destroyed by the new editor. I got warned for vandelism whilst I was trying to fix up my first edit. RonaldDuncan (talk) 22:22, 20 July 2013 (UTC)

meta:Research:VisualEditor's effect on newly registered editors/Results

The A/B test, June 25-28, showed that new users using wikimarkup made more edits, more "productive edits", spent more time editing, and were far more likely to start editing compared to those using the VisualEditor. Newcomers with the VisualEditor were ~10% less likely to save a single edit than editors with the wikitext editor.

A number of severe bugs with the VisualEditor, which were not solved before launch, are likely to blame for these results. Adam Cuerden ^(talk) 17:03, 19 July 2013 (UTC)

Thank you for politely pointing this study out, Adam. It would be nice to hear from Jdforrester to find out why given the profoundly negative feedback this product has received combined with empirical evidence that in its present condition it doesn't achieve any of the goals, he doesn't withdraw this deployment and delay all future plans for deploying this on other versions of Wikipedia. This is intended as a polite question, so I would appreciate it if detractors didn't pile on with insults. I'm told that the deployment schedule is Jdforrester's decision alone, and I'm extremely interested in understanding his reasoning.

The study is flawed in one way: it measures only edits reverted instead of edits that required correction. Most responsible editors, confronted with the common defects of VE, would choose to correct the edit by removing extraneous nowikis and similar glitches rather than completely revert them. That renders the conclusion that the editor creates "no additional burden" extremely suspect.—Kww(talk) 17:18, 19 July 2013 (UTC)

Template:Xt just as they would for syntax errors made by editors using the source editor. My gut feeling is that VE will produce more errors that need fixing, but without any data it is impossible to draw any valid conclusions. Thryduulf (talk) 17:24, 19 July 2013 (UTC)

This study was meant to be run for about two weeks, it got compressed to three days. I'm willing to give them some slack on a very-hard-to-evaluate metric for which they got far less data than they were supposed to. I agree the burden is likely underestimated, but the team was independent from VE, and likely never even considered VE itself could cause burden when designing the study. Adam Cuerden ^(talk) 17:33, 19 July 2013 (UTC)

It was never planned to run for two weeks; what is your citation for that? Okeyes (WMF) (talk) 21:01, 19 July 2013 (UTC)

It actually was. See [1], which gave the timescale as June 17-31st (Although this wasn't the best planning: June doesn't have a 31st). Likewise, [2], when the delay was noted, but before the schedule was updated, gives the start date as the 18th, with the second half of the experiment beginning on the 25th, and the experiment ending on July 1st. Adam Cuerden ^(talk) 21:17, 19 July 2013 (UTC)

Well, no. If you look, you'll see that one of those two weeks is for experiment deployment - in other words, gathering background data. The original plan was for 1 week of bucketing, and 1 week of data, not 2 weeks of data: it eventually worked out as 86 hours of bucketing, 72 of data. I know because I was involved in the design of the testing conditions (I just checked with Dario, our lead researcher: he confirms my memory is accurate). Okeyes (WMF) (talk) 21:50, 19 July 2013 (UTC)

Hence "extremely suspect", not "flat-out wrong".—Kww(talk) 17:36, 19 July 2013 (UTC)

As an idea off the top of my head, would "time taken to edit page" divided by "size of diff" be a useful measure of productivity to compare the efficient of the editors? So for example if VE took on average n minutes per 1k of diff and the source editor took 2n minutes per 1k of diff then would it be fair to say that VE was twice as efficient as the source editor? I know it's not something we have the data to do at the minute would would it be worth compiling it? Thryduulf (talk) 18:18, 19 July 2013 (UTC)

Not unless you can subtract 17 characters for every pair of nowiki tags in the output.—Kww(talk) 19:17, 19 July 2013 (UTC)

Actually, the study has another major flaw: the reduction in completed edits by new editors was not 10%, as stated, it was 43%. If 27.5% of editors were able to successfully make an edit with the wikitext editor and only 15.7% were able to make an edit with VE, that's a 43% difference. The formula is 100*((27.5-15.7)/27.5) , not 27.5-15.7.—Kww(talk) 05:36, 20 July 2013 (UTC)

The results of this A/B trial are actually less depressing than they might appear, because (as with everything to do with this release) it was premature. It is not surprising that new users presented with a buggy, confusing and undocumented prototype edited less and gave up sooner, and it tells us nothing about what the result of a comparative trial with a fully-functioning VE might be. JohnCD (talk) 21:57, 20 July 2013 (UTC)

In terms of long-term effect of VE, I agree that testing a buggy version doesn't help a lot. But in terms of short term effects, especially given the release of the software immediately after the completion of the study, but before the generation of results, it remains depressing. - Bilby (talk) 00:45, 22 July 2013 (UTC)

why is beta so buggy

I get a weird api error message. 31.126.193.88 (talk) 20:27, 19 July 2013 (UTC)

Oh dear :/. Can you copy-and-paste the message? Okeyes (WMF) (talk) 20:36, 19 July 2013 (UTC)

Because it really wasn't ready for Beta yet, but it was deployed anyhow to get feedback to help get it there. Zell Faze (talk) 14:33, 21 July 2013 (UTC)

FAQ- copyedit needed

Why is this change being made? The wikimarkup text in the old editing window is so complex that people who could become productive, experienced members of the community if the editing system were simpler are turned off upon attempting their first edit; read our longer explanation for more details.

Do we mean

• The wikimarkup text in the old editing window is so complex that people, who could become productive experienced members of the community if the editing system was simpler , are being turned off while attempting their first edit; read our longer explanation for more details.

• The wikimarkup text in the old editing window is so complex that people, who could become productive, experienced members of the community were the editing system simpler, are turned off attempting their first edit; read our longer explanation for more details.

Using the KISS principle, are we trying to say.

• We think that the existing wikimarkup system is too complex for new users. These users don't come back after their first attempt at editting so never become part of the community. Read our longer explanation for more details.

What ever you want to say keep the sentence structure simple- and avoid long words.-- Clem Rutter (talk) 15:55, 20 July 2013 (UTC)

Hi. I've copied this over to the FAQ talk page, since that page is for discussing changes to the FAQ and this one for issues that need developer attention. The developers are generally uninvolved with writing the FAQ. :) --Maggie Dennis (WMF) (talk) 14:37, 21 July 2013 (UTC)

Known Problems?

What's the status of Wikipedia:visualEditor/Known problems? Who is supposed, or encouraged, to add to it? It doesn't give any indication. Is it where editors are supposed to look before reporting problems on the feedback page, to avoid duplication? Is it a list of acknowledged problems in a more user-readable form than raw Bugzilla? Or what? I note that the very important topic of the inability to see hidden comments or Template:Tl-type templates doesn't seem to be listed. PamD 16:37, 20 July 2013 (UTC)

Its a page I put together which I though might be a good idea to get an overview of the state of the visual editor. About three or four people have contributed to it and anyone else is encouraged to add items to it. Feel free to add anything or reformat. Its very much a work in progress. See Wikipedia:VisualEditor/Feedback/Archive_2013_07#Known_issues for when the page was first discussed.--Salix (talk): 18:09, 20 July 2013 (UTC)

I was thinking of helping out with the page (I transcluded the "Limitations" section from the main WP:VE page so we could reduce some duplication). But, quite frankly, the ever-increasing number of reported bugs, and the slowness in fixing them (hidden text, for example, or the botched warning message about entering wikitext) are really discouraging.

And yes, the page could be used as a way to find out what bugs have been reported, and even to see if the bug reports accurately reflected what was wrong and how it best could be fixed, particularly for "enhancements". -- John Broughton (♫♫) 19:30, 20 July 2013 (UTC)

I've used it that way myself. I could help by adding issues I track, but really don't have capacity to update it generally. Would it be helpful for me to just add my items, or would that just result in stuff added by other than me being overlooked? I don't want to break its function. --Maggie Dennis (WMF) (talk) 14:42, 21 July 2013 (UTC)

I think any additions to the page are helpful. Its not got the same purpose as bugzilla, more a way of highlighting the main problems and maybe making it easier to find the appropriate bug numbers.--Salix (talk): 16:41, 21 July 2013 (UTC)

Feedback on Visual Editor by old-school/long-term member

I am (or rather, I must confess :D) an "old school" Wikipedia editor (registered in year 2005) and this new Visual Editor is simply confusing to me... I understand though that it might enable new members easier editing. Though my "complain" still stands that if you choose to edit just a section of an article (i.e. with Visual Editor by clicking [edit] and not the old way, as I just figured out it's possibly by clicking [edit source]...) there is no clear to an editor that he is editing just a section (and not the whole article). Wayfarer (talk) 00:01, 21 July 2013 (UTC)

It's a pretty big leap for those of us familiar with wikitext. :) I'm a little confused about your issue, though - are you saying that you'd like for the "edit" button next to sections to indicate that it is section specific? (At the moment, it actually isn't, unless you're doing it the old way. You are directed to the section you selected, but can actually edit anywhere on the page. But users have requested that be altered.) --Maggie Dennis (WMF) (talk) 14:57, 21 July 2013 (UTC)

It probably didn't occur to him that anyone would intentionally put a link with a false title by every section header, Maggie, and he's presuming that there's something about "edit section" that actually limits the edits to that section.—Kww(talk) 15:06, 21 July 2013 (UTC)

I don't really understand your perspective there. It says "edit". You hover over it, and it says "edit section." You press it, and it takes you to the section you want to edit. "Old school" editors may expect that editing a section will be limited to that section - and there may be good reasons, from a performance standpoint to so limiting it - but I think it's a bit much to call that "false." :/ The expectation that it will edit that section and that section only does not seem automatic to me, and it is taking you to do exactly what it says it will. --Maggie Dennis (WMF) (talk) 15:09, 21 July 2013 (UTC)

Saying that new users will expect see the whole page, and to be able edit the whole page, when the popup says "Edit section:" is a bit of a stretch. Chris the speller ^yack 16:29, 21 July 2013 (UTC)

I agree, it's not exactly false. It is misleading, and leads to increased edit conflicts. But that might be a feature of VE. — Arthur Rubin (talk) 16:34, 21 July 2013 (UTC)

Maggie, that comment saddens me, and makes me concerned that defending VE for so long is beginning to have an effect on your judgement. "Edit section" means just that: "edit section". Not "allow me to make changes to the entire page, but start my cursor out here". "False" is not only not a stretch, it's precisely descriptive.—Kww(talk) 16:41, 21 July 2013 (UTC)

Obviously I disagree, and I find your statement about your concerns on my judgment rather out of character for Wikipedia discussions...at least, the goal for Wikipedia discussions. :/ I'm all for making the software work as well as possible, but I do not see "edit section" as promising that I will be restricted to that section. When I click a section link in a table of contents, it does not restrict me to reading that section - I'm still able to move around. When I use my word process and search for a term to edit, it still lets me edit other areas of the page. This seems entirely reasonable to me, although it differs from the behavior of the existing editor and, again, it may not be the best behavior of the software for other issues. --Maggie Dennis (WMF) (talk) 18:18, 21 July 2013 (UTC)

My "goal" is to help you understand that your comments seem to play into a recurring theme: instead of treating feedback from experienced editors as well-placed and on-point, the very fact of the experience is generally treated as a reason to view the feedback skeptically, and relatively unreasonable definitions of English are employed to defend current behaviour. This has been the most frustrating part of dealing with VE so far.—Kww(talk) 18:31, 21 July 2013 (UTC)

I believe I can amply demonstrate that I have treated feedback from experienced editors as well-placed and on-point many times on this page. I've reported them and advocated for them - the experienced users offer some of the most salient suggestions for improving VE. However, that doesn't mean that I have to agree with your terming this language false. We are familiar with section editing meaning one thing, but newcomers may not share that expectation. --Maggie Dennis (WMF) (talk) 18:39, 21 July 2013 (UTC)

Your past history of reasonable behaviour is precisely why I attempted to give you a light nudge about the reasonableness of your position on this topic. You have, indeed, been the most generally reasonable WMF representative on the topic of VE.—Kww(talk) 18:47, 21 July 2013 (UTC)

Thank you. I'm fine with being told my perspective is way off, but I really do worry that when such things are voiced as concerns that I'm losing my neutrality, it puts me in an awkward position of feeling I either must agree or hold my tongue. :) I'm here to support VisualEditor in terms of helping make it the best software it can be, but it's not my goal to be an apologist for it. --Maggie Dennis (WMF) (talk) 18:52, 21 July 2013 (UTC)

Progress on template editing (mostly)

The good:

• You can click on a parameter, and it automatically gets added to the left side of the dialog box.
• The descriptive information about a parameter is displayed above the input box when you start entering information for that parameter.

The bad: Template:Tracked

• Scrolling still doesn't work; this is very irritating for templates with lots of parameters. But search does work.

  Template:Comment search does work, but sometime necessarily returns a list which needs scrolling; for instance, "at" as a parameter in some citation templates. --User:Ceyockey (talk to me) 12:16, 21 July 2013 (UTC)

• Double-clicking on a parameter seems to add and then delete it, leaving the parameter list unchanged.
• In Firefox (22.0, on a Mac), the font in the dialog box is too large (the dialog box, for me, is the same size in Chrome, Safari, and Firefox); as a result, fewer parameters (three, rather than six) are visible in the list, and some text is cut off on the right side of the dialog box.

Still, progress. -- John Broughton (♫♫) 01:15, 21 July 2013 (UTC)

I'll make this comment here: It would be handy for complex templates, like Template:Track listing, to list the parameters in the order they are given in the documentation, not by alphabetical and numerical order. For instance, while Template Track listing gives the following: | title1 = | note1 = | writer1 = | lyrics1 = | music1 = | extra1 = | length1 =

However, VE lists the parameters as

| extra1 = | extra10 = | extra11 = | extra2 = ... | length1 = | length10 = ... | lyrics1 = ... | music1 = ... | note1 = ... | title1 =

Personally, I would rather fill out all of the info one track at a time (title, note, writer, extra, length, in that order) than by type of entry. Perhaps allow users to toggle which listing style they prefer? And the numeric sorting problem with 10, 11, 12, etc., coming before 2 needs fixing.--¿3family6 _contribs 01:45, 21 July 2013 (UTC)

The template need to have its parameters documented using Wikipedia:VisualEditor/TemplateData, when that section is added it will list the parameters in the order given in the documentation. There is some delay between adding the template data and the dialog working correctly. --Salix (talk): 05:17, 21 July 2013 (UTC)

The lack of scrolling in the parameter list is noted as Bugzilla:51739; I can't reproduce the double click bug you mention using Firefox 22 on Linux. I agree the font size is on the large size in Firefox 22 but having not seen it in any other browser I hadn't thought about it much. what do others think? Thryduulf (talk) 14:55, 21 July 2013 (UTC)

Another link problem

Going through disambiguating links to the America dab page, I found the [[United States of America]][[America|. ]]He [3]. I'm not sure what JCGDIMAIWAT did there as it's in the middle of a block of text added in that edit. My guess is that they initially wrote "America" with the full stop and trailing space included in the link by VE, but they subsequently attempted to change or delete the link to the full United States of America, not realising that the full stop and space were included in a different link. Thryduulf (talk) 09:03, 21 July 2013 (UTC)

For those that understand how edit filters work, would it be possible/useful to track visual editor edits that include a trailing space in a link? ie. where the code " ]]" appears? I can't think that it will be something intentionally entered with any great frequency? Thryduulf (talk) 20:32, 21 July 2013 (UTC)

Yes. It's complicated by the fact that the trailing /nowiki tends to be delayed, but that should be able to be handled with appropriate regex coding. How many other cases are there where we can specifically point at it being a result of an editor struggling with VE? It would probably be best to combine a few cases and replace Filter 550 with it.—Kww(talk) 20:41, 21 July 2013 (UTC)

In this case it didn't add a nowiki tag at all, I don't know whether that makes a difference? As for other cases, I've seen several mentioned on here but I can't remember the details off the top of my head. Thryduulf (talk) 22:00, 21 July 2013 (UTC)

Significant editing problems now (20 July 11:40 AM EST)

Template:Tracked Seems the following are manifesting at the moment (Chrome 28)

1. inability to complete a save operation; the animated bar runs, then stops, but the article does not go back to the viewing state and the changes are not being saved
2. inability to scroll in the Template Editor dialog (no scroll bar; no movement of content if manually down-arrow moving through parameters).

--User:Ceyockey (talk to me) 15:42, 20 July 2013 (UTC)

Your second issue is bugzilla:51739. Can you give any more information about what you were trying to do with your first edit? Do you know if there were any database locks at that time (if there were, then it would likely be Bugzilla:51536) or anything like that? Thryduulf (talk)

Template:Ping thanks for the feedback :). I echo Thryduulf's question. Okeyes (WMF) (talk) 17:07, 22 July 2013 (UTC)

Cut and paste refs?

Template:Tracked I wanted to cut a ref and land it elsewhere in the page. Clicking the numeral display the contents of the ref, but this is not copyable either. Does VE support my purpose? trespassers william (talk) 21:57, 20 July 2013 (UTC)

According to Bugzilla:43936 if you select the text either side of the reference as well, this works the way you want it to. I haven't tried this myself though, and the last comment on that bug was a fortnight ago so something may have changed in the meanwhile. Thryduulf (talk) 23:14, 20 July 2013 (UTC)

Template:Ping does that make a difference for you? Okeyes (WMF) (talk) 17:18, 22 July 2013 (UTC)

Fucking awesome

The way forward, definitely. Keep up the great work Wiki peeps. 109.76.87.94 (talk) 22:22, 20 July 2013 (UTC)

Thanks! Okeyes (WMF) (talk) 17:22, 22 July 2013 (UTC)

Feedback from scientists

Hi, I just wanted to relay some feedback I got from new editors at a scientific conference I'm attending. I just ran a workshop for new editors and taught them how to use the traditional editor and the VisualEditor and they vastly preferred VE. One of the participants said it was intuitive for her and she liked how the interface was familiar. Another said she liked Visual Editor a lot but that she thinks scientists who use LaTeX a lot would prefer the wikimarkup editor. Just another data point for you. I'm doing another one tomorrow so I'll come back with more comments. :) Keilana|^{Parlez ici} 17:29, 21 July 2013 (UTC)

I'm not sure I buy the idea that the first five minutes' of use are actually representative of preference, particularly if the functions currently poorly-supported by VE are avoided. Try to get them to add a reference, with both the Wikimarkup reference tool, and the VE "practically no support" option. Adam Cuerden ^(talk) 17:44, 21 July 2013 (UTC)

Template:Ping Yeah, I thought of that too - one of them did add a reference and thought it was okay actually. I'll see what they think of it tomorrow, I think that'll be a better gauge. Keilana|^{Parlez ici} 03:20, 22 July 2013 (UTC)

Adam: I would agree, and would note that would apply to experienced users too - moreso, in some ways, since they'd have to actively un-learn as well as learn. We are planning on redoing template and reference editing. Okeyes (WMF) (talk) 18:05, 22 July 2013 (UTC)

Article creation

If I search for a topic which doesn't yet have an article, I get a red link offering me the chance to create an article. (You may create the page "Aassddff".) If I click on that red link, I'm starting to edit the article ... in Edit Source.

If our new editors are being made accustomed to VE, what will they do when faced with an empty box into which to start creating an article? Is there a mechanism which will let them choose to edit in VE instead? If not, then in the short term, perhaps there should be an edit notice which says something like "The new Visual Editor has not yet been set as the default editor for page creation. If you would like to use the Visual Editor to create this page, please type at least one character into this box and then click "Save page" below, and then click on the "Edit" tab to re-open it and edit it. Sorry for this inconvenience - we are working on it." PamD 23:06, 21 July 2013 (UTC)

Good Point! --User:Ceyockey (talk to me) 23:15, 21 July 2013 (UTC)

I'm not going to switch English on just for this, so I don't know what the tabs are named. When I do it, I am immediately placed in source editing mode inside a tab labeled "broncode aanmaken" (roughly "create source code") and there is a tab immediately to the left labeled "aanmaken" ("create") that will take me to the visual editor. This is in the Monobook skin. Don't you have something similar?—Kww(talk) 00:24, 22 July 2013 (UTC)

The edit notice for new pages is MediaWiki:Newarticletext. I've mentioned this at MediaWiki_talk:Newarticletext#Mention_VE. (Kww, there is a 'Create' tab in Vector, but that isnt a very intuitive way to switch. John Vandenberg ^(chat) 00:47, 22 July 2013 (UTC)

Maybe not intuitive, but clearly better than saving a one-character version and reopening it as Pam suggested.—Kww(talk) 01:00, 22 July 2013 (UTC)

Thanks, Kww. I do see the create tab and clicking that takes one into the VE mode. --User:Ceyockey (talk to me) 01:52, 22 July 2013 (UTC)

I do hope the redlink isn't made no-way-to-not-have-it-be-VE, though. Please give us a choice. Adam Cuerden ^(talk) 06:49, 22 July 2013 (UTC)

No, MediaWiki:Newarticletext is not the editnotice seen by editors creating an article in English Wikipedia.

I'm not sure whether it's changed since last time I looked, but I now see there is a "Create" tab alongside "Create source", in the page which opens when you click on the red link. If you click on that "Create" tab, then after a disconcerting pause with the "Wikipedia does not have an article with this exact name" display, it opens up VE to let you create the article.

For the sake of our new editors who we've led into using VE as a default, we need to make this much clearer. The message box already has 5 bullet points, but we surely need to say, very clearly, separated out from the other five, "To create an article using the Visual Editor, click the CREATE tab above this box". It's not obvious, especially to new editors who are, presumably, not really supposed even to know about the old editor.

Of course, in VE they don't get to see the words of wisdom displayed in those five bullet points ... perhaps the info about the CREATE tab should be at the bottom, below them, so they can be assumed(?) to have read that information? PamD 09:44, 22 July 2013 (UTC)

What message you see when you arrive on a page that doesn't exist depends on the method you use to get there. There is also MediaWiki:Noexactmatch and Template:No article text (transcluded by MediaWiki:Noarticletext). Thryduulf (talk) 10:42, 22 July 2013 (UTC)

The one I'm talking about is the one you reach if you search for a topic (eg "aassddff") and get search results and a message saying " There were no results matching the query. You may create the page "Aassddff", but consider checking the search results below to see whether the topic is already covered." Clicking on that red link, you get the Edit Source box opened and a message which says:

• Before creating an article, please read Wikipedia:Your first article.
• You can also search for an existing article to which you can redirect this title.
• To experiment, please use the sandbox. To use a wizard to create an article, see the Article wizard.
• When creating an article, provide references to reliable published sources. An article without references, especially a biography of a living person, may be deleted.
• You can also start your new article at Special:Mypage/Aassddff. There, you can develop the article with less risk of deletion, ask other editors to help work on it, and move it into "article space" when it is ready.

The above all in a box (with a few links), followed by:

Content that violates any copyrights will be deleted. Encyclopedic content must be verifiable. Work submitted to Wikipedia can be edited, used, and redistributed—by anyone—subject to certain terms and conditions.

I'm suggesting that somewhere in that lot should be a large and friendly message for new editors to alert them to the "Create" tab above which will take them to the Visual Editor to which they are accustomed. They may not even know about the existence of the other editor, if they have been seamlessly introduced to VE from the start, so are likely to be confused! PamD 14:46, 22 July 2013 (UTC)

That is Mediawiki:Newarticletext, it just doesn't look like it because it has a different appearance depending on the namespace. Rather than directing people to a tab above, we could just include a link along the lines of "You can create this page using the visual editor" (although with dynamic urls rather than one hardcoded into my userspace). This would need discussing at MediaWiki talk:Newarticletext though. Thryduulf (talk) 15:05, 22 July 2013 (UTC)

Layout

This is horrible Bladez636 (talk) 19:25, 22 July 2013 (UTC)

Template:Ping is there anything specific that is causing you problems? Okeyes (WMF) (talk) 20:50, 22 July 2013 (UTC)

Time to take a long, hard look at WP:CITEVAR.

Up to now, complying with this somewhat over the top guidance has been relatively painless as any existing refs are visible in the edit window, and in many cases become the source of the new ref (copy, paste, change as needed). Now that refs are (almost) working in VE most editors will simply construct a new ref using the mandatory parameters in a template. Just for fun I tried the copy, paste, change method in VE. The result is a fail for at least three reasons:

1. No way to enter the new URL.

2. Cannot be sure what parameters the existing fields represent.

3. No way to enter new fields in such a manner that they will display something useful to a reader.

Downsize43 (talk) 02:24, 22 July 2013 (UTC)

Template:Replyto When you edit an existing citation, whether or not you created it by copying a citation already on the page, there are three possibilities: (a) It's "raw" text - no cite template was used; (b) it uses a cite template, and TemplateData has been set up for that; or (c) it uses a cite template, and TemplateData has not yet been set up for that. For (b) and (c), you should see, when you click on the text of the citation, a boxed, blue background, and a new icon (for me, to the bottom right of the box). That's your clue to use the template dialog box ("puzzle piece") to edit that template. When you go into the template dialog, it will tell you (upper left) what template you're editing.

To distinguish between (b) and (c), take a look at WP:VisualEditor/User guide#Editing references, where TemplateData has been used - case (b).

It sounds like you may have situation (c), based on (2), but I can't tell for sure - and even then, (1) and (3) don't necessarily follow. If you do have situation (c), what is the template name? (For that matter, what is the article name, what footnote number did you copy and then try to edit, and what operating system and browser are you using.) -- John Broughton (♫♫) 15:57, 22 July 2013 (UTC)

Using Google Chrome Version 28.0.1500.72 m on Win7. Editing Kidman Way. Copying ref 3 (which shows as 1 in VE) pasting it to another location and wishing to change the items.

Ref 1: <ref>[http://www.kidmanway.org.au Kidman Way - Where the legend begins], ''Kidman Way - Backtrack to the Outback''. Retrieved on 11 May 2008.</ref>

Display in ref window in VE: Kidman Way - Where the legend begins, Kidman Way - Backtrack to the Outback. Retrieved on 11 May 2008.

(with the title as an active link to http://www.kidmanway.org.au) Note that the double quotes have gone.

After copying the displayed text and pasting into a new ref window it displays as above without the active link. Changing some text results in (for example): Hillston Way - Where the legend ends, Hillston Way - Track back to the Outfront. Retrieved on 11 May 2013. Without a URL attached to the title this is merely garbage, so where does one go from here? Downsize43 (talk) 06:17, 23 July 2013 (UTC)

This thread was intended to start a discussion about how WP:CITEVAR will be less likely to be complied with by both new and experienced editors using VE. It was not intended to be about the bug reported as Bugzilla 51725, but they are now inextricably linked, because user John Vandenberg has, in "testing" bug 51725 without understanding its implications, breached WP:CITEVAR in exactly the manner I alluded to at the top of this post. Downsize43 (talk) 00:31, 24 July 2013 (UTC)

External links to Wikipedia pages

May I suggest that VE translate (what appears in Wikitext as)

[http://en.wikipedia.org/wiki/X Y]

by

[[X|Y]]

The concept of "external link" vs. "wikilink" is complicated enough if you can see the Wikimarkup; if you can't see it, we really can't expect new users to understand it. It would be nice if it would also fix links to other Wikiprojects. (And this is not only of use to en.Wikipedia; any other Wikiproject using VE is likely to have the same problems.) — Arthur Rubin (talk) 01:10, 23 July 2013 (UTC)

I assume they both appear as Y with a hook? — Arthur Rubin (talk) 01:15, 23 July 2013 (UTC)

They appear as Y and Y. So, clearly the second one is better. Some tools are already proposing editors to fix the replace them when found. --NicoV ^{(Talk on frwiki)} 04:22, 23 July 2013 (UTC)

One needs to be a little bit careful with this. As I recall, there is a convention that in the rare cases where an article needs to reference a non-article space wikipage (for example, the user page of a notable Wikipedian referenced from his article, or a Wikipedia space page referenced in an article discussing Wikipedia), then those links are supposed to be maintained as external links. The reason for this is that most reusers don't copy pages from non-article spaces, so in the rare cases where an non-article space wikilink is valid as a reference within an article, it recommended to use an external link to make sure the link is still accessible for reusers. That said, the transformation would seem to be fine for the example given above of a wiki article linking to another wiki article. Dragons flight (talk) 05:59, 23 July 2013 (UTC)

No, the editor should not translate external links to internal ones. As Dragons flight notes, it could only safely be done with non-permanent links to current article-space pages, and it is not guaranteed that every wiki will have the same policies. It also should not be up to the parser to determine the target of an external link before deciding how to parse it, and anyway having silently different behaviour for different links is a Bad Thing. Far easier and far better to just educate users about the difference between internal and external links. Thryduulf (talk) 11:25, 23 July 2013 (UTC)

Regarding The concept of "external link" vs. "wikilink" is complicated enough if you can see the Wikimarkup; if you can't see it, we really can't expect new users to understand it, I have to disagree - VE is easier to understand than wikitext. (If I had a dime for every time that someone used a pipe to separate the url from the text to be displayed ... ) Please take a loot at WP:VisualEditor/User guide#Editing links; basically one pastes an external link and one searches for an internal link, and there is no need to worry about wikitext format at all. -- John Broughton (♫♫) 15:50, 23 July 2013 (UTC)

I think the case where you need an external link to wiki content is enough of a rare case that it should be saved for editors who "know what they're doing". What I'm missing is the Visual Editor UI/UX perspective here -- how is it that editors are making these external links to wiki content? We should make it so that the "most natural way" to make a link Does The Right Thing. There can be a checkbox somewhere to say, "make this an external link even though its wiki content" for power-users to use, but the default thing should be correct. In order to be inclusive and welcoming to new contributors, we should avoid having to lean on the "educate the users" trope. Let's make the easy thing the almost-always-correct thing. C. Scott Ananian (talk) 18:21, 23 July 2013 (UTC)

In reality, only power users are going to know when and when not to link in an external form (http://) to what could be an internal link (wikilink). On the other hand, we are likely to have a lot of inexperienced editors pasting in external links by mistake. This is the sort of thing that a bot or AWB or TW or similar is best at dealing with, rather than adding complexity to the UI with yet another box.

Still, it would be great, when that mistake (mostly) is made, if VE would pop up a dialog box, as, for example: "Your external link, http://en.wikipedia.org/wiki/1974_South_Australian_Tennis_Championships_%E2%80%93_Singles, probably should be an internal link - 1974 South Australian Tennis Championships – Singles. Do you want to change that? (yes) (no)." -- John Broughton (♫♫) 00:44, 24 July 2013 (UTC)

https://gerrit.wikimedia.org/r/#/c/73565/

Can this finally be launched? There's been a unanimous poll and a near-unanimous poll, and it's not what hidden preferences are intended to do.

You're giving the very strong appearance that the WMF doesn't care what the users say. Adam Cuerden ^(talk) 14:21, 23 July 2013 (UTC)

slow

The loading is slow on pages with tables El Otro (talk) 11:02, 18 July 2013 (UTC)

I believe that the VE is still picking up speed after all and hope that you will find this less of an issue going forward. --Maggie Dennis (WMF) (talk) 20:04, 19 July 2013 (UTC)

Pawn

I found it really slow earlier this evening. It was so slow that I pulled up top to see if my machine had crashed, killed some add ons and other firefox windows and came back to find it still messing around. Apart from that it also completely broke the article deleting a large chunk and saved something I had already deleted and did not insert the stuff that it was showing on screen. Just a complete disaster all round. RonaldDuncan (talk) 22:26, 20 July 2013 (UTC)

I'm sorry; it looks like you encountered one of the pawn bugs. :( I've heard of these, but have not encountered one before. Can you tell me what you were trying to do? --Maggie Dennis (WMF) (talk) 13:50, 21 July 2013 (UTC)

Is there an edit filter for pawn ♙ and snowmen ☃? I'm guessing that it doesnt appear often except for this bug. If the edit filter eliminates article that mention 'chess', or 'pawn', I'm sure we'll have nearly zero undesirable hits. Unfortunately I can see how many articles have this character because of bugzilla:51790. --John Vandenberg ^(chat) 02:08, 22 July 2013 (UTC)

I don't know, John, but I'll ask. :) --Maggie Dennis (WMF) (talk) 13:29, 22 July 2013 (UTC)

Seems like there's not, but that this could be a very good idea. :) I've asked User:Reaper Eternal if he can help out. --Maggie Dennis (WMF) (talk) 19:56, 23 July 2013 (UTC)

User:Reaper Eternal has helpfully created a temporary edit filter pending correction of this issue in the software, Template:Ping. :) See [4]. --Maggie Dennis (WMF) (talk) 19:29, 24 July 2013 (UTC)

It appears the pawn is used as a placeholder by VisualEditor; other bugs pop up when you actually try to use the pawn legitimately in an article, as well. I'm surprised that the VisualEditor people decided to use a visible character with legitimate use in content as a placeholder like that. (The developers really ought to read up on the inherent issues with in-band signaling.) Fran Rogers (talk) 13:40, 22 July 2013 (UTC)

save page

each time I press the 'save page' button it keeps saving, but nothing happens. If I close the page, the changes aren't saved. HeroPsycho22 (talk) 07:52, 22 July 2013 (UTC)

Template:Ping, which page did this occur on? John Vandenberg ^(chat) 08:55, 22 July 2013 (UTC)

user:HeroPsycho22 commented on my talk that it was this edit, and it worked OK, but was strange. John Vandenberg ^(chat) 09:37, 22 July 2013 (UTC)

I've just edited that page in VE to tweak the wording in the lead and it was very slow to load and slow to save. I'm starting to think there might be a correlation between pages that have lots of references and pages that are slow to load and save in VE. I'm not certain yet though, if anyone can think of any short articles with lots of references and long articles with few that would be useful. Thryduulf (talk) 10:25, 22 July 2013 (UTC)

Template:Suggestion I have not tested this, but using null edits might be a way to assess this without revising any content.

Template:Question This is, if null edits are supported by VE - not sure of that. --User:Ceyockey (talk to me) 12:25, 22 July 2013 (UTC)

Yes, VE does support null edits [5] Thryduulf (talk) 12:31, 22 July 2013 (UTC)

This is not a true null edit, a whitespace character has been added. With the wikitext editor, you can do a true null edit. --NicoV ^{(Talk on frwiki)} 12:37, 22 July 2013 (UTC)

In that case no you can't, as if there have been no changes the save button is not enabled. Thryduulf (talk) 12:51, 22 July 2013 (UTC)

Template:Od Well it isn't just related to the number of references. I was unable to get the editing interface to load for List of United States counties and county-equivalents - first time it crashed firefox with the error "###!!! ABORT: OOM: file /build/buildd/firefox-22.0+build2/xpcom/string/src/nsTSubstring.cpp, line 348 " on the terminal. So I tried again with a single window and no other tabs open (I normally have ~90 tabs open over three windows) but after waiting 13m 39.322s I gave up. Along the way though I got the following warnings about scripts running slowly. I chose to let them continue each time:

Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:130
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:130
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:7
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:30
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:38
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.core%2Cicons-vector%7Cext.visualEditor.viewPageTarget.icons-vector%7Crangy&skin=monobook&version=20130719T023752Z&*:38
Script: https://bits.wikimedia.org/en.wikipedia.org/load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2CviewPageTarget%7Cjquery.visibleText%7Coojs%7Cunicodejs.wordbreak&skin=monobook&version=20130719T023752Z&*:122

(duplicate lines mean the same error was received more than once). I do appreciate this was an exreme test (that article is number one at special:LongPages), but for comparison the source editor opening it in 7.680 seconds. I'll keep testing :) Thryduulf (talk) 18:05, 22 July 2013 (UTC)

It seems that the only reliable page load/save time correlation is with the size of the page (bytes rather than length). Citations and tables add a lot of characters to an article relative to plain text so I suspect that's what lead me to my earlier observations. Larger pages taking longer to open is not exactly an illogical correlation and should make it easier to test (if not necessarily to fix). Thryduulf (talk) 21:35, 24 July 2013 (UTC)

Fail to save

Running on Chrome 28.0.1500.72 m. Edited a 600 word article, Uzbl. Clicked save repeatedly. I got the working graphic, but when it stopped, the save dialog was still displayed. Made my changes the old-fashioned way. — Preceding unsigned comment added by Lfstevens (talk • contribs)

Hmm, assuming you made the same changes in the traditional editor you were attempting the visual editor, there is nothing there that should cause any problems afaics. Thryduulf (talk) 19:21, 22 July 2013 (UTC)

Template:Ping does this happen consistently? Okeyes (WMF) (talk) 20:49, 22 July 2013 (UTC)

No. I've edited several articles with VE without a problem. Lfstevens (talk) 21:18, 22 July 2013 (UTC)

user:HeroPsycho22 reported something very similar ~12 hours ago on this page, however they found their edits had been saved. John Vandenberg ^(chat) 03:05, 23 July 2013 (UTC)

Very strange; a temporary blip, maybe? If people see it again, please do let me know, with a timestamp if possible - maybe we could try and trace it through the logs. Okeyes (WMF) (talk) 19:39, 23 July 2013 (UTC)

Saw it again today editing Amiga software. I had clicked edit on a section header rather than at the top. Made changes in about 10 paragraphs. Lfstevens (talk) 05:08, 24 July 2013 (UTC)

Hmn. I just tried the same and it appeared to work. What time did this issue crop up? Okeyes (WMF) (talk) 16:32, 24 July 2013 (UTC)

Just before I added the update here. Lfstevens (talk) 17:36, 24 July 2013 (UTC)

Fantastic way to disable Visual Editor completely

Hi, I know a lot of people are interested in getting this out of their face, including myself (and I mostly edit without being logged in), fortunately I found a way to do it if you are using Chrome and have AdBlock installed, it makes it completely go away, works even though I'm not logged in, and I love it :) Steps:

• Click the AdBlock icon next to the Options menu (a white hand on a red background, right of the URL bar)
• Click "Options"
• Select "Customize" tab
• Click "Block an ad by its URL"
• Under "Block URLs containing this text", paste the following (without the quotes): "/load.php?debug=false&lang=en&modules=ext.visualEditor"
• Under "Domain of page to apply to", type "wikipedia.org"
• Click "Block It!"

Yay, no more VE. As far as I can see it fully fixes this bug without any adverse side-effects. 86.30.129.146 ([[User talk:86.30.129.146|talk]]) 12:56, 24 July 2013 (UTC)

For those who do edit while logged in, opting out of VE via preferences is much cleaner. (Today, that's done via the editing section of the Gadgets tab; starting tomorrow, that will be done via an option on the Editing tab.) -- John Broughton (♫♫) 17:55, 24 July 2013 (UTC)

VE use stats - one article and a suggestion

another recent thread on usage stats for VE → Wikipedia:VisualEditor/Feedback/Archive 2013 2#Some performance notes

I took a quick look at the editing history of University of Delaware. The first VE edit was done on 20 June ...

Template:Question is there a good release date value which we can use for baselining?

...and since then this is the editing pattern where 12 of 26 edits have been created using VE:

editor type	editor count	editor choice
ip	2	Classic
ip	1	VE
new account <50 edits	1	VE
user	1	Classic
user	1	Classic & VE
user	1	VE

Template:Suggestion might there be a method whereby one could take a look at 1 week or 1 month slices across article histories and return some statistics about a) proportion of edits contributed using VE, b) user types vs. editor choice. This combined with c) number of edits during period, d) article class (e.g. start, stub, FA) and e) main topic classifications, might provide a pretty useful look at the dynamics of VE adoption over time. This data, in fact, could serve as part of a peer-reviewed publication on the release and impact of VE. --User:Ceyockey (talk to me) 00:07, 25 July 2013 (UTC)

The VE navbox (see, for example, at WP:VisualEditor/FAQ) has, at the bottom, a new section, "Live analystics", with links to WMF dashboards that show hourly editing activity, for VE and the wikitext editor, by type of editor (IP, newly registered, prior registered). This was added, without much (any?) publicity, a couple of days ago. -- John Broughton (♫♫) 00:41, 25 July 2013 (UTC)

Very nice. Thanks for pointing this out. --User:Ceyockey (talk to me) 03:19, 25 July 2013 (UTC)

Shortcuts for Saving and Preview

I initially read this posting as saying that VE had these shortcuts, but no longer does, and could they be put back. For anyone else with the same impression, that's incorrect; what is being asked for here is that the equivalent (or duplicate) of existing wikitext editing shortcuts be added to the existing VE software. -- John Broughton (♫♫) 17:49, 24 July 2013 (UTC)

+1 to that. Better described was having trouble figuring out how to add the frustration :P Sadads (talk) 18:10, 24 July 2013 (UTC)

On the bug, you said the user mentioned ctrl+alt+s, for me in chrome, it's just alt+s. When I highlight the the button in the browser it says that it is shift+alt+s. I have never held down the shift though... 18:19, 24 July 2013 (UTC)

Nevermind, didn't read that thoroughly not Okeyes, Sadads (talk) 18:23, 24 July 2013 (UTC)

I'm confused by the flow of this conversation, I'm afraid :(. What's the current situation/concern/question? Okeyes (WMF) (talk) 16:53, 25 July 2013 (UTC)

Removing template subpages from the template selection list?

If I'm searching for cite web, I also see, in the list, cite web/doc, cite web/sandbox, cite web/today, cite web/old, cite web/testcases, and more. None of these are templates that users are likely to need; the list would be much cleaner if they were excluded.

Given that occasionally users may want to use these templates, in VE, I suggest a checkbox, checked by default, in the dialog for "New template". The checkbox should labeled something like "Exclude subpages". That way, if a user does in fact want to see these, he/she can do so by unchecking the box. The checkbox could be part of the "Options" area; if so, it should be visible only during the "New template" part of the dialog. A better place probably would be below the "Add template" button, so it's still visible during the search process, and can be checked or unchecked during that. -- John Broughton (♫♫) 20:19, 24 July 2013 (UTC)

I'd worry about the possibility of wikis where things are stored as subpages. So cite web would be cite/web, cite/journal, cite/book...etc. Is anyone aware of projects that do this, or that have subpages that are templates in their own right? Okeyes (WMF) (talk) 20:24, 24 July 2013 (UTC)

Have you seen Wikipedia_talk:VisualEditor/TemplateData#Need_some_way_of_categorising_template_data_usage? It's probably not a complete solution, but a first step in the right direction imo. I agree, that template "management" and selection need a bit of improvement. GermanJoe (talk) 20:30, 24 July 2013 (UTC)

Template:Replyto While I can see the value of categorising templates by whether they have TemplateData or not, I'm not sure it's on point - I thought one could edit templates in VE even if they lacked TemplateData. (Personally, my suggestion for figuring out which templates are a priority for adding TemplateData would be to create a bot to monitor RecentChanges; every time a template was added to an article, the bot would (a) check it against a master list, and (b) if not on the list, check the template itself; if both tests fail, then the bot would add the template to a "to do" list, perhaps with a count of how many times the template is used in articles, to give a better sense of priority.)

Template:Replyto Point well taken. I'm going to stick with my suggestion that there be a checkbox, but am modifying it: whether the checkbox is on or off should be a setting that is controlled by each local project. Or, if one wanted to be extreme, each local project would have the option of hiding the checkbox and its caption, entirely. -- John Broughton (♫♫) 22:38, 24 July 2013 (UTC)

I strongly support this suggestion - will make the list of templates much more user-friendly. Great idea. PamD 08:29, 25 July 2013 (UTC)

There are a handful of templates on en.wp that use a /, e.g. Template:Temp, so simply turning off all subpages isn't the answer. Thryduulf (talk) 08:44, 25 July 2013 (UTC)

Urgh :(. Okeyes (WMF) (talk) 17:02, 25 July 2013 (UTC)

I can think of three ways round this (listed in the order I thought of them):

1. Set an explicit "I am not a template" statement on pages in the template namespace that are not templates. VE would just not display in the list any page with that statement on it. I think it's reasonable to assume that any page in the template namespace is a template unless it says it isn't. Perhaps something like __NOTTEMPLATE__ at the top of a page, it would need to be either automaticaly never transcluded, meaningless when transcluded or manually surrounded by <noincude>...</noinclude>tags. Ideally it would be able to be included as part of Template:Temp but I don't know how that is compatible with it not transcluding from the doc subpage to the main template.
2. Same as above but use a category rather than a magic word. Pages in that category would not be included in VE's list.
3. The inverse of the above - exclude all template subpages unless they are explicitly marked (by magic word or category) as being user-facing templates.

I don't know which is best, but I'm leaning towards option 3 as I've also just remembered that there are a gazillion subtemplates that Template:Temp users that the user doesn't need to know exist list Template:Temp. If subtemplates are used more frequently on other wikis that might make a difference though. Thryduulf (talk) 17:46, 25 July 2013 (UTC)

Would excluding pages in Category:Template_documentation_pages, Category:User documentation pages, and Category:Template sandboxes be a start? Failing that, editing Template:Tl and Template:Tl would let you easily add whatever code you do want to use to exclude templates. Adam Cuerden ^(talk) 18:19, 25 July 2013 (UTC)

If we go down the exclude route then that is the sort of thing I was thinking should be possible. Thryduulf (talk) 18:31, 25 July 2013 (UTC)

Addition of hidden categories

Category:Commons category without a link on Wikidata is added to any article that transcludes Template:Commons category whenever anyone uses VE, e.g. [6]. The category should not be added per Template talk:Commons category#Edit request on 24 April 2013: Check Wikidata errors. DrKiernan (talk) 20:26, 24 July 2013 (UTC)

I couldnt reproduce this at [7] or [8], so I tried on "that page" and it didnt happen then either. There must be some additional ingredient to cause it to happen, or the bug has been fixed. John Vandenberg ^(chat) 06:49, 25 July 2013 (UTC)

More on Android

I edit using a Droid RAZR, on desktop not mobile. Starting today, I am seeing VE error messages on user talk pages. The "edit source" option pops up, but my browser crashes when I try that option. I am not consistently able to edit existing sections and have to open a new section to continue a conversation. Cullen³²⁸ Let's discuss it 22:27, 24 July 2013 (UTC)

On user talk pages, there should not be an "edit source" option. VE isn't enabled for talk pages, and the label for the edit option is supposed to say "edit", as it always has. What exactly is the VE error message you're seeing, and (sorry to ask) are you sure you're seeing it on a user talk page, as opposed to a user page? (VE is enabled for user pages, though you still shouldn't get an error message.) -- John Broughton (♫♫) 01:34, 25 July 2013 (UTC)

It could very well have been the bug where both buttons displayed in all namespaces temporarily. Okeyes (WMF) (talk) 17:04, 25 July 2013 (UTC)

I am 100% sure, John Broughton. I comment on user talk pages all the time, but I don't edit other people's user pages. If I see the error message again, I will write down the exact wording and report it here. Cullen³²⁸ Let's discuss it 19:35, 25 July 2013 (UTC)

I encountered this yesterday, too, but I haven't seen in since. I think it was a temporary glitch. Whatamidoing (WMF) (talk) 20:51, 25 July 2013 (UTC)

Right-aligned image shown left=aligned in editor

At [9] the image of the train is shown left aligned. When viewed in read mode it is right aligned. This might be because the infobox means it can't be shown on the right in the section where it is included, and if so I don't know what would be better. I'm just about to go to bed and haven't got the mental energy to do any testing or reporting. Thryduulf (talk) 01:12, 25 July 2013 (UTC)

VE (or Parsoid) is apparently programmed to keep an image close to where the "File" link is on the page (in this case, the File link is the first wikitext in the "Reaction" section). So it's willing to put the image on the left side of the page (despite the "right" parameter) to keep it roughly in the "correct" place in the section.

By contrast, the Wikimedia software that decides where images go always follows the right/left parameter; if that means that an image isn't visible within (or, in my browser, barely within) the section where the File link is located, well, that's what happens when an editor lays out a page badly.

So yes, Parsoid/VE and the regular display software are handling the image differently. I don't think that's desirable in a visual editor, but perhaps this is the best of a bad situation? -- John Broughton (♫♫) 03:09, 25 July 2013 (UTC)

I 'feel' like more images are being placed on the left in VE than was the case yesterday. It would be good to know if the VE team has made a related change, and why? I agree with John Broughton ; there is no good solution that will work all the time, as lots of images are float'ed right and they appear a long way down from their place in the wikitext.

A small overlay icon in the corner of the image to signify "will float right" would help writers ignore the left placement in VE. John Vandenberg ^(chat) 07:08, 25 July 2013 (UTC)

This seems like a bug. I do know that image alignment is what the team is currently working on, but it wasn't getting deployed until today?? It might be that a change preparing for that has accidently broken something in the deploy from yesterday. —TheDJ (talk • contribs) 08:58, 25 July 2013 (UTC)

Mockup of how I think it can be done better

Now I'm awake and have had time to think about it, I reckon that the poor-quality mockup I've added here would be better. That is render the image in the editor where it will appear in the view, but place the slug where the image is called in the source and have a dashed line linking the two whenever either is selected. Thryduulf (talk) 09:53, 25 July 2013 (UTC)

Loading never finishes

Problem: I click "edit this page", the VE begins loading, but never finishes. At first I thought this might be a problem with a particular article, but I've tried many different articles—big ones, small ones, with images, without images—and it's the same thing every time.

I've used VE on other computers with no problems, and I can edit source on this computer with no problems, but for some reason VE just doesn't like this computer.

• Browser: Chrome v28.0.1500.72
• OS: Windows 7 Ultimate
• Puter: Com Fixer eMachines D640

Could there perhaps be some browser settings I'm not aware of that could block VE? --Cryptic C62 · Talk 04:39, 25 July 2013 (UTC)

Template:Replyto, Can you open your Chrome JavaScript Console (Under Tools->JavaScript Console), load a page, and tell us what error is in the JavaScript console? John Vandenberg ^(chat) 06:13, 25 July 2013 (UTC)

Template:Replyto Here's what I got:

Uncaught TypeError: Object function (selector,context){return new jQuery.fn.init(selector,context,rootjQuery);} has no method 'getVisibleText' load.php?debug=false&lang=en&modules=ext.visualEditor.base%2Cmediawiki%2Cvi…t%7Coojs%7Cunicodejs.wordbreak&skin=monobook&version=20130725T023359Z&*:16

--Cryptic C62 · Talk 06:23, 25 July 2013 (UTC)

That is odd. The method 'getVisibleText' was added ages ago. I've tested on Chrome/Win7 Enterprise and dont see the problem. Do you have Chrome addons? John Vandenberg ^(chat) 07:01, 25 July 2013 (UTC)

I've also got the following error message:

Blocked a frame with origin "http://www.superfish.com" from accessing a frame with origin "http://en.wikipedia.org". Protocols, domains, and ports must match.

At first I didn't think it was relevant, since the error appeared before I tried to open VE, but I'll let you be the judge now. Extensions list:

• iLivid New Tabs 5.0
• GoPhoto.it 1.5
• Skype Click to Call 6.10
• Smiley Bar for Facebook 1.0
• SpecialSavings.com 2.0

Meep. --Cryptic C62 · Talk 17:02, 25 July 2013 (UTC)

Template:Replyto, could you try disabling all of those addons briefly, and trying again. If it is an addon causing the issue, we'll look at the source code of those addons to find the problem. If it isnt an addon, we'll have to look elsewhere for the problem. John Vandenberg ^(chat) 01:43, 26 July 2013 (UTC)

Template:Replyto I tried VEditing with extensions enabled one last time; didn't work. I disabled everything, it started working! Hooray! I re-enabled them one at a time to try to figure out which one was causing the problem, and it continued working, even when I had all of them enabled again. Very weird. --Cryptic C62 · Talk 02:47, 26 July 2013 (UTC)

Heck; the gamma rays win again. John Vandenberg ^(chat) 03:33, 26 July 2013 (UTC)

VE thoughts

I'm of the opinion that VE is a great idea, but on fundamentally the wrong track. It's far too mouse-based for something based around editing an encyclopedia: The last thing you want to do while typing up text is to lift hand from keyboard and use the mouse to fill in forms. It'd need huge amounts of keyboard shortcuts to be viable... and the VE team seem oddly convinced that using the pre-existing wikimarkup shortcuts is somehow moving backwards.

If I thought the VE team cared about the views of older users, I'd be more optimistic, but the preferences fiasco killed that belief. As such, I have little faith that VE will ever merge in enough wikimarkup-as-shortcuts to ever be practical. Adam Cuerden ^(talk) 04:48, 25 July 2013 (UTC)

I on the other hand think that VE is a great idea, on the right track, for the limited scope of assisting novice users, for whom it is designed. It is well known that expert users have different requirements than beginners, and that tools designed for performance are usually not user-friendly; it's very difficult to get both, and the VE is not trying to do it. For efficient edit, typing+autocompletion will always be faster than a form-based interface. Fortunately the source editor will never be disabled, so experienced editors can have their expert tool and edit quickly through wikicode. Diego (talk) 05:33, 25 July 2013 (UTC)

Except that the VE team have made it extremely clear they want it to be used by old and new editors alike. You don't block the preference to turn VE off if you think it's just for new users. Hell, the whole method for editing sections defaults to VE so strongly that it's an annoyance to anyone who doesn't want to edit in VE, and breaks screenreaders. Adam Cuerden ^(talk) 05:49, 25 July 2013 (UTC)

It doesn't matter what the VE team want old users to do. Volunteers can't be forced to use tools that they don't like; we are not wage earners that must swallow whatever their bosses decide them to put them through. Those that don't find the new interface practical would simply abandon the project, or find workarounds to disable the new tool (which is exactly what happened with the alpha VE). If the VE developers at some point decide to listen to the veteran's needs and build a tool that support them (either within the VE or as a separate tool), they will entice some experienced editors to start using it. If not, they will keep wondering why the VE has a low adoption rate and people prefer using the "obsolete, old way" of doing things instead of the shiny visuals. Since they've promised that they won't remove the source editor (for now), I don't care. Diego (talk) 08:54, 25 July 2013 (UTC)

• VE is expensive extravagance but inspiration to write about WYSIWYG or other topics: Well, 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", 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, 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. -Wikid77 (talk) 06:45, 25 July 2013 (UTC)

Maybe we should move this thread to Wikipedia talk:VisualEditor? These topics are fascinating, but they are not providing feedback on how the current VE works. Diego (talk) 09:53, 25 July 2013 (UTC)

Moving my comments to there... -- The Anome (talk) 10:08, 25 July 2013 (UTC)

• I have copied my comments as "WT:VisualEditor#VE as inspiration for related articles" as a broader form of high-level feedback, not bug-report level. -Wikid77 (talk) 13:38, 25 July 2013 (UTC)

Proposal for site notice about how to turn VE off

Wikipedia:Village_pump_(technical)#Proposal:_English_Wikipedia_should_set_up_a_sitenotice_explaining_how_to_turn_VisualEditor_off.
Just a heads up. Adam Cuerden ^(talk) 14:37, 25 July 2013 (UTC)

I've moved the link outside the header and given this section a sane title. Thryduulf (talk) 15:35, 25 July 2013 (UTC)

Copy and past wikilinks?

Template:Tracked Hi is it really not even possible to move wikilinks around by ctrl x ctrl v? It only inserted the lable but not the Link! This is definitely not an luxury feature but core functionality.--Saehrimnir (talk) 14:56, 25 July 2013 (UTC)

This is Bugzilla:48720, which has been marked as high priority since the end of may. It was targeted for inclusion in three consecutive deployments in late June/early July. It seems that when it became clear that it would not be ready for the deployment on 11 July the target was removed and a new one not set. Template:Ping could you get a status update on this one please. Thryduulf (talk) 15:49, 25 July 2013 (UTC)

Certainly :). Okeyes (WMF) (talk) 17:36, 25 July 2013 (UTC)

Answer is that it's being blocked on general copy-and-paste improvements, which necessitate a rewrite Roan is doing. Okeyes (WMF) (talk) 18:20, 25 July 2013 (UTC)

Thanks, any idea of timescale yet? Thryduulf (talk) 18:33, 25 July 2013 (UTC)

I just spoke to Roan; he estimates "roundabout Wikimania, but no promises". From the explanation it's kind of a complex issue, so I understand their thinking there. Okeyes (WMF) (talk) 18:50, 25 July 2013 (UTC)

On flow conservation

Isn't it supposed to be the equation \sum_{u \in V} f(u, w) - \sum_{u \in V} f(w, u) = 0? Rodichi (talk) 16:13, 25 July 2013 (UTC)

You appear to have posted this in the wrong place. This is for feedback on the VisualEditor rather than on article content which should go on an article talk page. I've copied your question to Talk:Flow network as I think that is relevant place. Thryduulf (talk) 17:51, 25 July 2013 (UTC)

how do I turn this off?

Template:Answered I've updated the edit notice with the opt-out message, but I've not touched the FAQ. I'll do that when I come back later if nobody has beaten me to it! Thryduulf (talk) 18:46, 25 July 2013 (UTC)

Opt-out question, invalid token

This doesn't work and while I appreciate it is a beta version, why is there no link to get rid of it? I get an error relating to an invalid token. GPSJane (talk) 18:55, 25 July 2013 (UTC)

Look at the bottom of Special:Preferences#mw-prefsection-editing for the opt-out option. Whatamidoing (WMF) (talk) 21:06, 25 July 2013 (UTC)

Wikipedia:VisualEditor/Opt-out

I've roughed in a page giving instructions on how to turn VisualEditor off. Additional editing is welcomed. Adam Cuerden ^(talk) 19:10, 25 July 2013 (UTC)

I welcome this. However, I do hesitate to stop using the hide gadget and instead use the official opt-out. My hesitation is based on these words: "This option is recommended, as it will automatically give you a chance to try VisualEditor again when it's more developed and fully-featured." As I don't want to try VisualEditor ever again, the official opt-out might not be for me after all. Manxruler (talk) 23:19, 25 July 2013 (UTC)

Right Side Bar

Not sure why it disappeared when I was trying to edit the population. Please help and I apologize for the error. Eddiz (talk) 23:23, 25 July 2013 (UTC)

this edit was reverted by another editor because the information added by Eddiz was already in the article - which the Eddiz would have seen if he could see hidden text. Which he could not, because he was using VE. He also managed, via that edit in VE, to totally munge the large infobox on the right. -- John Broughton (♫♫) 01:43, 26 July 2013 (UTC)

Template:Replyto Just to make it clear, John Broughton is expressing frustration at the limitations of VisualEditor, not at your edits. Don't worry about the glitch, and thank you for taking the time to tell us about it. If you have any other feedback about the visual editor, we'd love to hear it. --Cryptic C62 · Talk 03:05, 26 July 2013 (UTC)

And, just to be clear, I also pointed out to Eddiz that VE was problematical, and thanked him for posting at VE/F. -- John Broughton (♫♫) 03:47, 26 July 2013 (UTC)

Renumbering of references

Noted when editing the Toronto Star article. References 1-5 are in the infobox. When clicking "Edit" anywhere on the page (i.e. by clicking either the "edit this page" button or the "Edit" link at any section header), the references all renumber to exclude the references in the infobox, and the reference list drops the references in the infobox. Risker (talk) 05:52, 26 July 2013 (UTC)

I've forgotten the number, but that one's already been spotted. I believe it's covered by Template:Phab.—Kww(talk) 06:10, 26 July 2013 (UTC)

"Opt-out" option being re-enabled

James D. Forrester wrote on the mailing list last night: Template:Blockquote

I personally would like to see this option enabled indefinitely, but this is better than the current situation! Zell Faze (talk) 13:28, 24 July 2013 (UTC)

Yay! Resentful push-back is enough to move people who is not listening. I'm making a note here: big success!!1! Diego (talk) 13:43, 24 July 2013 (UTC)

Well, the option to disable while in beta is there in the "Editing" tab, but it didn't disable it. Also, there are both "edit" and "edit source" links for sections on this page, but VE's edit link gives a namespace error. Pseudonymous Rex (talk) 16:22, 24 July 2013 (UTC)

Well, it works now. Huzzah! Pseudonymous Rex (talk) 16:34, 24 July 2013 (UTC)

Template:Ping that's the wrong conclusion to draw. The decision was not made because of resentful pushback; it was made because of sustained, reasonable complaints from reasonable people. If you want to take note of that, feel free. Okeyes (WMF) (talk) 16:40, 24 July 2013 (UTC)

The "making a note" phrase Diego used is from Still Alive which was a bit of a meme a couple of years ago. It's difficult to judge in what tone it was being used. Thryduulf (talk) 16:45, 24 July 2013 (UTC)

For the good of all of us (except the ones who are dead). --Cryptic C62 · Talk 16:56, 24 July 2013 (UTC)

This is why I need to work <14 hour days sometimes; I have no idea about pop culture. I got introduced to Archer and Venture Bros yesterday, however, which makes me happy. Okeyes (WMF) (talk) 17:04, 24 July 2013 (UTC)

This one of only about 2 video game reference I know (certainly for anything newer than Sonic the Hedgehog), and that's only through having a couple of friends who were very into Portal (the other being Team Fortress 2)! Thryduulf (talk) 17:31, 24 July 2013 (UTC)

I think it's unlikely that so many editors will "deprive the community of their input", by opting out, that the VE team won't find out about problems, or won't get a good understanding of their impact. I've seen a lot of sustained work here, by volunteers (not to mention the stressed WMF staff), to help make this project a success, and I don't think that's going to slacken off as VE gets better. If (say) half the community opts out - well, that leaves the other half still helping on the VE project. It also means more time (and less irritation) for the half that opted out to do their regular things at Wikipedia, improving it, which is a good too. -- John Broughton (♫♫) 17:20, 24 July 2013 (UTC)

I agree with you, and this is the argument I made; that most of the people providing useful bug reports (you, Pam, Thryduulf, Excirial) etc are not looking to hit the button, just for the button to be available for those who are. I'm tremendously grateful for the work you and others have put in. Okeyes (WMF) (talk) 17:23, 24 July 2013 (UTC)

Now we just have to work on making this the default setting for new accounts until VE works. It still frustrates me that we insist on exposing new editors to a tool that our own experience and WMF's quantitative research both demonstrate doesn't achieve the objectives for the project. VE may be the wave of the future, it may be wonderful next year, but it isn't functional enough to expose newbies to right now.—Kww(talk) 19:06, 24 July 2013 (UTC)

Okeyes - I like the way you try selling this as you listening to the editors. To me taking so long and requiring so many people to say something is not something to be proud of. Consensus on this matter, at least amongst en.wiki editors has been clear for some time and yet only now does this happen and only then "temporarily" despite most editors wanting the option permanently. Am I against VE, no, I think it's a wonderful idea and will help a lot of people. Do I want to use it, also no. I'm a computer person who codes, spends hours looking at data text files etc. I would much prefer editing raw wikitext to the VE - I can work out what's happening with the first much better than the second. I accept I'm probably in the minority on this but I don't like VE being pushed down my throat like it was. It's not like you had to do much extra to cater for us that don't want to use VE - the capability to edit wikitext was already there. Yet there was a WMF / developers know best attitude which seemingly ignored the views of many editors who are happy editing wikitext and who also happen to be a lot of the experienced editors that keep this site running. This method of deployment of WMF / developers know best followed by eventually backtracking after a large backlash (which has always needed to be much, much larger than it should need to be to get attention) has to stop. The backlash here was very predictable but WMF / developers either didn't bother to find out or didn't care. I don't think you can now take any credit for the very late correction. Slightly ranty but I'm fed up of being dictated to by WMF / developers. Start listing to the editors more. How long do you think you'd be able to keep en.wiki running for without the senior editors / admins? I reckon you'd struggle to last 24 hours but this is the very group you're annoying most. The WMF would do well to remember that and try to at least engage us more else there will be very few left. Dpmuk (talk) 22:49, 24 July 2013 (UTC)

I'm not trying to sell it as anything, Dpmuk. I'm saying that I as an individual argued for it for those reasons. Okeyes (WMF) (talk) 00:10, 25 July 2013 (UTC)

Just to be clear I was referring mainly to your first comment the one starting "that's the wrong conclusion to draw" which seemed to be a comment about WMF / developer thinking as a whole, not your personal thinking. Your personal thinking on this seems sensible, WMF / developer thinking, as a group, seems extremely misguided - there seems to be an obsession with getting new editors on board while not caring about existing editors or tools to make running wikipedia easier. Dpmuk (talk) 14:16, 25 July 2013 (UTC)

Oh, and could you explain how finding out what users want is wasting time, that seems to be implied by the original mailing list post, and getting users on board if that's not possible, is a wate of time - "Instead of endlessly arguing the point about this, I'd rather my team and I spending our time working to make our sites better." I suspect part of the problem here may well be communications issues but statements like that hardly help editors to feel there opinions are valued. Dpmuk (talk) 14:20, 25 July 2013 (UTC)

I can't, because I didn't make the statement; James is speaking for himself, and I encourage you to ask him directly about that for greater transparency :). My first comment was largely personal, but I've been here for two years, and I don't think I've ever seen a decision made because of sheer outrage. Outrage from reasonable points, yes, but the reasonable points are what swings it. The outrage is, at best, superfluous. Okeyes (WMF) (talk) 16:51, 25 July 2013 (UTC)

I'm going to continue this on your talk page as I think we're moving away from VE feedback to more communication issues which is a slightly different subject. Dpmuk (talk) 17:26, 25 July 2013 (UTC)

I thank the WMF for finally listening, but do think that the announcement of this is, at best, rather tonedeaf. Also, while I fully expect and encourage the WMF to turn VE back on for everyone when they're sure it's ready, I really don't think it would help anyone if they remove the ability to disable it again.

For one thing, the VE actively rejects even the most basic wikimarkup support. That means that many, perhaps even most old users will never accept it. In the example linked, the WMF is rejecting a choice between a keyboard-based "type [[link]]" in favour of a mouse-based interface, a choice that will never be as fast as keyboard alone. This seems counterproductive, petty, and frankly, a sign that the WMF don't understand what people actually like about Wikitext. As such, I have strong doubts VE will evolve into anything I'd want to use anytime in the next three years.

By keeping the option to disable VE, the WMF may cause a lot of people who dislike VE to choose not to use it, but the alternative is to force the people who dislike it to use it anyway - and that's a good way to make people hate VE and you.

So far as I can tell, the VE development was done based solely on the desires of new users. Whilst they're an important audience, by cutting out older users from the research, the VE team have basically assured that old editors would be dissatisfied. Until that changes, I do not see myself ever willingly using VE, and would stop editing Wikipedia if given no other option. Adam Cuerden ^(talk) 23:50, 24 July 2013 (UTC)

Template:Ping It's incorrect to say that we're rejecting markup inside the VisualEditor "in favor of a mouse-based interface". In the case of links, for example, the keyboard shortcut is the same that's used as in many other rich-text editing environments: Ctrl+K.

Adding a link to the page "Ten Commandments" in wikitext:

1) Use search to ensure I'm linking to the right page

2) Type [[Ten Commandments]] into wikitext editor

Same result in VE:

1) Type Ctrl+K, followed by "Ten Co", cursor down, enter, enter

As a nice plus, if I want to view the page I linked to, I can right-click (yes, mouse) the link in the editor and open it in a tab. No need to preview or run a search in a new tab.

No need to search at all, and number of keypresses for the link reduced from 20 to 10.

There's still more room for optimization, but I hope the point comes across that the goal is very much to build interfaces that are efficient and discoverable. Yes, tying wikitext into VisualEditor would be moving backwards. Yes, there are cases where VisualEditor is slower -- e.g. if you use certain templates frequently, and have the parameters memorized, or if you're using the citation toolbar in the old editor. But our goal is to continue to improve on all fronts.--Eloquence* 07:18, 26 July 2013 (UTC)

Well, if Wikuitext isn't tied in, I will never even consider using it. I see absolutely no reason to learn a whole new set of shortcuts if the VE team bizarrely think that using the shortcuts already there is "moving backwards". That's an insult to everyone who worked to make Wikipedia what it is today.

If the Visualeditor team cared about bringing in new users, they'd make the transition easy. Instead, they'd rather create something with no connection to Wikimarkup.

And let's presume for a moment that VE succeeded in replacing Wikimarkup for a majority of new users. (although the tests say all it does is drive users off). Who, then, would be able to maintain templates? Handle tricky issues like the maths code - you're never going to wean mathmaticians from LaTeX, you know - or deal with all the structure and maintenance that needs something more powerful than VE could ever be? VE can't train users to use Wikitext, anything learned on it is wasted training when it comes time to skip over to the editor that actually has all the features - and if you really think coding templates will ever be practical in VisualEditor, I'd like to see a short plan for how you'd handle that.

A user compared VisualEditor to New Coke a while ago, something that everyone involved in the creation of thought was great, but which only served to let them know how much people cared for the old product.

VisualEditor was a good idea, that was strangled at birth by a misguided desire to be different from what came before, and a stubborn refusal to ever listen to editors (or even to consult editors) that have been on Wikipedia for years. My first Featured Article was seven years ago now, and, through thick and thin, I keep coming back to Wikipedia because I support its goals of free content. And I'm glad the WMF are experimenting, but for god's sake, stop only polling people whose first experience with Wikipedia is five minutes into the testing. That's one important dempographic. The people actually editing Wikipedia are another demographic you seem to think are worthless. Adam Cuerden ^(talk) 07:30, 26 July 2013 (UTC)

Erik, by the time the VE developers finish making an efficient and easy to use interface, it will by necessity resemble Wikitext a lot. You seem blind to the fact that wikitext is a very good tool for the problem it solves; this is what has allowed Wikipedia to grow this size - its base is a really sound one. Every time you say how wikitext is obsolete or hard to use, I die a little death inside.

There are tasks for which the simple approach of a visual editor are simply not adequate, and one based on editing a stream of tokens is superior. See for example:

• How would you efficiently create a table with all the links to the different treaties of Paris, changing the first letter to lowercase?
• How would you quickly reformat this table into this list with the VE? I can do it fairly quickly with search-and-replace techniques on the source code.

Of course Wikitext has drawbacks, and the VE would do well to improve templates' discoverability and copy the previous reference tools; but that shouldn't be at the cost of creating a whole new way of creating articles just for the sake of novelty. Visual editing is so 1980's, and better interaction models have been invented since then. VE should grow towards WYSIWYM (where M=mean), not WYSIWYG, i.e. a tool allowing editors to type semantic tags directly or through wizards, not an editor based around syntax pretty-printing.

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 by the VE, true, but also much less efficient by the new interface). Hiding all markup complexity from newbies is making them a disservice, since learning templates and categories is needed to become an experienced editor, and templates and categories are best edited as raw text (i.e. good old copy-paste), rather than through wizards and slower form-based dialogs. This is not incompatible with making them discoverable, but modal dialogs are discouraged for a reason, and they're not the only way to get a usable interface. An Archy-type project is what you should be trying to achieve (minus the ZUI), as it's the best model for the kind of semantic-text-oriented editing that a wiki requires. Diego (talk) 11:11, 26 July 2013 (UTC)

new editor is creating artifacts

Template:Tracked in the 'Karma in Hinduism' page every time i edit the page using the new cool uber-awesome fantastic (but slow to load) editor it changes an unrelated paragraph next to an image. You can see the edits and artifacts around this time:

8:32 PM Thursday, July 25, 2013 (UTC) 201.27.126.60 (talk) 20:32, 25 July 2013 (UTC)

This one is very wierd. Here are the diffs from 201's editing[10][11]

I've been able to reproduce this[12][13], ... intermittently: [14]. I havent seen any other junk-insertions that insert different junk each time, and sometimes don't insert junk at all. John Vandenberg ^(chat) 05:53, 26 July 2013 (UTC)

Thanks both :). Now in Bugzilla. A regression after yesterday's deployment, maybe? Okeyes (WMF) (talk) 18:09, 26 July 2013 (UTC)

This is caused by an image followed immediately by a wikilink. I suspect this doesnt happen too often, but often enough it is going to be problematic. It would be good to do an impact analysis to identify all pages with this syntax and fix them all at once, taking the pain out of this bug and letting the dev team work on the bigger problems. John Vandenberg ^(chat) 06:00, 27 July 2013 (UTC)

Editing infobox followed by inability to edit references

If this was reported / dealt with earlier, thanks for saying so and pointing. Sequence of events with VE ...

1. started editing University of Delaware with VE
2. opened the main infobox template for editing
3. found that the reference I wanted to update had been added with ref-tags and template in the 'endowment' field as text in the field
4. edited the text to introduce archiveurl, archivedate and deadurl parameters
5. closed the infobox to return to editing the rest of the article
6. found that selecting ref elements did not call up the edit-reference icon, thus making it not possible to edit other references / citations on the page.
7. saved the page with just the infobox / referenced edit having been completed
8. confirmed save OK -- the diff

Regards --User:Ceyockey (talk to me) 00:41, 26 July 2013 (UTC)

That's odd. I can't reproduce that in Firefox 22 on Linux, which browser/operating system are you using? Thryduulf (talk) 08:00, 26 July 2013 (UTC)

Chrome 28 on Linux. --User:Ceyockey (talk to me) 20:10, 26 July 2013 (UTC)

Strange reference formatting change

Anyone got an explanation for this one, where VE apparently decided it didn't like the reference tag formatting?—Kww(talk) 06:06, 26 July 2013 (UTC)

The parsoid topfails is full of examples of the parser standardising ref names and removing spaces inside ref tags that only have a name parameter. The parsoid team call that a stylistic change rather than a semantic change. John Vandenberg ^(chat) 08:15, 26 July 2013 (UTC)

Is there a bugzilla? Dirty diffs are unacceptable.—Kww(talk) 14:35, 26 July 2013 (UTC)

Just so it is clear, as I clarified in this wikitech-l mail, stylistic changes show up as dirty diffs only when refs/templates are actually modified. Even there, we have started to track original whitespace to restore it. But, at this time, it is not possible to completely eliminate all stylistic changes. Our goal has been to limit the scope of such changes only to modified sections. That said, for this particular example that Kww linked to, this is a bug in VE (that we identified couple days back and Roan is working to fix) where occasionally, <ref>s show up as modified when it reaches Parsoid (even when it is not). Since it shows up as modified, Parsoid uses the full serialization algorithm and introduces the diffs. Once that VE bug is fixed, these kind of diffs should go away. Ssastry (talk) 15:49, 26 July 2013 (UTC)

Editing sections

Template:Tracked When wanting to edit a section of an article, it is highly frustrating to wait (what feels like ages) for the entire page to reload with the microsoft word-style buttons. Can we make it possible to just edit individual sections like with the original editing style?--Coin945 (talk) 08:44, 26 July 2013 (UTC)

That is an often requested feature - see Template:Phab for the current status. Excirial ^{(Contact me,Contribs)} 09:19, 26 July 2013 (UTC)

You can continue to use the original ("source") editor to edit sections, just click the "edit source" link rather than the "edit" link by the section title. At present you have to hover over the title line for a second or so before the edit source link appears, but you can disable this by using the code shown in the #Edit Source is upsetting. When reading is upsetting section a few sections above this one. Thryduulf (talk) 09:29, 26 July 2013 (UTC)

I can't help but feel that section editing and VE are and should be mutually exclusive. If you want the WYSIWYG effect then you have to see the whole article to see how the section you're amending changes the overall structure and appearance of the whole article. I know it can be a bt of a pain to have to manipulate a whole article especially large ones but I think the benefits outweigh the downsides especially as sections are easier to identify in VE rather than walls of wikitext. NtheP (talk) 09:47, 26 July 2013 (UTC)

The developers plan for VE is that clicking "edit" should be instantaneous and without a reload, and therefore performance should not be a problem when you want to edit a single section. Unfortunately the architecture required to achieve this won't be in place for at least one year. Diego (talk) 09:50, 26 July 2013 (UTC)

hey!!!

i dont feel good with this new sistem of edition. simply not good Cheposo (talk) 12:02, 26 July 2013 (UTC)

Template:Replyto You're not alone. Is there anything in particular that you would like to see changed? --Cryptic C62 · Talk 15:55, 26 July 2013 (UTC)

The ↵ character

Template:Tracked Template:Diff added the ↵ character, as well as screwing several references and removing some wikilinks. --Redrose64 (talk) 12:14, 26 July 2013 (UTC)

That is caused by copy and paste between VE's. --John Vandenberg ^(chat) 14:38, 26 July 2013 (UTC)

To elaborate - you can copy/cut and paste within a page when editing in VE, but you can't copy/paste between pages using VE, at least not yet. That's on the (long) to-do list of the VE development team. -- John Broughton (♫♫)

Well, I thought VE could do a cut/paste within a page, but apparently not even that, per this posting, above. -- John Broughton (♫♫) 17:06, 26 July 2013 (UTC)

Per #Copy and past wikilinks? this should hopefully be fixed around the time of Wikimania. Thryduulf (talk) 21:40, 26 July 2013 (UTC)

Link formatting trick

• Case 1a: Find or create a piped link of the form [[Title|'Anchor']] (including the apostrophes). VEdit the page, highlight Anchor and hit Italics. When the page saves, the result is [[Title|'''Anchor''']], which produces a bolded link.

• Case 1b: Find or create a piped link of the form [[Title|'Anchor']] (including the apostrophes). VEdit the page, highlight 'Anchor' and hit Italics. When the page saves, the result is [[Title|''<nowiki>'Anchor'</nowiki>'']], which produces an italicized link.

Interesting. --Cryptic C62 · Talk 16:27, 26 July 2013 (UTC)

This is a parsoid serialization bug. Thanks for the report. Will work on a fix. Ssastry (talk) 16:36, 26 July 2013 (UTC)

Visual editor slow

I think the visual editor is slow and it never saves the edits I make until I press the " Return" button. I mean it definitly needs alot of improvement.--BabbaQ (talk) 16:43, 26 July 2013 (UTC)

It is slow. On long pages it takes two minutes and more before you can modify anything and it takes way too long to store the changes (mostly because of the fact that with VE so far it is not possible to edit a section only, so the whole article must be transmitted to the servers. It is so slow that I believe WP will loose editors because of this. --Matthiasb (talk) 19:14, 26 July 2013 (UTC)

The underlying issue is that the new system requires a great deal of local computation, and so performance is dependent of the speed of your personal computer (as well as the efficiency of your browser's javascript). Old computers and browsers will be slow under this framework, though even modern computers are rather sluggish on large pages. For some features also requires many back and forth HTTP requests, adding a layer of latency for slow connections. Under the old system, most of the computation occurred on the WMF servers, which made the experience more consistent than it is now. Better optmimzing what is computed, when, and how should offer potential for improvement, but I don't think this system will ever be as responsive as wikitext for most use cases. Dragons flight (talk) 19:32, 26 July 2013 (UTC)

Example with an 88 kb article. Many if not most editors are contributing with hardware like was used in this example – or even older, I think. --Matthiasb (talk) 21:27, 26 July 2013 (UTC)

"VisualEditor: The present and future of editing our wikis" at Wikimania

[15] lists this rather interesting event. I look forwards to hearing about the inevitable booing and chaos as they try to sell this idea to a hostile room. I can't imagine the VE team can have even the minimal humility needed to keep the editors on their side.

And I really do think it's important that they have to face editors face-to-face on this one. They're never going to listen to editors who write in text. They're going to need to experience personally the users' opinion on how poorly they've handled the launch, the planning, and, most of all, how their dismissal of wikitext is backwards and unacceptable. Adam Cuerden ^(talk) 19:05, 26 July 2013 (UTC)

Adam, I don't think it's necessary to use the word "fuckup" here. In person at Wikimania, yes. Here, no. (I don't really mean that to be sarcastic. The WMF people and Wikipedia editors who read this page already know what you think. Most of the Wikipedia editors already agree with you, but not entirely with your wording.) — Arthur Rubin (talk) 19:34, 26 July 2013 (UTC)

My apologies, I've replaced it with a description. Adam Cuerden ^(talk) 20:11, 26 July 2013 (UTC)

Interesting, especially the submission. By Wikimania, we hope to have set VisualEditor to be the default way people edit all Wikipedias : is it the explanation many editors asked trying to understand why the schedule was so important ? --NicoV ^{(Talk on frwiki)} 21:17, 26 July 2013 (UTC)

I hope, in the Q&A at the session, this statement comes up (from that submission): "We expect the VisualEditor to be a better way to edit not just for new users, but also for experienced community members – whether it is with templates, references, categories or other areas." It will also be interesting to see, by August 9th (the start of Wikimania) what percentage of all edits are being done using VE, versus the wikitext editor. And perhaps an up-to-date count of how many editors have opted out would be informative. -- John Broughton (♫♫) 04:14, 27 July 2013 (UTC)

Something odd

Template:Tracked The top part of this diff with the duplication / breaking of the <br> tag is rather odd. Dragons flight (talk) 19:58, 26 July 2013 (UTC)

Indeed that is rather odd. I've reported this as Bugzilla:52124 (although it might be a duplicate of Bugzilla:51304). Thryduulf (talk) 22:22, 26 July 2013 (UTC)

Panel tint

I want to mention it here in case anyone else likes it. For a while now I have been using:

.ve-ce-surface { background: #F8FFF8; }

To tint the entire VE edit space a soft green. I find this very helpful for making obvious when I am in edit mode and when I am in reader mode. Dragons flight (talk) 20:07, 26 July 2013 (UTC)

Which page do we add that to? Our personal css or something more specific? Thryduulf (talk) 21:44, 26 July 2013 (UTC)

Personal CSS. (Unless of course you want to discuss doing that for everyone.) Dragons flight (talk) 21:56, 26 July 2013 (UTC)

Thanks. I wouldn't object to doing that for everybody, but having read James' comments at Bugzilla:48008 about how the design philosophy is that there is no difference between reading and editing I suspect there would be serious "push back" about doing so. Thryduulf (talk) 22:14, 26 July 2013 (UTC)

Template:Ec Template:Phab relates: devs don't like the idea, feel that edit mode and reading ought to be seamless...? Sounds daft to me. It's been ranked as "Lowest enhancement", which is presumably only one step up from "No". Others might like to contribute to the discussion there. I favour a red bar down left margin, but pale green surface would do fine too (perhaps would need to be configurable by editor, for colourblindness and other visual impairments?) PamD 22:17, 26 July 2013 (UTC)

Thanks for this tip, though for me the color change was too subtle. I tried #000000 and found it's great for finding and working on just links, and it keeps me out of all kinds of other trouble ;-) Chris the speller ^yack 02:13, 27 July 2013 (UTC)

#000000 is, well, a bit harsh, unless you really do want to limit yourself to link editing. I tried #F8FFF0, which provides a light pink background that I like. The suggested F8FFF8 was too subtle for me as well. -- John Broughton (♫♫) 04:27, 27 July 2013 (UTC)

I've changed mine to #FFFDD0 which is a yellow shade that contrasts sufficiently for me and is nothing like the pink of a protecteed page. Thryduulf (talk)

existing error

Template:Tracked While putting in stub templates in article "Zhang Shi (prince)" using the visual editor, when trying to save I got the text

"Error loading data from server. Unsuccessful request: Invalid token."

This appears to be an existing bug.

will try using the Edit source. Successful Rpyle731^talk 22:25, 26 July 2013 (UTC)

Yes, this is Bugzilla:51915 which has been assigned and marked as high priority. Thank you for the report as it makes devs aware of the scale of the problem, Thryduulf (talk) 22:35, 26 July 2013 (UTC)

Visual editor is still a disaster

Its obvious at this point that the WMF isn't going to admit the huge mistake they made in releasing this piece of crap but its clear that's how the vaste majority of people feel. Its been more than a month since its beta release and more people are screaming for the madness to stop than ever before. People are flooding talk pages with bugs, complaints and comments. I took a break for a couple weeks to see if things got better, they haven't. The application is garbage and needs to be removed until its fixed. I'm logging back off now since this is no longer about helping editors but the WMF being pointy. Visual Editor is officially driving away editors because the WMF doesn't want to do the right thing. What a shame. Kumioko (talk) 00:08, 26 July 2013 (UTC)

I think it is important that people continue to flood "talk pages with bugs, complaints and comments." Without that, we could be ensured of a total failure to advance VE from beta to pre-production. It is when people stop talking and just walk away, leaving a silent wasteland, that things are truly over. --User:Ceyockey (talk to me) 00:44, 26 July 2013 (UTC)

Still, it's disappointing to read this (from a July 17th meeting of WMF executives and VE staff):

Sue [Gardner]: Jimmy [Wales] might cover VE in his Wikimania keynote. My general sense: we are getting less pushback than I personally expected. Time has passed for a mere "help us test this" message

Trevor [Parscal]: What convinces community members is us reacting to their concerns and needs, incorporating feedback

Philippe [Beaudette]: Yes, we fixed ~200 bugs. also: this whole project has been a reactive one from the very beginning, taking up concerns/needs that were voiced in the community for a very long time

Sue: Imagine all the awful things (breakages etc.) that *could* have happened, but didn't. Do we have some illustrative examples of people whom VE empowered? Of "wanted" editors, e.g. subject matter experts?

Erik [Möller]: We have some, ID'ed by community liasons. e.g. comments on feedback page

Erik: Most contentious issue: made a conscious decision not to offer an "off" switch

-- John Broughton (♫♫) 01:17, 26 July 2013 (UTC)

That's part of the problem with things in Wikipedia these days. The WMF is so full of themselves and their "accomplishement" of VE that they are hearing the comments and not listening to them. They are clearly trying to justify a decision that was bad when it started and getting worse by the day. Yeah they fixed 200 bugs but there are double that still to be fixed. That also eludes to what many of us have been telling them. That this early release had so many problems is a testemant to the poor planning and implementation. The WMF can deny it all they want and continue to pat themselves on the back but this is nothing but crap and the way the WMF is going about it is just piss poor. Kumioko (talk) 01:37, 26 July 2013 (UTC)

The visual editor is completely useless for anything other than the simplest tasks and its design is fatally flawed. Until the WMF wakes up and acknowledges that unpalatable truth nothing is going to change. How many years have they been working on this crock for now? Eric Corbett 01:43, 26 July 2013 (UTC)

That link to the minutes goes nowhere. Can you fix it?—Kww(talk) 01:50, 26 July 2013 (UTC)

It's meta:Metrics and activities meetings/Quarterly reviews/VisualEditor-Parsoid/July 2013. John accidentally linked mw: instead of meta:. I have fixed his post. PrimeHunter (talk) 02:00, 26 July 2013 (UTC)

Sue stated, "My general sense: we are getting less pushback than I personally expected". Really? With all the comments, questions, complaints and bugs and dozens of venues by hundreds of users. This was less than they "expected" and they still went ahead with it? They trully are as stupid as I thought. The release of VE was nothing short of an F'ing disaster and they thought it would be worse. Simply appalling. Kumioko (talk) 02:10, 26 July 2013 (UTC)

I wonder if your "dozens of venues" knocks the nail on the head. They can't get a full of idea of the response as it's too fragmented and they seemed to have overlooked developing methods of effectively communicating with editors and vice versa. Dpmuk (talk) 04:54, 26 July 2013 (UTC)

Template:Unindent Actually, VisualEditor is not targeted at the thousands of users who've made it through the gauntlet and figured out how to edit with wikitext; we know it, and we're not all that likely to change. I have the sense that the WMF isn't the least concerned that about 95% of "old user" edits are done using wikitext. That, to me, is a problem, because it creates a serious social gap between generations of users. We're not that far off from having only a small percentage of "old hands" being able to explain what we consider to be basic editing practices to new users, and we don't know very much about the new users who are joining at this point and won't for a while. The last time that we had a major gulf was around 2006-07, and we have never really got past the problems with socializing a large group of new users whose activities were "different" from other editors. It was at about that time that so many of the issues relating to "civility" and mutual respect started to erode. It concerns me that there's little evidence of thought on the part of the WMF as to how these new editors are going to be socialized into the communities. Of course, I could be wrong, and there could have been lots of thought about this, but that thinking hasn't been shared with us. I just keep pointing to the fact that they've got half a dozen short-term community liaisons, and once they're out of the picture, there's no reason to believe that the community is going to be in any position to support all these new editors using software that is largely terra incognito for the rest of the community. One thing that I know for a fact much of the developer community (both staff and volunteers) hasn't realised is that most of what they are doing now is as much social engineering as it is technical engineering. The code that they write isn't just keeping the servers running. It's intended to directly affect socialization and interaction on the projects. They need to own that fact, and to be willing and able to deal directly with the human effects of their work. Risker (talk) 05:05, 26 July 2013 (UTC)

What worries me even more is that the new experience has such profoundly inferior capabilities. How can we explain to editors that a table is the best way to go for certain kinds of data when they can't edit tables? That using templates like Template:Tl is better than manually coding links to charting sites when VE can't display the output of the template correctly?—Kww(talk) 05:19, 26 July 2013 (UTC)

Agreed, it's extremely irritating and having to click back all of the time because of habit of clicking the edit button and it going to the visual editor. I've hidden it in my preferences at least. It is very worrying to me that the foundation seem to think that this has been well-received.. Tibetan Prayer ^᧾ 11:31, 26 July 2013 (UTC)

Risker, from reading the various WMF messages and the some of the long-term planning documents, I believe the WMF's likely response to your concern about having two communities is that they ultimately want there to be only one community united in their use of VE. In other words, VE is intended to be the future for old and new users alike. In the short-term, that means adding more functionality and tools to VE in the hope that it will eventually have usability and features sufficient to entice old-timers like us to use it (at least part of the time). In the medium term, VE will be enabled on most non-talk namespaces (aside from specialty spaces like Template and Mediawiki), while Flow will be bringing a VE-like experience to talk pages. This will make it harder to avoid using VE. We would also start seeing features, via Flow (and possibly in VE as well), that are hard or impossible to replicate without using visual editing. The long-term plans calls for completely replacing wikitext with HTML+RDFa as the primary storage medium for page content. Wikitext would still be available, but only to the extent that Parsoid can convert HTML+RDFa to and from Wikitext. At that point, any wikitext constructions that Parsoid still can't represent would cease to be possible. In addition, Wikitext editing could become slow due to the need to do HTML+RDFa to wikitext transforms on demand, while VE would become faster as it would no longer be required to generate wikitext. It is clear that WMF sees VE as the future of the interface and HTML+RDFa as the future of the backend. The WMF has no plans to eliminate wikitext, but if they follow through with their plans as currently outlined then the side effect is that wikitext would become a legacy product that doesn't support all the features of VE and possibly has a degraded experience due to added conversion overhead. The WMF plan is for a future where ultimately most users are using VE for most things. That would avoid the two communities problem, but getting there will require both a VE experience that is much better than today across many classes of users and also getting the existing user base to accept and use VE (hopefully because they want to, but possibly because they have to). Dragons flight (talk) 18:50, 26 July 2013 (UTC)

They claim to want two communities united in VisualEditor, but flat-out refuse to provide even the most basic compatibility options, like '''bold''', ''italic'', and [[Link]] wikitext support. The whole lot of them are mad, bad, and dangerous to be in charge of the project. Adam Cuerden ^(talk) 19:01, 26 July 2013 (UTC)

Adam please try to tone down your words. While that is a quote, and the actions of the VE team are clearly not to the liking of many people, they are not "mad" and both they and VE are far from "dangerous" ("bad" is subjective). You have made your point many times, and while I agree with some of what you say the way you say it is frequently bordering on offensive. Thryduulf (talk) 21:36, 26 July 2013 (UTC)

Why tone it down. Editors all over the project have been saying the VE wasn't ready for months. There are still major bugs and missing functionality. The WMF refuses to accept that VE is a failure and stonewalls or ignores comments to the contrary. The VE project has exhausted virtually every friend they have in the community and have turned supporters of the project against them because they rushed it. I wished I could be at Wikimania to see all the complaints and comments in person. The VE and the conduct of the WMF is a perfect example of why Wikipedia is a ailing project. Kumioko (talk) 16:22, 27 July 2013 (UTC)

Template:Xt Because people are far more willing to listen to reasoned, rational arguments and because insults and personal attacks are likely to be counter-productive. I agree it's far from ready, that it has been pushed far too soon and that they have been ignoring this for months, I disagree that acting like a child about it will help. I too wish I could be a Wikimania to see if they finally grok the community's view that VE is alpha software still. Thryduulf (talk) 16:37, 27 July 2013 (UTC)

But the developers of VE, the WMF nor the people that are acting as community liaisons aren't listening. The nice way or otherwise. It doesn't matter what we say or how we say it. They flat out do not care what we think, do or say. They don't care about the community or the project. Its just a job to them and they show it in their actions. They want us to tell them what a great job they did and pat them on the back. But the VE is garbage in its current state, continuing to be a nice little editor and sitting quietly in the corner is neither my style nor is it helpful to the project. The developers and the WMF may have good intentions but their piss poor planning and implementation of VE is doing more to destroy this project than any vandal ever did. I didn't edit for 2 weeks because of this crappy app. I'm not the only editor that stopped editing over it either. I'm not going to clean up the WMF's mess. Kumioko (talk) 17:09, 27 July 2013 (UTC)

Workshop for newbies using Visual Editor

Just wanted to record the salient points of using VE at a workshop for 40 newbies (35 women, 5 men) at Sophia College, Dept of Social Communications and Media, Mumbai on July 13. The Mumbai community ran this 3-hour workshop on request from the department.

• Editors conducting the workshop need to plan to use VE in advance, and themselves be comfortable with using it. While 4 of us conducted the workshop, only the two of us who were comfortable with VE did the demo. We agreed on this in advance.
• Check that the laptop being used has a non-IE browser. We forgot that VE is not enabled for IE and spent 15 minutes puzzling over this - we were using the department's laptop.
• Demonstrating the VE is a huge time saver. We had 2 hours for a hands-on experience; it took us only 15 minutes to demo VE, after which the students broke into groups and edited. They got much more editing time using VE; the back-end was more intuitively familiar than wiki markup, so they immediately got it. They created their first stubs within 15 minutes, and most of that 15 minutes was spent looking for references. (We had already introduced them to guidelines and policies in an earlier session.)
• It is difficult to add references using VE. We did not manage this successfully and went back to wiki markup, and while we managed to demonstrate how to insert a ref using markup, this was confusing for the students. Shuttling between two editing modes was also confusing.
• In sum, while there are pros and cons, this experience makes me hopeful that we can successfully use VE with newcomers in future workshops. One thing, though - we have to put ourselves in a newcomer's shoes and accept that this interface is instinctively more comfortable for a beginner: it facilitates quick, easy learning. (Even if we love markup, we need to accept this and start from here). Fully agree that a whole bunch of bugs and glitches need to be sorted out before we can take on VE lock, stock and barrel. Bishdatta (talk) 06:23, 27 July 2013 (UTC)

• Please teach students how markup is hypertext: While introducing students to VE is one aspect of using Wikipedia, please also teach them that wikitext markup is a form of special "hypertext" as textual data which transcends the literal text on the page and can concisely reformat, or cross-connect text with other pages, images, graphs, videos or sound recordings. Many computer scientists, such as myself, have worked hard for many years to create and improve hypertext interfaces and provide multi-word, search-engine searches, rather than just finding text-strings in a file. Please teach students how searching the wikitext for "[[" can find each wikilink inside the page, and searching for "{{" can pinpoint the use of each template, and putting hashmark '#' in column one can generate auto-numbered lines. In general, explain to students how wikitext is a text-formatting language which the computer can also read, or generate, even though the computer cannot, itself, change pages with VE, the computer can expand portions of pages by generating sections of wikitext as the result of computer processing. In a sense, the wikitext markup is a universal interlingua as a common language, beyond English or Latin or French or German, which both the computer and people can read or write to produce formatted pages. Computer scientists have worked decades to reach that level of communication between people and computers, and the hypertext can be multi-word searched, as with a search engine, for the hypertext keywords, such as "ifexpr" or "formatnum" or "nowiki" or template parameter names. As Plato said, "Those having torches will pass them on". Please spread the word, so the students understand how and why the wikitext form of hypertext was developed, and its connection with the multi-word search used by search engines. Thank you. -Wikid77 (talk) 12:35, 27 July 2013 (UTC)

Thank you for the detailed report. I hope the User guide (rewritten since your workshop), plus the VE fixes done since July 13th, will make similar workshops even more successful.

Having taught a couple of workshops on editing with the old wikitext editor, I fully agree with you that VE is much better for those who have never edited Wikipedia. I also agree that as editors gain more experience, they should learn more about wikitext editing - if only to understand what "Review your changes" (otherwise known as a diff) is actually showing them, and to know how to use page histories to find out who did what, and when, and (sometimes why) to that particular page. But for teaching absolute beginners, it's great to be able to concentrate on "You must have a source when you add information to an article; you must have several good sources when you create an article", and not on saying "remember, it's two squared brackets before and after text to create an internal link". -- John Broughton (♫♫) 23:56, 27 July 2013 (UTC)

MS Word compatibility

Template:Tracked Here's an experiment I conducted: In source, I wrote a sentence which employed strikeout, subscripts, and a Template:Tl tag. I entered VE, cut the sentence, and pasted it in MS Word 2007. To my pleasant surprise, all elements of the formatting and hyperlinking survived the journey. I then cut the sentence and pasted it back in VE. None of the formatting survived. I found it somewhat curious that formatting can survive the journey in one direction but not the other. --Cryptic C62 · Talk 06:26, 27 July 2013 (UTC)

There isnt a bug specifically about MS Word, but there is a request for the paste operation to work, properly, irrespective of whether copying from a webpage, a wordprocessor, or from a different Wikipedia page. See Bugzilla:33105. John Vandenberg ^(chat) 11:55, 27 July 2013 (UTC)

Swapping out images

Task: Using VE, Change an image while preserving its caption and positioning.

Method 1: Click on image. Click on media popup. Nothing helpful here.

Method 2: Click on image. Click on media button in toolbar. Select new image. Position is preserved, but caption is deleted.

So how would one do this? Is it even possible? --Cryptic C62 · Talk 16:41, 27 July 2013 (UTC)

I've added a new subsection, at WP:VE/UG#Editing images and other media files, that addresses this. Basically you need to copy the caption before you replace the image, then paste the caption text (from your clipboard) when you edit the caption for the new image.

That's a bit of a kludge, admittedly. When you're in the replacement process, the dialog box should show the prior caption and either allow you to edit that, or at least check/uncheck a box that says "Keep the caption used for the previous image/media file." -- John Broughton (♫♫) 19:38, 27 July 2013 (UTC)

Wikipedia VE versus Wordpress VE

It has recently dawned on me that the Wikipedia VE is to a substantial degree modeled on the VisualEditor used by the Wordpress blogging system (see http://en.support.wordpress.com/visual-editor/ for an overview). However the Wordpress version does quite a number of things that the Wikipedia version can't, such as special character insertion and switching between visual and source mode. It seems like it would make sense to set a goal of replicating those features (of course implementing them would take time). Is there a reason why that can't be explicitly set as a goal? Looie496 (talk) 17:02, 27 July 2013 (UTC)

Well, the VE team has, as an objective, "Be a great general editor for non-MediaWiki users too (e.g. WordPress), encouraging an ecosystem of reusers", so one would think that most or all WordPress features might eventually make their way into VE. However, it's still probably better to post specific suggestions for VE improvements to bugzilla (mentioning WordPress, as a nudge, wouldn't hurt), since I think that the VE team pays more attention to those (at least for the moment) rather than more general objectives. (For other mentions of WordPress, see the notes of the July 17 meeting from which I just quoted.) -- John Broughton (♫♫) 17:39, 27 July 2013 (UTC)

reference problem

ref tag is not okay 188.230.2.168 (talk) 17:21, 27 July 2013 (UTC)

Template:Replyto Can you give us more detail? I see this diff, but it isn't entirely clear what you were trying to do. --Cryptic C62 · Talk 17:25, 27 July 2013 (UTC)

Editing transclusion box....

Sorry, but I simply couldn't figure out how to do this using the VisualEditor. Thanx. 132.216.109.173 (talk) 20:57, 27 July 2013 (UTC)

Have you looked at the VE User guide (in particular, the section on templates)? If not, please do and see if that explains things. If you've looked and it still doesn't make sense, please let us know at what point the User guidel wasn't helpful. -- John Broughton (♫♫) 22:58, 27 July 2013 (UTC)

Edit wiki on the fly

Hello again, not sure if this is the right place/time to suggest this but here we go: I wish I could edit the plain wiki just by clicking a section... sort of a instant edit but without all the VE WYSIWYG items. Maybe this would need a all new dev but since current VE is full of resources, maybe could be a "lite version"? Thanks a lot. Dianakc (talk) 22:16, 27 July 2013 (UTC)

Template:Replyto You can edit just a section using the old wikitext editor. At the section title, hover over the "edit" link (or over the section title itself) until you see an "edit source" link appear; when it does appear, click on it. Yes, it's not the most intuitive thing, but the VE development team is determined to make the VE editing option more prominent than choosing the old wikitext editing, even when - in this case - VE cannot edit just a single section. -- John Broughton (♫♫) 23:03, 27 July 2013 (UTC)

Template:Replyto Yes I can edit a section but not without changing the screen, I'm suggesting a VE feature to edit plain wiki text on the same screen, withot WYSIWYG features, just a text editor. I think this would be helpful to ocasional users correcting small errors and when adding references.Dianakc (talk) 04:41, 28 July 2013 (UTC)

Would not save

VisualEditor wouldn't let me save an edit I was trying to make with it. After clicking the Save button, and waiting awhile (1 to 2 mins), the following error message came up: "Error loading data from server: Unsuccessful request: Invalid tokin". I tried saving numerous times, including after return to make more changes with the edit, and the same thing came up. In the end I clicked the Review your changes button, copied the diff to a file on my computer, and the made the edit [16] in source mode. Not being able to save edits is a really huge bug – I doubt most people would think to save the diff, and thus would lose their edits. I am using Chrome v28 on Windows 7. - Evad37 (talk) 02:20, 28 July 2013 (UTC)

We've had a steady stream of reports of this problem, but it is vital that the reports keep coming. I believe that the devs have fixed a few of the causes of this problem, but it seems there are more causes yet to be found.

user:Evad37, which browser are you using. Is there anything you can recall which might have caused this? e.g. Did you spend a lot of time working on the page before pressing Save?

As I mentioned above, Chrome v28. It may have been a timeout issue, as I did spend some time editing - which sounds like Bugzilla:50424, which was supposed to be fixed. The only odd thing that happened was that TemplateData failed to load for one instance of Template:Tl, and so I entered a couple of parameters manually, but all the other templates I edited before and after loaded the TemplateData normally. I didn't think it would be related, and I can't think of any thing else that would have caused it. - Evad37 (talk)

I suggest you install user:John Vandenberg/switch editor so you can bypass this problem when it happens (without resorting to copying the diff). John Vandenberg ^(chat) 02:56, 28 July 2013 (UTC)

Thanks, brilliant idea. If only the VE team could get that, and hiding the VE section links, and other workarounds built into the product, rather making us use custom CSS and javascript. - Evad37 (talk) 03:20, 28 July 2013 (UTC)

Refnames with VE?

Template:Tracked I added an existing citation that did not already have a "name=" value to a second location within an article. VE added a default name to the reference to allow it to be cited twice, I think the value was ":0". Is there a way to assign a more meaningful name to the reference within VE? VQuakr (talk) 18:43, 25 July 2013 (UTC)

Thanks for the note, VQuakr. Do you have a diff handy? It's always nice to put one in, if there isn't already a bug report on this. Whatamidoing (WMF) (talk) 21:03, 25 July 2013 (UTC)

Actually I do not; I did not click "save" the second time after viewing the changes. I will see if I can recreate it later; I ended up making the change in the Wikitext editor here instead.

Just so I understand - is what I described the intended functionality? Is there supposed to be a place to enter the ref name on the references interface in VE? VQuakr (talk) 00:33, 26 July 2013 (UTC)

Template:Replyto - No, VE does not ask (or allow) a user to specify this parameter when he/she clicks "Use an existing reference" and then selects one, in the Reference dialog. Presumably this is something the VE team will consider adding at some point, and/or getting VE to suggest or specify something more human-friendly.

Template:Replyto This reference naming approach is standard VE behavior - see this edit, for example. -- John Broughton (♫♫) 17:03, 26 July 2013 (UTC)

Yeah :/. In bugzilla; hopefully they'll at least come up with an explanation for why this has been done. Okeyes (WMF) (talk) 18:03, 26 July 2013 (UTC)

Even if the devs add the ability to change ref names, VE will still need to automatically assign refnames, and ':0' is definitely not a good ref naming convention. On enwp we have, or had, a bot that automatically merged refs together. To do this, it will have automatically assigned refnames to refs. It would be helpful if we can find the developer and see if they can provide some suggestions on how to automatically name references, based on feedback they received. p.s. VQuakr, shameless plug: if you use User:John Vandenberg/switch editor, you can finish your VE edit in the source editor when you find VE has created an unsatisfactory diff. John Vandenberg ^(chat) 22:22, 26 July 2013 (UTC)

My default name for reference is the primary author's last name followed by the year of publication. I am not sure if there is any standardization of this, however. If citation templates are used, it should be trivial to pull a similar ref name out of the reference to use as the ref name. VQuakr (talk) 00:10, 27 July 2013 (UTC)

The bot is User:Citation bot, operated by User:Smith609, and the code is open source at Google Code. John Vandenberg ^(chat) 03:31, 29 July 2013 (UTC)

Edit Source is upsetting. When reading is upsetting

Template:Tracked It is VERY unpleaseant for me to read with the new feature. When I pass the mouse over the edi button, appears a new button saying edit source. I know these things are great for editors. But they are really distracting because one scrolls the mouse accidentally, in all the horizontal white stripe, i mean one scrolls the mouse over any place at the same height of the screen that Edit button, then Wild Edit source button appears. This is horrible. Please, make it harder to find. This distracts the eye a lot, i'm tottally serious. Plase, don't take this for a joke, i'm serious, the editors may have another way to do that, for example clicking on a small STATIC button for visual editing, that would be GREAT! Thank youSantropedro1 (talk) 01:22, 26 July 2013 (UTC)

Santropedro, it appears that English may not be your first language. I will attempt to summarize your concern in a way that may be clearer to the developers and other contributors. Please let me know if I make a mistake.

It is very unpleasant for me to read articles now that VisualEditor is enabled. When my mouse passes over an "edit" button, a new button appears which says "edit source". I know these things are great for editors, but they are really distracting for readers: if one accidentally scrolls the mouse anywhere at the same height as an "edit" button (even on the other side of the page), then the "edit source" button appears. [...] One possible solution would be to incorporate a small static button for visual editing, as this would be less distracting for readers.

Thanks for the feedback! --Cryptic C62 · Talk 03:02, 26 July 2013 (UTC)

This is interesting feedback, really. You might consider using Safari (the section target contains mention of the reader mode) to read Wikipedia if you can. This browser has a "reader" mode which renders web pages in a way which would likely eliminate the behavior your seeing. When I read Wikipedia on the iPad using Safari, I often switch over to "reader" mode as it does improve the readability dramatically. --User:Ceyockey (talk to me) 03:11, 26 July 2013 (UTC)

Several people have requested this. Whatamidoing (WMF) (talk) 03:18, 26 July 2013 (UTC)

Millions experience this constant flickering. Just readers. --93.75.134.116 (talk) 03:33, 26 July 2013 (UTC)

You could try adding the following CSS to your Special:MyPage/skin.css

.mw-editsection-link-secondary { visibility: visible !important; content: "source"; }
.mw-editsection-divider { visibility: visible !important; }
.mw-editsection-bracket { visibility: hidden !important; }

It changes the way the edit links appear so they no longer flicker with the mouse.--Salix (talk): 05:59, 26 July 2013 (UTC)

I agree that the current default behavior for section needs to be improved. We're assessing various options.--Eloquence* 07:02, 26 July 2013 (UTC)

I have taken User:Salix alba's idea a step further to provide IPs with an opt-out. See Wikipedia:VisualEditor/Opt-out#Options_for_IP_users The CSS will need to be optimised with funky selectors, but the basic CSS should work on any browser. --John Vandenberg ^(chat) 08:10, 26 July 2013 (UTC)

Credit should go to User:Dragons flight for this: [17].--Salix (talk): 08:58, 26 July 2013 (UTC)

Can we bring this back in focus. A user responds (good)- do we agreed to change it, no we tell him to change his browser instead (bad). We then suggest how he can be helped with his little problem- by making some arcane changes to his skin set up (worse). For an editor that is supposed to attract the masses by making things easier-- this is barking mad. -- Clem Rutter (talk) 08:55, 26 July 2013 (UTC)

Indeed, and that is a point that should be made on the linked bug report. It seems that the VE team are slowly starting to understand that almost everybody thinks they made the wrong decision with regards to these links. They obviously registered that there was disagreement but they previously didn't (and I think they still don't fully) grasp why people didn't like it. The more evidence there is of it causing actual problems the more likely it is that they will understand that people would rather have the "cluttered" appearance than the sleeker hovers and the reasons why they prefer that, and so change it. Thryduulf (talk) 09:24, 26 July 2013 (UTC)

Alternative approaches are being discussed on the design mailing list.--Eloquence* 01:37, 27 July 2013 (UTC)

Eloquence (Erik Möller). I note that in this message you agree with Trevor: "The hover effect is easy to drop - if we are all willing to take the hit on the clutter." I agree with you on this: "If we want experienced users to test it every once in a while, give feedback on how it can be made better, and have them see the improvements, finding a solution that poses the least burden on them will give us the biggest win."

It needs to be emphasized that there are many experienced users who edit anonymously (IP edits). They will not be able to go to preferences to choose other options. I think both hover and dropdown will irritate those experienced IP editors. I think the least cluttered longterm solution for them might be an "edit" link for the visual editor, and an icon for the source wikitext editor. --Timeshifter (talk) 02:23, 27 July 2013 (UTC)

"think the least cluttered longterm solution for them might be an "edit" link for the visual editor, and an icon for the source wikitext editor" least cluttered perhaps, but an nightmare from a usability perspective. Either make both an icon (with alt text and tooltip) or both text links. Usability is far more important than avoiding a tiny bit of clutter. Thryduulf (talk) 12:07, 27 July 2013 (UTC)

Thryduulf. I don't understand. How is it difficult to click a static icon that is there all the time (without having to go through any hovering)? There is a star icon at the top of almost every page for adding or removing a page from one's watchlist. If clicking an icon to get to the source wikitext editor is a nightmare, then how is making both links icons (as you suggest) better. I agree that the icon for the source wikitext editor should have alt text and tooltip. I should have stated that to begin with, but I assumed that would be done, just as it is for the watchlist star at the top of the page. --Timeshifter (talk) 00:52, 28 July 2013 (UTC)

It would make more sense to use an icon for VisualEditor and text (preferably, just "edit") for the Wikitext editor. In fact, I would insist on text for the wikitext editor. — Arthur Rubin (talk) 03:02, 28 July 2013 (UTC)

If the goal of VE is to make things easier for new editors, then it would seem more logical to make the "edit" link default to VE. Experienced editors won't have any problem figuring out that the icon is for the wikitext source editor. Especially since it will have a popup tooltip saying "edit source" or "edit wikitext". You can insist all you want, but you and I do not decide. We just put in our votes and opinions.

Other options might be put in preferences. The more the better as far as I am concerned. Happy editors means more editing. But the setup of the default edit links is very important to reversing or slowing down the decline in the number of edits and editors. Eventually, the VE might also increase the efficiency of editing so that more gets done faster, and more gets done with each edit. --Timeshifter (talk) 05:38, 28 July 2013 (UTC)

If the goal of VE is not to discourage infrequent editors, who have seen Edit links before, then the Edit link and tab should link to the Wikitext editor, and a different link, tab, or icon should link to VE. Furthermore, if VE is designed for more (looking for an appropriate word which doesn't mean "illiterate") modern editors, those editors should be more familiar and comfortable with icons than those of us who started with Atari-OS and DOS. — Arthur Rubin (talk) 09:10, 28 July 2013 (UTC)

No, I believe the goal of VE is to encourage new editors to try editing, and see that it is WYSIWYG, just like their email, blogs, etc.. And then to continue editing because it is easy due to it being WYSIWYG. So the edit button needs to go to VE. Nearly all editors whether new or old are familiar with WYSIWYG editing since it is what we get in our email and blogs. Keep working on trying to sound authoritative and admin-like. Underlining and insisting and all that. That ol admin groupthink. --Timeshifter (talk) 21:12, 28 July 2013 (UTC)

This is the comment I came here to make. Perhaps not so emphatically but, yes, I too find the dynamic links to be really distracting. One of the reasons I love Wikipedia is the cleanliness of its interface; dynamic things detract from this. Perhaps modifying the trigger area so it only changes when hovering the 'edit' link (vs current behavior: when the cursor is anywhere on the same line) would be sufficient. — Preceding unsigned comment added by 70.0.31.239 (talk) 01:52, 27 July 2013 (UTC)

Please keep the Edit Source on each section as accessible as possible, since many of us (probably the majority) prefer it to the Visual Editor. Dynamic as it is now is ok, and two permanently visible tabs on each section would be even better. Just don't remove it, as Visual Editor is frankly too frustrating to work with, especially for long articles. Dirac66 (talk) 19:45, 28 July 2013 (UTC)

Turn OFF this F**king Editor

This editor sucks. Not only is it different, it fucks things up like wikified links - it displays the brackets rather than wikifying. You guys are fucking idiots.

I can't express how fucked up you folks are. I specifically set my profile to *NOT* use the new editor weeks before it went online, and you still fucking forced it down my throat. Jeffrey Walton 01:11, 27 July 2013 (UTC)

It's obviously crap and unfit for purpose, but to say so is politically unacceptable here in the best of all possible worlds. Eric Corbett 01:18, 27 July 2013 (UTC)

I couldn't agree more. Its too bad the WMF refuses to admit that VE is garbage in its current condition and they need to quit[e] forcing broken garbage down people throats until its fixed. Kumioko (talk) 01:22, 27 July 2013 (UTC)

I have warned Jimbo of potential VE hostilities to rise at Wikimania. I think WMF managers had imagined some grandstanding or showboating to have VE widely deployed before Wikimania, but even a prima donna knows to sing in tune and get *all* the words right in the song, before prancing to center stage. Beware, "Pride goeth before a fall" (<KJV Proverbs 16:18). I think WMF needs to face the music.... -Wikid77 (talk) 04:20, 27 July 2013 (UTC)

See bottom of Special:Preferences#mw-prefsection-editing. There is now an option to "Temporarily disable VisualEditor while it is in beta". --Timeshifter (talk) 01:47, 27 July 2013 (UTC)

For a comprehensive list of options, see WP:VisualEditor/Opt-out. -- John Broughton (♫♫) 04:28, 27 July 2013 (UTC)

We need a petition to request shutdown of VE until fixed for basic functionality. -Wikid77 (talk) 08:12, 28 July 2013 (UTC)

Personally I would be happy to sign such a petition if I thought it would mean anything but the WMF doesn't care what we editors think. No matter how much and how many people complain or how obvious it is that it needs to be disabled, they have their minds made up. The only way they are going to listen is if we stop editing until its fixed. If enough editors stop editing for a while, they'll get the hint. Kumioko (talk) 14:22, 28 July 2013 (UTC)

What future does a website have if it doesn't listen to the people who use that website? The answer is it doesn't have one. If changes are repeatedly pushed through that wikipedia users don't like, they're not going to use the site anymore. My edit count is seriously down and I have to admit VE is just so un-user-friendly I just can't be bothered to edit. Plus the sites constantly glitching, the sites taking longer to load so I'm going to other sites when I'm searching for information, and avoiding wikipedia all together. And it seems I'm not alone; talking to friends who include from registered users, anon-editors and casual browsers, the reply is a unanimous "WFT is wrong with wikipedia?". Its sad to see something I have enjoyed and valued falling apart before my eyes whilst whoever's running the shop seems blind to criticisms saying that they know best. Every time I've made a suggestion about improving this shambles its been put down in the rudest manner; and reading though these pages, I'm obviously not alone. When will this shambles end? When wikipedia has no visitors anymore? --Rushton2010 (talk) 18:26, 28 July 2013 (UTC)

Deleting a section heading only deletes the heading, but the section remains.

Template:Tracked I have made two edits in my sandbox to demonstrate this. Here [18], you can see me inserting a heading called "Demo". Here [19], I delete the heading called "Demo". I had expected the section to be deleted with the heading, but the section remains there, without a heading. I think this would be particularly baffling for someone unfamiliar with the text editor.OrangesRyellow (talk) 10:21, 27 July 2013 (UTC)

Hi user:OrangesRyellow, on bugzilla:50100 there is another user saying that "you have to highlight an invisible area *preceding* the heading" to delete it. Maybe try that? John Vandenberg ^(chat) 12:08, 27 July 2013 (UTC)

@John Vandenberg I think there are at least two is at least one way in VE to do it. One is to delete the section heading and hit the backspace. The other is to select the heading and hit the deformat button, and then delete heading. But I feel this should be fixed because it can be confusing otherwise.OrangesRyellow (talk) 12:17, 27 July 2013 (UTC) I could not highlight the preceding area and delete it.OrangesRyellow (talk) 12:50, 27 July 2013 (UTC)

I noticed the "trick" that John Vandenberg pointed out: highlight the heading, hit backspace to erase the text, hit backspace again to remove the heading. I was tempted to report this, but after pondering it, I think this is actually the way it should work.

	Task 1: Change heading completely	Task 2: Remove section
Protocol A: Deleting header text removes section	Method 1A: Highlight heading. Backspace. Select header level from drop-down. Begin typing.	Method 2A: Highlight text. Backspace.
Protocol B: Deleting header text creates blank section	Method 1B: Highlight heading. Backspace. Begin typing.	Method 2B: Highlight text. Backspace. Backspace.

Methods 1A and 2B are the most inefficient methods, and it seems clear to me that 2B is the lesser of the two evils in terms of efficiency, and perhaps user frustration. --Cryptic C62 · Talk 16:29, 27 July 2013 (UTC)

Looking at the chart, there is a reasonable case to say that this is the way it should work. This is very true in case the user does not want to delete the section and only wants to change the heading. But the confusion creeps in when the intention is to delete the section with the heading. I think the problem may be solved by inserting some mechanism to delete the section when the heading is empty. It does not look like a severe problem as it is, but still...OrangesRyellow (talk) 01:14, 29 July 2013 (UTC)

VE drop?

If you look at [20] and look just at the VE parts, there appears to be a somewhat abrupt drop in VE edits of perhaps 20% during the last day or so. Assuming this is accurate, then one might want to investigate whether some recently deployed update to VE is making it harder to edit. I'm unaware of any specific likely cause, but it seems a bit more than one might expect from random variation. Dragons flight (talk) 22:43, 27 July 2013 (UTC)

The absolute number of VE edits per hour will, of course, vary significantly by time of day and day of week. But what Dragons Flight pointed to is the proportion of edits that are done with VE versus the proportion that are done by the wikitext editor. That ratio should be much more stable. In fact, it has dropped off significantly for all three groups (IP, registered after 6/30, and registered prior to 7/1).

I'm not seeing more complaints at this page (VE/F), and certainly not complaints about not being able to complete VE edits, or preferring VE but running into new problems. I wonder if the recently added opt-out option has made that much difference? I'd think it would take longer than a day or two for the word to get out, but of course I don't know all the ways that the change might have been communicated. -- John Broughton (♫♫) 23:15, 27 July 2013 (UTC)

A preference option shouldn't have any impact on anonymous editors (unless they magically all decide to register, which seems unlikely). Dragons flight (talk) 23:34, 27 July 2013 (UTC)

The proportions looks pretty constant over the last day: 6% edits for established users, 35% for new users, 18% for IPs. I'm seeing that the ratio of accounts stays pretty solid once you apply any level of smoothing, but the IP ratio is somewhat more variable. Nothing looks too out of whack, though.—Kww(talk) 00:02, 28 July 2013 (UTC)

Way too much variability in that for any meaningful conclusions to be drawn at this time. Adam Cuerden ^(talk) 17:15, 28 July 2013 (UTC)

Smoothing by 24 or 48 datapoints gives a better sense of trends (that's smoothing by daily or 2-days of editing). This shows that Anonymous editors started showing significant % editing mid-month and peaked at the end of this past week and has dropped off over the weekend ... but there is really only <2 weeks of data, so stay tuned to see what things look like after a 3rd week. For new registrants, there was a slow rise peaking at ~2% around the 18th and it's stuck around that since then. For established users, there was a peak around the beginning of the month and there has been a slow decline from a high of 4% down to current around 3%. So ... I don't see precipitous changes here. --User:Ceyockey (talk to me) 17:58, 28 July 2013 (UTC)

Interesting to compare new registered users at wikitext vs. VE ... wikitext is consistently higher, about double the proportion (~4% vs. ~2%). --User:Ceyockey (talk to me) 18:02, 28 July 2013 (UTC)

Something's wrong with your math, Ceyockey. The percentage for established accounts has been hovering between 5% and 6%, and the percentage for new accounts has been roughly 35%. I use an 8 hour smooth.—Kww(talk) 18:07, 28 July 2013 (UTC)

The numbers on the vertical access are % ; these are the two lines for new registered users.

File:VE versus Classic editing proportion - newly registered users.png Twice the proportion of new accounts using wikitext versus Visual Editor. --User:Ceyockey (talk to me) 19:19, 28 July 2013 (UTC)

Exactly: you are mixing proportions and absolutes. If twice as many newcomers use wikitext as use use VE, then 66.6% of edits made by newcomers use wikitext and 33.3% use VE. Actual statistics are closer to 65% and 35%,—Kww(talk) 19:26, 28 July 2013 (UTC)

I'm not mixing up anything ... I just hate to use proportions out of context. The 35% figure is out of context from all edits, and I would prefer to consider things in their proper context. --User:Ceyockey (talk to me) 21:01, 28 July 2013 (UTC)

It depends on what you are trying to talk about: that 3% of edits are made by new editors using VE doesn't say anything about its acceptance among new editors, and to say that 35% of edits by new editors are made with VE doesn't say anything about how many edits those editors make.—Kww(talk) 21:39, 28 July 2013 (UTC)