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 regular "Edit" button) 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 chanTest 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
looking great, can't wait016:43, 14 April 2014
VE office hour in April011:17, 7 April 2014
One annoying little thing308:43, 7 April 2014
Public parsoid server?102:51, 5 April 2014
Can't edit sections402:50, 5 April 2014
Disambiguation detector220:07, 27 March 2014
Some suggestions1007:20, 26 March 2014
Workflow for adding references could be improved113:00, 21 March 2014
MSUpload extension intergration?201:02, 20 March 2014
2 (minor) problems202:53, 5 April 2014
Media resize621:53, 18 March 2014
Signature115:51, 17 March 2014
Special characters1413:23, 11 March 2014
Why not using an existant HTML5 editor?908:06, 9 March 2014
Feedback for the character inserter4820:05, 4 March 2014
Text Color1123:43, 3 March 2014
No-break space (& nbsp;)1123:41, 3 March 2014
Guide to theming changes123:39, 3 March 2014
Add pre-made citation and image templates to VE, it's already in conventional source code mode223:35, 3 March 2014
nowikis & double apos322:20, 27 February 2014
First page
First page
Previous page
Previous page
Last page
Last page

looking great, can't wait

Hi there, the new editor is looking great. Can't wait to see it in production..

Great work, keep it up!

Cheers 124.176.151.188 17:30, 13 April 2014 (UTC)

Whatamidoing (WMF) (talk)16:43, 14 April 2014

VE office hour in April

Greetings! The Wikimedia Foundation's engineering department has been scheduling office hours to discuss VisualEditor for months now. Please join Product Manager James Forrester to discuss the products and upcoming plans in April as well!

The discussion will be on IRC (w:Internet Relay Chat) at irc://irc.freenode.net/wikimedia-office. For more information on office hours, including how to attend, please see meta:IRC office hours. Logs will be posted at Meta afterwards.

If office hours are heavily attended, it can be difficult to get to all questions, but if you want to ask a question and cannot attend or do not speak English, then please let us know your question here by the day before, and someone will add it to possible discussion topics.

Thanks!

Elitre (WMF) (talk)11:17, 7 April 2014

One annoying little thing

I like the Visual Editor for when I'm just doing surface stuff (copyediting, fixing typos, etc), but otherwise, I prefer the source editing. There's a minor annoyance about the VE that shouldn't be too hard to fix, however: Every time I open it up, I can't do anything for a few seconds then "Welcome to Visual Editor!" After a while, this can really get annoying, especially when you're on an unreliable internet connection where you often have to reload the page two or three times to get it to show up. If there was some sort of "Don't show this message again" box, that'd be great.

Supernerd11 (talk)02:10, 5 April 2014

The beta welcome dialog sets a cookie after you've seen it once that makes it not show for the next 30 days (and resets the cookie to 30 days hence every time you use VisualEditor), so unless your browser is set up to clear cookies it shouldn't show the dialog a second time on a given browser. Do you have your browser set to only accept certain cookies?

Jdforrester (WMF) (talk)02:49, 5 April 2014

I've got it set to delete cookies after I close out, I'll change that. Thanks!

Supernerd11 (talk)03:10, 5 April 2014
 

I think it´s OK. It welcomes you like a greeting, like welcome back. Plus, it doesn´t know if you are there for the first time or not.Tina3456 (talk)

Tina3456 (talk)08:43, 7 April 2014
 

Public parsoid server?

Hi there, is a public parsoid server avaiable? If yes, could s'one tell me the url which I have to paste at this position: $wgVisualEditorParsoidURL = '<<servuer url>>'; Thanks in advice! Daniel

193.196.36.1019:54, 27 March 2014

No, sorry, you will have to host your own Parsoid instance. We do not provide a public Parsoid service for non-Wikimedia wikis.

Jdforrester (WMF) (talk)02:51, 5 April 2014
 

Can't edit sections

Edited by author.
Last edit: 21:45, 14 March 2014

The 'edit' links by sections don't let you edit sections as one would expect, but rather take you to an edit window that includes the whole page. I believe this was a bug someone hadn't fixed yet, or maybe it was intentional, but anyway it should probably get fixed sometime. Thought I'd let you know.

Cathfolant (talk)21:41, 14 March 2014

wait what is this doing at the top? So that's how that works? Cathfolant (talk) 21:42, 14 March 2014 (UTC)

Cathfolant (talk)21:42, 14 March 2014
 

It seems to work now for some reason. Don't know what was up.

Cathfolant (talk)21:52, 14 March 2014

If you scroll the page while it's opening (at all, even by accidentally bumping your mouse very slightly), then the section edit links won't take you to the right place. But you're right that it does open the entire page. Full-page editing is necessary to allow things like re-using references that are defined in other sections.

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

Editing Sections worked for me. Weird! Tina3456 (talk)

Tina3456 (talk)11:54, 2 April 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
 

Some suggestions

I have some suggestions-complains about the VE. I guess some of this has been told by other users, but i can not review all of these comments.

  • The Visual Editor takes to load, I guess that images could be to loaded with less resolution.
  • Use the cancel button [X] as standard to close windows/boxes, trash can icon could be confusing.
  • I guess the template editor is developing but, however, is meaningless to use the VE to avoid the source code characters (as [ ] < > ) only to encounter with it in the template editor. The template editor should work equally as the VE itself.
  • Also, it should be a template gallery as the multimedia gallery.
  • When you embed an image, you should to put the option to write the label by default. Basically all of the images in the Wikipedia have label, is absurd to have to edit the image later only to put a label. (But, if the image is embedded without a label, the image should not appear with a blank label by default, just in case).
  • You should to put an image alignment button (left, center, right) in the menu bar.
  • Menu bar should have two rows that include the rest of the options that were put in the "more" button. Anyone would not mind by that, I think.
  • You should to put the text format buttons and the hyperlink/references buttons in a separate groups, Is more intuitive, I guess.
  • Right now the references tool is so useless. I think this can be the ideal tool to standardize the style/format of the references. But what is the sense of push the references button an get a box that allows you only write plane text? The box should to show buttons in that you select the kind of source that you are quoting (book, magazine, web page, video, and so on) and to predetermine the fields to fill (title, author, year, etc). Also, the immense space below the text box could to show the used references in the article in a list and give the option to use the selected reference. That also would merge the references button with the list of references.
  • And you can put an iside note tool. I mean, If I am working in an article and I find something in that I want to work later I should be able to put a mark with a note (as "review spelling").These notes should not be saved with the article, of course.
SirWalter (talk)07:57, 26 October 2013

Hi, thanks for writing. You might also want to read and report some of your comments on:

Elitre (WMF) (talk)14:08, 15 November 2013
 

WYSIWYG must not degrade quality of images.

Nnemo (talk)06:08, 26 January 2014

User:Nnemo, are you seeing problems with image quality? Can you describe it or send a link to me?

Whatamidoing (WMF) (talk)23:16, 28 January 2014

I suggested that VE should degrade quality of images in aim to make faster the load of VE. Nnemo states that he does not agree with that.

SirWalter (talk)07:20, 26 March 2014
 
 

In the VisualEditor there is no menu bar.

Nnemo (talk)06:16, 26 January 2014

Um, yes there is? The bar at the top where you can select bold, italic, header size, images, ... is a menu bar.

Fram (talk)08:28, 27 January 2014

No. This is a button bar. You may call it a tool bar. But the menu bar I have has Safari, Fichier, Édition…

Nnemo (talk)21:52, 28 January 2014

Nnemo, what would you need a menu bar for? I'm afraid I don't get it :)

Elitre (WMF) (talk)15:29, 3 February 2014

Nnemo is only saying that Sir Walter accidentally used the wrong name for this bar in his note. It might confuse some people who are reading it.

Whatamidoing (WMF) (talk)20:04, 3 February 2014
 
 
 
 
 

Workflow for adding references could be improved

Yesterday, I decided to give VisualEditor a try, making this edit on enwiki. It's not a complicated edit, but it's the sort of thing that should be bread-and-butter on Wikipedia—adding wikilinked text and a reference using a citation template. Before navigating to the page, I had all the details of the citation ready to go (URL, article title, journal title, volume, date, page number). The content was fine to add (it felt odd not typing [[ and ]] to link, but I think that's just unfamiliarity) but adding the reference wasn't all that pleasant. Here's the process I went through:

  • Click 'Insert' -> 'Reference'
  • Be confronted with a modal dialog box
  • Click 'Insert' -> 'Template'
  • Type 'cite journal'
  • Click on 'cite journal'
  • Click on 'add template'
  • Fill out the two fields asked for straight away—but I've still got four more to go
  • Four times over:
  • Click on 'add parameter'
  • Scroll through the list and hunt for the parameter I'm adding
  • Fill out these four fields
  • Click 'insert template'
  • Click 'insert reference'

I found the process quite awkward, much more than using wikicode. There's a certain amount of inherent complexity here that I've already internalised with templates and wikicode (e.g., knowledge of parameter names), but there are still some things that are just taking too many clicks:

  • If you're adding a reference, chances are it'll use a cite template. The UI should make this common path very easy. (Individual wikis will probably want to specify what a 'cite template' means for them as a configuration variable.)
  • It should be possible to add multiple parameters at once, without having to click on 'add parameter' multiple times and scroll from the start of the list again. Templates should be able to hint what non-mandatory parameters are likely to be used very often (or, if they can do that already, they should do a better job of it on enwiki).
Facing the Sky (talk)12:51, 21 March 2014

Working on the reference dialog is exactly what is happening at the moment. The following is from the most recent newsletter about VE (on en.wp): the forthcoming simplified citation dialog [...] The main priority in the coming weeks is building this new citation dialog, with the ultimate goal of providing autofill features for ISBNs, URLs, DOIs and other quick-fills. This will add a new button on the toolbar, with the citation templates available picked by each wiki's community. Concept drawings can be seen at mw:VisualEditor/Design/Reference Dialog. Please share your ideas about making referencing quick and easy with the designers. So make sure you share your feedback there. Hope this helps!

Elitre (WMF) (talk)13:00, 21 March 2014
 

MSUpload extension intergration?

http://www.mediawiki.org/wiki/Extension:MsUpload

This works very well, and makes it super intuitive for non technical users to upload images by just dragging on dropping like they do with word processors, email sites, blogs, etc. Could this be integrated into the new visual editor? I'd love to have both on my wiki!

140.190.134.3921:16, 10 March 2014

It's more complicated than that, because we need to keep track of copyright-related information.

They do have some plans to integrate image uploading at some point in the future. However, it may not happen this year.

On a related point, the image (formatting, not uploading) dialog has changed quite a bit in the last week, so you might want to have a look while you're here.

Whatamidoing (WMF) (talk)17:45, 11 March 2014
 

I'm sure that this could be integrated into VisualEditor, yes. However, as Whatamidoing (WMF) says, the extension is not appropriate for Wikimedia's needs, so we will not be working on that. Plans to integrate UploadWizard into VisualEditor are at an early stage.

Jdforrester (WMF) (talk)01:02, 20 March 2014
 

2 (minor) problems

(I like the visual editor, and think it was a step in the right direction.)

Two small "bugs" that may, or may not, have already been reported before: 1) while editing, red links appear blue in the visual move, even though they link to non-existent pages; 2) when editing boldface text, ''' ''' appear surrounding the newly added text, when that is perfectly unnecessary. (E.g. [1])

(Ah, and one quick question: at first, I thought VE's biggest flaw was its loading time (after one clicks "edit"), but recently it seems to have gotten better? [Or maybe it's just me, who's gotten used to it.] Thanks.)

DanielTom (talk)23:21, 13 March 2014

On further reflection, you can just ignore the second "complaint"—what probably happened in that diff, was that the VE read that I was adding a dash without it being boldfaced. So, no problem there.

DanielTom (talk)23:31, 13 March 2014

VisualEditor's speed has improved significantly, and today's status report from the devs suggests that another small boost may be in the works (but only for Chrome users, and only after the page has opened).

The redlink problem may be solved as early as this Thursday (here at MediaWiki.org; next Thursday at the Wikipedias). It's something that's been on the list for a long time.

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

Media resize

I like the new media resize. I would propose extending it with some type of snap-functionality.

  • So while dragging, I would snap to 5 or 10px dimensions, and only allow overriding this in the dialog.
  • After dragging, I would present two or three hover buttons (default, large, larger), in addition to the drag point.
TheDJ (talk)10:55, 20 February 2014

Have you tried shift-dragging it? That should let you re-size in 10px increments.

Whatamidoing (WMF) (talk)19:56, 21 February 2014

Potentially we could invert the 'standard' operation (so dragging locks to 10px increments, but shift-dragging does at 1px increments). Not sure if this would be too confusing.

TheDJ: When you say "two or three hover buttons (default, large, larger), in addition to the drag point", do you mean prompting people to "correct" the size they just adjusted to one of three standard sizes?

Jdforrester (WMF) (talk)21:23, 21 February 2014

I like the idea of inverting the drag-to-resize feature, and I think people would adapt to it.

  • What would happen with an image that started off at 123px? Would it drag to 130px or to 133px next?
  • How does this interact with upright sizing (which is still in early stages)?
Whatamidoing (WMF) (talk)21:17, 24 February 2014
 

That's what I meant James. I also think that inverting the operation is logical. (who needs pixel accuracy ?)

TheDJ (talk)19:03, 27 February 2014
 

I find it (the 10 pixels increments) extremely unnecessary. Is there any reason to do this, other than relieving your OCD? The image quality is not affected and the page layout is restricted. I don't see why anyone would want this.

Frlara (talk)23:46, 15 March 2014

Most people are trying to make images the same size as other images on a page, and if they all snap to the same numbers, then that's easier to do.

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

I would like see a feature that would allow me to insert my signature.

ȸ (talk)15:37, 17 March 2014

Hi there. A similar request was made on Bugzilla, so you might want to keep an eye on that. Best,

Elitre (WMF) (talk)15:51, 17 March 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
 
 

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
 
 

Why not using an existant HTML5 editor?

Raptor or Mercury Editor are really better HTML5 WYSIWYG editors than VisualEditor. Why not collaborate and adapt them to Mediawiki? Mercury Editor is not compatible with IE but is better than Raptor for the moment. But next version of Raptor is planning features that will render it as good as Mercury Editor. http://www.raptor-editor.com/demo http://jejacks0n.github.com/mercury/

81.50.158.18211:13, 29 December 2012

How do these editors embed with wiki software? Are the parsers separate?

Malyacko (talk)13:38, 31 December 2012
 

The Wikimedia Foundation decided that the existing wiki WYSIWYG editors did not meet its expectations. For existing HTML5 editors, they would have to be redesigned to handle wikitext, something that I believe was considered less feasible than writing a new one from scratch.

Jasper Deng (talk)02:25, 6 January 2013

Yes - there's more on this in the "backgrounder" blog post about why we couldn't re-use an existing HTML editor, which otherwise would have made everything a lot easier on the VE front; however, we would still have needed to do the incredibly-hard work of building Parsoid, so it wouldn't have made things trivial.

Jdforrester (WMF) (talk)22:35, 7 January 2013

Raptor Editor have just released a major update including a ton of new features, improved documentation and improved plugin API - http://www.raptor-editor.com/

27.252.173.25506:15, 25 April 2013

You are comparing apples and oranges here - Raptor and Mercury aren't really the same thing as VisualEditor. I appreciate the intention of your suggestion, but if you research the point further I'm confident you will find that VisualEditor is solving a different set of problems, most likely a super-set, but a different set nonetheless. We have requirements such as clean round tripping, whole document editing with protection of unsupported or generated content, and internationalization issues (just to name a few) that take a considerably different approach. We are always looking for ways to reuse existing open source code, and currently use jQuery, QUnit and Rangy. VisualEditor has been licensed under MIT to maximize reusability in and compatibility with other projects.

Trevor Parscal (talk)19:19, 25 April 2013

Yes, I'm comparing oranges and apples. Raptor is actually the easiest and ergonomic editor I know, VE isn't. Mediawiki should listen more to the needs of users or it could disappear one day.

78.247.32.8816:12, 17 January 2014
 
 
 
 
 

Feedback for the character inserter

Please post your ideas about VisualEditor's character inserter tool here. It would be helpful if you said what language(s) or characters you tested it in. Thank you!

Whatamidoing (WMF) (talk)19:47, 22 January 2014

The same was asked at enwiki, [1], where a number of people left rather damning (but entirely correct) feedback. I'll repeat mine here:

I was going to test this and detail the individual shortcomings, but really, what's the point? Either you come here and ask for "what would you like to see and get in a 'special character insertion tool'", or you deliver us an at least half-finished but well-thought out product. Now, you present us with something that may not produce instant errors, but which has zero functionality for 99% of the wanted edits. The number of special characters, even for editors at enwiki, is minimal to the extreme; capital letters are missing; you can't add more than one character at a time; and so on.

Go back to the drawingboard, get some user expectations first (it looks as if you don't know what this tool is really supposed to do), look at the "special characters" insertion tool in normal editing mode, but don't bother use with this nonsense. You are only making a fool of yourselves, and aren't winning any souls for VE, while the actual practical benefit of these responses to you will be minimal. Really, you have developers, you always claim to have a QA team, you have enough people willing to give feedback if you simply ask "what would you like to get in this tool", you have an existing example, and still you dare to come here with this? Please, find the one who asked you to get input on this tool, and (assuming it is a paid WMF employee) fire him or her for gross incompetence. How many times will you (WMF) make the same errors before anything changes there? Just leave us alone and do your job. Fram (talk) 12:44, 24 January 2014 (UTC)

Fram (talk)13:08, 24 January 2014
 

Hello, tested today on it.wiki while writing a new article. I didn't know it was a new feature, our community liaison just linked this discussion page. I found the tool not useful for my purposes: I was looking for greek letters to add as plan text, in order to avoid mass usage of the math mode. The current layout is almost useless for an Italian user: we already have more than 50% of those characters on our keyboards. Thanks.

Baruneju (talk)21:54, 24 January 2014

Hi User:Baruneju,

Thanks for your note. The current tool is just a very, very simple one—to give people a starting point, and perhaps to help them see the concept if they haven't used one before (or, for those who don't speak English, if they didn't know what it was called).

You said you need Greek letters, and I think every Wikipedia will need them. How would you like to get to the Greek letters? Would you like a bigger box? (If the box is big enough to show all the characters someone might need, then it won't fit on your screen, but it could be bigger than this.) Would you like some sort of menu or button or collapsible sections? Do you think it would make sense for each Wikipedia to be able to define the ones that show first (so that Italian users won't have é put in front of them, but English users would)?

Whatamidoing (WMF) (talk)05:49, 25 January 2014

Hello, the size of the box is not a problem, but of course it would need a scrollbar and a floating index/collapsible sections. Having a per wiki/per user setting to rearrange the sections (i.e. greek letters before symbols and so on) is mandatory, in my opinion.

Baruneju (talk)14:15, 25 January 2014

Hi User:Baruneju,

There is a per-wiki setting. Would you like me to request a per-user setting as well? It might be possible (I don't know, but I could ask).

Whatamidoing (WMF) (talk)17:43, 28 January 2014
 
 
 

Hallo, I'm from eml.wikipedia. I tested yesterday your new way to insert the special caracters: I find that they are in a small quantity, instead of the major one that we usually need. I hope that in a future there will be more special caracters in your new medium, end the maximum, I think, it will be that we can find all the beautiful special caracters that are in the olt wiki-editing. Bye,

Glory sah (talk)07:19, 25 January 2014
 

Hello,

I think the main need is customization:

  1. (the most important) by sysops for default character set on a given wiki
  2. by users for basic changes, with preferences
  3. by advanced users, with a js API

...you will never have the right set for all regions/wikis, and never know who needs what. That is the main thing people will complain about. And yet they did.

Some needs:

  • uppercase equivalent for accents. In French keyboards most of it is on the keyboard, but it is painful for MS Windows users to have the capitalized equivalent (Linux and MacOS are fine on this)
  • propose localized quotes when a string is selected (« in French », „in German“, and so on).

Thanks for all the work!

Turb (talk)08:20, 25 January 2014
 

Carons are missing (č, š, ž)

Smihael (talk)15:26, 26 January 2014

Hi everybody, and thanks for the feedback so far! I want to make clear that as far as I know the inserter can be customized by the single wikis in order to get exactly what is needed at each of them ;) So, I'd suggest that we test the tool and take notes of what works, of what could be added and of what should be changed, and after that, that each wiki makes its list of needed characters, possibly excluding items which would not work in VE. Thanks,

Elitre (WMF) (talk)16:24, 27 January 2014

possibly excluding items which would not work in VE. Care to elaborate? I thought all characters were supposed to work in VE?

Fram (talk)17:05, 27 January 2014

I was talking about characters in the way they were used to create wikitext. For example, of course brackets would be ok, just not grouped as [[ ]].

Elitre (WMF) (talk)17:19, 27 January 2014

Ah, like that... It sounded more ominous. Can you explain where people are able to change the characters in this inserter for their wiki? I would like to test this for enwiki, to see whether this works and what else we can configure locally for VE.

Fram (talk)17:39, 27 January 2014
 
 
 

Hi. I observed that for Romanian language letter "Ă", "Ș", "Ț" doesn't appear.

Cornel Punga (talk)19:17, 30 January 2014
 

Hi. I've tested in English. So, first I think it's a must to have a brief tutorial about how you can start to edit, where you can find basic tools. Why I say it is important? Because once you edit an article and during editing you find a new tool that makes your article and work on that article easier and better, you think: "Man, If I knew about it at start of my work!?". I consider that most people will start editing without exploring every new tool or feature. It's my opinion. What you think about it?

I think it's great that toolbar just scrolls down or up while you're surfing through the article. Another great feature is that media, transclusion etc. appear under insert. Stuff in transclusion is just amazing. Also, great that special characters panel appears relative to cursor present position. Amazing possibilities with media, I like it.

I'll continue to test it and forward to you my impressions and other suggestions.

Thanks! :)

Cornel Punga (talk)17:59, 29 January 2014
 

Hi.

I observed that for Romanian language letter "Ă", "Ș", "Ț" doesn't appear.

Cornel Punga (talk)18:04, 29 January 2014

I guess that one main intended usage of this is for users of a certain wiki to insert characters that are not part of the standard character set for the language of that wiki since that's typically a situation where users may not have an appropriate keyboard layout at hands. In many cases, such usage would be as part of a template: an article title in its original language within {{Cite journal}}, a {{Quote}} in original language, just some foreign language words with {{Lang}} in the regular text, etc.

Well... I didn't find a way to use this tool within templates. Is it well hidden somewhere?

Other griefs include

  • Such a big tool for so few characters...
  • No apparent support for multiple characters sets (I mean switching the whole list of characters from a Latin set to a Greek or Cyrilic one)...
  • Insertion of just 1 character at a time...

At best, I'd say that this tool seems useless in such an early stage. I even fear that some fundamental requirements may have been overlooked and that this early stage is not even a good basis to make the tool evolve into something really useful.

Klipe (talk)11:06, 30 January 2014

Hi Klipe,

The inserter isn't hidden in the templates; it isn't there yet. It needs to be there, and in many other places, too. I've got a list at bugzilla:60657, and if you think of any that I missed, please feel free to add them there (or to ask me to add them for you).

Whatamidoing (WMF) (talk)23:48, 30 January 2014
 

I completely agree with Fram and Klipe about their feedback.

What's the point of bothering us with feedback when developers didn't even look at the existing tools for the wikitext editor ?

One extra remark on the configuration for defining character sets and characters in each set. There are currently 3 different informations in the configuration:

{
	"symbols": {
		"−": "−",
	}
}

The first one seems to be the set's name, the second I'm not sure (maybe what is displayed in the button), the third one probably the character(s) that will be inserted. It would be nice to have 3 different informations for each special character: what is displayed in the button, a tooltip (would be useful for example for the various dashes), and the characters that will be really inserted.

NicoV (talk)09:23, 31 January 2014

What's the point of bothering us with feedback when developers didn't even look at the existing tools for the wikitext editor ?

The devs did look at the existing systems. However, they did not want to automatically assume that they way it's been done in the past is the best possible solution. There were pretty significant technical limitations in what could be done in the wikitext editor (e.g., no possibility of floating palettes—which we might not want in the end, but which simply were impossible in the old editor).

Whatamidoing (WMF) (talk)17:45, 3 February 2014

They did look at the existing system, and decided to ignore it completely and make sure that the new one couldn't do anything the old one could. And then they and you were surprised when the feedback was so scathing?

That you wanted to add possibilities not available in wikitext is fine, but that is not an excuse to remove the most basic needs of a character insertor. Or was there some bugzilla entry that said "please make the character insertor single entry only"?

Did anyone, at any time, make an analysis of what a character insertor is needed for? What the few basic functionalities are? Can you link to that document?

Fram (talk)17:56, 3 February 2014

I'm not the least bit surprised that people have identified deficiencies in the existing iteration; identifying them (and seeing which "missing" items and which "new" items people don't call out as deficiencies) is the point of this discussion.

As far as I know, none of the original design documents are available online.

Whatamidoing (WMF) (talk)18:46, 3 February 2014

Perhaps it's time that the WMF changes it appraoch then, and puts its discussions, documentation, ... online? It can't be that you have anything to hide, surely? Or worse, that there is nothing to show?

Anyway, as long as you have no evidence for your claims about prior discussions and so on, I don't believe anything of it.

And the point of this discussion is to get the WMF to change their approach drastically, so that they don't come across as a bunch of totally incompetent losers. Which is the effect you have with putting things into production which have no useful new features, but has abandoned all the useful old features for no good reason at all, and then come here afterwards to ask for feedback.

But I'm glad to see that if we haven't made our list of deficiencies exhaustive, then you consider the things that haven't made our listed as "not important", "not needed", "not wanted" apparently. Yes, you totally have the right idea there, everything we haven't yet complained about is a real gem to treasure, and everything we haven't said is missing can be safely discarded.

Have you perhaps considered that most people give up after noting the few most glaring deficiencies and realising that the WMF hasn't put any thought at all into this? Comments like "At best, I'd say that this tool seems useless in such an early stage. I even fear that some fundamental requirements may have been overlooked and that this early stage is not even a good basis to make the tool evolve into something really useful." say it all, really.

Fram (talk)07:54, 4 February 2014
 
 
 
 

Greetings, here's what our French-speaking friends noted so far.

  • Not enough groups of characters, and not enough characters per group;
  • the window should not close automatically;
  • the feature can't be used to add s.c. inside templates, external and internal links and so on;
  • The screenshot shows about only 40 characters right now and the window is already of a noticeable size. The [...] tool in the wikitext editor shows about 200 characters just for "Latin", and "Latin" is only one of the 18 character sets currently managed (which is probably only a portion of Unicode character sets). The current "mockup" doesn't address this basic issue of scalability, and the tool should grow in width;
  • The special characters tool shouldn't be a window, rather a kind of tab just like the wikitext tool or like tabs in Microsoft Word;
  • Where can one translate the labels of the groups, and why are the sets different (including their order; fr.wp lacks the Math one for example, but MediaWiki:Visualeditor-specialcharinspector-characterlist-insert wasn't changed locally)?
Elitre (WMF) (talk)12:57, 6 February 2014

Re: Missing math: The list at translatewiki wasn't replicated from the English version - whoever did it clearly made their own choices. Compare [1] with [2]. HTH.

Quiddity (talk)03:13, 7 February 2014
 

Here is a summary of the suggestions and needs expressed at the English Wikipedia:

  • Must be able to switch between multiple character sets (access to math symbols, Greek, Hebrew, etc., depending on what you need). At the English Wikipedia w:en:MediaWiki:Gadget-charinsert.js has 11 charsets and the wikieditor toolbar has 18; about 34 sets exist.
  • Must support multiple character insertion, even if it's not the default mode. (Not mentioned: it's probably necessary to be able to insert multiple characters from different character sets, e.g., mathematical symbols plus Greek letters or anything plus IPA.)
  • Must be able to use within transclusions, language settings, or any other dialog/tool that you can type into (bug 60657).
  • Prefer having the dialog near the menu rather than floating with the cursor. If the cursor is near the bottom of the screen, then the character selector menu is mostly below the screen.
  • Prefer having a menu attached to the main toolbar in VisualEditor that uses the full width of the screen to maximize the number of characters that can be seen at once (bug 60770).
Whatamidoing (WMF) (talk)20:55, 12 February 2014

Sorry if this has been told already, but why not use the same special characters submenu as in WikiEditor? To be honest, I've never used it, but it looks good. So when choosing Insert -> Special character it could open same kind of submenu like in WikiEditor.

Stryn (talk)21:20, 19 February 2014

Hey Stryn! The character inserter for VisualEditor is meant to be and is customizable for local wikis. We want communities to be able to populate it with what they need, rather than what we think they want. For example, since you're a admin on the Finnish Wikipedia you can adapt the character inserter directly on the MediaWiki page, just like I believe you can do for WikiEditor. VisualEditor should mimic as many functions as source editing as possible, and that includes local customization.

Keegan (WMF) (talk)08:25, 20 February 2014

I see that James kind of gave the same answer below about Annotation buttons. I hope the link to the Finnish Wikipedia page helps you adapt the inserter.

Keegan (WMF) (talk)08:35, 20 February 2014
 
 
 

Hi, IMHO, I think the V.E. special characters tool, I prefer a priority section with most used special characters.

Arrange of sections: I think:

  1. Accents
  2. Symbols
  3. Math
  4. others

The tool must remains visible until I want to hide it, I prefer the tool in a fixed position on screen (as startup) but I can drag it.

I hope my comment can be useful about develop of this cool tool.

See you soon!

Joetaras (talk)23:05, 12 February 2014
 

Just wondering if it would be better to have the accents aligned with the letter going down and the accents across, and leaving space where the accents doesn't exist for that character. Test1

À Á Â Ã Ä Å
È É Ê Ë
Ì Í Î Ï
Ò Ó Ô Õ Ö
Ù Ú Û Ü
71.189.7.2308:37, 13 February 2014
 

I've been using VisualEditor for about 80% of the content I've added, and it's improving more and more. I like that the character inserter has been added; it makes things much, much easier. I don't use special characters very often, except for the em-and-en dashes, which I use almost every session, and sometimes a few times each session. I also like how the inserter has been set up thus far. IOW, I only have positive feedback for you. Nice work, and keep it up! Figureskatingfan (talk) 17:37, 19 February 2014 (UTC)

Figureskatingfan (talk)17:37, 19 February 2014

Great to hear that you're finding constant improvement, Figureskatingfan. Any feedback you have to build VisualEditor is always welcome.

Keegan (WMF) (talk)08:28, 20 February 2014
 

Please add Devanagari character.

Wikiuser13 (talk)06:22, 20 February 2014

Thanks for the request, Wikiuser13. We'll see about adding them to the default inserter. In the mean time, if you can help we'd like to make sure that local wikis are getting the support that they need, including proper characters for the Hindi Wikipedia.

Keegan (WMF) (talk)08:33, 20 February 2014
 

Hi, french editor here :)

Firsts things first: the actual characters we have nowadays are useless in french (most of the accented characters already exist on the french AZERTY keybord, and the symbols are not the oft used symbols we need like the french quotation marks). Also I am not a big user of the Visual Editor, but I have tried it some, and even if I am still not convinced by its purpose, I think improving it is important.

To introduce my reasoning on the special character question, I would like to remind you that while templates can be mostly skipped when writing, and references are useful but most often added at a rate of 1 ref/multiple sentences, special chars on the other hand are part of the writing. If we need easy access to templates and references, then we doubly need twice easyer access to the special chararacters because if putting refs can be done afterwards, adding little [1] at the end of the sentences, writing your regular lengthy article will require the use of all those pesky little «» ± ó æ Á É right in the middle of the sentences we write.

So, answering some of the questions asked in the dedicated section of the VisualEditor french suggestion page:

  • Yes we would need the whole wikieditor special character toolbar. For one, nobody can predict what characters they will need while editing. I might need greek letters for a physics article, then edit some article about some czech woman or something and need some accents non accessible on the french AZERTY keyboard.
    • The whole toolbar won't be too much, it will just be enough. Even in the french community keyboard-related problems about apostrophes are a reoccuring matter because people won't have access to the same keyboard in a language community.
    • The pop-up sorta thing should go down the drain : special characters are too plentyful to be used as a pop-up. Microsoft Word is an example of the sort of thing a pop-up would become : a huge jumble of signs, symbols and letters, all together in a invasive pop-up window in the middle of the text frame, superimposed on the text, making it unnerving when we want to add just a single character, or multiple characters in different places in the text. Please, prettty please don't do that.
    • A good vertical or horizontal toolbar/tab, taking the whole length/width of the editing window would be good, that you can wrap/unwrap so as to have easy and quick access to the characters without the thing blocking your view from the text. Different tabs would allow us to go from one set to the other, since the worst possible thing would be to have all the characters in the same frame, making users go crazy finding the right character (Microsoft Word, again...)
    • For users without enough place to store all the characters in a few lines, two things should be done in my opinion:
      • For starters reduce the size of the little buttons to click. Seriously, being user friendly slash omg so cool and design doesn't mean we should have small letters/symbols encapsulated in huge squarish buttons. Reduce the size or use the whole space of those squares, because for the time being it feels like a ot of free empty unused space. That way, more special characters will be encompassed in the pop-up/tab/navigation bar/whatever
      • Second add a scroll. Really, scrolling is like, the basics. Not enough place to store everything ? Scroll.
  • A special section with the ten/twenty or so most used characters would be so so nice.
  • La barre d'outils a déjà trop d'options. Comment la simplifier ?/The toolbar has already too many options. How do we simplify it? Well... You have to ways of figuring this out:
    • The VisualEditor is only some sort of simplified editing tool, sorta like Wikipedia-for-dummies thing, adapted for people unfamiliar with the internet/the computers/whatever. Then you can already scratch all those template-adding, special characters and such, because this should be made simple and would be a tool designed for occasional editors
    • The VisualEditor is destined to be some sort of alternative for all the editors: well then you're screwed because the actual, nowadays, code-like interface does a humonguous number of different things, so the VE toolbar will reflect this state of things and be a humonguous thing. And thus, the VE won't be easy to use even for people unfamiliar with code editing: no amount of nice little buttons with cutesy little logos and images will be able to simplify the understanding of a newbie in front of Wikipedia. It takes time, practice, and help from humans... (Help that is made kinda hard to give since you just never know what tool the newbies will use...) Anyway, I am rambling and straying on another path here, sorry ;)

Good luck implementing the special characters in VE

Euterpia (talk)10:35, 20 February 2014
 

Hello,

Here is my feedback. I totally agree with Euterpia (just above). I proposed the idea of a tab on fr.wp a few weeks ago, I think using a vertical tab on the right side of the screen is better as it takes less place than horizontal tabs,if it it not too wide. One user on the French Wikipedia (TigH) suggested that VE should be able to analyse the characters of the page which is edited, so that special characters which are used the most on that page are displayed in a special "priority" section. It could be mixed with a general "priority" section, with special characters that are needed most often in the language of the wiki.

Then, reducing the size of the buttons would also be useful (and not only for the special character inserter): the toolbar on the top of the page has two drop-down menus, a few icons, and a veeeery large blank space on my computer. So you should add an "advanced" mode, in which only icons are displayed in the toolbar: this could avoid drop-down menus and allow a faster access to the different features. Keep it up !

NemesisIII (talk)18:44, 4 March 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
 
 
 

No-break space (& nbsp;)

How do I enter a no-break space (& nbsp;) into the source text via the keyboard? Something like Ctrl+Space would be nice … And, BTW, can I see the difference between a regular space and a no-break space?

Troubled @sset Work • Talk • Mail18:03, 8 July 2013

Thanks for the feedback, request added here: [1]

PEarley (WMF) (talk)15:23, 9 July 2013

On Mac, Option Space gives a non-breaking space. And Ctrl Space is already taken by the OS.

Nnemo (talk)20:47, 2 February 2014

In Visual Editor?

Fram (talk)14:13, 3 February 2014

Hi Fram, I was going to reply on en.wp. I don't think there's a way to do this currently, and I believe it also can't be added via the character inserter now. Will add this to the list of things I'm asking James ASAP, thanks.

Elitre (WMF) (talk)14:43, 3 February 2014

Thanks. I only replied here because Nnemo seemed to have misunderstood the question (i.e. not how do I insert a non-breaking space, but how do I insert a non-breaking space in VisualEditor. Thanks for confirming my suspicion.

Fram (talk)14:53, 3 February 2014
 

In the VisualEditor, I expect this to work.

Otherwise, the VisualEditor would be broken, and I would avoid it.

Nnemo (talk)21:20, 9 February 2014

User:Whatamidoing (WMF), User:Nnemo, I'm confused, and I don't have a Mac. :) Do we want to change something about https://bugzilla.wikimedia.org/show_bug.cgi?id=51045 ?

Elitre (WMF) (talk)19:51, 26 February 2014
 
 
 
 
 

Guide to theming changes

Is there a guide to what changes need to be made to the theme? It would be nice to be able to just add XYZ instead of having to reverse engineer every detail.

Indolering (talk)22:48, 25 February 2014

I'm not sure what you are trying to do. Is this "theme" in the Windows 98 sense of changing icons and colors? Or something else?

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

Add pre-made citation and image templates to VE, it's already in conventional source code mode

In the conventional edit source method, on the top toolbar there's a function for editors to select from a variety of pre-made reference templates, e.g. template for book references, website citations, newspaper citations etc, and all editors had to do was fill in the necessary info in the blanks in a popup window to formulate the citations. There's also a similar function for adding images, letting users to format the size and positioning. These pre-made templATES are very useful and convenient for editors, and are valuable for editors who aren't proficient in Wikicoding. The lack of this feature is an obstacle block preventing editors from using VE as much as they liked to.

88.150.205.11421:55, 1 March 2014

The references part is already in the pipeline, not sure about the images however.

Nicereddy (talk)07:01, 2 March 2014
 

Thanks for your note. The newest update to VisualEditor has more image-handling options than the edit toolbar that you've been using. If you haven't looked for a while, then feel free to play around in my sandbox here at MediaWiki to see what's happened. MediaWiki's version of VisualEditor is always a week or two ahead of Wikipedia's.

Last I heard, w:en:Wikipedia:RefToolbar/2.0 (the citation tool that you are presumably talking about) was only available at the English Wikipedia. It is not available at German, Spanish, French, etc. Wikipedias, nor is it available in other English projects, like the English Wiktionary. The VisualEditor team is working on a similar tool, with, they hope, the significant improvement that it will work at all of the projects instead of just one. You can see their current ideas at VisualEditor/Design/Reference Dialog and leave your suggestions on its talk page. This is a complex tool to get right, so it will probably be a while before we get to test it, much less to use it.

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

nowikis & double apos

Hello, first time trying VisualEditor, thanks a lot for your effort. in napwiki we use a lot of double appostrophes (as modern-authors in nap usually write... e.g. the famous song: Chist'è 'o paese d''o sole) that makes a contraction of what in arcaic+non directly neapolitan would be de lu--> d''o (as one example).

I was used to write the & # 39 ;' stuff. but when looking at my own try with the Visual Editor output I see you implemented nowikis for those exceptions.

Question is: have you ever considered putting & # 39 ;' instead of detecting and implementing a nowiki area? what do you think about it?

Thanks a lot.--C.R. (talk) 23:40, 25 February 2014 (UTC)

C.R. (talk)23:40, 25 February 2014

Hi there! It's weird that this wasn't noticed before at nap.wp. I'll investigate and we can keep talking about this at the Circulo as well. Thanks,

Elitre (WMF) (talk)18:12, 26 February 2014

Sorry because I was aware of that opportunity for improvement and never reported. You can take a look my message at our Circulo in napwiki, I'll make some more diffs. Thanks again! - To be precise for the information of the developing team, double apostrophes can also appear in the title of the article (e.g. nap:Cità d''o Vaticano). Since I'm not using VE every day I pass over this trap by putting & # 3 9 ;' as a routine. I wanted to know your opinion.

C.R. (talk)22:05, 26 February 2014

More details & trials in napwiki's Circulo. Regards & thanks.

C.R. (talk)22:20, 27 February 2014
 
 
 
First page
First page
Previous page
Previous page
Last page
Last page