Talk:VisualEditor on mobile/Section editing

Prototype Feedback

We are interested in your thoughts on the prototype. Is this a better experience? Was it easier for you to stay focused on where you were within your edit? Was this expected behavior? Any and all comments are appreciated! Feedback will be summarized on the main project page. JKlein (WMF) (talk) 21:01, 11 January 2019 (UTC)

Editing

Seemed pretty nice and slick. My main issue was when keyboard was present it pushed the next and save "buttons" up a little too high.

2001:630:D0:8E08:85BB:976A:32A1:3B93 (talk) 15:06, 14 January 2019 (UTC)

Meant to attach this image [1] 2001:630:D0:8E08:85BB:976A:32A1:3B93 (talk) 15:07, 14 January 2019 (UTC)

Thanks for sharing this! I'll look into it. JKlein (WMF) (talk) 14:00, 11 February 2019 (UTC)

Feedback

Coming from desktop editing, this was more in line with expected behaviour of editing a section and helpful in the same way as it is on desktop: easier to focus on the particular part I wanted to change.

(I still find it somewhat confusing that I have to click on the check mark, then click save, then write my edit summary and click again to publish the change. To me, that seems like at least one step too many. But that has less to do with section editing.) Julle (talk) 07:54, 13 February 2019 (UTC)

Thanks @Julle - We have the multi-step save to publish process earmarked for design review, but I appreciate that you are confirming that's it is confusing. JKlein (WMF) (talk) 20:30, 13 February 2019 (UTC)

Feedback

From my iPhone, clicking "done" on the keyboard in lieu of the check mark felt very intuitive. After clicking "done", I was immediately able to save. Really easy to use. ELappen (WMF) (talk) 19:06, 13 February 2019 (UTC)

The good, the bad, and the ugly

Tracked in Phabricator
Task T216162

Tracked in Phabricator
Task T211255

It seems like a promising design and works well enough to deploy it. Here's some feedback:

The good

• Section editing is pretty intuitive
• It seems to be slightly more performant than loading the whole article
• It makes it easy to make quick fixes

The bad

• It seems to consume as much bandwidth as the loading of the full article.
• Harder to see all other references, so the user is forced to "try" to insert a new reference to see references defined elsewhere in the document. This should be a quick interface to give context while editing.
• Categories not shown, in edit or in preview. A section edit can result in categories or tracking categories being added by templates, extension tags, or parser functions.

The ugly

• Too many pencil icons. It simply looks ridiculous even on the desktop to have so many edit links, aside from just wasting bandwidth with unnecessary overlinking. Real estate on mobile devices is limited, so this makes things worse.
• Page title is cramped on the toolbar, and can't ever be properly visible for smaller devices. The browser url field contains more text but still makes this more visible. 197.235.77.159 (talk) 08:57, 14 February 2019 (UTC)

Many thanks for you feedback, it will be shared with the team.

Here's some additional context around the issues you have raised, which may be of interest:

It seems to consume as much bandwidth as the loading of the full article.

That is correct. We have evaluated the possibility of only requesting the required HTML, and may yet pursue that apporach in the future but for now we went with a client-side approach for a number of technical reasons. There are still many performance benefits to be had with this client-side approach as you observed.

Harder to see all other references

This is true, although will be somewhat unavoidable with any section editing solution, especially on pages with very long reference lists

Categories not shown

Categories are currently not shown in any of the mobile interfaces. If this changes we can reconsider if/how we want to support them in mobile section editing.

Too many pencil icons.... aside from just wasting bandwidth

The bandwidth overhead is pretty low, each icon is only a few bytes.

Real estate on mobile devices is limited, so this makes things worse.

In most cases the pencils occupy space that would otherwise be blank.

In general, the length of a section is not part of the parser output so we currently can't decide to render section edit links based on section length. ESanders (WMF) (talk) 18:25, 14 February 2019 (UTC)

This is true, although will be somewhat unavoidable with any section editing solution, especially on pages with very long reference lists.

To be clear, the idea here is to simply take pictured "re-use references dialog", and make it possible to show it separately outside the dialog. For example, it could be triggered by a small icon at the bottom of the page, or it could be swiped from the left or right in its own pseudo-toolbar. The idea could even be extended to contain collections of items on the page, references, categories, interwikis, et al.

Categories are currently not shown in any of the mobile interfaces. If this changes we can reconsider if/how we want to support them in mobile section editing.

That's true. Generally speaking, using categories for tracking errors has always been a bad approach, although it is better than nothing. For example, consider adding an empty <ref></ref> reference. It currently triggers no error at all. Perhaps, at a minimum it would be a good idea to have error reporting similar to the desktop interface.

As for the extra pencils, it might be more sensible to only show the icons in the view area, maybe just the ones in the middle. The user will quickly learn to scroll up or down to click the others.

Alternatively, doing away with all icons except for the first one, and requiring a double tapping or triple tapping to edit an section would be more sensible than excessive icons or links. That could easily be a tip taught to the user when they click the edit icon for the first time. Anyway, that's a considerable change that might be a separate project. 197.235.77.159 (talk) 20:10, 14 February 2019 (UTC)

Can't to switch from wikitext section mode to visual editor section

Issue: Unable to switch from wikitext section to visual editor section

Steps to reproduce 1. Edit section using wikitext editor 2. Click the dropdown to switch to visual editor

Expected Loads just a section in VE

Actual Loads the whole article in visual editor. 197.235.77.159 (talk) 00:10, 15 February 2019 (UTC)

Note, this only happens after toggling the desktop mode, when clicked on the footer. So this might not be a 100% relevant to mobile devices. 197.235.77.159 (talk) 00:40, 15 February 2019 (UTC)

A lot of established editors use the desktop system on their mobile devices, so it's possible that this will happen more than it might be expected. Whatamidoing (WMF) (talk) 02:17, 15 February 2019 (UTC)

I'm having trouble reproducing this issue because when I try to switch modes, I get the prompt to save. This is documented in phabricator.

Tracked in Phabricator
Task T128422

JKlein (WMF) (talk) 14:03, 6 March 2019 (UTC)

197.235, if you see this, could you tell us what your web browser and OS is? For example, Safari on iOS or Chrome on Windows 10. Whatamidoing (WMF) (talk) 18:43, 7 March 2019 (UTC)

Page not scrolling back to edited section once saved

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce 1. Click pencil to edit section 2. Make edit 3. Save page

Expected

Page scrolls back to section.

Actual

Page shown on top.

It seems reasonable that the user would like to see the saved section. Currently they'll need to scroll or try browser find.

Possible solution:

• Scroll to edited section.
• Show note on top with link to allow user to jump to section. 197.235.77.159 (talk) 00:26, 15 February 2019 (UTC)

Thanks! This an absolutely reasonable expectation. Iamjessklein (talk) 14:50, 20 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

When closing a section, page doesn't go back to read mode

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Steps to reproduce

1. Click http://visualeditor-prototype.wmflabs.org/w/index.php?title=Pride_and_Prejudice&veaction=edit&section=5&action=edit
2. Click the "X" (close) button to go back to read mode

Expected

The user is in read mode

Actual

A blank page is shown with no information.

Note

This must be done directly by clicking the link. 197.235.245.211 (talk) 16:53, 20 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Lose edits if idle on page

This is being tracked https://phabricator.wikimedia.org/T217783

Steps to reproduce:

1. On iOS open http://visualeditor-test.wmflabs.org/w/index.php?title=Pride_and_Prejudice&mobileaction=toggle_view_mobile from GChat.
2. Allow phone to enter sleep mode and return to lock screen
3. Unlock phone and return to page where you were editing

Expected:

The page would still be there and editable.

Notes: The black loading screen appeared and it shut out of Mobile Web and returned to the GChat app. The phone may not have been able to handle the testing server, it may just be too much for it. However, from a user perspective this could be discouraging. Not sure what can do about it. 98.218.225.109 (talk) 08:20, 26 February 2019 (UTC)

I don't know what we can do about it in the end (beyond "recover your edit", which would be handy there when it works). You're right, and there are all kinds of ways for that to happen: in addition to the case of the phone going to sleep while you're reading, you could lose your work because your battery dies, or the browser might drops everything in the editing window if it needs all the memory to open a large webpage. I'm sure you could think of more scenarios than I can right now. It is a worrying thing.

Do you happen to know whether Android behaves the same way? Whatamidoing (WMF) (talk) 00:51, 27 February 2019 (UTC)

It worked but VE took double the time to load

Both worked well for me with no preference either way. I did however compare to wikitext editing and it loaded in half the time. 213.57.79.144 (talk) 22:24, 26 February 2019 (UTC)

Thanks! Whatamidoing (WMF) (talk) 00:52, 27 February 2019 (UTC)

Thank you for giving the prototype a try ^ _ ^

That's reassuring to hear about the loading times you encountered. Out of curiosity, in the times you've used visual editor on mobile in the past, how often do you remember feeling like you were "waiting" for the editing interface? PPelberg (WMF) (talk) 16:20, 4 March 2019 (UTC)

@PPelberg (WMF), check the title—VE's loading time was worse, not better :) Neil Shah-Quinn (WMF) (talk) 01:20, 13 March 2019 (UTC)

Oh, no – I'm a bit unclear...@Neil P. Quinn-WMF, what do you think is meant by this, "I did however compare to wikitext editing and it loaded in half the time." here?

I interpreted "it" in the second sentence of the post's body as referring to section editing given the thread's title, but perhaps "it" is actually a reference wikitext in which case, yes, I am mistaken...

PPelberg (WMF) (talk) 07:00, 13 March 2019 (UTC)

213.57.79.144 if you're out there, somewhere, please know your help is needed 🔭 PPelberg (WMF) (talk) 07:01, 13 March 2019 (UTC)

Non-editor feedback

• Version A, Version B: which experience did you prefer? Why?
• What device and browser did you use to test Versions A and B?
• How familiar are you with the visual editor?
  • Not at all – I never use it
  • Familiar – I use it occasionally to make edits
  • Very familiar – I could teach someone how to edit
• How frequently do you use the visual editor on a mobile device?
  • On a daily basis
  • On a weekly basis
  • On a monthly basis
  • Less often than a monthly basis
  • Never 100.12.66.238 (talk) 16:07, 28 February 2019 (UTC)

Sorry, I hit ctrl-enter and didn't realize it was going to post

• Version A, Version B: which experience did you prefer? Why? Version B took significantly longer to open, and I didn't notice a significant difference in usage from a casual use. Version B also had a functioning "remove format" button where version A's did nothing.
• What device and browser did you use to test Versions A and B? Android 9 Chrome browser, Google Pixel 1
• How familiar are you with the visual editor?
  • Not at all – I never use it
• How frequently do you use the visual editor on a mobile device?
  • Never 100.12.66.238 (talk) 16:11, 28 February 2019 (UTC)

Feedback

Extra white space is a known issue being tracked.

Tracked in Phabricator
Task T217769

• Version A, Version B: which experience did you prefer? Why?
  • I preferred Version B, although the load time was a bit slower than I had expected. That being said the loading indicator was significantly clearer in Version B then on Version A.
  • I liked being able to focus on the section. When loading Version A I was initially brought to the Wikitext editor and then my place was lost when I switched to VE.
  • One negative with Version B was the extra empty space at the bottom of the section, it made it harder for me to gauge by looking at the scroll indicator how much text was included in the editing view (eg. would it be one section or all of the sections below the selected section).
  • I also found the two step process (check and then publish) for publishing my edit to be a bit confusing and cumbersome.
• What device and browser did you use to test Versions A and B?
  • iPhone X running iOS 12.1.2
  • Chrome app
• How familiar are you with the visual editor?
  • Familiar
• How frequently do you use the visual editor on a mobile device?
  • Never (Sorry, I always edit in the app!) CMadeo (WMF) (talk) 16:55, 28 February 2019 (UTC)

Thanks @CMadeo (WMF)

The white space is a known issue and can be tracked on phabricator. JKlein (WMF) (talk) 13:50, 6 March 2019 (UTC)

Non-editor feedback

Cool stuff.

General note: perhaps this was done intentionally, but I wasn't able to find any instructions regarding which parts of the prototypes to focus on/compare when giving feedback. I think it would be useful to get a bit of guidance regarding what is different about Version A and B, and perhaps even a sense of what decision you all are trying to make, i.e. why you're testing these two versions.

• Version A, Version B: which experience did you prefer? Why?
  • I preferred version B, because with version A when I tapped the edit icon I saw the top of the article while the editor loaded (screenshot), which seemed more jarring/confusing than version B where the section I was on remains on-screen the entire time (screenshot).
• What device and browser did you use to test Versions A and B?
  • Samsung Galaxy, Chrome
• How familiar are you with the visual editor?
  • Familiar – I use it occasionally to make edits
• How frequently do you use the visual editor on a mobile device?
  • Less often than a monthly basis AHollender (WMF) (talk) 19:53, 4 March 2019 (UTC)

Thanks for the feedback @AHollender (WMF) - we were trying to leave the questions and test open-ended, but will keep this in mind for future tests. JKlein (WMF) (talk) 13:29, 6 March 2019 (UTC)

What about desktop VE 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. 197.235.75.43 (talk) 11:11, 17 June 2019 (UTC)

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. 👋 PPelberg (WMF) (talk) 16:28, 21 June 2019 (UTC)

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. 197.235.65.98 (talk) 13:04, 22 June 2019 (UTC)

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? PPelberg (WMF) (talk) 01:16, 2 July 2019 (UTC)

> 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.66.163 (talk) 17:59, 3 July 2019 (UTC)

197.235, is the "size constraints" problem primarily about the visual editor, or does the mobile wikitext editor have the same problem? Whatamidoing (WMF) (talk) 20:12, 9 July 2019 (UTC)

>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. 197.235.66.142 (talk) 19:00, 10 July 2019 (UTC)

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.

PPelberg (WMF) (talk) 00:33, 18 July 2019 (UTC)

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. PPelberg (WMF) (talk) 00:35, 18 July 2019 (UTC)

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

197.235.76.58 (talk) 10:35, 19 July 2019 (UTC)

A/B test results: 1% --> 3%

Previously, we had stated contributors using Section Editing are 1% more likely to save the edits they start than contributors using full-page editing. The correct difference in the probability that a contributor using Section Editing will complete their edit compared to a contributor using full page editing is ~3%*.

We are sorry for any confusion this might have caused.

---

*2.71% to be more precise PPelberg (WMF) (talk) 01:36, 27 July 2019 (UTC)