Page MenuHomePhabricator

Determine which Reply text input should be shown by default
Closed, ResolvedPublic

Description

Which input mode – source or visual – should people be presented with when they click "Reply" links?

This task is about running a test on our four partner wikis to help answer this question. We are foregoing the variant test for now. Instead, the Reply tool will inherit wikis' existing article editing configurations. You can review our rationale for making this decision in this comment: T250523#6114984.


Context

Version 2.0 of the Replying tool will introduce a visual mode to the text input area.

This creates a question: Which input mode – source or visual – should people be presented with when they click "Reply" links?

We are approaching this question with the following principle in mind: changes should be minimally invasive and strive to honor existing community conventions and agreements.

Text input mode configuration

In line with the principle above, the Reply tool should behave in the ways described in this table:

Account statusWiki configurationUser's editing mode preferenceUser edit countReply text input defaultNotes
Logged intwo edit tabsno preference set≥1last article editor used
Logged intwo edit tabsno preference set0follow behavior defined in getPreferredEditorThis means visual on all wikis except: en.wikipedia, es.wikipedia, he.wikipedia and fr.wikitionary
Logged inN/Avisual≥0visual
Logged inN/Asource≥0source
Logged inN/AShow me both editor tabs0follow behavior defined in getPreferredEditorThis means visual on all wikis except: en.wikipedia, es.wikipedia, he.wikipedia and fr.wikitionary
Logged inN/Avisual≥0visual
Logged inN/AShow me both editor tabs≥1last article editor used
Logged outtwo edit tabsN/AN/Afollow behavior defined in getPreferredEditorThis means visual on all wikis except: en.wikipedia, es.wikipedia, he.wikipedia and fr.wikitionary
Logged outdefault visualN/AN/Ashow visual
Logged outdefault sourceN/AN/Ashow source
Logged outN/AN/APublished ≥1 comment with the Reply toolshow the last Reply text input mode used to publish a comment

Partner wiki article editor default configurations

WikiLogged inLogged out
Arabicvisualvisual
Dutchtwo edit tabstwo edit tabs
Frenchtwo edit tabstwo edit tabs
HungarianVEVE

Testing instructions

  • If QA has a vagrant virtual machine, all configurations described in the "Text input mode configuration" and "Partner wiki article editor default configurations" section can be tested.
  • If QA does NOT have a vagrant virtual machine, ONLY the user-level configurations (read: preferences) described in the "Text input mode configuration" section can be tested; the "Partner wiki article editor default configurations" can be tested as well.

Done

  • Behavior described in "Text input mode configuration" has been implemented

  1. People who always expect to see the visual text input are those people who have the following Preference set: Preferences > Editing > Editing Mode: "Always give me the visual editor if possible."
  2. People who always expect to see the source text input mode are those people who have the following Preference set: Preferences > Editing > Editing Mode: "Always give me the source editor if possible"
  3. E.g. logged out users
  4. E.g. editors on two-tab wikis

Event Timeline

ppelberg created this task.Apr 17 2020, 7:58 PM
ppelberg updated the task description. (Show Details)Apr 17 2020, 8:01 PM
LGoto triaged this task as Medium priority.Apr 20 2020, 4:37 PM
LGoto moved this task from Triage to Upcoming Quarter on the Product-Analytics board.

As @matmarex pointed out offline, this is now the same as our getPreferredEditor logic in article editing, which we use whenever we the user hasn't made an explicit editor selection (e.g. a red-link)

We should also state that this logic only applies to the first time they open the tool. Every subsequent time they open the tool we will remember the last mode they used in it.

Per this morning's meetings, we are not going to run a variant test at this time.

As such, I am updating the task description to include the approach we arrived at around defaults, as Ed alluded to in: T250523#6114627.


Context
Here are the reasons we decided to forego a variant test of the text input modes for now:

  • We assume the risk of a non-technical user being presented with the source mode and becoming confused and/or discouraged (as has been the case in article editing) to be relatively low considering they will not see any wikicode in the Reply tool's text input.
  • We assume it is likely that a non-technical user who is presented with the source mode and not able to perform a certain action in the current interface (e.g. sending a ping), will click over to the visual mode considering how visually prominent it is in the interface.
  • The time and effort required to implement and analyze the variant test does not seem to warrant the value it would provide considering the bullet points above.
ppelberg updated the task description. (Show Details)May 7 2020, 1:15 AM

As @matmarex pointed out offline, this is now the same as our getPreferredEditor logic in article editing, which we use whenever we the user hasn't made an explicit editor selection (e.g. a red-link)

We should also state that this logic only applies to the first time they open the tool. Every subsequent time they open the tool we will remember the last mode they used in it.

@Esanders I've attempted to represent the above in the task description; please let me know if anything looks off to you.

Change 595031 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Create a user preference to store visual/source mode

https://gerrit.wikimedia.org/r/595031

Change 595031 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Create a user preference to store visual/source mode

https://gerrit.wikimedia.org/r/595031

ppelberg moved this task from Inbox to High Priority on the Editing QA board.Jun 3 2020, 3:29 PM

Testing instructions
Adding the following "Testing instructions" to the task description:

  • If QA has a vagrant virtual machine, all configurations described in the "Text input mode configuration" section can be tested.
  • If QA does NOT have a vagrant virtual machine, only the user-level configurations (read: preferences) described in the "Text input mode configuration" section can be tested.
ppelberg updated the task description. (Show Details)Jun 3 2020, 6:15 PM
Ryasmeen added a subscriber: Ryasmeen.

I tested this today on both Beta and Partner wikis.

There are two things I observed while doing that:

First case:

  1. A contributor posts a reply.
  2. Goes to Preferences section and changes the Editing mode preference to source/visual mode.
  3. Then goes back to discussion page and click on Reply again.

It shows the previously used editor, not the one that has just been set to. My understanding was, when a user explicitly chooses an editing mode, it will override the last used editor choice. How should it behave in this case?

Second case:

  1. User goes to Preferences section first and then sets source mode as preferred editing mode.
  2. Then clicks on Reply link, and switches the editing mode to visual.
  3. Then reopens the comment box again, this time it opens the last used editing mode: visual, instead of preferred editing mode: source.

Is this behavior expected?

ppelberg added a comment.EditedJun 10 2020, 6:16 PM

I tested this today on both Beta and Partner wikis.

There are two things I observed while doing that:

Thank you for flagging these, Rummana.

First case:

  1. A contributor posts a reply.
  2. Goes to Preferences section and changes the Editing mode preference to source/visual mode.
  3. Then goes back to discussion page and click on Reply again.

It shows the previously used editor, not the one that has just been set to. My understanding was, when a user explicitly chooses an editing mode, it will override the last used editor choice. How should it behave on this?

The behavior you described above is expected.

Said differently: the last text input mode someone used to post a comment using the Reply tool is the text input mode people should "land in" when clicking the "Reply" link in a future session, regardless of what preference is set in "Preferences" > "Editor" > "Editing mode."

The reasons this currently works as it does:

  • We are assuming people will see the context in which the Reply tool is used (discussions) and the ways in which it is used (adding comments, pinging other users, etc.) as being different enough from where (all namespaces and contexts) and how (adding/modifying/removing existing content) they use other editing interfaces. [i]
    • This leads to the following conclusion: people will expect to be able to set different preferences for the Reply tool and the full-page editing interfaces.
  • Initially, the simplest way to implement the above, is to have the Reply tool remember the mode used when posted the last comment.
    • Additional, more granular controls can be added later...if necessary.

Second case:

  1. User goes to Preferences section first and then sets source mode as preferred editing mode.
  2. Then clicks on Reply link, and switches the editing mode to visual.
  3. Then reopens the comment box again, this time it opens the last used editing mode: visual, instead of preferred editing mode: source.

Is this behavior expected?

This behavior is also expected for it is subject to the same logic and reasoning above. In short: the last text input mode someone used to post a comment using the Reply tool supersedes/overrides the what preference is set in "Preferences" > "Editor" > "Editing mode."


i. Note: when using the Reply tool for the first time, it will inherit the preference people have set for other editing interfaces.

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

Ryasmeen added a comment.EditedJun 10 2020, 7:23 PM

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

@ppelberg, those were the only two questions that I had when I checked with logged in users.
I checked with logged out user accounts today and in all partner wikis only the source mode is showing up when I used dtenable=1, regardless of what the default configuration is.
Using dtvisual=1 does not show any Reply links at all.

Also, I could only test the user-level configurations from preferences section described in the "Text input mode configuration" section. Couldn't test the ones that say "follow behavior defined in getPreferredEditor".

@Ryasmeen before closing this out, can you confirm that what you commented in T250523#6204414 were the only issues/questions that emerged in the testing you did?

Asked another way: by me addressing the issues you raised in T250523#6204414, can we assume the Reply tool is behaving as is described in the "Text input mode configuration" section of the task description?

@ppelberg, those were the only two questions that I had when I checked with logged in users.
I checked with logged out user accounts today and in all partner wikis only the source mode is showing up when I used dtenable=1, regardless of what the default configuration is.

This is expected considering the source mode is the only mode that is currently available on our partner wikis without using ?dtvisual=1.

Using dtvisual=1 does not show any Reply links at all.

Funky. @Ryasmeen: do you remember the URL of the page you tried this on? Appending dtvisual=1 to this URL seems to works as expected for me: https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion?dtvisual=1

Also, I could only test the user-level configurations from preferences section described in the "Text input mode configuration" section. Couldn't test the ones that say "follow behavior defined in getPreferredEditor".

Understood. This is expected per the following bit in the task description:

  • If QA does NOT have a vagrant virtual machine, ONLY the user-level configurations (read: preferences) described in the "Text input mode configuration" section can be tested; the "Partner wiki article editor default configurations" can be tested as well.
ppelberg moved this task from High Priority to Inbox on the Editing QA board.Jun 26 2020, 4:30 PM

Resolving this because the visual mode is now deployed to our partner wikis as a Beta Feature and thus the dtvisual= parameter is obsolete.

ppelberg closed this task as Resolved.Jun 30 2020, 5:58 PM
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJun 30 2020, 5:58 PM