VisualEditor/Feedback

From MediaWiki.org
Jump to: navigation, search
Share your feedback
Report bugs

Your feedback about the VisualEditor beta release

This page is a place for you to tell the Wikimedia developers what issues you encounter when using VisualEditor on Wikimedia projects. This page uses LiquidThreads, so you need to click "Start a new discussion" (not the ordinary "Edit" link) to post your message.

VisualEditor is still a beta 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 commentView known bugsReport a new bug in BugzillaJoin the IRC channelTest VisualEditor! (no account required)

Archives generated by MiszaBot:
VisualEditor/Feedback/Archive/2011/12 VisualEditor/Feedback/Archive/2012/01 VisualEditor/Feedback/Archive/2012/02
VisualEditor/Feedback/Archive/2012/03 VisualEditor/Feedback/Archive/2012/04 VisualEditor/Feedback/Archive/2012/05
VisualEditor/Feedback/Archive/2012/06 VisualEditor/Feedback/Archive/2012/07 VisualEditor/Feedback/Archive/2012/10
VisualEditor/Feedback/Archive/2013/05
Start a new discussion

Contents

Thread titleRepliesLast modified
Why is IE not officially supported?016:18, 24 November 2014
Save dialogue unreadable315:27, 20 November 2014
New thing suggest219:35, 18 November 2014
Symbol after citation disappear after edit103:41, 18 November 2014
VisualEditor conflicts with any templates218:14, 7 November 2014
Citing sources is really difficult in VisualEditor!218:13, 7 November 2014
MediaWiki theme: popupToolGroup should have hover and active state021:45, 6 November 2014
Table tests and use case studies + bullet/numbered indented list bug116:09, 6 November 2014
Text Color1311:51, 5 November 2014
syntax highlight geshi and visual editor116:49, 29 October 2014
Cancel button1421:14, 25 October 2014
Why has Ctrl-V suddenly stopped working?821:22, 24 October 2014
How can i get the VisualEditor extension for my companie's knoledge based system, which are based on MediaWiki?119:33, 24 October 2014
VE can't handle Template:Extension219:31, 23 October 2014
bug 49904 not on roadmap1619:03, 23 October 2014
Adding a link to an image caption317:37, 23 October 2014
Extreme lag in updating link suggestions116:20, 23 October 2014
Special characters2313:50, 23 October 2014
VE help menu in ruWP218:24, 22 October 2014
Can't desactivate the VisualEditor516:29, 21 October 2014
First page
First page
Previous page
Previous page
Last page
Last page

Why is IE not officially supported?

Why is that? On your page , it says that it plans to support IE9 +, but even editing on IE11 brings up a warning that it is not 'officially supported'. Even though it is better than before (where IE users were blocked fully) , I'd like to know why is IE not getting full support for the latest versions. Is there something missing?

Leaderboard (talk)16:18, 24 November 2014

Save dialogue unreadable

Is it my imagination or has the font of the save dialogue recently become ridiculously and unreadably small?

SpinningSpark09:03, 15 November 2014

Did you upgrade to MacOS X Yosemite ? They have started to use a different default font for such textareas. It's not smaller, but it is less legible at smaller sizes than the previous font in my opinion, due to the kerning.

TheDJ (Not WMF) (talkcontribs)09:51, 18 November 2014

No, I do not even use a Mac. I am on Windows 7. The problem seems to be specific to Monobook. See this screenshot.

SpinningSpark12:04, 18 November 2014

That also applies to other dialogs: therefore, I filed it.

Elitre (WMF) (talk)15:27, 20 November 2014
 
 
 

New thing suggest

I suggest another part of "insert" for "insert asbox" and "insert ambox".

Qwertyxp2000 (talk)04:07, 16 November 2014
Edited by another user.
Last edit: 19:32, 18 November 2014

Those are very specific uses, they might be better developed as gadgets that integrate with VE in my opinion.

TheDJ (Not WMF) (talkcontribs)09:50, 18 November 2014

Agreed for this suggestion in particular; note that there is a suggestion in bugzilla:53590 that we prompt the user with contextually-appropriate common templates when they click "insert", which is an alternative direction.

Jdforrester (WMF) (talk)19:35, 18 November 2014
 
 

Symbol after citation disappear after edit

I have tried in both the English and Chinese Wikipedias, and I found that whenever I add a Chinese full stop "。" (without the quotations) after an inline citation, the "。" will disappear after the edit is saved. If you need an example, you can tell me, but basically, try putting "。" after <ref>(cite source)</ref> and see what happens.

HYH.124 (talk)03:39, 18 November 2014

I am referring to when you add the "。" after the citation and nothing follows it (e.g. at the end of a paragraph).

HYH.124 (talk)03:41, 18 November 2014
 

VisualEditor conflicts with any templates

Hello!

I just noticed, that I can add new pages with VisualEditor and edit em, also i can edit already existing pages, but if there are no templates. If these pages have templates then there is an error "Parsoidserver-http-badstatus: 500". Templates workin if the next syntax is used: {{subst:Name}}. Any ideas?

Piroru90 (talk)10:58, 1 November 2014

There was a problem with version (I got MW 1.23.6 (latest stable)).

I have to update to MediaWiki 1.24 and reinstall VisualEditor (Parsoid already exists in MW >1.24) and then it works fine without errors.

Piroru90 (talk)07:34, 3 November 2014

I'm glad that you figured it out.

Whatamidoing (WMF) (talk)18:14, 7 November 2014
 
 

Citing sources is really difficult in VisualEditor!

Hello; I'm a fairly new user (< 1 year) and I'm motivated (and trying!) to improve some articles, but the VisualEditor citation tools are just not usable, and I really don't have the time to learn source editing. I know that you guys have a busy schedule, but I just wanted to leave this message here to let you know that it's a bottleneck, at least for me.

The main problem I am having with the tool is that shortened footnotes or similar are not supported, so I can't reference multiple pages from the same source, meaning I can't write the article. There are also problems with intuitive selection behaviour in reflist templates and all sorts of other stuff. Is there a "fix citation tools" task on the roadmap? I couldn't see one.

Anyway, I hope I'm not telling you things you already know. Thank you for making this tool; in a few years I'm sure Wikipedia will regain some new editors because of it.

Thennicke (talk)12:02, 1 November 2014

Hi there. Thanks for stopping by to tell us your experience. The ability to name references is requested at bug 50568. In the meantime, you can still reference multiple pages from the same source easily, I think? Or at least, this took me just a few seconds. All I did was creating a new reference. Then I copied the content of this reference and pasted it into new ones (made in the same way), and added the detail about the pages (this is useful for more complex references created by templates, for example, because VE will retain links, style, etc. when you paste). If you want a bit of insight into the future of references in VE, please try en:User:Mvolz/veCiteFromURL :) Best,

Elitre (WMF) (talk)15:01, 3 November 2014
 

User:Thennicke, When you say that "shortened footnotes are not supported", do you mean that this:

{{sfn|Smith|2010|p=15}}

is not supported, or do you mean that this:

<ref>Smith (2010).  p. 15</ref>

is not supported? Or something else?

Whatamidoing (WMF) (talk)18:13, 7 November 2014
 

MediaWiki theme: popupToolGroup should have hover and active state

The new MediaWiki theme looks good, though the popupToolGroup (a toolbar element, ref. demo) should have a hover (and probably active) state when someone mouses over or clicks the element. Apex has both a hover state and an active state, and the current editor has both as well. Adding such a state would make the editor toolbar seem more responsive.

However, this is inconsistent with the hover behavior of the other buttons, so it's a valid question whether it's a good idea or not to add a preferential hover state to the popup tool group. However, I think it should have an active state, since other toolbar buttons themselves have an active state when activated, so adding one to the popup tool group when the popup is active would be in line with the behavior of other items.

Mark Bao (talk)21:45, 6 November 2014

Table tests and use case studies + bullet/numbered indented list bug

Hello, here are some tests I have done with tables. I have quite a few different cases to be covered here, so I'll separate them by bold text.

1. Typing a backspace on the first character of text below a table makes that table "eat" the following line.

In my test, seen here (first table in the code's edit), I tried editing the content of the headings right below the table in section Heading 2aa. The result was such: one too many backspaces made the headings jump into the last cell (code-wise) of the table, stripping their heading format and appending their line's text to the cell.

A second test, seen here, has me styling text and trying to append it to the last cell of the table. The text retains its styles.

In my third and final test on this subject, seen here, I created a heading and applied multiple styles before moving the text into the table. The styles were retained, but the heading was stripped due to the text being appended to the end of the last cell's last line.

In conclusion, this shouldn't actually happen. Jumping from text into a table cell with backspaces can cause some rather unfortunate problems, especially if you accidentally move a large paragraph into a compact table with narrow columns. The stripping of headings is also a loss of data, since we lose all reference to the heading's previous level.


2. Moving between cells in edit mode is impossible.

While not necessarily a universal concept, it is a usability enhancement that would make things far less annoying: while editing a cell's content, I have not found a way to move to an adjacent cell without having to use the mouse to select a different cell.

Many systems accept the use of the Tab and Shift + Tab buttons to move between cells in a row (wrapping to the next/previous row if at the extremity) without using a mouse. Others additionally or alternatively accept the use of the arrow keys when at the cell's editing border in order to jump to the next cell (Up needs to be on the first line, Down on the last line, Left on the first character of the first/current line, Right on the last character of the last/current line)


3. Entering a cell's editing mode should put the text cursor where the user has clicked

This is another usability quirk: it takes a double-click (for edit mode) and a separate single click in order to reach the user's required editing target. This is can be an annoyance for people who edit tall cells that exceed their screen's size, since the cursor's position isn't immediately apparent.


4. Alternating between bullet and numbered lists with indentation is buggy

Do the following steps:

  1. Add a bulleted list with text.
  2. Add a second bullet with text. Increase its indentation once.
  3. Change the second, indented bullet to a numbered list.
  4. Change the second, indented number back to a bullet.

VisualEditor removes the number, removes the bullet and all indentation. If done within a list of mixed bullets and numbers, it effectively breaks the list by dragging the following list item to the first level.

Proper functionality should be that the entire indentation level changes to bullets. All other indentation levels should not be affected. If the list is of the following kind:

  • Indent 1-1
    1. Indent 2-1
      • Indent 3-1
    2. Indent 2-2
  • Indent 1-2
    1. Indent 2-3
      • Indent 3-2

Changing the numbered list at 2-1 should affect 2-1 through 2-2, but not 2-3.

My test was done with the following list, which was subsequently modified here.

184.151.114.14415:28, 6 November 2014

For reference, I used Firefox 33.0.2 for those tests.

As for Chrome 38.0.2125.111, I got similar results.

This is the original list and this is the broken list while using Chrome.

Thanks again!

184.151.114.14416:09, 6 November 2014
 

Text Color

Will there be any way to quickly edit text color, rather than having to place the desired style within a template and require inserting templates everywhere colored text is needed? Thanks! 184.151.127.142 14:36, 19 June 2013 (UTC)

184.151.127.14214:36, 19 June 2013

Do you have a specific example (or 2) in mind? Examples (almost) always help!

I know we use colored backgrounds, in many tables. (E.g. en:List of Arizona Cardinals head coaches), but I can't think of any uses of colored text. (Pick examples from en:WP:Featured lists, if possible.)

Note: en:MOS:ACCESS#Color and en:WP:WikiProject Usability/Color both strongly caution against using coloured text.

Quiddity (talk)16:19, 19 June 2013

Here is one example from the Featured Lists page - Transport section, Vancouver Skytrain's page - where forcing white text is required due to the background colors of tables, though it's mostly in related templates. There's also a lesser amount of coloring going on in the Stations section where the line colors are indicated next to the line name by adding a colored emblem. Since it's not the entire cell that's colored, the use of <span style="color:#XXXXXX"></span> is still required to get that effect.

https://en.wikipedia.org/wiki/List_of_Vancouver_SkyTrain_stations

Since I just read that there will be support for cleaning up empty span tags, it seems like VisualEditor already seems able to read those tags' properties.

Thanks, 74.15.154.98 16:48, 28 June 2013 (UTC)

74.15.154.9816:48, 28 June 2013

I just noticed the use of color on your own user page. https://en.wikipedia.org/wiki/User:Quiddity which uses full cell coloring, as well. That could definitely be something else to add in VisualEditor in order to cut down on span tags if a color is applied to a cell. 74.15.154.98 16:56, 28 June 2013 (UTC)

74.15.154.9816:56, 28 June 2013
 

This page has a nice use of coloured text.

Nnemo (talk)22:16, 9 February 2014
 

You may want to take a look at Requests for comment/Deprecating inline styles.

Helder20:52, 2 July 2013

Very interesting discussion, however it doesn't seem to change the original request outside of modifying which element of code would be edited in order to allow text color, text bordering, or text background fill. That proposition definitely shows a need for migrating away from div and span tags in favor of style tags with injected CSS, but none of those three options can currently be modified by VisualEditor, nor are any of them planned to be modifiable. However, allowing the modification of style tags could likely allow more than just text color, opening style options up to text size, alignment, and many more. That would be especially powerful if implemented in a future (post beta?) release.

74.15.154.98 11:10, 5 July 2013 (UTC)

74.15.154.9811:10, 5 July 2013

Or just move entirely to using templates for styling? E.g. en:template:color. (I'm not uptodate on this at all, just suggesting).

Quiddity (talk)21:20, 5 July 2013

Eww, more templates! ;-)

Jdforrester (WMF) (talk)16:12, 12 July 2013
 
 
 

A quick way to select text and then pick a color from a small color palette would definitely be very useful. This is something we do very often on my local wikisite to highlight things in large tables.

217.210.124.17422:01, 12 July 2013

I agree. Would be very useful for us local wiki site users that use this great open source wiki for our own projects.

/Daniel

195.60.68.15515:11, 28 February 2014

Do you use it outside of tables? Inside tables, do you usually change the text color or the background color?

Whatamidoing (WMF) (talk)23:43, 3 March 2014

The best thing would be if it would work both inside and outside of tables. But I guess outside of tables would be most important since I guess there will be someway of coloring background in tables in the near future?

A typical scenario for a local wiki would be to color something in a project page as important with red color, something less important with orange color etc.

/Daniel

195.60.68.15611:47, 5 November 2014

Well, a bug was filed about this anyway.

Elitre (WMF) (talk)11:51, 5 November 2014
 
 
 
 
 

syntax highlight geshi and visual editor

Hi,

I have a local wiki installed with the latest mediawiki from git master (1.25alpha (a9d0cfc)), latest visual editor extension from git (0.1.0 (358268b)), latest parsoid extension from git (0.2.0 (9b986c9)), latest syntax highlight extension from git (1.0.8.11-wmf1 (53e1b42)).

But when hoovering over the syntax highlight parts I get the not editable icon (sorry, this element can only be editable in source mode for now) and not the editable popup that you are suppose to get.

Anything missing here to get it to run ok with syntax highlight geshi?

BR, Daniel

195.60.68.15611:56, 29 October 2014

Hey,

I'm afraid that the SyntaxHighlighter_GeSHi extension doesn't yet have a VisualEditor plugin. There was some excellent work last year by a GSoC student to make one of these, but that work had a few bugs and is not yet ready to use, I'm afraid.

The work in progress is currently available on gerrit – https://gerrit.wikimedia.org/r/#/c/114529/ – but we don't have the spare cycles to devote to this area of work, as it's not a priority for Wikimedia content wikis.

We'd be happy to work with and help someone interested in taking it on, but without someone coming forward, it's not scheduled to happen for quite a while.

Jdforrester (WMF) (talk)16:49, 29 October 2014
 

Cancel button

Hello, I'm experienced wikipedian. But when I tried VE last time I couldn't find some Cancel (editing) button. I think it's very important because of average internet users. Not everybody knows it could be canceled by clicking to Article link. Reloading is useless. So some people could be pushed to saving it.

Dominikmatus (talk)16:54, 13 October 2014

Well, also if you use wikitext editor, there is no cancel button. I don't think that it's needed. Users can just click the "article tab" or alternatively click the cancel button in the browser.

Stryn (talk)19:08, 14 October 2014

Yes there is. There's even one on this edit window right now. There is no cancel button in the browser. That doesn't even make sense, how would the browser know what "cancel" means in this context?

101.160.157.7103:04, 15 October 2014

Not a "button" though. Anyway, in August User:Jdforrester (WMF) commented on Bugzilla, "We just removed the Cancel button because user testing showed that it wasn't helpful. Any link out of the editor leaves the editor…"

Elitre (WMF) (talk)10:58, 15 October 2014

The technicality of if it is a "button" or link is irrelevant to the user. Clicking it does a thing either-way. And quiet buttons (which the VE one was) look identical to links.

121.214.105.20004:27, 16 October 2014
 

In what way is a cancel button "not helpful"? Is it deemed to be harmful in some way? I understand that it is not necessary, but that can be difficult for a new user to grasp. It is not self-evident that navigating away from the page is the way to cancel the edit, and besides, that seems to me like crashing out of a program to stop it - a bit of a kludge, not very clean, and counter-intuitive.

SpinningSpark23:47, 16 October 2014

Apparently nobody actually used it (except me, because I cancel a lot of sandbox edits when I'm sorting out bug reports). Also, I think it was removed several weeks before anyone said anything about it. It's been gone for a couple of months, and this is only the second or third time anyone's mentioned it (except me).

Whatamidoing (WMF) (talk)00:14, 17 October 2014
 
 
 
 
 

Why has Ctrl-V suddenly stopped working?

Why have Ctrl-X and Ctrl-V suddenly stopped working? It was working fine earlier tonight. I've tried two different PCs with two different operating systems both logged in and logged out so I'm pretty sure its not me at fault. Browser=FF32.

SpinningSpark23:40, 16 October 2014

It's happening for me, too, so it's not just you.

This is now tracked as bugzilla:72164. Thanks for the report.

Whatamidoing (WMF) (talk)00:06, 17 October 2014

Any chance of a heads up on how this has happened? The current VE version is dated 9 October, that is, it apparently hasn't changed since this bug materialised. There would seem to be something seriously wrong with VE version control.

It is extremely inconvenient. I use these keys all the time. Apparently, this same bug can cause random bits of the article to end up deleted so it needs fixing as a matter of urgency.

SpinningSpark20:39, 19 October 2014
 

Hi, Ctrl+V is do not work in Visual editor in my firefox, explorer, chrome. Do not work drag and drop.

I.Sáček, senior (talk)10:58, 19 October 2014

User:I.Sáček, senior and User:SpinningSpark, this is supposed to be fixed now. Please check and let me know if it's working for you.

Whatamidoing (WMF) (talk)21:40, 21 October 2014

Quick check, it's not working in either monobook or vector. Am I supposed to restart my browser or something?

SpinningSpark22:34, 21 October 2014

The version is still showing as 9 October so presumably nothing has changed (unless this is more poor version control). I would copy-paste the full version info, but not even select is working in the help window, let alone copy-paste - not very useful.

SpinningSpark22:39, 21 October 2014

The dates are the release dates, which take at least a week to get to the Wikipedias. Cutting and pasting is working for me in Firefox here at mw.org but not at en.wp. I'll tell James F; I believe that this was supposed to be released ahead of schedule.

Whatamidoing (WMF) (talk)19:27, 24 October 2014
 
 
 
 
 

How can i get the VisualEditor extension for my companie's knoledge based system, which are based on MediaWiki?

How can i get the VisualEditor extension for my companie's knoledge based system, which are based on MediaWiki?

95.131.179.21013:48, 14 October 2014

The basic instructions appear to be listed at Extension:VisualEditor.

Good luck!

Whatamidoing (WMF) (talk)19:33, 24 October 2014
 

VE can't handle Template:Extension

Edited by another user.
Last edit: 19:31, 23 October 2014

If I roll over the {{Extension}} box on Extension:Campaigns I see a jigsaw icon which brings up a template editor, but it's blank.

S Page (WMF) (talk)01:21, 11 June 2013

When I click in that template I don't see any icon until I change the zoom from 100% to e.g. 90% or 110% (and if I keep the new zoom, click outside the template, and then click on the template again, the icon is not shown either - I need to change it again to see the icon, even changing it to 100% is enough).

On the other hand, if I go to https://www.mediawiki.org/wiki/Extension:Campaigns?debug=1 and click in the content from section "Installation" (generated by Template:ExtensionInstall), I get the following error in the console (on Google Chrome 27.0.1453.110): Uncaught Error: No focused node to edit (from ve.ui.MWTemplateDialog.js).

Helder12:36, 12 June 2013

Yeah, this is a pair of selection bugs we're working on; sorry about this. :-( Hope to get them fixed very soon.

Jdforrester (WMF) (talk)16:36, 12 June 2013
 
 

bug 49904 not on roadmap

Bug 49904 is not on the roadmap. To me, the lack of subst: support is often a blocker for me.

Martijn Hoekstra (talk)18:43, 8 August 2014

I think the right question there, is what is it in your workflow that requires subst ? And for what reasons is that subst'ing then being applied in this workflow ?

TheDJ (talk)17:44, 11 August 2014

Mostly speedy deletion patrol on en.wiki. I often replace speedy deletion requests with PRODs which must be subst:ed (for a reason I'm not 100% sure of). I'm not sure why this is the right question. Is subst:'ing templates deprecated or discouraged?

Martijn Hoekstra (talk)10:00, 14 August 2014

Because VE is not wikitext and subst is an extreme form of wikitext. If there is something you need, then the developers want to understand why you need it. In certain cases, an alternative solution might be sought.

For instance, I can imagine that in this case that they would reimplement some of the annotations for templates, or even for subst itself, to make sure that something like this just happens automatically. In other cases, perhaps an editor is just looking for 'action favorites' or something which. They are not trying to reimplement wikitext, they are building an editor that supports what you need to do and that is backwards compatible with wikitext syntax.

Looking specifically at PROD, it indeed seems to be implemented as a templated action for a set of templates, that insert current information (and thus need to be replaced).

TheDJ (talk)10:30, 14 August 2014

This line of reasoning still somewhat troubles me. I don't need much convinving that Wikitext is a heaping pile of terrible, or that this is difficult, and, frankly, just wrong. In my mental model a template substitution is similar to a macro application (and happens at "save-time"/"compile time") where a transclusion is similar to a function application (and happens at "display-time"/"run time"). In the VE model "display time" comes before "save time", while in the wikitext model the situation is reversed. I understand that brings challenges with it as the available context is different. I truely understand the brokenness of being able to detect during parsing (which happens at save time in case of template substitution) to detect if you're in a "save time" context or a "display time" context and adjust output accordingly. I feel your pain when I have to think about unsubst, and deciding at "save time" you're not going to do the substitution and just return the wikitext, including the brackets. This is all crap.

When I think about implementations I feel your pain even more; when following the wikitext model, this would mean that the content is substituted as soon as it is entered, but from a usability perspective this is terrible, as there is no way to go back and change the substitution afterwards if you just insert the VE model of the parsed template (if that is even possible, node fragments ftl) - parsed in "save time mode" - right into the VE model being edited. (While I acknowledge the terrible, I could live with this as a first stab at it by the way).

But template substitution is a fairly often used feature - and if it is used fairly often, there are valid use-cases for it. At an intellectual level I understand the desire to know why it is wanted, and what those use cases are, but the bottom line is that you can bet on it there are such use cases, even if you don't yet know them, and they'll just need to get implemented, no matter how much they suck on a technical level. It also means that knowing and understanding the use case won't influence the implementation.

I realise my earlier response was curt, and this response still has some irk in it. The reason for this is that - although I haven't edited much over the past months - I think I'm one of the few people on en.wp who tries to do everything with VE primarily, first of because it can be an amazing product (it is when it works, which is most of the time), and secondly because when I'm doing admin tasks I run across a larger part of the long tail of features than most other tasks, and I can provide the team with feedback on what is working for me and what isn't. A response that I interpreted as "well, we'll be the judge if we find the work you're doing now in wikitext valuable enough to carry over to VE", while at the same time aiming to ultimately completely replace wikitext (again, the latter is a good thing). For me, that doesn't really feel inviting to keep providing that feedback. I hope you can see this perspective as well.

Martijn Hoekstra (talk)09:16, 25 August 2014

I am not aware of an ultimate goal of replacing entirely wikitext with visual editing.

Nnemo (talk)14:16, 21 October 2014
 
 
 
 

User:Martijn Hoekstra, thanks for this note. This may be fixed this Thursday (appearing at the Wikipedias the following Thursday).

Whatamidoing (WMF) (talk)22:00, 18 August 2014

User:Martijn Hoekstra, subst'ing templates is working now.

While I'm happy to have you using VisualEditor (and telling me when you encounter problems!), have you considered using Twinkle for this work? It might save you a little time.

Whatamidoing (WMF) (talk)23:29, 2 September 2014

Thanks, that's great to hear! The problem with Twinkle for this is that I like to notify the tagger personally, and twinkle is a little peculiar with edit summaries when replacing CSD with PROD

Martijn Hoekstra (talk)16:24, 3 September 2014
 
 
 

Adding a link to an image caption

I seem to be unable to easily add a wikilink to an image caption using VisualEditor. When I open the "Media settings" window to edit the caption, I can click the "Link" button to add a link, but then the program doesn't seem to think I've actually made any changes to the caption, because it won't let me click the "Apply changes" button. Am I doing something wrong, or is this a bug?

Mr. Granger (talk)18:55, 11 October 2014

User:Mr. Granger, what's your OS and web browser? Is this still a problem today? (There's been a software update since your message was posted.)

Whatamidoing (WMF) (talk)00:21, 17 October 2014

Yep, it's still happening. I'm using Mac OS X 10.9.5, and the problem occurs in both Firefox and Safari.

Mr. Granger (talk)01:18, 17 October 2014

User:Mr. Granger, thank you. This is now tracked as bug 71065. It's on the list for the next round of work, and it's assigned to Moriel, who is awesome, so I think you can expect that to get fixed soon (plus the usual two weeks for new code to reach the Wikipedias).

In the meantime, it appears that the temporary workaround is to make some other change in the caption.

Whatamidoing (WMF) (talk)17:37, 23 October 2014
 
 
 

Extreme lag in updating link suggestions

New articles seem to take forever to get on the suggested links list. I created an article last night and it is still redlinked in the suggestion list now, 6 or seven hours later

SpinningSpark08:56, 22 October 2014

VisualEditor can only supply what (old) Search gives it (at en.wp).

Whatamidoing (WMF) (talk)16:20, 23 October 2014
 

Special characters

Here's another thread about the special character inserter; the other one has gotten kind of long. Some questions to consider:

  • Do you normally use a character inserter? The one in your computer, or the one in the Wikipedia/MediaWiki editor?
  • Which character sets are useful to you? Should it include all 18 of the character sets provided in the wikitext editor's newer toolbar at the English Wikipedia, the 10 present in the older editor toolbar, or some other combination of character sets?
  • How many special characters would you like to see at one time?
    • Should there be a "priority" or "favorites" section for the 10 or 12 characters that most editors need most often? Is it okay if you need an extra click to go beyond the limited priority set?
    • How should the sections be split up? Should they be nested? Ordered?
    • How should the sections be navigated? Should there be a drop-down? A nested menu?
  • The wikitext editor has never included many symbols and characters, like ℗ and ♀. Do you find that you need these missing characters? If the character inserter in VisualEditor includes hundreds or thousands of special characters, will it be overwhelming? How will you find the character you want? What should be done for users without enough space to display more than a few dozen characters?
  • Should the character inserter be statically available until dismissed? Should it hover near the mouse? Should it go away on every selection or 10 seconds after a selection with no subsequent ones?
  • Some people believe that the toolbar already has too many options—how would you simplify it?
Whatamidoing (WMF) (talk)00:00, 18 February 2014
  • Change the "<" to an "X" - I would change the current "<" button to an "X" and move it to the top right. The "<" doesn't make sense as it's not inherently attached to any sidebar, so the arrow points at nothing in particular. This is also a problem I have with the Gallery dialog.
  • Moving the dialog like a window - The dialog should be movable by the user as though it was a separate window (e.g. grab the header and drag it elsewhere in the browser.), rather than attached to the location of your cursor in the edit window.
    • To add on to this, I think all of the Insert dialogs should have this functionality, I oftentimes want to look at the picture I'm captioning in the gallery or the text which is located nearby it. However, I can't do this without closing the dialog and then opening it back up again.
  • The dialog is too vertically lengthy - Limit the height of the dialog box vertically and add a scroll bar. The entire box should be visible when it's first opened. Currently, the bar is very long and can go all the way to the bottom of the article in some cases.
  • Change the sections into tabs - It shouldn't look like Wikipedia's section headers, it should be a tabbed interface a la a browser. This would also help with the aforementioned height of the dialog.
  • Add a search bar to the dialog - I'm not sure how this would be done from a technological perspective, but I would assume it's possible to add "tags" of some sort to each symbol. For example, á and other variations of "a" or "A" with accents would be tagged with "A". This way, you can search for a letter (e.g. "a", "c", "e", "i", etc.) and it will bring up all variations of that letter. For symbols with actual titles, like the tilde (~), these would be tagged with their actual name. The tags wouldn't be visible to the user, they'd simply allow symbols to be searched more easily. This would be especially useful if a large amount of symbols were added to the dialog.
  • Organize the buttons into a proper, aligned grid - Currently, the horizontal width of each button containing a symbol differs greatly. This makes it a lot harder to search through, as your eye randomly skims through the unorganized list of symbols. Preferably, every symbol would be contained inside a button with the same horizontal size, all lined up similarly for ease of navigation for editors.

Hopefully these are helpful, I look forward to future progress!

Nicereddy (talk)01:09, 18 February 2014

Thanks for this, it's really helpful – some replies.

Change the "<" to an "X"

As you say, this is a consistent design for all inspectors; I agree that it's worth looking at this again.

Moving the dialog like a window

This is quite a lot of work (and yes, if we wrote this functionality it would also be something we build for all inspectors and dialogs). Would this be more valuable than (say) TheDJ's suggestion of it appearing as a hovering block at the bottom of the window (in the same way but the opposite end of the view to the toolbar)?

The dialog is too vertically lengthy

We can very easily make it only sized to the window (maybe with a minimum height, like we do for dialogs). Should the page scroll down so that you get to see enough of the dialog, too? Right now we don't do this for inspectors, but it might make them a bit easier to use when your cursor is at the bottom of the page.

Change the sections into tabs

The problem here is that the sections are defined by local communities; what would we do if there were 10 sections? 20? 50?

Add a search bar to the dialog

This could turn what should be a quite simple and quick to use interface into something that's very "heavy", and I think it'd only be useful for a minority of characters, and only to some users who already know that they're looking for an "a"-related character (for example, would you expect "α", "א", "æ" and "ɐ" to show up when you typed in "a"?). Would it be better if we had some way of organising the characters so that all the As were clustered together in each section, like was suggested here?

Organize the buttons into a proper, aligned grid

This could be very helpful, yes – I'd note that the WikiEditor's special character panel uses this approach, to its credit. Do you think that we should hard-code a maximum width and show buttons with labels centred regardless of their actual width, or should the width of the buttons on screen alter as the widest character currently shown gets wider or narrower? I think the first option is probably better, but it's not a great choice to need to make. Note that users' browsers/system/font selection (amongst other issues) can make it unpredictable how wide this will be (and indeed which character is widest), which may be a little confusing.

Jdforrester (WMF) (talk)22:03, 21 February 2014

Thanks for replying!

Would this be more valuable than (say) TheDJ's suggestion of it appearing as a hovering block at the bottom of the window

I would definitely prefer the hovering block to its current state, especially if it had a minimize feature that saved its contents but kept it in a "dock"-esque footer-bar. Though, generally I do believe the ability to control it myself would be preferable over having it locked in anywhere, but if it's too much work that's perfectly understandable.

Should the page scroll down so that you get to see enough of the dialog, too?

I don't think it should. Most users probably wouldn't want the editor to move their viewing space without consent or warning, and this would probably make for a bad user experience.

I believe you're referring to the fact that if the user were to be selecting text in (for example) the bottom 200 pixels of the screen, the inspector wouldn't have enough room to open and part of it would be cut off? If I'm misunderstanding please correct me, but the "right-click" dialog already handles this problem quite well. When you right-click near the top of the screen the menu opens downward, but if you right-click near the bottom it opens upwards in order to fit itself into the given area. Making it dynamically able to open above/below the cursor would likely be preferable. Of course, the dock functionality mentioned above would fix this if implemented, and make this issue essentially irrelevant.

what would we do if there were 10 sections? 20? 50?

This kind of contradicts your next point (with regards to the search box) about it being a quick-to-use dialog. If it's capable of reaching 20+ sections, there's probably something wrong with the dialog or its purpose. That would mean hundreds of potential choices in the dialog and there's no good way of organizing that (without a search box ;) ). Currently, it's so large it's cumbersome to look through and my eyes don't scan through it in any real order because it's so condensed. These problems may be fixed by the improved grid but, assuming they aren't, perhaps we could settle at both tabs and sections? Max it to a reasonable number of tabs, e.g. 6, and then allow sections to serve as subheaders for each tab.

Either way, I think collapsible sections will be necessary if you want the dialog to be reasonably usable.

This could turn what should be a quite simple and quick to use interface into something that's very "heavy", and I think it'd only be useful for a minority of characters, and only to some users who already know that they're looking for an "a"-related character (for example, would you expect "α", "א", "æ" and "ɐ" to show up when you typed in "a"?).

With regards to its simplicity and speed, I think this would make it more complicated at the back-end, but the user-facing interface would be much quicker and easier to find exactly what you're looking for. The simplicity may be complicated a bit by a search bar, but we're talking about a huge, difficult-to-organize list of characters. I wouldn't imagine most users would immediately think "simple" upon viewing it.

And while I can understand that users may not understand the features of the search bar immediately, a simple tutorial or note would make it evident and understandable reasonably quickly.

Would it be better if we had some way of organizing the characters so that all the As were clustered together in each section

This would definitely be a good way of organizing it, but again I feel like everything would just be smoother with the Search dialog.

Do you think that we should hard-code a maximum width and show buttons with labels centred regardless of their actual width

I think the approach which uses a maximum size for each panel in the grid is preferable, especially since issues could come up if there was, for whatever reason, a character which was especially long or tall. That character would cause all of the buttons to become that same size and create a really odd-looking interface, especially if the buttons weren't squares.

Note that users' browsers/system/font selection (amongst other issues) can make it unpredictable how wide this will be (and indeed which character is widest), which may be a little confusing.

I may be completely wrong here, but is it not possible to override the user's font selection for this specific dialog? That way all users would see the same size/type of font in the Special Characters window? Obviously not the best way of solving the issue, assuming it's even possible, but its the only I could think of.

Cheers,

Nicereddy (talk)06:24, 23 February 2014
 
 
Edited by another user.
Last edit: 15:52, 11 September 2014

Do you normally use a character inserter? The one in your computer, or the one in the Wikipedia/MediaWiki editor?

Yep. I'd normally use Extension:CharInsert gadget first as its most convenient, I like the way it has a <select> drop down as I can quickly go to the set of chars I want and does not take much screen space. I find then the wikitext character inserter has a bit too much scrolling involved and is greedy in screen space. If neither of the two has the character i want I'll use my Mac's Character Viewer, I've done some work on the unicode pages and sometimes need exotic symbols.

Which character sets are useful to you? Should it include all 18 of the character sets provided in the wikitext editor's newer toolbar at the English Wikipedia, the 10 present in the older editor toolbar, or some other combination of character sets?

I tend to use the maths symbols and greek letters. For maths articles I need a more extensive range of maths symbols than is provided by VE. The set provided by CharInsert has most things I'm likely to use: − × ÷ ⋅ ° ∗ ∘ ± ∓ ≤ ≥ ≠ ≡ ≅ ≜ ≝ ≐ ≃ ≈ ⊕ ⊗ ⇐ ⇔ ⇒ ∞ ← ↔ → ≪ ≫ ∝ √ ∤ ≀ ◅ ▻ ⋉ ⋊ ⋈ ∴ ∵ ↦ ¬ ∧ ∨ ⊻ ∀ ∃ ∈ ∉ ∋ ⊆ ⊈ ⊊ ⊂ ⊄ ⊇ ⊉ ⊋ ⊃ ⊅ ∪ ∩ ∑ ∏ ∐ ′ ∫ ∬ ∭ ∮ ∇ ∂ ∆ ∅ ℂ ℍ ℕ ℙ ℚ ℝ ℤ ℵ ⌊ ⌋ ⌈ ⌉ ⊤ ⊥ ⊢ ⊣ ⊧ □ ∠ ⟨ ⟩ {{frac}} &nbsp; &minus; <math></math> {{math}}. I need all the upper and lower case greek letters. I normally only edit in English so fancy accent characters are of little use to me.

How should the sections be navigated? Should there be a drop-down? A nested menu?

The way Extension:CharInsert works on en wikipedia is about ideal,

Extension-CharInsert.png

A simple drop-down and a set of characters, a minimum of styling, surrounding boxes or buttons are just distractions. This gives a high density of characters using minimal screen space.

How many special characters would you like to see at one time?

Lots, probably 70 at a time, I need all upper and lower case greek letters. Not bothered by accents on them.

Should there be a "priority" or "favorites" section for the 10 or 12 characters.

Possibly, would I need to set this up?

The wikitext editor has never included many symbols and characters, like ℗ and ♀. Do you find that you need these missing characters?

Sometimes, if it very exotic I may use the unicode escape sequence &#x24C5; to give Ⓟ
Different users are likely to want very different ranges of characters, how about making it possible to add a particular unicode block to the set of possible sets. Say for example I want to add a page about a Russian mathematician like [[en:Vladimir Arnold]]. Then I want to add Cyrillic script. Even on en.wikipedia I guess some users will want most scripts for adding native names.
Salix alba (talk)08:07, 18 February 2014

Thanks! Some replies and queries in-line:

I find then the wikitext character inserter has a bit too much scrolling involved and is greedy in screen space.

Yeah, this was something we were particularly keen to avoid repeating, though I feel we've yet to find a design that is better and yet meets the other requirements.

Should there be a "priority" or "favorites" section for the 10 or 12 characters.
Possibly, would I need to set this up?

I was imagining a "commonly-used" section that the tool defaults to displaying, rather than a per-user set of favourites (though if there's demand for it we could do the latter too, at some point).

Sometimes, if it very exotic I may use the unicode escape sequence Ⓟ to give Ⓟ

Unicode currently has over 100,000 characters defined; I think trying to have a tool that displays even "most" of them is probably unnecessary. Maybe an advanced button that can insert a character by Unicode code (so, in your case, you'd enter "24C5")?

Jdforrester (WMF) (talk)22:12, 21 February 2014
I was imagining a "commonly-used" section that the tool defaults to displaying, rather than a per-user set of favourites (though if there's demand for it we could do the latter too, at some point).

I would think most editors will request a personalized favorites section, as different editors may prioritize specific characters over others. An editor who primarily edits pages about math would likely want different "favorites" than someone interested in famous Spaniards or Russians.

Nicereddy (talk)06:27, 23 February 2014
 
 
  • The most basic set é ü etc i do straight from the keyboard.
  • The more complex but oft used chars, I do from MediaWiki:Edittools (JS version of en.wp)
  • I NEVER use the Special characters drop down in WikiEditor. (I think we should do some analytics gathering on that usage there btw)
  • Since Mac OS 10.9 I use the OS version, because: It has a helpful keyboard shortcut that works OS wide now. Very nice categories, search and variants.
  • Ideally, it should have like 6 categories of chars that you might often use on that wiki and ability to lookup and add other categories to your profile.
  • Per category I would expect max 25 chars, multiline
  • I would expect a fixed positioned footer (in view, consistently accessible, but out of the way) or a dock able floating panel or something the like.
  • I would expect it to be available until dismissed. Auto disappearing is nice in theory, but dismissing after 2 secs is too quick for multiple actions and dismissing after 10 secs would probably be too 'unexpected' for users.
TheDJ (talk)10:47, 20 February 2014

Thanks.

I NEVER use the Special characters drop down in WikiEditor.

We've heard that from a number of people, which confirms our suspicions that EditTools (which was meant to be switched off when the WikiEditor special character inserter was rolled out, but never got axed) serves the needs of most users, particularly in terms of quick-and-easy UX.

(I think we should do some analytics gathering on that usage there btw)

Hmm, yeah; patches welcome. ;-)

Since Mac OS 10.9 I use the OS version, because: It has a helpful keyboard shortcut that works OS wide now. Very nice categories, search and variants. … Ideally, it should have like 6 categories of chars that you might often use on that wiki and ability to lookup and add other categories to your profile. … Per category I would expect max 25 chars, multiline

Mac OS X's native character inserter has 11 top-level categories, and yet misses a bunch of characters insertable in WikiEditor – IPA, Cyrillic, Arabic, Hebrew, … – and the "arrows" category has (at rough count) 300 characters alone. I don't think we'd want all of these, but drawing the line at 25 might be hard. :-) There are 20 variants of "A" in the Latin group, and another 27 of "A" in the Latin extended group, for example.

I would expect a fixed positioned footer (in view, consistently accessible, but out of the way) or a dock able floating panel or something the like. I would expect it to be available until dismissed. Auto disappearing is nice in theory, but dismissing after 2 secs is too quick for multiple actions and dismissing after 10 secs would probably be too 'unexpected' for users.

Perhaps a pop-out panel that disappears on each use, or can dock down to the bottom of the page to be persistent?

Jdforrester (WMF) (talk)02:16, 22 February 2014

disappearing after each use, prevents you from inserting multiple characters in sequence (not that i personally use that feature, but some folks do)

TheDJ (talk)02:55, 25 February 2014
 

James, you need to play more with the character palette of Mac OS X.

In my Mac OS X character palette, I have dozens of top-level categories of characters. One of them is phonetic alphabet, there are also cyrillic, arabic, hebrew…

Nnemo (talk)15:54, 1 June 2014

Perhaps I need to upgrade to the latest OS. I've been unable to find these characters in the character palette (which are combinations; all the pieces are there, but not the assembled units):

k̚ t̪ d̪ s̺ s̻ θ̼ s̬ n̥ ŋ̊ a̤ a̰ β̞ r̝ e̘ e̙ u̟ i̠ ɪ̈ e̽ ɔ̹ ɔ̜ n̩ ə̆ ə̯ ə̃ ȷ̃ z̴ ə̋ ə́ ə̄ ə̀ ə̏ ə̌ ə̂ ə᷄ ə᷅ ə᷇ ə᷆ ə᷈ ə᷉ t͡ʃ d͡ʒ t͜ɬ k͈ s͎


and I have only ten top-level palettes: Arrows, Parentheses, Punctuation, Currency Symbols, Pictographs, Bullets/Stars, Math Symbols, Letterlike Symbols, Emoji, and Latin.

Whatamidoing (WMF) (talk)17:59, 2 June 2014

…Or you need to play with the System Prefs. Even on my good old Snow Leopard, I have many exotic categories in my Character Palette.

Nnemo (talk)15:11, 5 June 2014
 
 

There is a keyboard equivalent for the Character Palette of Mac OS X now ? What is it ? I am egoistically interested. :-)

Nnemo (talk)16:15, 21 October 2014

Nnemo, If I'm thinking of the right thing, it's only for common Latin letters. Press and hold the letter 'a' for about two seconds, and see if a little menu with eight variations on 'a' appears. It only seems to work on "common" letters. I get nothing by holding down 'k', for example.

It works in 10.8, but I don't know if it works in 10.6 or 10.7.

Whatamidoing (WMF) (talk)22:04, 21 October 2014

Ah if it's this feature, I know it. I turned it off because I prefer the repeatttttttttttt (there is a trick to turn the feature off). This feature came after Mac OS X 10.6, it is one of those imports from iOS. Thank you anyway, but James seems to be speaking about something else.

Nnemo (talk)13:50, 23 October 2014
 
 
 
 

you should do this in categories, like all types of a=á,å,â,... similar for phonetics etc. and include keyboard shortcuts, so when a is pressed in editor all sounds and forms of a are present. for math simbols you could include short words that indicate symbols like 3(Dot)5 or something like LaTeX or similar. I don't think the tool would be very useful otherwise, because it takes way too much time looking for characters.

93.103.171.2916:56, 20 February 2014

Thanks. I was not referring to character input though, it was a more general question of how to extend the functionality of the VisualEditor. In my specific case this would be a custom popup dialog (action: dialog) that inserts a link to a picture recently uploaded by the editing user.

Simulo (talk)09:54, 21 February 2014
I was not referring to character input though, it was a more general question

I think the user was responding to the general request for input on the character input tool, rather than your question, and just responded on the wrong thread; I've moved it here instead.

In my specific case this would be a custom popup dialog (action: dialog) that inserts a link to a picture recently uploaded by the editing user.

Interesting! It was suggested in bug 60398 that we do this in VisualEditor itself, and there's a work in progress commit to do this which you might be interested in.

Jdforrester (WMF) (talk)02:22, 22 February 2014
 
 

Thank you for inviting me here. Indeed the tool "special characters" is very important. I am very content, how it works with the conventional source editor (as I admire wikipedia technology in general, just to let you know that criticism here is on a very high level), but the tool in the beta editor, as it is now, is useless for me.

1) The box should not be fixed within the text (better with the toolbar), otherwise I have to open and to close it again. I just opened it and then the box was hiding the word, which I wanted to correct.

2) The design is nice, but it has not the characters I need (even for IPA this is not enough, not even for the vowels, and where are the consonants and semivowels?).

3) If I tell you precisely which characters I need, you will never satisfy the users. Users should choose between different languages, let's say between Cyrillic or even Glagolitic for those who work with Slavic sources, and polytonic Greek, or phonetic alphabet. The current choice for everybody is not useful, because the Latin alphabet does not often need diacritics. You need some for Spanish, others for Slavic languages who do not longer use Cyrillic (Polish needs ł,Ł,ą,ę,ó,ś,ń,ź,ć, and ż; Czech Š,š,Č,č,Ž,ž etc.), while other would like transcribe the Arabic or Persian alphabet. I advice to compose certain choices which are adapt to different user profiles. Please don't hesitate to ask questions.

Platonykiss (talk)19:08, 6 March 2014

Platonykiss, thanks for your thoughts. Real use cases are what James is looking for, so "I need ALL the characters!" or "I don't need any of them" are both useful information for him :) This said, wikis can already change those sets locally in the meantime if they urgently need something that is missing.

Elitre (WMF) (talk)13:23, 11 March 2014
 

“the Latin alphabet does not often need diacritics”

Platonykiss, I bet that you are not a native francophone.

Nnemo (talk)16:00, 1 June 2014

Though I am regularly in France, I am not a fan of the French keyboard. I do not need it to have all characters I need to write in this language, or to say it in a way useful for you, I do not need your tool at all to write in those languages. This is probably not an anglophone perspective to it, I suppose... ;D

Platonykiss (talk)11:00, 17 August 2014
 
 
 

VE help menu in ruWP

In ruWP use page "report an error in the article". VE panel has a menu "help" (?) -> Leave feedback. Anonymous user often confused and leave error message on the page "Leave feedback". Whether it is possible locally in ruWP add a new menu item "(?) -> report an error in the article" under the item "(?) -> Leave feedback about VE"?

Sunpriat (talk)13:48, 22 October 2014

Can't desactivate the VisualEditor

Hello, I come from the Spanish Wikipedia, and I do not really like the function of the visual editor, sometimes I'm wrong and when I pressed the button to press to edit code.

I tried to turn it off through preferences but not disabled and if I try to disable other beta function is deactivated correctly

as I can disable it?

And sorry for my bad English, I'm using google translator.

Feefre (talk)21:31, 31 May 2014

Hello User:Feefre. All you need to do is removing the flag near "Editor visual" here, then click on the Guardar button. After this, you'll only see one Editar tab which provides access to the wikicode editor. If this still doesn't work for you, please let us know which browser, skin and operating system you're using. Thank you.

Elitre (WMF) (talk)15:46, 2 June 2014

I've the same. I use Win 7 x64. This is because the option "Automatisch alle neuen Beta-Funktionen aktivieren" - "Automatic all Beta-features activated" is on. This is a bug.

Perhelion (talk)09:13, 7 June 2014

This is not a bug; it is acting as intended. The checkbox you have chosen causes all Beta Features, including VisualEditor, to be enabled for you every time you check your preferences. If you don't want all Beta Features to be loaded, uncheck this box.

Jdforrester (WMF) (talk)20:45, 9 June 2014

This box being enabled by default may be considered a bug. I consider that enabling beta features by default is a bug.

Nnemo (talk)16:26, 21 October 2014

It isn't checked by default.

Elitre (WMF) (talk)16:29, 21 October 2014
 
 
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page