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)

Sal Quintanilla volunteer to test on our engineering intranet site. --Salquint (talk) 02:06, 23 September 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)

Is there an Updated Project Timeline?
All of the dates I see for when the VisualEditor will be available reflect a June (in the past) date. Would it be possible to project the estimated first release so that we have a date to plan against? Thanks, and excellent work!!!

FAQ: why it is difficult?
Hello folks,

In the context of editor decline and so on, the VisualEditor project and the promises of a bright future that come with it, are often mentionned when talking to the press and like :-)

Though, I noticed we regularly have the comment (especially in tech-centered press) “but what hasn’t it done before”, “why does it take so much time”, “there are already so many WYSIWYG-like editors out there” etc. etc, and we are a bit at loss to give a really good answer to that (rest assured that we know you people are not sitting on your hands :-)

Would you have some kind of quick explanation “Why is it hard?” that we could use, ie that would not go into too much technical details?

Thanks, Jean-Fred (talk) 13:52, 2 August 2012 (UTC)


 * Hi Jean-Fred, I get a lot of the same questions myself when I'm explaining this. What I tell people is that it's hard because:
 * 1) It's Open-Source (all the exampes they give of other ones are usually proprietary) so we have to "invent from scratch".
 * 2) It's not hard to create pages that are "born-WYSIWYG", but it is SUPER-hard to make it backwards-compatible so that existing articles (with all the templates, images, tables, references...) can be converted to WYSIWYG.
 * 2.1) Then, to make sure people can make diffs of articles, you need to be able to swap seamlessly back-and-forth between old and new styles without losing any data in-between. Best way of giving an example of why this is hard is to compare with any translation software going back-and-forth between two or three languages and watching the original sentence lose its meaning/nuance.
 * 3) Our WYSIWYG has to work in right-to-left and left-to-right as well as mathematical and many other obscure languages and font systems. So, while it might be easy to complete 90% of the use-cases for English/French, when you add in 280 languages plus all the different template/table requirements that *might* be used in articles, that last 10% breaks a lot of code.


 * Hope this helps, Wittylama (talk) 06:25, 24 September 2012 (UTC)
 * Yes, this helps. But one point. It would be less difficult if we would start with an simple editor that can use references but ignores tables. As You wrote: For 90 % of our writers and potentially writers this would be a milestone. It would be no problem then to add the other abilities one or two years later. --79.226.60.194 16:12, 28 December 2012 (UTC)
 * The blog entry you can point people to: https://blog.wikimedia.org/2012/12/07/inventing-as-we-go-building-a-visual-editor-for-mediawiki/ Sharihareswara (WMF) (talk) 22:34, 28 December 2012 (UTC)

VisualEditor without 'References' is useless
Our main problem is that new editors' changes are often rejeceted because of missing sources for their improvements. If references aren't made top priority in this project the VisualEditor will be no improvement for our main goal, to get more and more female long time editors.--79.226.60.194 16:06, 28 December 2012 (UTC)

Wikivoyage parser extension tags and the VisualEditor
There is a thread on Wikivoyage's Travellers' pub regarding the use of custom pseudo-XML parser extension tags, and whether they ought to be replaced with templates. Will parser extension tags be supported with the VisualEditor? Are they handled by Parsoid? Would a shift away from using them over to using templates (possibly with Lua) be useful from the VisualEditor perspective? I'd invite VE developers and interested parties to participate in the thread on Wikivoyage. —Tom Morris (talk) 02:50, 16 January 2013 (UTC)