Wikipedia:VisualEditor/Feedback

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Shortcut:

VisualEditor is available here at the English Wikipedia alongside the original wikitext editor if you opt-in, by changing your preferences. VisualEditor is not available to unregistered users here or to users of Internet Explorer at any Wikipedia. The developers are working on support for IE9, IE10, and IE11.


Share your feedback
Report bugs
Your feedback about the VisualEditor beta release

This page is a place for you to tell the Wikimedia developers about issues that you encounter when using the VisualEditor here on Wikipedia. It is still a test version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we are making and the priorities for adding new functions. All comments are read, but personal replies are not guaranteed. If you have encountered a problem or have found a bug, then please include your web browser, computer operating system, and Wikipedia skin (usually Vector, sometimes Monobook).

A VisualEditor User Guide is at Wikipedia:VisualEditor/User_guide.

Add a new commentView known bugsReport a new bug in Bugzilla
Join the IRC channel: #mediawiki-visualeditor connectTest VisualEditor!
(no account required)

Archives: (generated by MiszaBot II)


Editing a section[edit]

Please, as I mentioned two times already, when I'd like to edit a section, this program should allocate an edit box for that one section, not for the entire page. Gryllida (talk) 03:16, 26 June 2014 (UTC)

I understand why the VE team has no plans to do this, but I also understand why some editors would like this -- for large pages, even if there's no savings in time, it's nice to restrict the view to just the area to be worked on. A workaround occurred to me: how about allowing a user to set a preference called something like "limit view to section in VE". If this were set, and the "edit beta" link were clicked for a section, VE would edit as it does now, but it would only display the section clicked. In other words, there would be no need to change the way VE parses, or operates; it would be editing the entire page. It just wouldn't display it all to the user. Would this be possible? Mike Christie (talk - contribs - library) 12:54, 26 June 2014 (UTC)
That seems like a great idea. -- Ypnypn (talk) 13:43, 26 June 2014 (UTC)
I don't understand why the VE team has no plans to do this. Having an entire article appear as an editable area when I want to focus on just one section is the major reason why I'm not using VE for generic editing. What goes on internally is completely irrelevant to editors. Their, our, requirements for working comfortably should be put first. — Scott talk 15:01, 26 June 2014 (UTC)
Although I think this would be a good enhancement, I would like the current behaviour to continue, at least with a preference setting. I've discovered that I frequently take advantage of the fact that VE edits the entire article every time -- when I notice an error at the end of a section, I click the "edit beta" button at the start of the next section, and don't have to scroll up. Mike Christie (talk - contribs - library) 18:11, 26 June 2014 (UTC)
That seems like a great idea. (Sorry for plagiarizing the message, but I do concur. :P). Gryllida (talk) 00:33, 27 June 2014 (UTC)
I agree, there's no reason for this not to be a feature. Darylgolden(talk) 00:39, 27 June 2014 (UTC)
Daryl, the reason that it hasn't been implemented is that editing a single section would be paradoxically slower than editing the whole page.
Scott, I agree with you about the problem of focus. If that focus cost, say, an extra 10% or 20% to open the page for editing, would it be worth it?
Mike, I'm adding your suggestion of "faux section editing" to the bug report. Whatamidoing (WMF) (talk) 04:23, 28 June 2014 (UTC)
I definitely believe so. If you could make it so that the editor interface appears in the section with the rest of the article still displayed above and below it, I would love you. That would solve one of the oldest annoyances there is - having to have a second tab with the rendered article in to check while you're editing one section. Allow inline section editing and you make a dramatic workflow improvement for just about everyone. It would also look hella modern. — Scott talk 11:32, 28 June 2014 (UTC)
I agree. @Whatamidoing (WMF):, thanks for adding that idea to the bug report; I just added a comment requesting the preference flag. This is a feature I actively don't want (though I can see why others would like it) so I think it should be optional. Mike Christie (talk - contribs - library) 11:52, 28 June 2014 (UTC)

There is also a subtle similar feature for another extension: an "edit [beta]" button for a code snippet like this one. Having CodeEditor show an edit box just for the snippet and not for the entire page would make sense. I think there is a bug for this (bug 60438), and for making it work without page reload (bug 61056).

On the former, there is a comment from TheDJ: “The biggest problem is that we need to make sure not to implement everything a dozen times (live preview, editpage, visual editor and inline code editor).”. Maybe VisualEditor, after learning to edit individual sections, should learn to plug CodeEditor into its edit area to resolve both these bugs. Just a thought. --Gryllida (talk) 23:15, 27 June 2014 (UTC)

Quotes:

Mike Christie has a suggestion: Edit the whole page, but only display the chosen section. by Mike Christie (on the bug)
the reason that it hasn't been implemented is that editing a single section would be paradoxically slower than editing the whole page. by Whatamidoing (earlier on this page)

This raises the question of someone pretty please looking at the thought about editing code snippets. Please also try to explain the paradox. Making whole page editable is ugly; the rest of the page should be visible while editing a section, in my view. Gryllida (talk) 03:37, 30 June 2014 (UTC)

I'm curious to know what benefit you would see from this. The only difference between what you're proposing and the current behaviour of VE is that if you were to actually click in one of the other sections and attempt to edit it, you would not be able to. Why would this be an improvement over the current situation? Mike Christie (talk - contribs - library) 10:10, 30 June 2014 (UTC)
I would be able to have two editable areas on a page. Gryllida (talk) 23:17, 30 June 2014 (UTC)
Because I wouldn't have to upload that much content. The API has means to edit a single section and VE should not kill it. Gryllida (talk) 23:25, 30 June 2014 (UTC)
I guess I either don't understand your answer, or I don't understand the original suggestion you made. What I thought you were suggesting was that VE should allow a situation where all sections are visible, as they are now, but only one section is editable -- that is, if you click in another section, you can't make changes to it. It sounded like you thought that's what should happen in VE if you clicked "edit beta" against a specific section. If that's really what you were suggesting, my question is: what benefit does that give an editor? There's no additional space on the screen as a result; there's no ability to have two separate editable areas on that page; there's no difference in the parsing that VE must do to the page. Why would an editor want that? I really think I must have misunderstood you. Mike Christie (talk - contribs - library) 00:23, 1 July 2014 (UTC)
Maybe I should write a FAQ for this. The wikitext editor does what you might call faux section editing—you just deal with the section, but you're missing some features as a result. Here is one of the simpler problems that faux section editing creates in VisualEditor:
  • In the wikitext editor, if you open a section, and you want to re-use a reference that is defined in another section (including list-defined references), then you take that ref name out of your own human brain and type it in: <ref name=Whatever />.
  • In VisualEditor, if you open a section, and you want to re-use a reference that is defined elsewhere, then VisualEditor takes that ref name out of the other part of the document, and types it in for you.
  • Problem: If you're editing Section #2, and the ref is defined in Section #4, and VisualEditor has not actually read Section #4 (because you told it to only read the source code for Section #2), then you cannot re-use the reference and cannot complete your editing task.
NB that there are also other problems, some of which are familiar complaints to anyone who uses section editing frequently, but this one example should be sufficient to understand why this is a bigger problem in VisualEditor than in the wikitet editor. We'll leave it with the oversimplified statement that faux section editing is a problem, because it doesn't allow editors to do their editing.
True section editing—in which you read everything, but then discard all the things that are irrelevant (e.g., images that don't extend into this section)—solves this problem. However, it is unavoidably slower. Here's the current system, which most advocates for section editing have already deemed to be too slow:
  1. Send everything to your computer (two seconds).
  2. Process everything locally (five seconds).
  3. Make your change (however long you want).
  4. Send everything back (three seconds).
Here's what true section editing would do:
  1. Send everything to your computer (two seconds).
  2. Process everything locally (five seconds).
  3. Throw away three-quarters of what you just processed (two seconds).
  4. Make your change (however long you want).
  5. Send everything back (two seconds).
There's a net loss to speed here.
Also, before anyone asks again, section editing hasn't prevented edit conflicts for about eight years now. Whatamidoing (WMF) (talk) 00:54, 1 July 2014 (UTC)
That does lead to the question - what's the plan for improving edit conflict handling, and if there is no plan, why not? We're so far behind the state of the art in dealing with those that it hurts. Note that this isn't a VE-specific question. — Scott talk 09:50, 1 July 2014 (UTC)
I don't know what the plan is, but I totally agree with you. I'll ask around. My initial guess is "not during the next three months", because they've already packed more than three months' worth of work into the official list for the next quarter. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
Scott, the story appears to be this: Currently, MediaWiki handles edit conflicts at the level of paragraphs (which is where it seems to have stood since about 2006 or 2007; before then, it was at the level of sections). Therefore, if you change paragraph 1, and I change paragraph 3, then all's well anyway.
The officially planned improvement is that VisualEditor will (someday) develop real-time editing capabilities, which will mostly resolve edit conflicts, but presumably this helps only people who are using VisualEditor. Doing this is not on the plan for the next year, and I would hesistate to guess which year this difficult work would actually be reasonably finished in. There is also a plan for Parsoid to handle edit conflicts at the sub-paragraph level, which I believe should reduce (but not eliminate) edit conflicts. This plan is less well-explained but may (probably will) happen sooner. However, again, it's not clear how much value this will provide to people who are using the wikitext editor in the short term. In the long term, it may help them just as much as anyone else, because the long-term (and somewhat tentative) plan is for pages to be stored as HTML5+RDFa files (ready to read instantly, but would have to be translated to wikitext before editing), rather than as wikitext files (which are ready to edit instantly, but have to be translated to read—the justification is that people do a lot more reading than editing). Parsoid is the tool for converting between those two formats, so if this plan is implemented, then that would reduce edit conflicts for people using the wikitext editor. Finally, Flow's structured discussion system should reduce or nearly eliminate edit conflicts, on the grounds that most edit conflicts are due to two people replying simultaneously, rather than both of us trying to edit your previous comment simultaneously.
The realistic bottom line, I think, is probably that the edit conflict situation will be improved, but not completely resolved in a couple of years. Whatamidoing (WMF) (talk) 17:51, 8 July 2014 (UTC)

Interface[edit]

About interface, I would leave all 3 options:

  • Entire page editable;
  • One section editable, rest of page visible;
  • One section editable, rest of page invisible (in a popup or separate page; most consistent with old behaviour, but also most annoying).

I don't care which of the last 2 options you make available, but I would like VE to just please stop processing or uploading the entire page. As mentioned earlier in this section, I may have wanted to edit a very small thing, a section typo or a small code snippet. Gryllida (talk) 09:35, 1 July 2014 (UTC)

Making the rest of the page visible or invisible isn't going to stop VisualEditor from processing and uploading the entire page. The only way to stop loading and processing the entire page is for all of the communities to declare that they really do want VisualEditor to be deliberately broken in ways that will surprise most users during section editing, e.g., making users unable to re-use references or edit templates that appear to be in that section, but are actually elsewhere. I haven't yet seen anyone say that dropping editors into an editing session with no clue whether they'll be able to make the change that they need to make is a desirable situation.
Would your practical problem be solved by making VisualEditor's opening much faster? Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
"Making the rest of the page visible or invisible isn't going to stop VisualEditor from processing and uploading the entire page." is stupid in my view, the API supports this.
"The only way to stop loading and processing the entire page is for all of the communities to declare that they really do want VisualEditor to be deliberately broken in ways that will surprise most users during section editing, e.g., making users unable to re-use references or edit templates that appear to be in that section, but are actually elsewhere" is something you can solve by making VE or API or Wikidata aware of the list of references used, so that they're accessible from within a section edit box.
Please do not blend the two problems together; this feature request suggests a need in doing some more work first, but such work would be useful to people who are using the classic source editor too (which does allow editing sections separately). --Gryllida (talk) 22:24, 2 July 2014 (UTC)
something you can solve by making VE or API or Wikidata aware of the list of references used... yes, we can do that. We do that by uploading and processing the entire page, which is exactly what you said that you don't want VisualEditor to do.
It's not that complicated: There are, because of the unstructured way that editors choose to write pages, going to be refs scattered throughout the entire page. Either (a) you read the entire page to find all the refs, or (b) you don't read the entire page and don't find all the refs. It is, in the end, your choice which one we recommend to the devs, but the option of "don't read the entire page, but (somehow) still know the contents of the entire page" is not actually plausible. Whatamidoing (WMF) (talk) 22:13, 3 July 2014 (UTC)
Hi Whatamidoing. Why do I need to process the entire page to know this information? I believe it should be stored with the page, like the flagged-or-not status with flaggedrevs. —Gryllida (talk) 08:52, 13 July 2014 (UTC)
You need to process the entire page to find all the refs because, for better or worse, all of the refs are currently typed into the text of the page.
There have been proposals to have this information stored elsewhere (e.g., at Wikidata), but this has not happened yet. Whatamidoing (WMF) (talk) 17:26, 14 July 2014 (UTC)
Whatamidoing (WMF), Would you consider working on that please? I recall the WMF Engineering Teams are good at collaborating and sharing their work. Gryllida (talk) 22:47, 14 July 2014 (UTC)
It's on the radar, but it's a long way off, and requires substantial support from both the Wikipedias and from Wikidata. James F is one of the key proponents inside the WMF. I believe that structured data for Commons files has been prioritized over it (in the sense that "priority" means "what you do first", not "more important"). Whatamidoing (WMF) (talk) 19:09, 16 July 2014 (UTC)

Referencing in a section[edit]

For the references issue described by Whatamidoing, remembering from brain is the current way. VE can do it client-side (as you say). It doesn't for me: copy-pasting [2] into another point in an article makes it appear as some other number.

Being able to pull references list from API or Wikidata is a feature request I believe, potentially preferred over doing it client-side. It could address Whatamidoing's concern about referencing within a section nicely. Gryllida (talk) 09:35, 1 July 2014 (UTC)

Copying and pasting refs doesn't work at the moment (it will eventually, but not yet). To re-use a reference, place your cursor where you want to add the duplicate. Go to the Insert menu and choose "Reference". In the lower left corner, click the "Use an existing reference" button. Choose the ref you want to re-use from the list. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
Acknowledged. Is this in the FAQ perhaps? I would be happy to translate some of VE documentation by the way, I will have a look. --Gryllida (talk) 22:25, 2 July 2014 (UTC)
It's in the user guide. The central copy is at mw:Help:VisualEditor/User guide. NB that most of the screenshots will change in the next few weeks, and some of the text will change then, too. We've been pretty chary of invalidating translations, so the 94% completion rate for the Russian version may be overstating the case significantly. Also, one of the other persistent problems has been that translators do good work, but then the updated versions don't make it out to the relevant communities. So if, after doing any translation work (VisualEditor or otherwise), you wanted to take a few minutes to copy it out to local wikis where editors could see it, then that would also be very helpful. Whatamidoing (WMF) (talk) 22:21, 3 July 2014 (UTC)

Timing[edit]

Saving the entire page in VE is dog slow (as is in the classic source editor) simply due to the amount of data I need to send.

Consider mobile applications — I see VE going mobile very soon. Scale it down to slow Internet.

For the sequences of seconds, surely sending (or processing) everything sounds redundant? Gryllida (talk) 09:35, 1 July 2014 (UTC)

I believe that most pages can be saved in about three or four seconds, although it depends on the page, your internet connection, and how busy the servers are. My sandbox is a fairly complicated page and I have a cheap internet connection. I made a change in VisualEditor, and it took about five seconds to save that page just now. I made another change in the wikitext editor, and it took about seven seconds to save (I'd assumed that it would be the same, but it was noticeably slower). As a result, I'm not sure that changing VisualEditor is going to help. What might help is Operations' increased emphasis on performance standards. Whatamidoing (WMF) (talk) 17:59, 2 July 2014 (UTC)
We are discussing the "process everything" in another section now.
On mobile Internet, saving a page in the classic source editor takes up to a minute for me easily. Gryllida (talk) 22:27, 2 July 2014 (UTC)
That sounds painful. What's your mobile platform? If it's Android, have you seen the new app? Whatamidoing (WMF) (talk) 22:14, 3 July 2014 (UTC)
WhatamidoingMobile Linux (Maemo) and Firefox OS. No, not Android. — The problem is bandwidth and the huge amount of kilobytes the entire page contains compared to a section. —Gryllida (talk) 08:54, 13 July 2014 (UTC)
I wonder how the page size compares to the overhead for editing (opening the editor itself). Whatamidoing (WMF) (talk) 17:32, 14 July 2014 (UTC)

Image replacement overwrites thumbnail size with maximum image size[edit]

Bug report VisualEditor
Description Image replacement overwrites thumbnail size with maximum image size
Intention: Replace an image in an article
Steps to Reproduce: #Clicked an image while in VisualEditor and clicked edit icon on image
  1. Navigated popup to "replace image"
  2. Replaced image with one found by searching for filename of desired image
  3. Make no other changes to captions, characteristics, etc of image.
  4. Reproduces when replacing same image with other images.
Results: Image appeared in VE editor at very large size. Wikitext shows that size of image thumbnail is now a square with side of the longest dimension of the original image.
Expectations: The replacement image would inherit the thumbnail size of the image I was replacing.
Page where the issue occurs https://en.wikipedia.org/w/index.php?title=Rocky_Mountaineer&diff=prev&oldid=616905078
Web browser Chrome
Operating system Win7
Skin
Notes:
Workaround or suggested solution

The Land (talk) 13:32, 14 July 2014 (UTC)

Thanks for this note, The Land! This definitely wins a bug report, which I'll have to file later today. But I've already told the dev whose specialty is media handling, and she's looking into it. With luck, this will get fixed in time to join the usual deployment train on Thursdays (which might mean reaching the Wikipedias next Thursday, depending on the details). Whatamidoing (WMF) (talk) 17:42, 14 July 2014 (UTC)

Insert ref[edit]

What's happened to the "reference" option in the "Insert" pulldown? It used to be possible to add a ref by clicking on insert and choosing "Reference"; now that option has disappeared. Is this a bug or an intentional change? Mike Christie (talk - contribs - library) 14:35, 15 July 2014 (UTC)

From the last Tech News: "The reference tool that adds empty <ref>...</ref> tags is now at the bottom of the Cite menu, below references that use templates like {{Cite web}}." By that, they mean Cite → Basic. --  Gadget850 talk 16:00, 15 July 2014 (UTC)
Aha. Thanks! Mike Christie (talk - contribs - library) 16:02, 15 July 2014 (UTC)
The hope is that putting everything in one place will make more sense (at least for people who didn't already know where to find it in the old model), and also that it will make citations more prominent for projects that don't use citation templates or haven't yet configured citation templates. Whatamidoing (WMF) (talk) 19:04, 16 July 2014 (UTC)

Line appearing above "beta"?[edit]

Bug report VisualEditor
Description Line appears below Edit and above beta
Intention: To make the line appear below "beta".
Steps to Reproduce: Go to any random page.

Hover over Editbeta.

Results: Edit has a line under it, while beta has a line above it.
Expectations: That the line would appear below "beta".
Page where the issue occurs Any page that you can use VisualEditor on
Web browser Firefox 30.0
Operating system Windows 7
Skin Vector
Notes: I usually use IE11 but VisualEditor doesn't work on that.
Workaround or suggested solution none

Eman235/talk 23:21, 15 July 2014 (UTC)

Thanks for your note. This is a known bug. It isn't actually a bug with VisualEditor itself; it's a problem with the MediaWiki skin that appears whenever you have superscripted text in that situation. The only realistic solution is to remove the "Beta" label. Whatamidoing (WMF) (talk) 19:06, 16 July 2014 (UTC)
Which I suppose ought to be removed eventually, at least when it's released to the general public. After all, it won't be being beta tested anymore. Eman235/talk 09:08, 18 July 2014 (UTC)
P.S. there seems to be something wrong with the bug report template -- in the "steps" parameter the first item of a numbered list renders as #lorem ipsum rather than 1. lorem ipsum. (S.A.A. but at 09:13, 18 July 2014 (UTC)) — Preceding unsigned comment added by Eman235 (talkcontribs)
Thanks for the note about the teplate. I don't know how to solve it. The # would need to start on a new line, rather than the first character of the table cell, and it appears that the template strips leading blank lines from the parameter. Whatamidoing (WMF) (talk) 17:48, 18 July 2014 (UTC)

Strange behaviour[edit]

I have run into some reproducible strange behaviour; I'm posting a description rather than a bug in case this is something that is already recorded. To reproduce:

  • Edit this rev of the article I was working on.
  • Go to the Bibliographic details section, and at the end you'll see a list of cite book templates. These are a bit messed up because when I realized I was seeing odd behaviour I did an intermediate save.
  • Place the cursor on "Three stories froro", after "fro" and before "ro". Type "m", and a space, and then delete the "ro" by hitting the delete key twice. This should leave the first part of the sentence looking normal: "Three stories from Science ..." but what actually happens is that the first del key deletes the "m " that has just been typed, and puts the "ro" before the cursor, instead of after. The "r" after the cursor does disappear, but the following "o" is still there.

Is this a manifestation of a known bug? Mike Christie (talk - contribs - library) 21:42, 20 July 2014 (UTC)

I should have said: Chrome, Windows 7. I'm now seeing some much stranger behaviour; so strange that I'm wondering if my browser is misbehaving in some way. It's starting to insert random characters as I type. I've restarted Chrome and still see the same behaviour. Before I spend more time on this, would someone mind trying to reproduce what I describe above? If it can't be reproduced it is likely something local to my machine. Mike Christie (talk - contribs - library) 21:52, 20 July 2014 (UTC)
Reproduced (with Firefox, Windows 7). It seems to be an issue with way VE handles the "Delete" key. -- Ypnypn (talk) 22:06, 20 July 2014 (UTC)
Thanks for verifying that. It's not just the delete key; I've been experimenting and I can get bizarre behaviour in other ways. This rev, for example, seems to act up. I've repeatedly been able to get VE into a state where it starts randomly inserting characters without me touching the keyboard -- it appears to go into some kind of loop. This happens after making multiple edits to the same area mentioning above -- I used multiple del, backspace and Ctrl-I keys, as well as double clicking on a word to select it and typing over it. If I can get a keystroke sequence that will reliably reproduce it I will post it here. Mike Christie (talk - contribs - library) 22:22, 20 July 2014 (UTC)
By "delete", you mean the "forward delete" key? That detail may not be important; I also get screwy text changes in Safari in a Mac (which doesn't have a forward delete key).
I think that this is a known bug, but I'll have to sort out which one. I believe that the template (rather than web browser or things like that) is the critical piece. Whatamidoing (WMF) (talk) 17:20, 21 July 2014 (UTC)