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
bug 49904 not on roadmap422:00, 18 August 2014
Dialog box still hides content321:54, 18 August 2014
;caption221:44, 18 August 2014
VE freeze in Chrome when switching to code editor221:41, 18 August 2014
Deactivated all Beta features110:51, 18 August 2014
Special characters2011:00, 17 August 2014
inserts "nowiki", why?121:43, 9 August 2014
captcha not displayed properly117:38, 31 July 2014
Feedback from editathon events regarding citations121:45, 21 July 2014
Special version of VE on tablets014:32, 21 July 2014
VisusalEditor in Ukrainian209:58, 21 July 2014
Useless error message411:47, 20 July 2014
Nowiki tag200:55, 10 July 2014
Unable to add my signature via VisualEditor419:11, 3 July 2014
Why are text styles hidden in a drop down?422:16, 28 June 2014
Clearing formatting and links004:51, 25 June 2014
Disambiguation detector308:15, 15 June 2014
Visual Editor has no Save/Cancel Button118:21, 13 June 2014
German quotation marks208:56, 11 June 2014
Can't desactivate the VisualEditor320:45, 9 June 2014
First page
First page
Previous page
Previous page
Last page
Last page

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
 
 

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
 

Dialog box still hides content

In response to the pleas just published I thought I'd give VE another shot, having trialled it a lot in earlier days and given up in sheer exasperation at its inadequacy. Sadly, there's no progress on one of my main complaints, probably my major problem with VE: the dialog box hides the content of the article. So if I'm adding a categoroy or a stub template I need to have memorised all the relevant details from the article before calling up the dialog box. I can't shift the box, or shrink it, so that I can read the article: it just hides it. I might persevere for a while, as the developers seem desperate for feedback, but for me this is the killer problem: it's just not fit for purpose.

PamD (talk)21:30, 8 August 2014

Is that bugzilla:49969?

Helder23:47, 14 August 2014

Yes, it's the bug from last year, and I've got the message: devs aren't interested in helping editors like me. I'll do a bit more testing of your VE, but at present it's pretty useless for me.

PamD (talk)18:56, 18 August 2014
 

At the moment, it looks like progress is stalled because VisualEditor's windows are created via OOjs UI WindowManager, and OOjs UI WindowManager doesn't understand the idea of re-sizing.

The story as it reached me is this: The design team has to expand OOjs UI WindowManager (major effort) followed by the editing team implementing the changes (moderate effort), and then we will have what we need. Immediate problem: I don't think that anything about OOjs UI WindowManager is anywhere on the design teams' goals for this fiscal year.

Whatamidoing (WMF) (talk)21:54, 18 August 2014
 
 

It seems that VE gives erroneous behaviour with captions beginning with ; at the beginning of a line. It doesn't display ;captions any differently from normal text, and when one hits enter, a new line of caption style is created but there's no telling until I've saved page and bold text appeared.

See this edit: [1]

Deryck C.Meta21:31, 14 August 2014

Reported as bugzilla:69689

TheDJ (talk)10:59, 18 August 2014
 

Support for association lists (aka definition lists, aka what we abuse to get lines of bold-faced text) is bug 37938. Unfortunately, I don't expect to see this fully resolved this year.

Whatamidoing (WMF) (talk)21:44, 18 August 2014
 

VE freeze in Chrome when switching to code editor

After editing https://fr.wikipedia.org/wiki/Adaptation_humaine_%C3%A0_la_haute_altitude for a while, I needed to switch to code, said that I would keep my changes and nothing happened except the page became grayed and froze. Clicked the green Save button but nothing. I can see my text but cannot select/copy it. Is it lost ???

in case it helps, here is what I see in the Chrome Console

JQMIGRATE: Logging is active load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:150 mediawiki.jqueryMsg: helppage: Unknown operation "ns" load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164 console.trace() load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164

(repeated many times)

mw.log.log.warn load.php?debug=false&lang=fr&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20140814T1…:164 'Range.detach' is now a no-op, as per DOM (http://dom.spec.whatwg.org/#dom-range-detach). Discontiguous selection is not supported. Adaptation_humaine_%C3%A0_la_haute_altitude:1 Uncaught TypeError: undefined is not a function Adaptation_humaine_%C3%A0_la_haute_altitude:502 84 Uncaught TypeError: Cannot read property 'getInternalList' of null Adaptation_humaine_%C3%A0_la_haute_altitude:79 Uncaught TypeError: undefined is not a function Adaptation_humaine_%C3%A0_la_haute_altitude:435 12 Uncaught TypeError: Cannot read property 'getInternalList' of null Adaptation_humaine_%C3%A0_la_haute_altitude:79 Uncaught TypeError: undefined is not a function

Goulu (talk)20:16, 16 August 2014

This looks like there are a lot of broken scripts in use on French Wikipedia, or perhaps by your user account. That will bring any piece of software to it's knees. You might want to ask a local user that has knowledge of Javascript if he can assist you to clean that up, you should have a lot fewer errors with any of the tools (especially those as complex as VE), if you have no JS errors from other software.

TheDJ (talk)10:56, 18 August 2014
 

User:Goulu, thanks for this report. I was able to switch to the text editor in Safari on that article just now. Do you have any large or unusual gadgets or preferences set for your account? Would you mind logging out (or opening a 'private browsing' window) and trying it again?

Whatamidoing (WMF) (talk)21:41, 18 August 2014
 

Deactivated all Beta features

Today I deactivated all Beta features. First: the talk-pages are only in English. I don't know whether I could only post feedback in English or in other languages and I know, many people don't give feedback at all because of this. (And the feature page for VE is even worse than the other ones) Second: I will not test any software from the WMF, until the Feoundation keeps the superprotect right, which is a thread to all communities.

Don-kun (talk)11:14, 17 August 2014

Feedback is welcome in any language, there are usually people willing to translate (and google helps a lot). Practically, the language du jour (ha, see what I did there ?) is English however. There is simply not enough capacity to translate everything into all languages and process the information that way.

Regarding superprotect. Well, I blame the WMF for getting us to a point where it's usage was required, i blame the community for pushing WMF into exercising it...

TheDJ (talk)10:51, 18 August 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
 
 

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. 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
 
 
 
 

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
 
 
 

inserts "nowiki", why?

The VisualEditor inserts "nowiki" into text at meaningless places, where it is unnecessary. Please correct this.

Misibacsi (talk)20:51, 9 August 2014

Hi there, can you please provide examples? There might be several different reasons for that, including user's mistake (ignoring wikitext warning, for example). Thanks,

Elitre (WMF) (talk)21:43, 9 August 2014
 

captcha not displayed properly

while saving changes in visual editor it asks for captcha, but the text field is not displayed only the captha image is displayed

Tejesh.alimilli (talk)07:08, 31 July 2014

Hi Tejesh.alimilli, please scroll down in that dialog to enter the code. Best,

Elitre (WMF) (talk)17:38, 31 July 2014
 

Feedback from editathon events regarding citations

Hello VE Team,

Here's some general feedback for you based on having attended a bunch of editathons and editing events.

From my perspective at editathons, VE would be ready to go as the new editor default if we just had the citation thing figured out enough to use the ISBN autofill.

The big block to getting new people to become a productive editor capable of creating content is adding the citations.

I've been finding that getting new editors to put in a full reference to a reliable source can be a really tough sell when working with people who aren't grad students / journalists (or the equivalent).

You can get newbies to add a fact with no problem. Sometimes you can get newbies to add a web link in the inline text at the end of their fact in parentheses, but they can also resist this because they don't like the way the bare link looks. The new editors who aren't very computer literate sometimes choke up a bit when it's time to fill in the citation form with the existing VE or from the source code editing box.

One thing to experiment with for low edit-count (maybe first 10-20 edits) editors could be a pop-up screen with checkboxes after completing their edit: "This information is based on existing sources already cited in the article" / "This information comes from new sources which do not appear in the article yet". If it's a new reference, you then offer them the options of adding a web link, an ISBN, or typing name of the source.

Alternatively, the pop-up screen could be used to direct them to the citation tool.

People at editathons will type data into infoboxes in wikicode just fine. But for whatever reason-- perhaps because the whole idea of citing reliable sources doesn't make much sense to them-- citations really slow a lot of new editors down.

Despite availability of VE, one of my primary activities at editathons turns out to be coding in lists of citations of source material for other editors, using Zotero with the ISBN autofill. The quick ISBN feature is really key (though I find I need to tweak a bit to add co-authors or authorlinks).

Conclusion:

In short, add in the ISBN autofill for citations and I'd say VE is ready to go for new editors. A popup window for the first few edits reminding about the importance of sources would help.

Add the NYT and Google citation generators to VE, and content creation might really improve!

You might also experiment calling the two tabs for VE and wikicode something like "Edit this article" and "Editing - Advanced."

Best regards,

Kristin

Djembayz (talk)17:48, 20 July 2014

Thanks for this note, Kristin. Have you looked at the Citoid tool, which is being written now? Marielle Volz is starting with URLs, but ISBNs are planned. I've tested the tool recently, and even though it's in the very early stages, I'm pretty happy with its overall direction. There's a lot of backend work that needs to happen before it can be widely used, but we might see some progress on ISBNs in the next month or so.

Whatamidoing (WMF) (talk)21:45, 21 July 2014
 

Special version of VE on tablets

Thanks for your feedback on the special version of VE which will be available on tablets on July 31st. You can test the new tool by choosing the beta version of the mobile view in the Settings menu.

66.249.81.41 using text from tech news, creating placeholder for future feedback.14:32, 21 July 2014

VisusalEditor in Ukrainian

A menu item of VisusalEditor in Ukrainian Wikipedia has been changed by mistake. Now we have instead of the correct menu item Редагувати код (Edit code) the absolutely incorrect Править викитекст. It's not even in Ukrainian.

MelVic (talk)00:30, 12 July 2014

This looks to be a bug – https://uk.wikipedia.org/wiki/MediaWiki:Visualeditor-ca-editsource shows the correct label here.

I think this is https://bugzilla.wikimedia.org/show_bug.cgi?id=67805 which is affecting the Italian Wikipedia too. Have bumped that bug.

Jdforrester (WMF) (talk)00:46, 12 July 2014

Hey User:MelVic, can you confirm the bug is gone now at your wiki? Thank you.

Elitre (WMF) (talk)09:58, 21 July 2014
 
 

Useless error message

While trying to fix the numbered list on Help:Templates#CSS and JavaScript code VE gives me a useless error message that prevents me from saving my edit.

http://i.imgur.com/REZwwrG.png

124.181.193.14503:40, 18 July 2014

That error message is caused by the Translate extension, which has some severe difficulties working with VE. When you clicked edit there would have been a notice saying that things might break, and unfortunately this is one of them. :-(

Jdforrester (WMF) (talk)21:01, 18 July 2014

It's not the fact that the extension prevented my edit that's a problem, it's the fact that the error message is completely useless and might as well not be there at all.

Why can the translate extension not give an actual error message?

121.219.255.12111:47, 20 July 2014
 

Yeah, unfortunately that error is sent by MediaWiki and I don't think there's much we can do about it...

That said, the "<ooui-dialog-process" strings should be fixed.

Krenair (talkcontribs)21:05, 18 July 2014

Already fixed; that's the weekly LocalisationUpdate-hasn't-run-yet situation for MediaWiki.org, sadly. :-(

Jdforrester (WMF) (talk)21:08, 18 July 2014
 
 

Nowiki tag

Hi! I'm sorry if this has been discussed earlier, but we have some problems at @lvwiki. When user creats link to article, it is common to create such link [[Article's title]]SomeSymbols. The Visul Editor creats unnecessary nowiki tag (as in this edit: ctrl+f "[[Padomju Savienība]]<nowiki/>s" (without quotation marks)). Some suggestions?

Edgars2007 (talk)10:33, 5 July 2014

I think that would require this bug to be fixed in Parsoid. Anyway, I'd recommend you include "trails" such as the s in the case above in the link: write Padomju Savienības and then select both the words to link to Padomju Savienība. Combine this to the "golden rule" of applying annotations (ie. bold or italics) to the word always before applying the link, and you'll get rid of most nowiki tags and ugly syntax.

Elitre (WMF) (talk)10:24, 7 July 2014

Erica's suggestion to do these steps:

  1. Type Padomju Savienības
  2. Select the whole thing
  3. Apply the link

will stop the nowikis. It will produce a different style of wikitext, however: [[Padomju Savienība|Padomju Savienības]] (unless there is a redirect to Padomju Savienības).

Whatamidoing (WMF) (talk)00:54, 10 July 2014
 
 

Unable to add my signature via VisualEditor

Perhaps I've simply missed it, but I've noticed that I'm unable to insert a signature anywhere in the VisualEditor interface. While I realize this would have limited use, seeing as Talk pages aren't VisualEditor-accessible, it does have use in User spaces, Project pages, and various MediaWiki pages. I was wondering if this feature had been taken into consideration at any point in the past?

Nicereddy (talk)23:21, 13 February 2014

@Nicereddy: This is intentional – the editing experience for a rich document editor and a rich comment editor are somewhat different, and rather than try to build a hybrid editor that serves both needs poorly, VisualEditor is focussed purely on the first. Flow, which will use VE's editing tools in time, is the project to make talk spaces great. As you mention, there are a number of different areas where users are encouraged to sign their name, and all of these will (in time) be served by Flow; this is why (for example) VisualEditor is disabled on the Project: namespace on most wikis.

Jdforrester (WMF) (talk)23:24, 13 February 2014

Almost always when I try VE, it can't do what it is supposed to. This is somewhat unproductive. It's nice that WMF has in mind good software architecture but it renders VE simply unusable for pages like Tool Labs/Collection of issues after Toolserver shutdown not to mention how confused I was that my signature wasn't accepted after I clicked "edit" despite it has been in the past.

Rillke (talk)17:25, 3 July 2014

Hi Rillke, I'd appreciate a list of what you try to do and don't manage to in VE. The reason why you can't use VE to sign is explained above by James. I agree that on pages like that it can be confusing (we shouldn't be using the main namespace for discussions, though :/ ). Some kind of warning (a pagenotice perhaps?) might help in this case. Best,

Elitre (WMF) (talk)17:31, 3 July 2014

Perhaps we should autodisable VE on pages that use NEWSECTIONLINK magicword, which is often used on discussion boards outside of talk pages.

TheDJ (talk)19:11, 3 July 2014
 
 
 
 

Why are text styles hidden in a drop down?

I'm a big fan of VisualEditor. We use it internally at my work with our two wikis. So please take this criticisms as a positive and honest inquiry.

It seems counterintuitive to hide common text style options such as bold and italic. Common editing interfaces else ware (WordPress, Google Docs, Microsoft Word, etc.) show the basic tools on the tool bar. The design decision in VisualEditor seems to skew toward those that are aware of, and conformable with, keyboard shortcuts.

Are there metrics being tracked that show what interface elements are used the most when editing wiki content? Is my situation 'weird' in that my wiki editors do use the menu and apply text styles frequently?

Is this VE design decision to dissuade editors from mucking with text styles?

Don't roll your eyes, but I support and educate co-workers with an internal wiki as part of my work responsibilities. This is #2 the most confusing issue* folks have when editing a page, they have to first discover where the options are and then click again to apply.

    1. 1 is not being able to edit tables. :)
170.29.64.415:30, 25 June 2014

I suspect this might be a side effect of the 'Wikipedia' focus, where using styling is indeed at least frowned upon. The options are all hidden under a common 'Text styling' drop down. Perhaps long term this should be a bit more configurable (or perhaps it already is, but I don't know about it.)

TheDJ (talk)13:22, 27 June 2014

My 2c: I use the new Gmail, and styles are "hidden" there as well. While the toolbar's design (as pretty much everything in VE) is not definitive yet, it is really important that it stays as simple as possible (and adding at least 2 more buttons there can lead to chaos :) ). The wikitext toolbar has icons for bold and italics, but lacks the other features. What you are more likely to click highly depends on what is your typical wiki-activity, so we need to find a balance. This said, please do suggest alternatives. Thanks!

Elitre (WMF) (talk)14:05, 27 June 2014
 
Perhaps long term this should be a bit more configurable

Yeah; one suggestion has been to have user-level configuration of toolbar preferences (or even have the toolbar automatically reconfigure itself based on your personal frequency of tool use), but we've not looked at that work yet.

Jdforrester (WMF) (talk)22:16, 28 June 2014
 
Are there metrics being tracked that show what interface elements are used the most when editing wiki content?

We did a review of typical MediaWiki content edits (across Wikipedias, Wikimedia's non-Wikipedia wikis, Wikia wikis, MediaWiki.org, and couple of others), looking especially at the frequency of use of the bold/italics tools against others. We made a judgement call that when we had them in the toolbar they were unnecessarily prominent compared to their use, and were crowding out other parts of the toolbar (like links) which are much more frequently used.

Is my situation 'weird' in that my wiki editors do use the menu and apply text styles frequently?

Certainly, it's quite different from our research, but that's not necessarily a bad thing. :-)

Is this VE design decision to dissuade editors from mucking with text styles?

Yes.

#1 is not being able to edit tables. :)

Working on it. :-)

Jdforrester (WMF) (talk)22:15, 28 June 2014
 

Clearing formatting and links

This is a general question for anyone who wants to share an opinion:

The "Style text" (character formatting) menu in VisualEditor has options like bold and italics. At the end of the menu, there is "Clear formatting", which removes bold, italics, etc., and also removes any [[link]]s. This is consistent with what some web-based software does (like Gmail). Do you think this is a good approach, or would you rather have "clear formatting" retain any links to other pages/other websites?

Whatamidoing (WMF) (talk)04:51, 25 June 2014

Disambiguation detector

The disambiguation detector is turned off when I enter the visual editor. It would help eliminating links to disambiguation pages if, when entering the visual editor, those links where kept with a yellow background.

Frlara (talk)22:56, 15 March 2014

VisualEditor has its own disambiguation and redirect detector built into the link tool. Which tool are you talking about?

Whatamidoing (WMF) (talk)21:56, 18 March 2014

Maybe it is w:pt:MediaWiki:Gadget-desambiguacoes.js?

Helder.wiki20:07, 27 March 2014

Yes, its the gadget described here: https://pt.wikipedia.org/wiki/Wikip%C3%A9dia:Detector_de_desambigua%C3%A7%C3%B5es Or, in english, here: https://en.wikipedia.org/wiki/Wikipedia:Disambiguation_detector

But, surplisingly, it doesn't appear in the english wikipedia preferences page, only in portuguese.

Frlara (talk)08:15, 15 June 2014
 
 
 

Visual Editor has no Save/Cancel Button

We use MediaWiki with the visual editor in version 1.23.

The visual editor loads and shows the articels. You can work with the visual editor (delete text, add text ...) but there is no Save or Cancel Button.

in the div "oo-ui-toolbar-tools" you see the all the tools (and they works) but the div "oo-ui-toolbar-actions" is complete empty no buttons

in IE, in FF and in Chrome ... always no buttons

Has anyone an idea?

Thanks for helping!!

95.172.88.515:05, 11 June 2014

I can't really help you, but I want to say that's very strange. This is the first time I've heard of that happening to anyone. There are some keyboard shortcuts described at bug 50897, but if the Save button isn't loading, I'm not sure those would work (and you want the menu to load anyway, even if there might be a workaround).

Whatamidoing (WMF) (talk)18:21, 13 June 2014
 

German quotation marks

Hi! I recognised, that there are no „German“ quotation marks (<- the kind I used here) in the list of special characters of the visual editor. Would be useful though. --Don-kun (talk) 19:53, 7 June 2014 (UTC)

Don-kun (talk)19:53, 7 June 2014

Thanks for your note, Don-kun. The entire contents of the special characters box can be changed by any admin at each wiki, to include any special characters you'd like. The formatting is a little picky, so if you need help, please post again, with a link to the project page.

Whatamidoing (WMF) (talk)22:39, 8 June 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
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page