MediaWiki talk:Visualeditor-preference-betatempdisable

Changing this message

Hi. This is the label next to the checkbox in Special:Preferences that allows a user to completely disable VisualEditor.

I believe we need to discuss whether this label should be changed. Many believe that there should be a clear pact with the community that VisualEditor will always be able to be completely disabled.

Thoughts? --MZMcBride (talk) 06:51, 6 August 2013 (UTC)[reply]

I take it you mean:

Usability features
[ ] Temporarily disable VisualEditor while it is in beta

I agree in principle. After all, who decides when the "beta" is over? Much simpler to be able to disable either editor, like this:

General
[ ] Enable Source Editor
[ ] Enable Visual Editor

I don't think you can automatically map the "during beta" decision, though, so in the short term three checkboxes might be better:

General
[ ] Enable Source Editor
[ ] Enable Visual Editor
[ ] Temporarily disable VisualEditor while it is in beta

Hope this helps - Pointillist (talk) 08:38, 6 August 2013 (UTC)[reply]

While at some point we might want to allow disabling the source (hate that term, should be "wikitext" or "wikimarkup") editor, VE isn't nearly far enough along to make that practical. As it is, I think the current label is unduly aggressive and really isn't helping get any support for VE. I'd change the name. Now, of course, I would expect the VE team to uncheck it for everyone when VE leaves beta; I would hope they would do a better job at communicating, though, such as linking to an information sheet from the announcement that VE has left beta that includes (suitably unemphasized, but findable) instructions for turning VE off. Adam Cuerden ^(talk) 13:44, 6 August 2013 (UTC)[reply]

Adam: Pointillist's wording carefully avoids 'disable' and double negatives. The suggested UI is about positive enablement. Regarding "Source/Wikitext, I would agreed, and refine that too:

General
[×] Enable Wikitext Editor
[×] Enable Visual Editor
[×] Temporarily disable VisualEditor while it is in beta. You will be warned when VisualEditor is ready for use

The reasons being two-fold; (a) "Source" has negative connotations that have not previously been presented to Wikipedia contributors; (b) "Source" in a literary context is known to mean citations/references/attribution/bibliography. —Sladen (talk) 14:14, 6 August 2013 (UTC)[reply]

I'm good with that. In which case the [edit source] links should be labelled [edit wikitext] likewise. It might be more neutral to say "advised" rather than "warned", though! - Pointillist (talk) 15:07, 6 August 2013 (UTC)[reply]

Adam, I agree that the Wikitext Editor needs to remain enabled. But it would be helpful to get the final UI for these preferences in place sooner rather than later. I'm hoping that when the Visual Editor has bedded in it will be possible to make a series of guides/videos to on-board new contributors. If we include screen-shots it would be nice if they were accurate. BTW, I'm not talking about a "noddy" intro. We need businesslike guidance that you could give to somebody well-educated and reasonably computer-literate, so that they can make a useful contribution (i.e. citing references and inserting images, not just fixing typos) from day 1. - Pointillist (talk) 15:18, 6 August 2013 (UTC)[reply]

Heh, you all are showing your inexperience with user interface design in this discussion. If you use checkboxes as proposed, what happens when someone selects neither? They simply can't edit?

The question right now is whether to re-label the current single checkbox. Anything else would require further development. --MZMcBride (talk) 16:40, 6 August 2013 (UTC)[reply]

All user interfaces are state machines. If not being able to edit is a valid state for a user, their preferences UI should accept it. If not, then you can challenge the decision, or disallow the choice, or apply radio button behavior. You knew all that really, didn't you!? In answer to your original question, I don't think it is safe to convert the user's decision Temporarily disable VisualEditor while it is in beta into Do not enable Visual Editor. Hey, here's a new question: what action does clicking on a redlink perform? All the best - Pointillist (talk) 17:47, 6 August 2013 (UTC)[reply]

Not being able to edit may be a valid state if the user is blocked. Otherwise, allowing the user to (accidentally) disable his or her ability to edit seems like a pretty nasty user experience. You'd use radio buttons or a drop-down menu ("preferred editor:"), yeah.

If you think it's unsafe to convert the user preference, all right. I think some people are keen on seeing a more permanent off switch for VisualEditor. That exists today, it's simply labeled as being a temporary switch. By setting user expectations (or "forming a pact" with the user), the ability to always have an off switch could become ingrained. That was my thought.

Regarding what happens when you click a red link, it somewhat depends. VisualEditor still has no concept of red links. ;-) The MediaWiki interface appends a &redlink=1 URL parameter to red links, which can alter their behavior. Sometimes they'll present with an editing window. Sometimes they'll show "no article here" text. It depends whether the user has permission to create a new page (e.g., IP editors do not and many titles are blacklisted from creation) and whether the user is blocked. (Previously, there were frequent reports of blocked users clicking a red link and being shown a nasty "you've been blocked" screen. The &redlink=1 URL parameter is supposed to mitigate this, as I understand it.)

Hope that helps. --MZMcBride (talk) 18:40, 6 August 2013 (UTC)[reply]

The fact that redlinks, undo, etc., have always used the classic wikitext editor should be an indication that VisualEditor has never actually been "the default". Whatamidoing (WMF) (talk) 19:24, 6 August 2013 (UTC)[reply]

The current system is obviously no good as anything other than a temporary solution, because the WMF can claim on any whim of theirs that the VE isn't in beta any more, and remove the switch. Long-term, the proposed solution is a good one; right now, we simply need an enable or disable VE button. Based on current consensus, it should be an "enable VE" button. Lukeno94 (tell Luke off here) 18:45, 6 August 2013 (UTC)[reply]
I don't know this for certain, but my assumption is the same as Luke's: this switch will likely be removed some day, and thus changing the label would only mislead editors into believing that it is permanent. MatmaRex's gadget, on the other hand, will likely stay here for years to come. Whatamidoing (WMF) (talk) 19:24, 6 August 2013 (UTC)[reply]

I think you've missed the point entirely. We're talking about a permanent switch here, not a temporary one. Quite why the WMF refuses to see that people want a proper, permanent, non-gadget based off switch is beyond me. It would take all of five seconds to make it permanent... Lukeno94 (tell Luke off here) 19:29, 6 August 2013 (UTC)[reply]
No, I haven't missed the point. You want a prefs switch that the devs will choose to keep in the Mediawiki software forever. However, what actually you've got is a prefs switch that the devs have publicly stated that they plan to remove from the software someday. Switches like this exist because they are in the software, not because someone made a label for them. Exactly like any other part of Mediawiki, this bit of software will exist only as long as devs choose to keep that bit of code on the servers. No matter what you type on this local label, the devs are still fully capable of deleting the entire section of software and making the label's contents completely irrelevant. Whatamidoing (WMF) (talk) 18:37, 7 August 2013 (UTC)[reply]

"You'd use radio buttons or a drop-down menu ("preferred editor:"), yeah." Nope, I'd take off ma stetson, scratch m'gray hairs and ask "how the heck did we get to talking about UI like it was gonna band-aid a saguaro?" I'd probably hawk and spit a little just to show I'm not afraid of "yeah" even though back at ma ranch it used to be a sign of just-barely-concealed contempt, and mebbe that's what you intended. But hey, you were the one who suggested monkeying with labels. Actually, there are situations where someone might be registered but not wish to edit:

User wants the benefits of having a watchlist and sight of notifications/links that are only displayed when signed-in, but doesn't want to edit.
Account has been pre-created e.g. as part of an outreach/GLAM initiative. The facilitator will explain how to enable the various editing modes.
Account is a permitted secondary account, e.g. for use when travelling, and disabling edits is one layer of defense if the account is compromised.
Maybe in future, it turns out that turning off editing means significantly less script is downloaded by default. Like that could never happen, "yeah"?
Maybe in future, users can set preferences at the device level, e.g. one set for their PC and another for their smartphone. Personally I would love that—imagine being able to set different default image sizes and scripts for different ways of reading Wikipedia.

We shouldn't be in this place to begin with. Let's all try to stay civil while we try to get somewhere better. - Pointillist (talk) 21:03, 6 August 2013 (UTC)[reply]

Nobody is being uncivil. I have no idea what the hell you're talking about in this most recent reply. It looks as though you're trying to brainstorm implausible scenarios in order to justify bad user interface design. Okay. But I was merely focused on whether the label of this user preference should be changed. I'm finished here; you're wasting my time. --MZMcBride (talk) 21:29, 6 August 2013 (UTC)[reply]

OK, I'll be net. You were poking fun at the idea of making UI decisions on the fly. I agree: UX should follow principles of interaction that have been thought through in advance. I thought your original proposal was wrong, but your energy and influence could be harnessed to find a better solution. I offered a starting point. There's a variety of established techniques for presenting constrained choices via a single page (i.e. without using a wizard). I'm sorry the interaction didn't work out this time. On another occasion, maybe you'd have wanted to derive a workable solution. - Pointillist (talk) 21:49, 6 August 2013 (UTC)[reply]

Using radio buttons means an extra line, and possibly two extra lines to cover "yes/yes" (something I would want and use) and "no/no" (something I'd do to amuse myself and maybe people would start doing as a way of taking a WP:WIKIBREAK).

I'm not sure where the VE project and this thread are headed. Why would someone want to disable the VE or "source" editing? Are they concerned about the screen real-estate used by the tabs and in the section headers? I disabled the VE for most of July because the hovering thing was screwing me up too much. Once the UI was changed to use separate links instead of hovering I re-enabled the VE and use it those times it'll work.

I assume someone in the development team liked hovering enough to spend time coding the thing. If we throw hovering back into the mix then I'd want the preferences choices to include the ability to control hovering vs. separate links and possibly control over the ordering and wording of the options as some people will want to replace the word "source" with something else. --Marc Kupper|talk 00:53, 8 August 2013 (UTC)[reply]

MZMcBride, "no suitable editor available" appears to be a valid everyday-encountered state. It appears frequently on Wikipedia already—where an account does not have sufficient permission to save the current page—in these cases View source is shown where the edit tab(s) would be expected (nb. Ideally this could be changed to View wikitext). —Sladen (talk) 15:17, 7 August 2013 (UTC)[reply]