Topic on Talk:VisualEditor on mobile/Section editing

Just saw the results of the A /B test, and it wasn't surprising at all. The mobile visualeditor is too limited to be used frequently.

Anyway, as far as section editing is concerned. I think that it ends up having limited impact because of the massive space that is being used by the site and the browser. Consider this, there is:

• Default browser toolbar / url bar.
• VE toolbar
• Sometimes a link bar shows up
• Virtual keyboard

Meaning that one an average phone you're left with 2 sentences to write on. You can test this out with Chrome's mobile emulator, by setting it to use nexus 5, and triggering the keyboard, or just check out https://imgur.com/aSDRFup. Aside from that at least for anynomous users, one great hindrance of all A/B tests is the awful big message asking users to register. It is presented in such a way that the average user will think that they must register before editing, even if the message says otherwise, because it actively blocks attempts to go directly to the editor until you click one of the buttons. There are a few times that I also get an overlay saying something about "welcome to wikipedia", also requiring another click.

One suggestion might be making the main VE toolbar collapsible, and perhaps considering a sidebar toolbar with just simple semi-transparent buttons.

Anyway, I think that until such issues are sorted, the benefits will be greater on desktop devices, and it might be more interesting to evaluate editing patterns there (e.g. how many section edits vs full edits), once it is deployed.

First off, thank you for being as thoughtful as you have been in sharing your feedback.

I want to make sure I have understood all of your points, address each one and then ask you a few questions (if you're open to them!).

1. Section Editing is likely to have a limited impact because it does not resolve the fact that the mobile visual editor is difficult to use. It is difficult to use because there is limited space to edit.

We also think the limited space to edit in the mobile visual editor can make it difficult to use. In fact, we are actively (as in, at this very moment) working on a new feature (see: VisualEditor on mobile/Edit cards) that will ideally create more space in the editor.

One of questions we are asking with this feature is: Will contributors complete their edits more often when there is more space for them to do so?

This leads me to wonder: would you be up for trying out an early version of this new feature and sharing what you think about it? We have some testing instructions here if you are up for it: 📲 Test Edit Cards v1.0

2. The current mobile VE onboarding experience is disruptive: the account registration overlay (see: https://imgur.com/iM8DPts) deters contributors from editing anonymously.

We know about 40% of contributors drop off before the editing interface is ready to be used (see: VisualEditor on mobile report) and we have ideas for why this could be. But, to my knowledge, we do not know the extent to which the account registration overlay is a cause for this attrition.

This, and the other feedback you shared about onboarding is now now included in a Phabricator task. Do you have any more thoughts about mobile onboarding? If you do, we would value seeing them. Here is the task where that conversation is starting: task:T226262

3. The "Welcome to Wikipedia" overlay (see: https://imgur.com/a/m9rfDh6) is disruptive to someone who is used to editing Wikipedia.

For someone who regularly contributes anonymously, I can see how having to tap through an extra screen each time you are trying to make an edit would feel unnecessary/disruptive. I've asked our team about the logic that determines when the "Welcome to Wikipedia" overlay is shown in an effort to determine whether this message can be suppressed for returning IP contributors. I will reply to this comment when we have an answer.

4. Section Editing is likely to have a greater impact on desktop where editing is more comfortable.

This would be an interesting hypothesis to test. Although for right now, our team's priority is simplify editing for contributors on mobile, using the visual editor. Here is some more detail about that: Annual Plan/2018-2019/Audiences

With this said: we do have a task open for enabling section editing on desktop in. Here is that task in case you would like to track its progress: task:T221908

5. Maybe changing the editing toolbar could improve the mobile visual editor's usability.

While I think this suggestion was made as a possible way of creating more space for contributors to edit, I thought you would value knowing we are actively thinking about how the editing toolbar within the mobile visual editor can be improved to help contributors more start and save their edits. There is some more information about that work on this project page: VisualEditor on mobile/Toolbar refresh

Your comments have been helpful and clarifying. Thank you for taking the time to share them ^ _ ^

And by the way, my name is Peter. I work as the product manager on the Editing Team. 👋

It is difficult to use because there is limited space to edit.

Yes, that's definitely one of the prime reasons.

This leads me to wonder: would you be up for trying out an early version of this new feature and sharing what you think about it?

I went through it. The linking problems:

• Adding link - the context is lost because of fullscreen , and a user might forget what they were linking in the first place. A fullscreen overlay is a bad interface for these kind of interactions. It would be better to use a smaller dropdown, next the bottom dialog.
• External / wiki link - A tab for this is completely unnecessary (on pc and mobile), it would be preferable to have a single checkbox to indicate if the link is internal or external.
• Full screen overlay - it could be a simpler dropdown, or alternatively, a sidebar (or collapsible bottom dialog) where the user can quickly show and hide the dialog without losing context.

Also turning on the browser spelling checker might reduce fixing typos before fixing the links. The referencing problems are pretty much the same as above.

We know about 40% of contributors drop off before the editing interface is ready to be used

For desktop devices, Mediawiki's silly interface forces an Editing interface load whenever one clicks any redlink, sometimes even for cases like red category links that don't even need to be created (see https://phabricator.wikimedia.org/T29311). Mobile devices stop unnecessary loads, and when triggered a full edit dumps the user on an empty page. It is a bit like throwing a user into a lake and hoping they can swim. The average person will try their best to get out ASAP.

"Welcome to Wikipedia"

It appears for first time editing. What's worse is that the two dialogs / overlays sometimes are triggered consecutively, one after the other. This could really be a dismissible one line "tip" that doesn't obscure the editing interface.

The likely only feasible way of exposing the full extent of the tools is either sub-menus or context aware toolbars.

This feedback is wonderful - thank you for taking the time to experiment with the prototype and communicate your thoughts. I'm going to try to respond to each one...

1. Add a new link: the fullscreen link search overlay feels disorienting

This is understandable. You are now the second person that has mentioned issues with the search overlay. We have a few ideas about what could be contributing to this feedback:

- Whole screen: as you mentioned, the search overlay takes over the whole screen.

-View title: the search overlay doesn't explicitly communicate what action you should be taking inside of it. The text in the title bar just says "Link."

-Transition: the way the search overlay "transitions"/"overtakes" the article and editing tools does not feel right.

- Context: besides showing text within the search field, the search overlay does not include greater context about the content/article you are trying to edit.

We will be addressing the View title issue in the second version of the Edit Cards that we are working on now. Here is a peek into what they are likely to look like: Edit Card v2.0 designs. If you have feedback on these, please let me know...these designs will get posted to the project page later this week.

We are also beginning to think about Transitions. That work and the conversation around it is happening in this Phabricator task: T224277

We will see if these interventions have an impact. Although, it is possible the root of this "loss of context" issue could turn out to be, as you suggested, that the search overlay takes over the whole screen. We're going to keep experimenting so we can find out for certain :)

2. Change a link target to an external link: two tabs are unnecessary.

Oh, interesting. Are you suggesting having two tabs – one for wikilinks and one for external links – is unnecessary because it adds friction to adding external links? If so, this friction is partially by design. Adding external links is not something we are trying to encourage more of.

Spellchecking

I want to make sure I've understood you correctly. Are you suggesting the following?

a) Spellchecking is not working for you in mobile VE.

(If so, what device and browser are you using? Spellchecking should work.)

b) Without spellchecking, contributors might be compelled to fix typos instead of doing more high value edits, like adding and modifying links and citations.

Taps on redlinks do not likely represent an intent to edit

It's funny you mention how contributors who tap on redlinks are not likely intending to make an edit. Right now, we are having a conversation about this very issue, albeit in a different context. We are talking about whether it makes sense to include edit sessions started by taps on red links in our calculation for edit completion rate. If you are curious, that conversation is happening on Phabricator, in this thread: exclude edit attempts initiated by red links.

Welcome to Wikipedia/onboarding appears for first time editors

You are correct. I checked and the "Welcome to Wikipedia" message will appear when you edit for the first time. Where "first time" is determined either by the prefs database (for logged-in users) or cookies (for logged-out users). This explanation is courtesy of the always helpful, @Whatamidoing (WMF).

This aside, I share your perspective that the mobile onboarding could be improved :)

Last thing! I had a couple quick questions about your experience with visual editor...

• How familiar are you with the visual editor on desktop?
• How familiar are you with the visual editor on mobile?
• How frequently do you use the visual editor on a mobile device?
• How frequently do you use the visual editor on desktop?

> Edit Card v2.0 designs. If you have feedback on these, please let me know...these designs will get posted to the project page later this week.

They mostly seem sensible except for the link label taking up the whole screen, as well as the search dialog (once again). At most 2 lines should be sufficient for that.

Also, while it is easy to type on a desktop device, it is downright painful to write long sequences on a mobile device. I'd suggest possibly providing existing links on the article as possible link locations, in addition, it would be pretty good to collect Special:whatlinkshere or related articles entries from the main namespace, as possible link targets.

> is unnecessary because it adds friction to adding external links?

Yes, partly. But the main reason is that it is one more component that needs to be learnt. More elements = more confusion.

> Spellchecking

I tested it out again, and it seems to mostly work. The concern was that if spellchecking was disabled, people might have more difficulty linking, because words might have typos.

> Redlinks

A good number of redlinks are quite simply caused by random typos, or mistakes. Others just waste time because in some cases a page may be protected from edits, and the user can't ever edit it anyway. It might be interesting to evaluate how many times people click red links to pages that they can't edit.

> How familiar are you with the visual editor on desktop?

I'm very familiar with it.

> How familiar are you with the visual editor on mobile?

I'm moderately familiar with it.

>How frequently do you use the visual editor on a mobile device?

Not frequently. Due to size constraints it seems more suitable for minor edits like fixing typos, and small changes.

> How frequently do you use the visual editor on desktop?

I've used it quite frequently in the past, but sporadically nowadays because I don't edit as much.

197.235, is the "size constraints" problem primarily about the visual editor, or does the mobile wikitext editor have the same problem?

>197.235, is the "size constraints" problem primarily about the visual editor, or does the mobile wikitext editor have the same problem?

Visualeditor's makes size constraints worse because of an excessive amount of toolbars, dialogs, and menu icons, and full screen overlays. This is a generic problem in any mobile editor, but visualeditor makes it worse. It is built in to its design.

But it is possible to make it a bit more convenient, compare VE mobile editor, to froala (test it on a mobile too) See examples, www.froala.com/wysiwyg-editor/examples/predefined-link-list , www.froala.com/wysiwyg-editor/examples/quick-insert. That was one of the more prominent mobile compatible editors that I found in a quick search, there are probably more that do it even better.

It is not perfect in any way, but it is in many ways more intuitive than something that hides content from the user. I think there is a usability guideline about never hiding essential information from the user.

RE: Edit Cards v2.0 designs

1. The fullscreen link search and label editing overlays can feel disorienting

We hear you on this. As you've seen, v2.0 still contains a full screen overlay for the link search dialog (we have not yet implemented a full screen dialog for editing an existing link's label. Although, we are planning to experiment with this in a future iteration.).

The full screen overlay remains for the link search dialog primarily remains because despite some instances of people finding the full screen overlay confusing, the majority of test participants were able to complete the editing tasks successfully without any mention of the full screen overlays.

This is not to say this feedback is anyway less valid, but rather that we have prioritized revising other parts of the workflows that blocked test participants from completing an editing task. A list of these "blocking" issues can be found here: phab: T227894

2. Typing on mobile requires significant effort. Potential improvement: offer more suggestions of potential internal link locations within search results

This is an interesting idea. I wonder: what gave rise to this idea? For example: how often – if at all – do you find yourself not finding the Wikpedia article you are seeking to link to within the search results while editing on mobile?

In the meantime, this idea is being track in Phabricator here: phab:T228353

3. Links to Wikipedia pages being separate from links to external webpage could be confusing to newer contributors.

This is a good catch. In fact, confusion around external links came up in our most recent user tests. The solution we have in mind for right now is to provide better instructions for contributors when they are searching for internal and external links. If you'd like to read more about this, here is where it came up in Phabricator: phab: T221299#5330448

4. If spellchecking was not working, it is more likely for words within articles to be misspelled. This could increase the likelihood contributors would end up trying to link to a page that doesn't exist (because it was misspelled).

This makes sense. Thank you for clarifying. Although, I'm glad to hear spellchecking is now working as you expect it to.

5. Red links

Interesting. To your earlier point, it might also be interesting to do something on desktop – similar to what is done on mobile – to create an intermediate between a potential contributor tapping on a red link and the editing interface loading. This is being talked about in Phabricator here: phab: T223339#5297463

6. Usage of VE

This is helpful context to know – I appreciate you sharing this.

Also! We have a version of Edit Cards version (v2) you can actually use.

Would you be open to trying this new version and sharing your experience with it?

Here is a link to test this new version, provided you are interested [and have the time!] : 📲Edit Cards v2

...either way, thank you for all of the time and thought you continue to put into your comments.

> I wonder: what gave rise to this idea? For example: how often – if at all – do you find yourself not finding the Wikpedia article you are seeking to link to within the search results while editing on mobile?

It is simple, an essay at a school, or a research paper, or even a wiki page, needs cross links, even if they are made up in fiction based documents. This is similar in wikis, e.g. a well written document about aids will always include tuberculosis because the two are linked. It is wasteful and tiresome to require users to have to type and search for what are obvious links especially in mobile devices with limited space, and bandwidth. In a perfect world, the search results would always prioritize such links, in addition to any pages that come from the same category or in intersection of categories.

> Redlinks : create an intermediate between a potential contributor tapping on a red link

In many cases an editing interface should never load.

In their desire to promote editing, earlier mediawiki developers were too overzealous. For instance all redlinks to user pages (e.g. user:Bugabuga) should never trigger an editor (and user:pages should really be Special), especially when it is not the actual user or the user doesn't even exist. The same applies to category pages, and is exacerbated by bugs like phabricator.wikimedia.org/T14019 . In the case of a non-existing user, someone can pre-emptively create an attack / spam /insult page for a popular username, and if the user is ever created they automatically get that spam for "free".

You'll also note that Special:wantedpages on this wiki is full of pages that should never be created. It is order of magnitudes worse in wikis like wikipedia.

Finally, many users (including myself) just open up the editor to see how something looks like when previewed, never intending to save, because mediawiki and Visualeditor lack a proper sandbox interface like Special:graphsandbox .

>Would you be open to trying this new version and sharing your experience with it?

Done.