VisualEditor/Feedback/LQT Archive 1

__NEWSECTIONLINK__

 Your feedback about the visual editor developer prototype

This page is a place for you to tell the Wikimedia developers what issues you encounter when using the visual editor sandbox. Please note that this is still an early prototype which cannot yet edit or save existing pages and has many known issues. We do welcome your feedback and ideas, especially on some of the early user interface decisions we're making!

[//www.mediawiki.org/w/index.php?title=Visual_editor/Feedback&lqt_method=talkpage_new_thread Add a new comment] – Report a bug in Bugzilla

Latest status update



Archives (older archive dates indicate date of initial comments and may span several months; newer archives span one month per archive and are generated by MiszaBot):

Test feedback
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

First post! NeilK 20:01, 13 December 2011 (UTC)

This is the greatest editor ever made!
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.969.0 Safari/535.13

Trevor should get a raise. Trevor Parscal 20:02, 13 December 2011 (UTC)

Link editing should work when cursor is on the link
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

When on top of an existing link using the link interface should be able to manipulate the link. Currently you get a visible but not really working interface until you manually select the entire link. Daniel Friesen (Dantman) 20:38, 13 December 2011 (UTC)


 * Yes, the little down-arrow with B/F/Link should be visible if the cursor is at a link and no text is selected. You should also be able to format the whole link with the menu if the cursor is on a link. -- JakobVoss 22:16, 13 December 2011 (UTC)

Incorrect behavior when typing 's into the editor
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

When typing asdf into the visual editor the editor leaves it as " asdf " the WikiText mode lists " asdf ", and the preview displays a literal " asdf ". Naturally this is not correct since either the preview is wrong and it will end up as a link, or the WikiText is wrong and needs nowiki tags. Daniel Friesen (Dantman) 20:41, 13 December 2011 (UTC)

Collapse same text links
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

When selecting the text "asdf" and linking it to "asdf" or "Asdf" the visual editor should collapse this to asdf instead of outputting asdf as the wikitext. Daniel Friesen (Dantman) 20:43, 13 December 2011 (UTC)
 * But foo should always collapse to foo for every "foo". If you link "Asdf" to "asdf", the editor does not collapse, so everything is right. -- JakobVoss 22:19, 13 December 2011 (UTC)
 * This can be done intelligently; if the markup is foo2 and foo2 would resolve to the same page as foo1 (typically foo1=foo2 if 1st characters uppercased), then replace foo2 by foo2.

Wow.
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

This is great, just as it is now it would make a big difference to users.

Minor issues: I'm using Firefox 8.01 on a Mac with OSX 10.6.8 I scrolled down the page then tried to use the scroll bar to get back to the top but it kept jumping back to where the cursor was.

I notice you can only edit in the wysiwig window. For more complicated formatting it could be useful to be able to edit in the wikiformat window and see the results in the wysywig window.

Having HTML and JSON windows may seem like a waste or a confusion but I think it is cool - there could be a settings option to hide show these if editors react badly to these.

Editing tables and templates will be the big deal - these are a bastard to edit now - code soup. Don't feel that every single thing has to be supported - some stuff can be deprecated if there is another way of doing it which works better or even left to be editted in wikicode until the next version.

MediaWiki version 2.0; bring it on, the sooner the better. Filceolaire 21:09, 13 December 2011 (UTC)


 * There are a lot of preview modes right now, and even a peek at the transaction history. But that's mostly for us developers. NeilK 21:37, 13 December 2011 (UTC)

Keyboard shortcut to clear formatting
User agent: Mozilla/5.0 (Ubuntu; X11; Linux i686; rv:8.0) Gecko/20100101 Firefox/8.0

Please add a keyboard shortcut to clear formatting, that would be very handy. Jean-Fred 21:11, 13 December 2011 (UTC)

Feedback
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0) Gecko/20100101 Firefox/5.0

Interesting start! Finally something to show for all that WYSIWG talk...

1) When highlighting text & choosing to insert a link, the link text should default to the highlighted text. I.e. if I select "Gene Mosher" and want to insert a link to "Gene Mosher", I should not be required to re-type "Gene Mosher".

2) In toggle wiki-markup, I see that some links are formatted with _ instead of spaces (like [Gene_Mosher]), which would make a bunch of AWB users very unhappy...

3) It's my understanding this does not yet work for templates, right?

4) How do I save? Or see what changes I made? Confused. Renata3 21:22, 13 December 2011 (UTC)


 * (1-2) thanks for the feedback. (3) we are still working on a template interface. (4) right now, you can't save. NeilK 21:38, 13 December 2011 (UTC)

Link editing
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

By default, editing a link should probably edit the *whole* link. Currently you only get the little arrow when you select some text in the link - should probably show anytime cursoring over a link. Currently allows trailing spaces in links (which aren't shown normally, iirc)

Toolbar icons are excellent. Everything else feels pretty good (especially compared to wysiftw). Not sure how much is happening behind the scenes though.

-- Steve Bennett (stevage) Stevage 21:45, 13 December 2011 (UTC)


 * Also it is easy to select part of a link and edit it, while not editing the whole thing, resulting in two adjacent links (which aren't discernibly separate until one mouses over them). 75.101.56.74 23:25, 13 December 2011 (UTC)

Fantastic! A few points.
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

1. Un-toggling the views (via the buttons on the right) is confusingly slow (i.e., multiple key presses) on Google Chrome 15.0.874.121-r109964. 2. There's a citation needed tag, but it's not clear how one would edit that...? 98.216.238.148 21:50, 13 December 2011 (UTC)


 * That un-toggling slowness is puzzling us right now too. Trevor was trying to fix that until like, seconds before I deployed. NeilK 21:51, 13 December 2011 (UTC)


 * Oddly, I don't see this with Firefox, and it comes down to Webkit taking a ridiculous (like 10x) amount of time to give a result for domElement.clientWidth (which measures the size of an element on screen). But yes, we are looking into it for sure. --Trevor Parscal 22:08, 13 December 2011 (UTC)

Link button
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

Would be nice if you could position the cursor anywhere on an existing link and hit the link button to edit the destination: it seems that you have to drag and select at least one character within the link for the link button to do anything?

Similarly, when adding a new link, it would be nice if after selecting a span of text and hitting the link button, the edit link popup came up with the destination defaulting to the text you have selected, so if you need to change it, you can, but in many cases you won't. 134.159.142.130 22:12, 13 December 2011 (UTC)


 * See bugs https://bugzilla.wikimedia.org/show_bug.cgi?id=33049 and https://bugzilla.wikimedia.org/show_bug.cgi?id=33053

Excellent starting point!
A few feedbacks:

FT2 (Talk 22:18, 13 December 2011 (UTC)
 * 1) Dropdown/popup dialogs for formating are not clear enough - they don't stand out enough against the text. Dimming the rest seems to be a common way to do it.
 * 2) The "toggle XYZ view" icons look good, and having them separate makes them more accessible. I like this. However:
 * "Toggle preview" is redundant, as the left pane is preview anyway
 * When a view is shown, its icon should change, to make it clearer. (And clicking the icon again should remove the split view)
 * 1) Selecting text then clicking escape to de-select whatever options pop up, causes the text to change format
 * 2) Cut/paste/drag/drop obviously aren't there right now, though partly shown in help. I assume they will be at some point.
 * 3) Adding wikilinks will be a major activity and one of the most used functions. But finding the correct link isn't easy. An "Advanced>" or "Search>" option would be important.
 * Bonus points if it can also explain "this isn't usually the best link" and show a list of possible links, if someone selects a disambiguation or redirect page (identified via template or page title).
 * 1) In some rich text processing software, clicking in the margin next to a paragraph, selects the entire paragraph. An easy way to select a paragraph, section, or entire containing section might be worth considering.
 * 2) When multiple editors work on a page, how will we avoid mayhem, or have meaningful attribution of edits? Or will it be local editing only, up to the point where the user presses "save"?
 * 3) If typing automatically edits the text, Readers could fear unintentionally changing or editing articles. For reassurance, users should choose "editing mode/reading mode" or have an "enable editing" button or icon, perhaps with editing tools and a subtle background color change (very pale cream?). If the user starts to do editing actions when it isn't enabled they should get a popup "You have started editing this page" or something. If this isn't considered then many editors not au fait with technology may panic the first time they get something unexpected when reading, and some may not access pages in future for fear of accidentally "doing something wrong" or typing into them.

Templates cannot be accessed or edited
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

They can, however, be deleted. Magnus Manske 22:22, 13 December 2011 (UTC)


 * There's a couple of examples of a template being rendered (and being treated as a single character) in the demo. We do not have a template editor yet, and the user interface for editing templates, images and hooks is going to be different than editing text. This isn't included in the demo because it's not done yet. --Trevor Parscal 22:43, 13 December 2011 (UTC)

A step in the right direction
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

First off, great work team. This is one of the best WYSYWIG editors I have seen on the web. Visually, I have very few gripes with it. The layout is clean, minimal and works very well with the existing mediaWiki look. The icon set works well and most things are where you expect them to be.

There does seem to be some functionality lacking, but I'm sure this will be coming in the future (this is just a first pass, afterall).

One thing of note, though. It would be super awesome if you could directly edit the source pane and see this changes in the preview. That way you could do simple editing tasks quickly on the preview (left) pane, and then switch over to the source (right) pane to do tasks that require more complexity than the GUI allows while still having the benefit of seeing exactly what changes you are making. 38.127.199.123 22:25, 13 December 2011 (UTC)


 * Agree with the last point, that was something I thought too. FT2 (Talk 22:30, 13 December 2011 (UTC)


 * The editor uses a data structure called Wikidom, which is based on Wikitext. We are working on a parser which can convert between Wikitext to Wikidom, but the parser isn't ready yet, so we can't convert from Wikitext to Wikidom - which means we can't make the right-pane editable. --Trevor Parscal 22:46, 13 December 2011 (UTC)
 * "Yet" was the key word there. Thanks Trevor! FT2 (Talk 22:56, 13 December 2011 (UTC)

List un-/remarking
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Turning a bullet point or numbered list item into a normal paragraph inserts an additional blank line before the paragraph. Re-applying a list style will break the list order due to that blank line, resetting numbering to start at 1 again. Magnus Manske 22:27, 13 December 2011 (UTC)

Cannot insert new link
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Clicking on the link icon or pressing Command-K while in normal text should open the link dialog, either blank or pre-selecting the word the cursor is currently in. Magnus Manske 22:29, 13 December 2011 (UTC)

Closing preview is strangely slow
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Opening it is fast, though. Affects all types of preview. Magnus Manske 22:31, 13 December 2011 (UTC)


 * See bug https://bugzilla.wikimedia.org/show_bug.cgi?id=33051

Inserting HTML tags will keep them "as is"
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Typing "dd" will add the exact same text to the wiki markup preview. However, if saved that way, they would render as italics, which is different from the Visual Editor display while editing. Magnus Manske 22:36, 13 December 2011 (UTC)


 * Both the Wikitext and HTML serializers could use a lot of attention, this is known and should be improving soon. --Trevor Parscal 22:49, 13 December 2011 (UTC)

Pre-formatting text breaks in lists
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

In new document, write some characters, click on list, then change to "Preformatted". The wiki markup preview will show the leading "pre"-space after the list star, which will obviously not work in later rendering. Magnus Manske 22:39, 13 December 2011 (UTC)

A space typed at the beginning of a paragraph...
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

...will be rendered into a normal wikitext space, which would create a "pre"-line in the next rendering. Magnus Manske 22:42, 13 December 2011 (UTC)

"Double linking"
User agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0

Pages such as computer science are being linked as computer science, required. Current best practice is to only link that sort of thing once. Is that a necessary technical change? Izno 22:43, 13 December 2011 (UTC)
 * Looks like Dantman commented on this at . On a side note, there might be more than a few duplicate posts with the way this is currently set up... :3 --Izno 22:45, 13 December 2011 (UTC)

Link removal cannot be undone
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Also, removing part of a linked text works, but can leave trailing spaces within the link. Magnus Manske 22:47, 13 December 2011 (UTC)

Pages accessible under multiple names
Although early stages, if we are redesigning the editor I would like to suggest an area of improvement to include within it.

A lot of pages can (and should) be accessible under multiple names. For example, project and community pages accessed under WP:SHORTCUT redirects, and articles with common alternate names that users might look for them under.

Redirect management (managing alternate names and ensuring likely alternate names are created) is hard. It's hard to ensure consistent coverage, especially for topics with multiple or non-English alternate names, and often significant alternate names aren't found when one searches. For example the article on the Chairman of the Libyan Transitional Council commences:

"Mustafa Abdul Jalil or Abdul-Jalil (Arabic:مصطفى عبد الجليل, also transcribed Abdul-Jelil, Abd-al-Jalil, Abdel-Jalil, Abdeljalil or Abdu Al Jeleil)..."

All 8 of these names including the Arabic, and possibly uncased or major familial-name variants, are possible valid redirects or expected page titles. There is no easy way for a non-expert editor to check that common "lookup terms" or alternate names are accounted for, or indeed to identify and remove "crufty" alternate names.

I would like to suggest a changed approach for alternate names, that would fit in well with the visual editor. What I'd like to see is that in the same way you will be able to visually add and edit a list of interwiki language links, or a list of categories, you can also add and edit a list of alternate page titles. That would replace (or act as a visual editing approach for) redirects.

The idea is that when you edit a page, you can simply edit a list of all other names that should redirect to this page, and mark one of them as the default page name. Conflicts where the same name appears on 2+ articles then naturally lead to a "this name is already used for XYZ article" and a request to disambiguate, or refusal to accept until it's resolved (ie the proposed name is unused elsewhere). I think this would help newcomers to enter and manage alternate page names and redirects in an easy visual manner. FT2 (Talk 22:54, 13 December 2011 (UTC)

New document: List breaks editing completely
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

If, in the new document, the first action is "bullet list", the cursor is "trapped" before the bullet and cannot be moved anymore. Magnus Manske 22:53, 13 December 2011 (UTC)

No button for definition list
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_2) AppleWebKit/535.13 (KHTML, like Gecko) Chrome/18.0.970.0 Safari/535.13

Also, opening this feedback form adds a "#" to the URL. Missing "return false", anyone? ;-) Magnus Manske 22:54, 13 December 2011 (UTC)

Tables are missing!
User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0.1) Gecko/20100101 Firefox/8.0.1

I don't see how to enter a table or a mathematical formula! WiseWoman 23:25, 13 December 2011 (UTC)

test
User agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.874.121 Safari/535.2

... Helder 23:28, 13 December 2011 (UTC)