Page MenuHomePhabricator

Converge on a single DiscussionTools source mode
Open, Needs TriagePublic

Description

This task is about converging on a single source editing mode to reduce the resources required to ensure volunteers can use Discussiontools in all the ways they expect.

Note: work on this task depends on us verifying that no blocking issues surface in "Step 1." and "Step 2" of the "Plan" below.

Plan

Step #ActionPurposeTicket
1.Offer the source mode with tools as an opt-in setting for everyone who has DT enabled1) Verify people who have expressed interest in this new mode functions as they expect it to. 2) Determine whether people who start using the new mode continue using it.T276608
2.Offer source mode with tools as an opt-out setting for some of the people who have DT enabled1) Identify and address edge cases. 2) Determine whether the source mode with tools has parity with the existing source mode.T276609
3.Converge on a single source mode with tools within DiscussionTools1. Increase the maintainability of Discussion Tools Note: this step assumes no blocking issues surface in "Step 1." and "Step 2."T276607

Background

T275950 introduced a new mode within Discussiontools.

Introducing this "mode" has meant volunteers gained access tools for pinging, linking, and formatting text within Discussiontools source editing interfaces.

It has also meant there are now three Discussiontools modes: 1) Visual 2) Source and 3) Source mode with tools.

There being "three modes" is notable in this context for it increases the resources required to ensure volunteers can use Discussiontools in all the ways they expect.

Related Objects

StatusSubtypeAssignedTask
OpenNone
OpenNone
Resolved ppelberg
ResolvedEsanders
ResolvedEsanders
ResolvedRyasmeen
Resolved ppelberg
Declined ppelberg
ResolvedNone
Resolved ppelberg
ResolvedEsanders
ResolvedEsanders
ResolvedEsanders
Resolved ppelberg
Resolved ppelberg
DeclinedNone
DeclinedNone
Resolved Whatamidoing-WMF
ResolvedDLynch
Resolvedmatmarex
OpenNone

Event Timeline

Update: Edits made in source mode without the toolbar accounted for only 0.36% of source mode replies in November[1] (about 0.28% of all replies).

  1. https://superset.wikimedia.org/superset/dashboard/152/

Now that the reply tool has been deployed at almost all wikis, it might be a good time to revisit this and clear up this maintenance debt. Very few users are using and it is not tested as part of our regular QA.

I'd like us to remove this technical/maintenance/testing debt.

From superset, in the last month still only 0.4% of source mode replies were made with the toolbar disabled.

revision_tagssum_edit_count
discussiontools-source56585
discussiontools-source-enhanced56366

It may not be entirely rational of me, but I'd prefer to keep the two modes forever. As a technology purist I wish that DiscussionTools wouldn't depend on VisualEditor at all. (We currently rely on various other bits and pieces of it that would be better placed in MediaWiki core along with Parsoid.)

On a slightly more rational note: users continue to occasionally report issues with input to the VE surface on various devices (e.g. T292538), and we're not very good at fixing them, so I want to have a fallback mode that works for these users.

On a slightly more rational note: users continue to occasionally report issues with input to the VE surface on various devices (e.g. T292538), and we're not very good at fixing them, so I want to have a fallback mode that works for these users.

In practice this is completely undiscoverable:

  1. Full preferences are not available on mobile
  2. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

The bug you linked to is basically a unsupported workflow (desktop site on mobile), but if there are genuine input issues we should prioritise fixing them, and not pretend that maintaining this rarely used code path is helping.

I’m happy to report breakages and live with them for a few days if this means that I can continue to use the interface that better integrates with OS features (like primary selection on Linux); works without JavaScript (once loaded), making it more reliable in case of CPU spikes; and doesn’t try to be smarter than me (e.g. I can input literal non-breaking spaces).

  1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

  1. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

People helping on technical village pumps can advise them to do so, leading a much faster unblock of their workflows than the code fix (take the current situation: learning that I have to toggle my preferences unblocked my workflow in minutes, others’ workflows probably in hours; the code fix will unblock it in days).

better integrates with OS features (like primary selection on Linux);

Does this not work with our surface?

works without JavaScript (once loaded), making it more reliable in case of CPU spikes

Especially with the small documents involved with replies, CPU is unlikely to be a bottle neck

(e.g. I can input literal non-breaking spaces).

There's NBSP in the special chracters menu, and a keyboard shortcut (ctrl+shift+space). NBSP is a special case because most of the time it is inserted it is accidental, so we would get more complaints if we didn't remove them, but our IME support is pretty solid at this point.

  1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

They are, but finding DiscussionTools options are still several menus deep on mobile

  1. A user having problems with the reply tool would have no idea that turning off the "source mode toolbar" might fix their input issue

People helping on technical village pumps can advise them to do so, leading a much faster unblock of their workflows than the code fix (take the current situation: learning that I have to toggle my preferences unblocked my workflow in minutes, others’ workflows probably in hours; the code fix will unblock it in days).

Having fewer edit modes means these regressions will be less likely, and fixes will be prioritised for the supported modes. A tiny proportion of users on read technical village pumps, and on smaller wikis such support is just not available.

Generally though - users who are advanced enough that they need a <textarea> input will still be able to do so in the full page editor.

better integrates with OS features (like primary selection on Linux);

Does this not work with our surface?

Not reliably. T338285 is definitely yet to be fixed, maybe there are other issues as well.

works without JavaScript (once loaded), making it more reliable in case of CPU spikes

Especially with the small documents involved with replies, CPU is unlikely to be a bottle neck

CPU spikes caused by other things (e.g. other tabs) can make DiscussionTools not work either.

(e.g. I can input literal non-breaking spaces).

There's NBSP in the special chracters menu, and a keyboard shortcut (ctrl+shift+space). NBSP is a special case because most of the time it is inserted it is accidental, so we would get more complaints if we didn't remove them, but our IME support is pretty solid at this point.

I don’t think inserting literal non-breaking spaces in discussions is problematic; no one will want to edit them later on anyway. Articles, for which VisualEditor was originally designed, are a different topic.

  1. Full preferences are not available on mobile

They may not have been back in February, but they have been for quite some time by now.

They are, but finding DiscussionTools options are still several menus deep on mobile

They’re linked from the reply/new topic tool, just like on desktop. I don’t think they’re hard to discover; and definitely not harder than on desktop.

Generally though - users who are advanced enough that they need a <textarea> input will still be able to do so in the full page editor.

I know, and I probably will if you remove this mode, but especially the reply tool is much more convenient to use even as an advanced editor: using the full page editor, when I decide to reply to a comment, I have to scroll back to top of the section, click the edit section link, find the comment I’m replying to in the sea of wikitext, then click preview and find my reply draft in the sea of parsed content every time I refined the text. And if I fail to sign the reply properly (e.g. one tilde too few or much, or no tildes at all), I make DiscussionTools unusable to others as well. If I use the reply tool, I have to click the reply button right where I want to see my reply without scrolling and searching, the preview also appears there, and if I decide not to, or forget to, add a proper signature, the tools does it for me.