Wikimedia Bugzilla is closed!

Sorry - wrong section.

See:
http://en.wikipedia.org/w/index.php?title=Wikipedia:VisualEditor/Feedback&oldid=562471375#How_to_disable.3F

This was proposed before and even had a rejected patch by me: I13bbb954.

Note that this request is being repeated a lot, including by people who are unhappy that mousing over causes words to pop up, which they say disrupts reading the page. They would prefer the words be always visible to avoid this.

This is (besides bug 50542) one of the main reasons a seamless coexistence of VisualEditor and Wikitext editor is *not* possible at this time (as intended by the WMF).

@Krinkle: I think the change of the summary is wrong.

This is (from what I get from the comments, the discussions linked are a little less clear I'm afraid) not about section "edit source" links being loaded with delay (although this would be an issue, too).
It's about having to hover over the "edit" link to be able to see the "edit source link". They should both be directly accessible (without hovering and visibility changes).

Clarifying.

It seems no one has pointed out that pads and phones and touchscreens usually can't "hover".  Hover stuff should pretty much never be a necessary part of any web UI.

This should be a priority and not just an enhancement. To think that future versions of MediaWiki will be crippled longterm by this incredibly buggy and slow visual editor is very discouraging. 

At the very least there needs to be a preference for direct "edit" and "edit source" links built in to MediaWiki preferences on the edit tab of preferences. MediaWiki installations should not need a "gadget" preference added for this by each webmaster of every MediaWiki installation. 

The hidden link to "edit source" is slowing down many editors. For more info and other options: 

[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#Edit_and_edit_source_links_so_confusing_I_had_to_disable_Visual_Editor_in_preferences]]

[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#Note_the_many_unhappy_people_who_do_not_see_the_HIDDEN_.22edit_source.22_link]]

A thread linked in a previous comment (comment 1) has been archived:
[[Wikipedia:VisualEditor/Feedback/Archive_2013_07#How_to_disable.3F]]

There have been many more comments requesting a direct link to "edit source" on each section. See:
[[Wikipedia:VisualEditor/Feedback]] and its archives.

Slowing down the many editors who will continue to need source editing to edit complex things more easily is a really dumb idea. What is the logic? That you will irritate and trick editors into using the visual editor? That they will click the "edit" link instead of the "edit source" by being tricked? It is extremely irritating to have to spend extra time to get to source editing. You will not lack in bug reports by providing direct links to "edit source". 

For help on putting links in Bugzilla threads:
[[WP:Bugzilla]]

(In reply to comment #7)
> It seems no one has pointed out that pads and phones and touchscreens usually
> can't "hover".  Hover stuff should pretty much never be a necessary part of
> any web UI.

It's not a necessary part.  First, the 'edit source' link at the top does not require any hover.  Second, the same thing occurs ('edit source' section link is shown) when you focus on the 'edit' section link (onfocus).

It's difficult to focus without clicking on a touchscreen as well.

There is no way this should be "Lowest" in importance. Moved up to "Normal". I would change enhancement to "normal" also, but developers still seem dead set against making the choice dead simple and easy; or as one recent commenter wrote: "I am talking about giving editors easy way to choose the way they want to edit wikipedia." This is a common request. 

This needs to be a baked-in option in the edit tab of preferences. Not an ad hoc addon gadget as it is now in English Wikipedia. At least then registered editors can keep editing most efficiently. Choosing instantly between visual editor and source editor as the need arises. Registered editors do twice as many edits each month as anomymous IP editors. See chart:
[[File:Anonymous, registered, and bot edits. English Wikipedia timeline by percent of edits.png]]

So if you can't get it right for anonymous editors, at least allow registered editors to get it right with an option.

I misspoke. The only VE gadget now in preferences is this one: "Remove VisualEditor from the user interface." 

But my point is that each language version of Wikipedia should not have to create gadgets to provide VE options to its editors. 

Some preferences need to be provided in all MediaWiki installations. Or at least all Wikimedia installations of MediaWiki. For example:
*Display both "edit" and "edit source" links for sections without hover.
*Remove VisualEditor from the user interface (VE still loads, but it can not be used).

The first preference will mean that far fewer people will use the second preference. And the 2 preferences should be together so that people can see why they should choose the first preference over the other. The reason being that since VE still loads, one saves no load time by blocking access to using VE.

We've been kicking around the section editing behavior a fair bit, and we recognize the need for more flexibility, in part because the mouseover interface doesn't translate well to touch-based user interfaces. (We also recognize that section-editing in VisualEditor overall is still a bit of a crutch, but that's a larger discussion.)

What James and I would like to suggest here is a multi-way pref:

Section editing links
(x) Hybrid edit / edit source links [default]
( ) Edit sections via VisualEditor
( ) Edit sections as wikitext
( ) Disable section editing

The section editing feature is already disable-able, so we could just merge the pref.

Having three modes may seem like overkill at this stage but James feels that having an option for VisualEditor specifically at least puts a flag in the ground that we want to continue to improve section editing usability.

If folks think that's too much, we could just have a single

[ ] Support section editing via VisualEditor 

checkbox as this point, enabled by default, which turns on or off the hybrid mode.

We don't love the [ edit ] [ edit source ] static links, because it feels cluttered and not the kind of user experience that we want to support.

Thoughts? If either of these feels like a reasonable path forward, we can re-use this bug to track it, or start a new one.

(In reply to comment #13)
> We've been kicking around the section editing behavior a fair bit, and we
> recognize the need for more flexibility, in part because the mouseover
> interface doesn't translate well to touch-based user interfaces. (We also
> recognize that section-editing in VisualEditor overall is still a bit of a
> crutch, but that's a larger discussion.)

The two issues I'm seeing from users are that:

A. some editors are annoyed by the animation, particularly when scrolling or trying to target a specific link with a mouse quickly (or when using a touchscreen device, as you note); and

B. some editors are annoyed by VisualEditor generally and would simply like to disable/hide all traces of it.

> What James and I would like to suggest here is a multi-way pref:
> 
> Section editing links
> (x) Hybrid edit / edit source links [default]
> ( ) Edit sections via VisualEditor
> ( ) Edit sections as wikitext
> ( ) Disable section editing
> 
> The section editing feature is already disable-able, so we could just merge
> the pref.

This proposed solution solves problem A (the animation/hover issue) for the non-default case (not really helpful...), while inhibiting users who want both links but without any animation/hover. Not great. For problem B, it mitigates the impact of VisualEditor slightly (though users are still left with two tabs at the top of the page and probably slower load times as a result of VisualEditor).

> If folks think that's too much, we could just have a single
> 
> [ ] Support section editing via VisualEditor 
> 
> checkbox as this point, enabled by default, which turns on or off the hybrid
> mode.

This proposed solution doesn't solve problem A (animation/hover) and doesn't solve problem B (VisualEditor being enabled at all).

I'm not sure either proposed (compromise) solution is better than the current situation. However, there's already an existing user preference to disable VisualEditor that was inexplicably removed. It's difficult to tell how many editors are having problem A or are having problem B, but re-adding a user preference to disable VisualEditor would solve problem B for sure and largely solve problem A (for those who find problem A to be a problem...).

However this will be solved: Put thought in it!
I could imagine, that this decision will determine whether people will be disabling/hiding VE or keep using it along with the Wikitext editor.

A proposal from my side which might be a better fit from a user's point of view:

1) One setting (radio button) that determines which editor the user prefers for normal tasks (e.g. whether "edit" or "edit source" is shown first in toolbar or whether "edit" or "edit source" is shown as section edit link while the other one is shown on hover only)
(o) Prefer VisualEditor
( ) Prefer Wikitext Editor

2) One setting (radio button) to control how edit section links are handled
(o) show preferred edit link, show the other one on hover
( ) always show both edit section links
    ([edit|edit source] or the other way round depending on 1)
( ) only show preferred edit section link, don't show the other one at all.
( ) no edit section links at all

Custom CSS workaround available at https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29&oldid=563794311#Removing_the_animation_from_.22edit_source.22_section_links_on_Visual_Editor

Eduard Braun's preferences proposal would work to solve all the use cases, but I don't see how this is superior to just always showing both links, with a preference for reverting to the old behavior (which already exists).

Users will quickly adjust to clicking on their preferred mode, if both are always shown.

I'd prefer just showing them always, too (they can then be easily be hidden separately with CSS if necessary). But others prefer how it is done now (see Erik Möller's concerns in comment 13).

That's why I proposed a *prefer*ence here.

Anyway, if we should decide against a preference, showing them always is the way to go, because the current hovering effects are a nightmare for both, accessibility and customizeability.

A user on the English Wikipedia has today commented that the hover links are not always displaying when the system is being slow or unresponsive (their local system or the WMF servers). This obviously means that section editing in the classic editor is not available when its small footprint would be most beneficial

For reference they included their technical specs:
Downstream 20 Mb/s; Safari 6.0.5; Mac OS 10.8.4; 2.7 GHz Intel Core i7 (64-bit); 8 GB 1333 MHz DDR3; Flash 11.8.800.94; Java 1.6.0_51.

Are you sure the single link was the VE one?

I've seen some occasional cases where only the wikitext section links showed (this is also the default, e.g. if you have JavaScript disabled), but I can't recall one where only the VE section links showed, since the hover code has been setup.

(In reply to comment #20)
> Are you sure the single link was the VE one?
> 
> I've seen some occasional cases where only the wikitext section links showed
> (this is also the default, e.g. if you have JavaScript disabled), but I can't
> recall one where only the VE section links showed, since the hover code has
> been setup.

It probably was a link to Source Editor, but when 'edit' could go to VE or SE, such confusion and concern results.  On mobiles, it's not possible to see what the link is without pressing it.

> 
> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.
> 
> Thoughts? If either of these feels like a reasonable path forward, we can
> re-use this bug to track it, or start a new one.

You seem to be under the impression that [ edit ] [ edit source ] dynamic links that appear and disappear on hover feel ''less'' clutter, but that's not the case.

The least possible clutter that support both editors is to show shorter links, and make them static:

[ edit | source ]

or maybe get rid of the square brackets - they don't look at all necessary if both links are always visible:

Edit | source

See? No clutter at all, and more functional for all users regardless of their javascript or pointing device availability.

(In reply to comment #13 by Erik Moeller)

> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.

If provided as a preference then it is not clutter, at least to that user. 

If you don't provide this as a baked-in MediaWiki preference in the edit tab of preferences, then probably all Wikipedias in all languages, and all MediaWiki installations outside the Wikimedia world will provide buggy gadgets to provide the 2 static links. 

For example; the buggy CSS hack described here:
*[[Wikipedia:Village pump (technical)/Archive 114]] - see section "Removing the animation from 'edit source' section links on Visual Editor".

Is it not a thousand times better for it to be a fully-maintained, baked-in preference that will not constantly become buggy after various MediaWiki updates?

(In reply to comment #13)

> Section editing links
> (x) Hybrid edit / edit source links [default]
> ( ) Edit sections via VisualEditor
> ( ) Edit sections as wikitext
> ( ) Disable section editing
> 
> ...
> 
> We don't love the [ edit ] [ edit source ] static links, because it feels
> cluttered and not the kind of user experience that we want to support.
> 
> Thoughts? If either of these feels like a reasonable path forward, we can
> re-use this bug to track it, or start a new one.

My first thought is that you are putting a lot of effort into preserving an option that doesn't work. The first and easiest step is to remove the button for editing sections using the source editor until you actually have a source editor that can edit sections. Similarly, your preference scheme seems OK, but the default should be "Edit sections as wikitext", at least until you actually have a source editor that can edit sections.

My second thought is that for any choice that presents both, the animated is far worse, and probably gets worse for anyone that uses an interface with a long word that means "edit". When I see a page, it has little buttons labeled "bewerken" next to each section header, and as I'm moving my cursor there, it suddenly animates and "brontext bewerken" slides out to the side (which is strange, because my main button for editing source is labeled "bron bewerken"). Not surprisingly, I'm accustomed to having the thing I'm aiming for not purposely jump out of the way once I try to get there. I'd prefer getting a popup and having to click twice to having the thing I'm aiming for run away. Of course, I can try to remember to aim 3 cm to the right of the button and click *there*, but that is really an odd UI.

In terms of the VE feature that makes me curse every time it occurs, it's accidentally launching VE because the thing I was aiming for ran away while I was aiming for it.

Discussed again at [[Wikipedia:VisualEditor/Feedback#Edit Source is upsetting. When reading is upsetting]]

I think this comment highlights the problem for readers, not just editors or power users, presumably this is effecting IP readers as well:

It is VERY unpleaseant for me to read with the new feature. When I pass the mouse over the edi button, appears a new button saying edit source. I know these things are great for editors. But they are really distracting because one scrolls the mouse accidentally, in all the horizontal white stripe, i mean one scrolls the mouse over any place at the same height of the screen that Edit button, then Wild Edit source button appears. This is horrible. Please, make it harder to find. This distracts the eye a lot, i'm tottally serious. Plase, don't take this for a joke, i'm serious, the editors may have another way to do that, for example clicking on a small STATIC button for visual editing, that would be GREAT! Thank youSantropedro1

I agree we need to revisit this, Richard. We'll kick around some options, but we won't be able to get a new interface out before next week at the earliest.

(In reply to comment #24)
> The first and easiest step is to remove the button
> for editing sections using the source editor until you actually have a source
> editor that can edit sections.

To clarify, "source" is one of the terms VisualEditor uses for wikitext.  So, the wikitext/source section editor has not changed (other than the label).

What about my suggestion in comment 15? I still think this would be a workable solution resolving most of the controversy around section edit links.

The proposed setting whether to prefer VE or the WikiEditor could also be used to relabel the buttons to improve the workflow for everybody:
* "Edit" for the edit button using the preferred editor
* "Edit Source" or "Visual Edit" for the second button

This way a simple "Edit" button would be the default way to edit an article, regardless of which editor the user prefers, while the other option was around for special use cases.

(In reply to comment #24)

> My first thought is that you are putting a lot of effort into preserving an
> option that doesn't work. The first and easiest step is to remove the button
> for editing sections using the source editor until you actually have a source
> editor that can edit sections. Similarly, your preference scheme seems OK,
> but
> the default should be "Edit sections as wikitext", at least until you
> actually
> have a source editor that can edit sections.
> 

Sleepiness had obviously hit. Replace with 

My first thought is that you are putting a lot of effort into preserving an
option that doesn't work. The first and easiest step is to remove the button
for editing sections using the visual editor until you actually have a visual editor that can edit sections. Similarly, your preference scheme seems OK, but
the default should be "Edit sections as wikitext", at least until you
actually have a visual editor that can edit sections.

While sleepiness had hit, the point remains valid: since Visual Editor doesn't work for sections, there's no reason to damage the user interface by pretending to support it.

(In reply to comment #26 by Erik Moeller)
> I agree we need to revisit this, Richard. We'll kick around some options, but
> we won't be able to get a new interface out before next week at the earliest.

I see that this is being discussed here: 
*http://lists.wikimedia.org/pipermail/design/2013-July/subject.html 

I note that in this message 
http://lists.wikimedia.org/pipermail/design/2013-July/000804.html 
you agree with Trevor Parscal: "The hover effect is easy to drop - if we are all willing to take the hit on the clutter." 

I agree with you on this: "If we want experienced users to test it every once in a while, give feedback on how it can be made better, and have them see the improvements, finding a solution that poses the least burden on them will give us the biggest win."

It needs to be emphasized that there are many experienced users who edit anonymously (IP edits). They will not be able to go to preferences to choose other options. I think both hover and dropdown will irritate those experienced IP editors. I think the least cluttered longterm solution for them might be an "edit" link for the visual editor, and an icon for the source wikitext editor.

(In reply to comment #30)
> I think the least cluttered longterm solution for them might be
> an
> "edit" link for the visual editor, and an icon for the source wikitext
> editor.

Least cluttered perhaps, but a nightmare from a usability perspective. Either make both an icon (with alt text and tooltip) or both text links. Usability is far more important than avoiding a tiny bit of clutter.

(In reply to comment #31 by Chris McKenna)

I don't understand. How is it difficult to click a static icon that is there all the time (without having to go through any hovering)? There is a star icon at the top of almost every Wikipedia page for adding or removing a page from one's watchlist. 

If clicking an icon to get to the source wikitext editor is a nightmare, then how is making both links icons (as you suggest) better. I agree that the icon for the source wikitext editor should have alt text and tooltip. I should have stated that to begin with, but I assumed that would be done, just as it is for the watchlist star at the top of the page.

It's not about "being difficult" it's about consistency!

We have two equivalent ways of editing an article, therefore there should be two equivalent buttons.

Either both of them should be textual links or both of them should be icons.

None of them should be hidden by default.

(In reply to comment #33 by Eduard Braun)
> It's not about "being difficult" it's about consistency!
> 
> We have two equivalent ways of editing an article, therefore there should be
> two equivalent buttons.
> 
> Either both of them should be textual links or both of them should be icons.

Chris McKenna said that a text link and an icon link were "a nightmare from a usability perspective". 

You are saying "it's about consistency". Something can be completely usable and not be consistent. Why is consistency important to you? I do not see the need. 

According to your logic, we should delete the watchlist star icon because it is inconsistent with the text links at the top of pages. I believe the watchlist star icon was partially implemented as a way to save space at the top of pages, and to avoid having dropdown menus in smaller screens. 

The star icon allowed the viewing of Wikipedia pages at smaller screen widths before the dropdown menus showed up at the top. 

With edit links we are trying to avoid dropdowns, hover, and hidden edit links. 

An icon avoids clutter on section header lines. We still need "edit" as text at least once, since that is what makes Wikipedia what it is; the encyclopedia that anybody can *edit*.

(In reply to comment #34)
> Chris McKenna said that a text link and an icon link were "a nightmare from a
> usability perspective". 
> 
Yes, because they are inconsistent. 

> You are saying "it's about consistency". Something can be completely usable
> and
> not be consistent. Why is consistency important to you? I do not see the
> need. 
Because there are two ways to do the same job (edit the page) the ways of doing this need to look the same. 

> According to your logic, we should delete the watchlist star icon because it
> is
> inconsistent with the text links at the top of pages. 

The watchlist star is irrelevant to this discussion. It does not offer an alternative interface to achieve the same job as one of the text links. Completely different situation
  
> An icon avoids clutter on section header lines. We still need "edit" as text
> at
> least once, since that is what makes Wikipedia what it is; the encyclopedia
> that anybody can *edit*.

As explained above, "clutter" is very significantly less important than consistency. If we need it to say "edit" at least once then we need two text links. If two text links are two cluttered then we need two icons.

Just to point out the importance of this bug:

I just deactivated VisualEditor for this exact reason. I hate the hovering, and I'm mis-clicking regularly because of the VE replacing my well known "Edit" button. Since it is know activated also in my Homewiki (dewiki) I can't stand it any longer. Goodby VE!

Actually I *tried* to give it a chance (I did not deactivate it up to now, although there are many possibilities around how to do it!), but the agressive way the VE is replacing UI links is just not acceptable.

(In reply to comment #35 by Chris McKenna)

You said the following concerning why you want consistency:

> Because there are two ways to do the same job (edit the page) the ways of
> doing this need to look the same. 

...

> As explained above, "clutter" is very significantly less important than
> consistency. If we need it to say "edit" at least once then we need two text
> links. If two text links are two cluttered then we need two icons.

I still do not see how one edit link being text, and one being an icon would slow down your editing in any way. It sounds more like an esthetic preference.  

You like things in order. My room is probably a lot messier than yours. ;)

I think many options should be put in user preferences. The more the better as far as I am concerned. More happy editors means more editing gets done.

It's not about aesthetics (that's the reason we have the hover) it's about usability. 

One icon and one link would not likely slow me down considerably, but it would seriously impact new users and those who are not as computer savvy as the people who comment here. UIs need to consistent and accessible. There are two editors, and they need to be accessed in the same way. One icon and one link is guaranteed to cause confusion and it will require active thought far longer than two of the same (blame human psychology).

Take a look at the user interfaces of all the websites and programs you use, and look at the ones you don't regularly use because you can do the same easier elsewhere. Notice how all the ones you think of as good are clear, intuitive and internally consistent. This is not a coincidence.

(In reply to comment #38 by Chris McKenna)

I think completely new users would be more confused by having to choose between 2 edit links in text format. We want to encourage them to try the WYSIWYG visual editor first. 

If there is one link and one icon they see the VE "edit" link and so they click it to edit. Nothing could be simpler up to that point. 

Then they type in some text, and maybe add bold and italic via VE. So far, it is very simple, and exactly like their email composition.  

My Google Mail "compose" link goes directly to the WYSIWYG editor. So should the "edit" link in Wikipedia. 

Google Mail offers a "plain text mode" in an unlabeled dropdown menu at the bottom right of the compose window. 

We don't want to make wikitext source editing difficult to access, and so an icon is direct access. But we won't confuse completely new users by having two openly-labeled "edit" links.

(In reply to comment #39)
> (In reply to comment #38 by Chris McKenna)
> 
> I think completely new users would be more confused by having to choose
> between
> 2 edit links in text format. We want to encourage them to try the WYSIWYG
> visual editor first. 
> 
Why would you want to do that? Wouldn't it be better to steer them to the working editor if you need to "steer" them at all?

The navigation needs to remain *neutral*.

(In reply to comment #40 by kwwilliams@kwwilliams.com)

I was assuming of course that the visual editor was working well. I think that the visual editor should be turned off for anonymous IP users until it is working well. 

The VE should have true section editing (instead of whole-page editing as it does now) before IP users are allowed to use the VE. 

The VE also needs to be able to add references well before it is enabled again for IP users.

Glad to see this report already exists.

The idea of having text for VE editing and an icon for standard editing is *wrong* : you can't have two different methods (namely text and image) for advertising two options of a single choice, it's an aberration in terms of user interface (I'm no expert though), it's completely counter-intuitive.  Furthermore people use to associate text *with* image (caption), which makes it even more counter-intuitive.

As far as I'm concerned, I'd be satisfied if we could just switch the default editing method.  That is, I don't want to use VE as a standard, but an advertisement saying it may be useful in certain situations, so I'd prefer to keep it at the hand in case I want to give it a try.  However, I want the default editing action to be the standard editing.  That is, I want the first "modify" link to open the standard editor, and the link enabled by the hovering to be the VE.  Therefore, a simple "default editor = standard/VE" in the preferences would be enough for me.

However I understand the reading issue mentioned in comment 25, so I'd prefer if the hovering was completely disabled and both links always present (possibly with the option to hide one or both in the preferences).

Furthermore, I'm strongly for the idea to give the user the choice of his editor.  And when I say "user", I also mean "new user".  Not all users are WYSIWYGers, and though people seem (and they're probably right) to think that the standard editor may frighten some new users, hiding the standard editor by default may as well repel some new users.

Therefore the best solution in my opinion would be to simply disable the hovering and keeping both links, with the possibility to hide one or both in the preferences.  The argument that it's too many links is absurd : on a webpage there are links everywhere, internet users are used to ignore them.  It's even more true for WP where almost half of words are links…

Two more comments, after reading the discussion pointed by comment 30 : 

- this argument from Nick White needs emphasizing : "I don't think two small edit links by section headings constitute clutter. Rather it emphasises *the* key
thing about wikipedia, that editing is encouraged."

- the cluttering invoked to justify the hovering solution is actually an argument *against* the hovering : in any case when you hover the link the second option appears, so at one moment the same text will be visible anyway, and actually the hovering is adding a level of cluttering, blinking (including additional blinking when the hovering occurs without the user wanting to edit the section).

This needs to be fixed as soon as possible. Compounded annoyance is a very bad thing.

Let's go with [edit | edit source] for now.

(In reply to comment #44)
> This needs to be fixed as soon as possible. Compounded annoyance is a very
> bad
> thing.
> 
> Let's go with [edit | edit source] for now.

Based on the results so far at http://en.wikipedia.org/wiki/Wikipedia:VisualEditor/Default_State_RFC#Question_4:_Should_the_user_interface_explicitly_warn_editors_that_pressing_the_.22edit.22_button_is_using_beta_software.3F I would suggest that we go with

[beta editor | stable editor] 

or there will be more calls that WMF is not paying attention to the preferences of the Wikipedia community

I don't think [beta editor | stable editor] is good as it doesn't tell you what the functional difference between them is. We probably also want to stick with "edit" rather than "editor" (verb rather than noun). 

[visual edit (beta) | source edit] would be better but not optimal I don't think. 
[edit | edit visually (beta)] is the most compact that I can come up with, but I'm not claiming that as perfect. If one of them is labelled simply "edit" that should be listed first (regardless of which one it is).

Allowing the titles to be set by a MediaWiki: namespace page would be ideal, but that is a different request and I can't remember if it has a bug or not.

(In reply to comment #45)
> I would suggest that we go with
> 
> [beta editor | stable editor] 

No. That RFC (linked in comment 45) is specific to one wiki and doesn't suggest using [beta editor | stable editor], it suggests better advertising that VisualEditor is beta software. This request should be filed as a separate bug (and cross-referenced with [[Wikipedia:VisualEditor/Improvements]]).

(In reply to comment #46)
> [visual edit (beta) | source edit] would be better but not optimal I don't
> think. [edit | edit visually (beta)] is the most compact that I can come up
> with, but I'm not claiming that as perfect.

As stated in comment 47, we don't need to point out that it's beta in the section edit links (it would just be more annoying). We can advertise that VisualEditor is beta software in the VisualEditor interface itself (i.e., ?veaction=edit).

(In reply to comment #47)
> (In reply to comment #45)
> > I would suggest that we go with
> > 
> > [beta editor | stable editor] 
> 
> No. That RFC (linked in comment 45) ... suggests better advertising that
> VisualEditor is beta software. 

It specifically asks about the "user interface", not the advertising.

(In reply to comment #48)

> 
> ,,, we don't need to point out that it's beta in the
> section edit links (it would just be more annoying). 

I suggest that you go back and read that section. The question is explicit. 

Answer 1: The "edit" button should explicitly say "beta editor" 
Answer 4: Please label that Edit button more clearly as the way to the Beta version.
Answer 7: Indeed, per Kww (i.e. per answer 1)
Answer 17: per User:Kww (again, per answer 1)
Answer 26: There is no reason the "edit" button shouldn't mention the fact it's using VE
Answer  28: Per kww (i.e. per answer 1)
Answer 34: Per kww
Answer 39: Label "Edit for beta or worse" (just kidding). Perhaps label as "Edit slow" or "Edit risky" or such

All the remaining supports were in the context of actually changing the *button text*, even if the question said "user interface".

The only mention of the warning that it is beta came in the "Oppose" section. The very fact that two of the only three oppose votes mention placing the warning after VE has been invoked makes it clear that people commenting are commenting in the context that the *button* should warn people that it's beta.

(In reply to comment #49)
> The only mention of the warning that it is beta came in the "Oppose" section.
> The very fact that two of the only three oppose votes mention placing the
> warning after VE has been invoked makes it clear that people commenting are
> commenting in the context that the *button* should warn people that it's
> beta.

That RFC can provide guidance, but there are issues of ends versus means. Changing the section edit links to read "beta" would be a bad idea both for the English Wikipedia and for VisualEditor generally.

As suggested in comment 46, the exact wording should be customizable by editing the relevant MediaWiki message pages on-wiki. This bug should focus on removing the animation altogether and providing a sane default behavior for VisualEditor.

(In reply to comment #50)

> That RFC can provide guidance, but there are issues of ends versus means.

Exactly. The "end" of testing Visual Editor should not include the "means" of having it used by the unwary. The only people using VE at this point should be people that are completely aware that they are testing in addition to editing. We can't rely that new accounts have seen some previous notice, or that anonymous editors have seen any notice at all. The only way to ensure that people are aware that it is a beta editor is in the button text itself.

As per https://en.wikipedia.org/wiki/Wikipedia:VisualEditor/August_2013_update this has been fixed.