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)

How to use it?
What's the easiest way to use VisualEditor? Especially if I am not a registered Wikipedia user? Please post a link if possible.

I found this testing page but it won't work for me on InternetExplorer 8, which i must use currently.

I'm really looking forward to this, it will be a great improvement for the project. I am a frequent Internet user but not a registered Wikipedia member. Sometimes I feel I could contribute soemthing, but the wikiediting doesn't encourage me to do it. Awesome idea, keep on!


 * Hello! Thank you for your kind words; we certainly hope that VisualEditor will make editing Wikipedia (and our other wikis) easier and more encouraging.
 * That page is indeed the easiest way to quickly test out VisualEditor on MediaWiki. However, as you have noticed, it does not work in Internet Explorer 8 - we have managed to support Internet Explorer 9 and above, but unfortunately it looks like supporting MSIE 8 would take so much effort that we would not deliver any functionality at all. Sorry about that.
 * Jdforrester (WMF) (talk) 16:52, 28 February 2013 (UTC)

Deletes spaces before nowiki
Title says it all Stefahn (talk) 18:55, 2 May 2013 (UTC)

bug
Hello,

I don't know where the bugs must be reported, but see.

I use Chrome Version 27.0.1453.110 m on Windows XP. I added internal links and removed some categories.

Regards

--Hercule (talk) 11:34, 14 June 2013 (UTC)
 * Thanks; this is a known bug, and is most definitely at our end and not down to your hardware or software :/. I've just spoken to James F; a fix to this is highest-priority. I'm deeply sorry about this (and think I speak for James and the VE team on that front, too). Okeyes (WMF) (talk) 14:31, 14 June 2013 (UTC)

VisualEditor:Test broken
VisualEditor:Test seems to be broken. Trying to edit it with VE's edit buttons (both fullpage, and section-edit), makes the animated-blue-loading-bar (name?) appear, but nothing further happens (For at least 4 mins).

Nobody has edited the page since June 13, so I assume this is a persistent problem that everyone is encountering. User:Jdforrester (WMF) ping.

(Note: I was wanting to test editing some templates with the newest VE, as suggested elsewhere, but no templates are in that page. Some should be added to its default 'restore' state, once it's working again. Ideally something as complex as en.wiki's en:Template:Cite book) Hope that helps. Quiddity (talk) 01:51, 17 June 2013 (UTC)


 * @Quiddity: Fixed; User:Ypnypn added an errant  block without any references to display, which crashes VE - see 49668.
 * For pages that test templates, see VisualEditor:Template_test; there's a level of cramming too much functionality into one test page. :-) Jdforrester (WMF) (talk) 02:40, 17 June 2013 (UTC)
 * Thanks Jdforrester. I've added that to the paragraph at en:Wikipedia:VisualEditor, which suggests trying out template editing here. Quiddity (talk) 05:12, 17 June 2013 (UTC)

[Bug]The VisualEditor unexpectedly deleted infoboxes at top of pages (bug parsing template transclusions).
On French Wikimedia a simple edit (that just added a few words in a paragraph within a section unexpectedly deleted the infobox template transclusion at top of page (there was no change there). The VisualEditor can delete lots of previous contents, and users may not notice it immediately.

I reverted this edit immediately. Evidences show that the VisualEditor does not parse the template transclusions correctly when they span several lines, or more probably if these transclusions contain HTML comments between lines of parameters. This also affects templates for references, that appear in the middle of a paragraph. The VisualEditor also attempts to cleanup unnecessary spaces within named template parameters, throughout the whole edited page (this may be the cause), even if this is not necessary, and we actually did NOT change these parts.

Affected page: Acide Chlorhydrique. (see http://fr.wikipedia.org/w/index.php?title=Acide_chlorhydrique&diff=prev&oldid=94124322)

Note: if we have an autoconfirmed account, the button to review the changes does NOT show the edits that will be done.

There are similar issues of unexpected deletions when adding a category to a page using the "Page Properties" menu item (in addition the category is added near the top of page, grouped on a single line (most used conventions is to place each category on a separate line, facilitating the visual review of diffs).

Please do not alter the content of template transclusions that you cannot understand for now, not even for cleaning up spaces. Do not delete HTML comments, or if you do, make sure that you won't delete the full code of this transclusion.

Verdy p (talk) 07:42, 17 June 2013 (UTC)

Suggestions for editing templates transclusions

 * In my opinion, the visual editor should allow editing template transclusions by presenting editing them in a visual table containing the list of positional parameters and the list of named parameters in two colums (one column for the name, one column for the value. It should also allow viewing the template page by pressing a button opening a scrollable frame (for getting access to its documentation), so that we can add the correct parameters in this editable table, as instructed in the template doc page. This editable table should be done within a popup dialog, because most templates will have a very different layout when rendered, not suitable for editing.
 * On the non-mobile version of MediaWiki, this popup could be a frame docked below the menu bar, and not using more than half the screen height. It should be also dockable on the right, for users that have wide screens: the left side shows the visual content of the page, and shows the rendered template as it is edited, the right side is for editing that template, and this docked template transclusion editor can be subdivided in two parts to showing the doc page of that template.
 * In addition we should be allowed to select another template name, keeping the parameter list (and if we do that, the doc page shown should reflect this change).
 * To select templates, we should be allowed to navigate in the list of categories for the current template (just like with the CatALot extension).
 * Similar navigation in categories should be possible as well when adding a cateofy to a page, when we don't know the exact name of the category, we wi still find other relevant categories, instead of beaing presented only a list of categories containing some existing words.
 * When editing template transclusions, all whilespaces should be preserved unless we actually edit a field (template name, parameter name, parameter value. This would preserve HTML comments most of the time and would minimize the number of changes in diffs.
 * Note also that template parameter names, or or template names way also transclude other templates (or could contain invokations of parserfunctions). These subparts present these fields should be marked as non editable.
 * Some whitespaces that are present at start or end of fields for parameter names or values or template names should be preserved (only duplicate SPACE characters may be simplified in the middle of the editable field, and whitespaces characters BEFORE a newline. HTML comments should be kept as much as possible, and should be made accessible in the editor, treated as an editable subelement.
 * When template transclusion parameters (or template name) contain another template transclusion, this creates the opportunity of recursive editing. The UI can still be made cleanly, by clicking on this field to open a new tab in this editor. When such a recursive edit is done, the visual rendering on the right side should also give the rendered result of this invokation to show its result, replacing temporarily the rendering of the full page (the full page can still be seen by selecting the first tab automatically created, the second tab being for the 1st level of edited template invokation. We can close the secondary tabs by confirming or cancelling the edit of one level of invokation (this also close tha tabs for its sublevels).
 * So in summary: we click the redenred box where the template transclusion appears in the visual page, this adds a row of tabs docked just below the menu bar, and a docked properties pane splitted in two parts : one part for the editable parameters in a table or in a vertical list, another scrollable part for showing the rendered template doc page, and each editable field in the 1st part is just a clickable list of field names, whose value appears in the visual preview (it activates a tab at the top), where actual values are entered visually (we constantly can click on the FULL PAGE tab to view the result in the full page.
 * And remember: ALL fields in a template transclusion (tempalte name, parameter name, parameter value) may contain one or more transclusions or invokations of parser functions, each one should have a rendered view accessible from a tab at the top, and viewable in its context ov invokation as if it was clickable element for editing it, or deletable. HTML comments should also be visible or invisible with a checkbox option in the top menu bar, as if they were inline content (i.e. in a subbox). And probably the preview pane should allow showing either the pre-rendered content, or the associated wikicode (if the wikicode is active, the properties pane is disabled or hidden, but tabs remain present at the top; the wikicode or visual rendering mode is a property associated with each open tab).

Similar editing should be possible as well for working with invokations of parser functions (which are mostly like template transclusion because they are just a list of editable subfields), or for inclusions of extension tags (like the search box), except that most parameter names or order are known, and that they don't have their own doc page which is located elsewhere on the Mediawiki.org site. One basic design idea would be that each extension tag or parser function should have a way to register a "hook" for filling a list of properties, some with fixed self-explanatory names subject to translations), specific to the extension (and with status giving their type and mandatory/optional status), some just listed in a defined order without names (or a name equal to an integer number starting by "1"):


 * These hooks would handle themselves if they can strip whitespaces, and would also provide some validation for fields editable as plain text, and saying if values may embed other tags, or if it should remain plain-text, or if the value must be one in a list of provided values.
 * The VisalEditor would provide the Interface itself in the properties pane, would create the necessary tabs and navigation. The VisualEditor may provide several layouts for editing these properties: either a pane-less mode where data is entered directly in the preview pane, or an edit within a "bubble" pane appearing on top of the page, for basic tags, or the full properties pane docked on the side from the preview pane.
 * The hooks will also generate the wiki code, that they will also render themselves (a hook could also generate additional wiki code that won't be saved in the article but which is required to give some meaning to the edited tag or function with an API like "getPreviewCode". To implement this API, when the inner parameters can embed additional tags edited separately, they will call a part of the API that calls the appropriate "getPreviewCode recursively in the appriate hooks for their tags. Note that the preview code will often be a bit different from the code that will be saved (it will limit some interactions with it, for example the visual preview of links don't work as links, buttons are inactive, tables don't sort, videos are not played when clicking on them, and a yellowish frame surrounds the element when the mouse hovers them in the preview pane, all of this depending on the type of edit mode best chosen for implementing the tag editor and integrating in the VisualEditor...)
 * When saving (or when the preview pane is replaced in edit mode by the wikicode edit mode, these hooks will only generate the editable wiki code containing everything, within unparsed contents for the parameter, i.e. the complete syntax of the tag and all its parameters and contents (in that case the properties pane is hidden or disabled; we have a top button above the wikicode editor that allows switching between the wikicode edit mode and the visual edit mode).
 * One of these tag/function extensions would manage the inclusion of images and media ; another would manage the inclusion of reference notes (and the hhok would provide an additional wiki code  that will not be saved in the the edited wikicode only in the view pane, but that will be appended in the preview pane that shows the note call in its context where it is inserted in the page); another will manage parser functions (one for each parser functions extension, another will manage template transclusions.
 * The hooks will also indicate if they have a documentation page to display below the properties pane, by an API like "getDocumentationURI" to help understand its usage, and may be links to the applicable policies (so the documentation pane will include a scrollable frame (links on the documenttion page may open a new tab in the browser to avoid complications, if you don't want to use HTML frames).
 * All this would finally allow editing complex codes (with lots of "{}" braces) in a much easier way, with less errors: just click one tag in visual mode to access to the subtag and its parameters in a new pane and with its new navigatable visual tab).
 * Note that when an extension hook provides flags for editable fields, if one of these flags says that the parameters will have its leaning and trailing whitespaces ignored and stripped by the rendering, the wiki editor should allow using a "pretty-printing" mode using automtic indentation (but a hook may also provide itself an API like "getPrettyCode" to format this code, or other presentation features like syntax coloring (recursive as well when subtags are embedded, using some code generators for fixing things like indentation levels).
 * All these hooks will be optional (the Visual editor will provide a default reasonnable interface, that each extension may override with their hooks to get easier editing mode. For example, the default will not validate the edited values of editable fields. The Visual editor will understand the wiki syntax using braces, colon and pipes by default, and the HTML or XML syntax of tags (with a leading tag name, a list of attribute names, their values, the inner content, and the end-tag marker (possibly abbreviated as "" in special tags like "tvar", or unnessary for some HTML5 tags where they are implied like in "li" elements).

Finally the current editing of categories in the "Page properties" menu is really a bad idea (it is also counter-intuitive). It should be done like in CatALot, by editing them at the bottom of the visual page, where they are effectively displayed, like in CatALot. I really suggest the integration of a working mode like CatALot, integrated and adapted in a specific version for the VisualEditor (CatALot should remain a separate extension).

Verdy p (talk) 07:42, 17 June 2013 (UTC)

Conclusions about the beta
Before reenabling this beta, PLEASE make sure that all users (uncluding those with autoconfirmed edits) will be able to review the changes in the wiki code. In the past, when submitting the changes, we were presented at least the edited wikicode before confirming it. This presentation of the wikicode when reviewing changes should be kept for now.

Verdy p (talk) 07:42, 17 June 2013 (UTC)

[Bug] : characters selector (for internationalization) missing
The useful characters selector (shown above the wiki code editor by clicking a button on its top bar), is definitely missing in the VisualEditor. There's also no support as well for input methods (set using the Universal Language Selector, aka ULS), meaning the many international users can't type the characters they need for their language or for more exact typography (e.g. apostrophes, maths symbols, IPA symbols), typically missing on their keyboards. Using characer name references is not an option for the VisualEditor. Please provide the characters selector, like in the wiki code editor.