VisualEditor/Feedback
This page is a place for you to tell the Wikimedia developers what issues you encounter when using the VisualEditor here on MediaWiki.org. It is still an alpha 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're making and the priorities for adding new functions.
Add a new comment – View known bugs – Report a new bug in Bugzilla
Archives generated by MiszaBot):
Contents |
Clicking edit [edit]
When you click edit and the page is blank and then visual editor find a page which was redirected and so you can save the page 5.66.149.62 11:54, 18 May 2013 (UTC)
VE altered wiki table markup, benignly [edit]
I made minor text and link edits to the table in mediawiki.org/Manual:Page_customizations. It worked! I note that VE added whitespace to the opening wiki table markup:
^ This may not even be a low-priority bug, but my understanding is that Parsoid tries not to unnecessarily alter wiki markup. S Page (WMF)(talk) 19:23, 21 May 2013 (UTC)
allow Enter accelerator in [Review and save] [edit]
In old-skool Edit source I'm used to filling in the summary field, tabbing out of it, then pressing Enter to Save page. In VE's [Review and save] > Save your changes dialog, this doesn't work (it's not a form with a submit button, it just looks like one).
Sometimes I'll try to Tab-tab-tab over to the [Save page] button to press Enter on it... that doesn't work either (it's not a form element nor a link and doesn't have a tabindex). S Page (WMF) (talk) 01:27, 22 May 2013 (UTC)
New paragraphs in wrong order. [edit]
I tried to add new paragraphs after the first, but they showed up before, in inverse order. 200.219.132.104 14:39, 22 May 2013 (UTC)
sdf [edit]
sdf 190.121.229.138 19:00, 23 May 2013 (UTC)
Contents
 First page |
 Previous page |
 Next page |
 Last page |
Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, use down-arrow to walk all the way down, then up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article will be obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar.
There are essentially two ways to create a link:
- You enter the link's text, select it, click the link button, and choose the link target.
- You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.
I'm not sure which method users prefer, but it's clear that both methods should work seamlessly. However, with the current setup both methods are problematic:
- Once the correct target has been picked (either by entering it, or by selecting from the list), it is not quite clear what the user should do next. Is the back arrow the right thing to do, or does that cancel the selection? Should I simply click outside of the dialog, or does that cancel? It turns out: if the target was selected from the list, both these actions are correct and do not cancel the choice, but if the link target was entered by hand (and not followed by Enter!), both actions do cancel the choice. The fastest way is to enter the link target and hit Enter twice. This is all fairly unintuitive.
- With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the whole distinction between link text and link target remains obscure.
I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two big differences: the selection box has a clear OK button, and it contains separate clearly labeled boxes for the link text and the link target. I believe both of these changes make a lot of sense.
When entering the dialog from an existing link or from highlighted text, that text should automatically be entered into the link text's box, with a corresponding suggestion for the link target preselected, but both boxes should be editable independently. The link target box should have a list of further suggestions underneath. Once everything is OK, clicking the OK button or hitting Enter should create the link; clicking outside of the dialog box or hitting the back arrow should cancel the action.
There is another minor issue: right now, when hovering over an existing link, the link target is displayed; when clicking on the link, a link symbol occurs which does not show the link target. The meaning of that symbol is not clear; it turns out that clicking on it will allow to change or remove the link. Gmail solves this issue as follows: hovering will not display anything, but when clicking on a link, a tiny window shows up giving the link's target and options to change or remove the link. I find that completely self-explanatory.
All of that makes sense, except “clicking outside of the dialog box”. Closing the dialog and discarding what the user has entered just because some click happened outside of the box would not be user-friendly at all.
I agree with all of this. The current link workflow is really confusing and non-standard, even for experienced users.
I've installed VisualEditor on our wiki, but after enabling it and configuring it according to the instructions I still just see the old editor whenever I create a new page. When I go under Special Pages-->Version I do see that the wiki instance sees the extension. Any idea why it isn't working? Dave
If the integration has worked correctly, and you have it switched on for your account (if that's how you've configured it for your wiki), on each of the namespaces that you've enabled it on, you should have a new tab labelled "VisualEditor" alongside the "Edit"/"Create" tab.
Assuming that you've installed it correctly, it not appearing is most likely an artefact of you using a browser that fails the current very-restrictive whitelist of what browsers are known to work in VisualEditor (the "big four" of Chrome/Firefox/Safari/Internet Explorer). Note in particular that forks of the big four browsers differ in the ways that we care about, so Iceweasel does not make it through the whitelist. Longer-term we will switch to using a blacklist for known-bad browsers, but we haven't had the opportunity to do this yet.
Blacklist ? Like ten years ago when whith Mac browsers I encountered stupid artificial barriers although my Mac browsers were perfectly able to handle the content ? It would be a bad idea. It would be totally anti-Web.
The time is not modified after I have edited my message. This is a bug. Please fix that. Thank you.
LiquidThreads only puts a notice up if a comment has been edited by another user - you may want to comment on [1].
What is anti-Web is a number of browser manufacturers coming up with their own "variants" on standards that break the concept of one Web for all users, and their failure to work together properly under WHATWG to agree what the standards now should be.
Of course, we would love for VisualEditor to work for all users using all browsers. We certainly intend in the short-term (i.e., in the coming months) to work with all major browsers and make it easy for browser manufacturers and their adherents to see the ways in which their browser fails to meet the standards and so does not work. Longer-term it would be great to expand the number of browsers covered, but due to limited funds and an ever-increasing number of ways that browser manufacturers invent to be incomptabile with each other, that it something that we cannot fund ourselves exclusively.
The world is imperfect, and yet we must live in it.
I have no problem with the Visual Editor not working everywhere — as long as the Visual Editor is done right and respects the standards. There is a problem if the Visual Editor decides not to work in some browser. Check for features, do not check for applications.
That would be a lovely approach to take (and was what we did initially), but then we found that a number of browsers consistently lie about their ability to support features, or have Quixotic support for core JS language elements such that we cannot write code for the standard and expect it to work on them. For example, Android's native browser in version 2 proudly claims that it supports ContentEditable (the key technology for VisualEditor)… but doesn't actually create a user-editable content area (no trigger to give the user a cursor or keyboard).
I entirely understand your antipathy for browser-based whitelisting, but we do not have the resources right now to manually check each browser on the planet and work out whether it is lying to users about the features it supports.
You should be able to go back and forth between WikiEditor and VisualEditor until all the features available are identical If VisualEditor isn't going to have a button for creating tables and one for images (and one for wikitext) - I hope this is the plan when released as it would obviate the need for both editors.
I agree that it would be good to allow editors to switch between VisualEditor and the wikitext editor would be good, and we intend to build it, but unfortunately it is unlikely for us to be able to deliver it in the next month or so. Our focus is on providing the ability to add and alter images, references, templates and categories, which we feel are more important than altering the structure of tables. We do not intend to build an "insert wikitext" button, though it's not impossible.
(BTW, the wikitext editor is different from WikiEditor, which is an extension deployed on Wikimedia wikis that gives it a toolbar.)
I find it very difficult to tell at-a-glance when I'm editing with the visualeditor (using alpha on En:wp). With 'normal' editing it's obvious, because the source looks different from the text. In the visual editor, seems like we should change the background color of the edit window -- or a big red banner at the top, or something -- to let you know when you're editing. Otherwise in vector it basically all looks the same, which is confusing.
This is (to some extent) intentional - we don't want "reading" and "editing" to be different modes in people's heads, we want it to be part of the same collaborative continuum. There are ways we can make it a little more obvious without breaking the frame of reference entirely, but overall this is a "feature not bug" kind of thing. :-)
In this case, fine, but the visual editor has to indicate clearly that the content is in unsaved state. The different background is a good idea. But it is not enough, think of colour-blind people and of text browsers. A dot in some title place, à la Mac OS X, is something to do.
When editing I usually have several tabs open on the same wiki. With [Edit source] I can identify the editing tab at a glance as it changes to 'Editing Ti...', but with VE it looks like the other tabs. It would be nice if VE changed the browser tab title when switching modes.
I find the editing tab too thanks to its specific title. It would be too bad to break this habit.
We don't want you to break your habit; we want your habit to transfer to using VisualEditor. :-)
More generally, a lot of our work over years has been around guiding people to use the "Edit" tab; the entire point of becoming the "default editor" is to be the place new users will click into to edit, without needing to know that they want to click "VisualEditor" rather than "Edit" (or whatever).
Would love to have images and file insert/links on this ASAP
Is there any work in supporting mathematical equation (<math>) editing? It should be possible, since Microsoft Equation Editor and OpenOffice Math both have it.
I don't believe there's any active work on it but that would be very interesting.
If someone's thinking of diving in, you might look into what people are already working on with math editors related to the MathJax client-side rendering. I don't know if there's something fully working yet, but it might be nice not to have to start from scratch. :)
We've decided that <math> elements aren't as high-priority as references and templates, but it's definitely something I want to happen.
Just because two well-established tools with multi-billion-dollar companies behind them can been able to produce a visual equation editor doesn't mean it's "easy", but I think it's worth doing. :-)
There is a Google Summer of Code student who's hoping to build a visual equation editor for VisualEditor if you're interested in progress
That "pawn" bug (bugzilla:48346) must be one of the weirdest bugs I've ever seen. Here's another strange one, seen in Firefox 20.0.1:
- Go to w:Mersin İdmanyurdu SK and invoke VisualEditor
- The cursor should automatically be on the first (blank) line. Start typing
- As well as a appearance of a pawn, strange duplication of characters starts to occur
Not only is VE playing chess, but perhaps also some drinking games :)
Try the visual editor on https://www.mediawiki.org/wiki/User:Dantman/Code_Ideas and scroll down to the image.
iirc that's supposed to be an image link, not an image. And in VE the entire thing isn't covered on hover making it still a link.
Oh dear, that's an unfortunate bug in Parsoid; filed as bug 48387. Thanks for the report.
It says in the minutes of 27th March under things that won't work:
- Tables
But will already existing tables (done through mediawiki syntax) be able to be edited in the release planned for 1st July? It seems to work fine in the test sandbox. This is something that would be very useful for us since we sometimes have large tables edited by several users. This work can be very tedious using wiki syntax.
/Daniel
Editing the contents of existing tables' cells will work, but you won't be able to alter the structure (add/remove columns/rows, merge cells, set background/etc. formatting).
How in any way is this acceptable? You're saying that an editor who wants to do anything with a table other than edit a cell has to switch to Vector to do so? At what point in the future do you think that Visual Editor will be able to edit everything related to a table - a few months after July 2013? A year or two? In the meantime, will you be recommending to new editors that they abstain from any more complicated table editing, or that they learn Vector as well as VisualEditor in order to have the full range of editing options?
I think that it's totally appropriate for projects that are primarily based on text, templates, images and references to have an editor which can do those well, rather than poorly with additional support for very complex tables that are currently outwith the capacity of editors familiar with wikitext, let alone newbies. The VisualEditor in no way makes it harder to edit a table than it currently is (quite the reverse). Yes, more progress would be nice, and so would a unicorn, but we have to work within reality.
We will focus on a table editor after the beta is launched, but I can't make up a date of it being ready at this stage as we aren't sure what facilities users will definitely need from such a tool (obviously add/remove row, column, cell; merge cells; mark cell(s) as 'header'/'footer'/'body'; add/remove caption - but there are other things that users might want to do as well, and I'm not going to declare it "done" when we've only hit those four functionalities.
Also, you mean "wikitext", not Vector, which is a skin. :-)
Sorry, apparently I misunderstood - the first production version (July?), not the beta (April/May?), will be able to do more than just edit existing cells in a table. That's fine.
Hi!
I have quite a few teachers who are eager to share their knowledge on Wikiversity here in Sweden. I think they would be very glad to be able to use the Visual Editor rather than the syntax. Would it be possible to have it on the Swedish Wikiversity as well as it would help them greatly?
Hi there (sorry for the delay in replying),
I don't think we currently have support in VisualEditor/Parsoid for Wikiversity sites. We've done absolutely no work on non-Wikipedia workflows, tools and extensions, and I'd be worried that we'd either break the site (unlikely, but not impossible) or be utterly useless, and we wouldn't have the time to help fix it in a useful fashion. Sorry! In a couple of months we should review our support for non-Wikipedia wikis and start the discussion about how well we can support your particular needs from VisualEditor, ahead of wider roll-out for everyone.
I edited a page with VE and saved successfully. I immediately opened the VE again, but the page I was given to edit did not have my most recent change. This seems to happen whenever I edit twice within a few seconds.
Sorry about this bug; we've fixed it in master but it's not yet deployed - it will be here on MediaWiki.org on 13 May and more widely soon afterwards.
I'm not sure why my feedback ^above^ from VE got inserted up here. I copied and pasted my feedback from a text editor into the VE [Leave feedback] dialog, it looked fine there and I got a confirmation from VE.
This is because we're using the core MediaWiki feedback tool, and LiquidThreads doesn't extend the API that the core tool uses, just captures section=new events through the UI. See bugzilla:41276. It's annoying, but not enough to switch off the tool.
Trying to make a local link to a section,
- The link pop-up dialog doesn't offer any help
- In wiki markup I know to type a leading #, when I start typing #Something the dialog displays
New page [checkmark] #Severity (in red) Matching page: $1
The resulting link to a section works, but the dialog is misleading.
I just finished reading Karen McGrane's recent column on A List Apart in which she discusses the separation of content from presentation. It made me think of the work around VisualEditor and, in my humble opinion, a reaffirmation that you're on the right track.
When you are on the normal edit page and VE replaces the edit button with an "Edit source" button it removes the selected/active styles from it.
I edited a page that was on my watch list with the VisualEditor. When submitting it the "Watch this page" was unchecked and when I just saved as normal VE removed the watched status of the page.
((There's a small possibility that I actually clicked the watch star and then opened up the VisualEditor after that instead of reloading first))
During the edition with the visual editor, an unwanted modification happened: ></table http://es.wikipedia.org/w/index.php?title=Alcatraz_%28serie_de_televisi%C3%B3n%29&diff=66703778&oldid=66536861
The prior disordered the table. Supousedly tables can not be edited, but this one was :)--3BRBS border|20px @ 16:31 6 may 2013 (UTC)
Thank you for your feedback! Sorry about this bug - we discovered it last week. It's due to a jQuery bug that we encountered with new code, which is now fixed in "master" ([1], [2]) and will be made available in production for eswiki on Wednesday 8 May.
Table structures aren't editable (no adding columns or rows), but cell contents should be - if you have any problems, please report back! :-)
Select a single word of text in some other app, paste it into an italic block in the editor, and the italics are closed and reopened either side. This is in Firefox 20 on Linux using the keyboard.
Yes, all copy-paste from external sources are stripped of all formatting before insertion; we're fixing this in 33105. I'm not sure we'd also want to provide a "paste without formatting and inherit local styles" tool, as this will be a mess to provide.
A mess ?? But this is the standard behaviour in any word processor software. I don't speak here of pasting formatted text. But, when there is plain text in the clipboard, pasting it must do the same as typing the same text with the keyboard — that is : give it the local formatting.
Yes, but giving users three options:
- Paste with remote formatting
- Paste with local formatting
- Paste with no formatting
... feels like a mess.
The choice would be between “original formatting” and “local formatting”. “No formatting” would not be an option. But, anyway, this does not apply to plain text in the clipboard. When there is plain text to paste, there is no choice, the text simply has to be pasted, without interfering with formatting.
First page |
Previous page |
Next page |
Last page |
.svg&action=edit&redlink=1){kind=link}