Talk:VisualEditor/Archive 1

Keyboard behavior
Is there any document specifying how the keyboard should behave in the visual editor?

If i understand correctly, it doesn't use the regular editing controls that a user would expect in a textarea. The arrows may move the cursor correctly, but other keys may work unexpectedly or not work at all. For example, Ctrl-Home should jump to the beginning of the editing area, but if not configured properly, it may jump to the top of the page (this happened in Google Translator Toolkit last time i checked; the site doesn't seem to work now).

Some important keys that i can quickly recall: Home, End, Page up, Page down, Backspace, Delete, Ctrl-Home, Ctrl-End, Ctrl-→/←, Ctrl-Shift-→/←, Shift-→/←. There are certainly more. --Amir E. Aharoni 12:17, 11 October 2011 (UTC)
 * ... Oh, and also Ctrl-X and Ctrl-Z. Very important. --Amir E. Aharoni 13:43, 16 October 2011 (UTC)
 * Visual editor/Features. --Yair rand 00:55, 23 November 2011 (UTC)

Testers
Bensin (Lämna Skottland!) volunteers to beta test the visual editor once it's ready for testing. Sumanah 20:34, 27 October 2011 (UTC)

Luis Orlando volunteers to beta test the visual editor too. --Luis Orlando 14:08, 23 January 2012 (UTC)

Charles Dayton from Wikipedia.org volunteers to beta test the visual editor. CharlesDayton (talk) 17:37, 16 February 2012 (UTC)

Justin West volunteers to test in a limited production environment. Jwestyp (talk) 02:36, 6 June 2012 (UTC)

Nicholas Wilson volunteers to test in a production environment alongside an existing mediawiki deployment. Nick Wilson (talk) 20:25, 26 June 2012 (UTC)

Important Details
Note that headings should have these little space characters. e.g. "== heading ==" instead of "==heading==". I propose there should be an intelligent algorithm which type of style is mainly used in one article and then go on with using this style.

It also has problems with preformatted text. Just try to make a new paragraph in a preformatted text!

I think it's still too dificult to set interwiki links with this new editor. You also may make sure that this visual editor has a lot of key bindings.--217.251.244.219 19:55, 17 December 2011 (UTC)
 * And another problem: If you have an empty heading or anything else empty on top of the page it should be converted into a plain paragraph if you use the "delete" button of your keyboard. Using the mouse to change the type is too difficult. --217.251.244.219 19:58, 17 December 2011 (UTC)

Heading problem
I want to point out, that the selection of the Heading is a real PROBLEM. We don't want presentational Layout but structured Layout. How do you make sure that people take the right Heading? With the current version of the editor which is deployed everywhere this is no problem, because people are forced to use the right heading. But how do you make sure that people don't use the Heading1 because they think that something is important but in reallity it should be heading3 ... i hope you understand what i mean.
 * How do you mean this is enforced in the current editor? From what I can tell this problem applies to that editor as well. Perhaps the distinction is that the structure is more apparent when viewing the wiki syntax in that case. --John Ericson 14:13, 18 December 2011 (UTC)
 * Yes, that is what i mean (the structure is more apparent when viewing the wiki syntax). This "forces" (at least me) to use a clean sturcture. Maybe you should show a hint "H1 ..." next to each Heading on the editing page (during editing). I think this would have the same effect.--92.203.104.91 08:23, 30 December 2011 (UTC)


 * "H1" is meaningless in a visual editor. You have to show the heading size to be clear on what it is. Badon 02:53, 9 January 2012 (UTC)
 * Now that I think about it, people don't understand "heading" either. To the average reader, they are "table of contents sections". Badon 02:56, 9 January 2012 (UTC)

Can this handle templates and tables?
Pretty much every Wikipedia article eventually runs into one of the two things that break pretty much all wiki visual editors -- tables and templates. Can this visual editor handle them? How are they implemented? How do you switch between entering template parameters and seeing the template? Is it laborious to figure out how to turn the visual editor off if that's what necessary to edit a template? For instance, a new editor wants to add some new information to the Barack Obama article on the English Wikipedia. How do they use a cite template without the ability to get into template editing? If they want to fix something or move something, will most of the page as it now stands essentially be locked to them, since they'd be unable to edit or manipulate the hundreds of current cite templates on the page? (Granted, the page is semi-protected, so it's going to be locked to them anyway, but after they're autoconfirmed will it still remain locked to them?) Then there are all the pages where tables are used to present well ordered information like: Or to put information on a webpage but (so as to not overwhelm the rest of a potentially small page) to make it "hidden" by default, which is usually done to include "here's lists of other related stuff" on the bottom of "linked" webpages, such as pages for bits of a series: Or to sort information (especially useful on particularly large tables -- click the up/down arrows to sort by that column) for instance if you want to see sports figures ranked by goals, or by some other metric, and they're initially ranked by name or team or some other standard than by how you'd like the list to be presented: Either a template or a table are seen on every English Wikipedia article that isn't a stub or something like that (all 3+ million of those article pages) and even on most stubs, since pages have infobox templates, stub-marking templates, etc. If this visual editor cannot handle either templates or tables, it's going to be fairly useless for anything except the lightest of editing. If it can handle those, then this is the greatest thing since sliced bread. Banaticus 05:01, 10 January 2012 (UTC)


 * Tables are easy. If word processors can do it, then a "visual editor" can do it too. Templates are different - probably only the most commonly used ones would be easy to make available, like "citation needed". Beyond that, the domain is so unrestricted that it would probably have to be dealt with the hard way. But, if users want to do that sort of thing, they're probably beyond their need for a visual editor anyway. Badon 06:04, 10 January 2012 (UTC)


 * Parsoid currently round-trips tables, but only renders / expands templates. The editor currently supports neither. In Parsoid, we plan to support unexpanded template round-tripping at first (so the page will not be WYSIWYG wrt templates). Editing with expanded templates will then likely follow later. See Parsoid/HTML5 DOM with RDFa for some ideas on how this might look. -- Gabriel Wicke (GWicke) (talk) 12:08, 28 June 2012 (UTC)

Image Manipulation
A really useful feature would be integration with image uploads so that a user can click insert image, select the image locally or from the web and upload/insert it right from there, with no need to visit the upload page.

Parse error message replaces content ... and there's no way to revert!
I think a visual editor is sorely needed as a core Mediawiki feature and the current beta has a nice look.

Unfortunately, I suspect the current software isn't very robust -- while making edits on the test page the content was replaced with a parser error message.
 * There's no revert function yet, unfortunately.Jasper Deng (talk) 01:39, 24 June 2012 (UTC)


 * Do you have a pointer to the revision where this occured? -- Gabriel Wicke (GWicke) (talk) 10:13, 28 June 2012 (UTC)
 * Never mind- found it. -- Gabriel Wicke (GWicke) (talk) 10:28, 28 June 2012 (UTC)
 * Will be fixed with the next deploy. -- Gabriel Wicke (GWicke) (talk) 12:02, 28 June 2012 (UTC)