Task overview

This task includes the work involved with resolving mobile VE's usability issues. "Usability issues" in this context refers to improving the frustrating and clumsy parts of common edit workflows [1] contributors encounter once the article becomes "editable."

Background

We are committed to increasing the number of edits on mobile, using VE.
Component to increasing the number of edits on mobile using VE, is contributors having success completing the edits they intend to make. Issue: the existing mobile VE experience can be feel clumsy and behave in ways contributors do not expect.

This work sits within our broader thinking that contributors will be more likely to complete the edits they set out to, when they can remain focused on their task at hand, without needing to spend a lot of effort doing so.

Todo

• @marcella represent "usability issues" from Usability Concerns in the "Usability issues we're committed to exploring" list below
• @ppelberg write "Definition of done"

Usability issues we're committed to exploring

Selections

These tasks relate to idiosyncratic ways that text selections behave on mobile, and how we handle them (or don't).

• (high priority) T136840 Selection dragging opens context menu on mobile, causing surface to move and breaking drag in Android Chrome
  • Problem: When the cursor is placed inside a link annotation (or similar), the editor's context menu under the toolbar opens, and to make space for it, the editing area moves down. If this happens accidentally while the user is trying to precisely place the cursor by dragging it, the cursor may end up in the wrong place, the interaction to place it may be reset, and other visual glitches may occur.
  • Solution: This will be resolved by the proposed context menu redesign (also known as edit cards: T221247), which among other changes moves the context menu to the bottom of the window. We also considered a more immediate solution to avoid moving the editing area, but it proves surprisingly difficult to do while also avoiding new visual glitches and results in new poor interaction patterns when the context menu covers the editing area, and so we decided to wait for the context menu redesign.
  • Status: Done

• T221723 iOS Safari: After inserting a link, the selection often ends up hidden by the keyboard
  • Problem: Because of the context menu opening and moving down the editing area, the newly inserted link scrolls out of view.
  • Solution: As above, context menu redesign (edit cards) should resolve this problem.
  • Status: Done

• (high priority) T204387 Can't drag a collapsed selection across a reference on mobile
  • Problem: On Android, try to drag a collapsed selection (cursor) by the blue handle across a reference. As soon as you get to the reference, the selection gets eaten.
  • Solution: This is a browser bug to which we haven't found an acceptable workaround, and may never.
  • Status: Not done

• (high priority) T202723 Mobile native selection context menu can obscure the VE toolbar
  • Problem: Browser's native selection menu (with tools like copy and paste) appears whenever and wherever there is a selection, and can appear on top of our tools.
  • Solution: We've analyzed several common browsers and their menu positioning. Now, whenever possible, the editor will scroll so that the native menu only covers text, rather than important tools.
  • Status: Done

• T204718 Mobile: Selection handles obscured after scrollCursorIntoView
  • Problem: Like in T202723, but in this case, the native selection menu appears underneath the touch keyboard.
  • Solution: Like in T202723.
  • Status: Done

• (high priority) T203555 On Android Chrome, Thai text selections next to a link can collapse unexpectedly
  • Problem: The way we implement links triggers selections to collapse (change from selection to a cursor) on mobile Chrome.
  • Solution: Unknown.
  • Status: Not done

• T109529 Cursor appears over the drop down menu for text styling in Mobile VisualEditor
  • Problem: When a toolbar dropdown menu is opened, it covers parts of the editing area. However, the native editing cursor would still be visible "through" the menu – apparently the native cursor (and selection) is rendered on top of everything, ignoring the normal ordering.
  • Solution: Deactivate the native cursor when opening a menu, then re-activate it when closing.
  • Status: Done

• T201329 Mobile: Hide keyboard while menus are open
  • Problem: When a toolbar dropdown menu is opened, the area available to it was limited by the native touch keyboard still open.
  • Solution: Close the keyboard, then re-open. Conveniently, this is equivalent to hiding the native cursor, as above in T109529.
  • Status: Done

• (high priority) T217797 Selection can appear on top of toolbar
  • Problem: When the editing area is scrolled so that the selection/cursor is hidden underneath our toolbar, the selection/cursor is still visible "through" it – apparently the native cursor (and selection) is rendered on top of everything, ignoring the normal ordering.
  • Solution: Again, we can't force the selection to be underneath the toolbar. The most promising solution seemed to be deactivating the selection when it is scrolled like this (T220634), but since this also hides the keyboard, it could be a poor interaction.
  • Status: Not done

• T217798 Selection lags behind scroll on iPhone
  • Problem: When the text selection is inside a scrollable container rather than the "root" of the page, iOS Safari would not render it correctly while scrolling.
  • Solution: We restructured the editor on iOS to avoid scrollable containers.
  • Status: Done

• T220633 Selection experiment: Don't re-activate selection after toolbar/dialog/inspector open on mobile
  • Problem: After closing any popup window, previously we re-activated the selection, which consequently opens the keyboard. The keyboard covers much of the text and makes it harder for the user to reorient themself.
  • Solution: Don't do it until the user taps on the deactivated selection.
  • Status: Done

• T218545 Cope with IMEs that make uncancellable alterations to DOM structural nodes
  • Problem: We made assumptions about how IMEs work (input method editors – custom keyboards, used especially for non-Latin-script languages) that turned out not to be true: we can't prevent them from making structural changes, e.g. merging paragraphs. As a result VisualEditor incorrectly detects text input in affected paragraphs.
  • Solution: At least one specific case was fixed (T217223), others might not be. Additional approaches: use mutation observer to detect structural deletions; make each ve.ce.ContentBranchNode track its own ve.ce.TextState.
  • Status: Not done

VisualEditor as default

These tasks are especially relevant if VisualEditor were to become the default editor, as they affect the first-time experience or editor switching.

• T209599 Show block notices on mobile visual editor
  • Problem: When mobile wikitext editor opens, and the user is blocked, it instead shows a popup showing the block information. This was not available in visual editor.
  • Solution: Make it show it. We had to update VisualEditor API code to return the block information in the necessary format.
  • Status: Done

• T221854 Show anon editor warning in mobile VE
  • Problem: When mobile wikitext editor opens, it shows a note about IP addresses and a prompt to log in. This was not available in visual editor.
  • Solution: Make it show it. Extra handling was needed to ensure it doesn't appear again when switching editors.
  • Status: Done

• T128422 Allow switching between editors with changes on mobile
  • Problem: Previously you could only switch editors on mobile at the beginning of an edit, and not during, which is very annoying when you realize that you need to do something that is much easier using one of the editors. Trying to switch would instead bring up a warning message and the save dialog; saving changes in the middle of an edit is a poor workaround, as they are immediately published to the live site.
  • Solution: We've refactored the initialization of both mobile editors to be able to pass the contents from the other editor, like on desktop. This involved changes in the MobileFrontend repository.
  • Status: Done

• T117716 Be able to switch to VisualEditor after starting to edit a section without losing edits
  • Problem: Initial implementation of section editing did not allow section editing, but most edits on mobile involve section edits.
  • Solution: Make it work. Due to semantics of editing references, visual edits to a section can affect wikitext outside of that section; therefore switching in that case has to expand to a full page edit.
  • Status: Done

• T222315 Abandon changes dialog is inconsistently shown after switching editors on mobile
  • Problem: After switching editors, the new editor would in some cases "forget" that changes have already been made in the other editor, and not warn about losing them when it was closed. Furthermore, the warning would sometimes not be shown when closing the editor by closing the browser tab (rather than by using the browser back button or the editor close button).
  • Solution: Straightforward, although tedious, as there are 8 times 3 possible cases.
  • Status: Done

Other

• (high priority) T212159 Scrolling a ProcessDialog scrolls the page behind on iOS Safari
  • Problem: When viewing a dialog on iOS, trying to scroll it can scroll the page in the background, as can be seen by the scrollbar movement. This is more than a small visual annoyance, because the browser seems to "remember" which element is being scrolled, and trying to scroll actually scrollable content inside the dialog afterwards may instead continue scrolling the page in the background. This is caused by a browser bug in Safari.
  • Solution: Several solutions have been proposed (T212159#5215550), with various drawbacks, and the most promising one forcing us to reduce the amount of vertical space available for the dialog. The Safari bug has been fixed in the meantime, and eventually we'll be able to remove this poor workaround.
  • Status: Done

• (high priority) T109508 Mobile VE: Consider providing a visible or larger area for CE when editing an empty page/creating a new page
  • Problem: When the content of the page was short (or empty), tapping the empty screen space below the content did nothing.
  • Solution: We set a minimum height on the content to avoid the issue.
  • Status: Done

• T216446 Page zooms slightly when focusing document on iPhone Chrome
  • Problem: When the user places a cursor for text input anywhere on the page, iOS browsers zoom in the page to ensure the text size is legible and the cursor can be comfortably placed in the right place with a finger. We suspect there's a browser bug that causes this zoom to unexpectedly occur even though our text is already using the required minimum size (16px). Additionally, the zoom occurs when placing the cursor in image captions, which intentionally use a smaller size. In both cases the zoom is more problematic than helpful, because it causes parts of the toolbar to disappear outside the viewport.
  • Solution: We found a way to cheat by telling the browser that zooming is disabled on our page (even though it isn't).
  • Status: Done

• T196839 Tapping in the editing area of the mobile visual editor causes the page to scroll up in Firefox for Android
  • Problem: The page scrolls up, as described. This is a browser bug.
  • Solution: Detect this and scroll back to the right position. This unfortunately causes visual flicker, but it's the best we can do.
  • Status: Done

• T211240 Mobile table editing should default to cell contents
  • Problem: We imported the table editing solution from desktop without considering interactions very much. We expect it to be more common to change the table text rather than the structure, but now it requires navigating a menu.
  • Solution: Defaulting to editing text on mobile to make it easier.
  • Status: Done

• T206829 Lack of next steps for new users on mobile devices when attempting to edit a protected page
  • Problem: When a page is protected, new users get a message like "This page is protected to prevent vandalism". It does not provide advice as to why it is locked or what to do next.
  • Solution: Guide the user to create an account or attempt editing pages that are not protected.
  • Status: Not done

---

Definitions

1. Common edit workflows: as defined by the features used most often in completed (read: successful) mobile VE edit sessions. See VisualEditor on mobile report: feature use