Clarify distinction between the Reply tool's two text input modes
Open, Needs TriagePublic
Actions

Assigned To

None

Authored By

	• ppelberg
	Jun 11 2020, 12:48 AM

Description

This task is about ensuring the purpose, relationship and behavior of the Reply tool's two modes – currently named Visual and Source – are clearly understood by contributors, across experience levels.

Background

This task is prompted by the following:

In the most recent usability test we ran with people new to using Wikipedia talk pages (T246190), we observed one test participant being reluctant to click source for fear of the comment they had just written in the tool's visual mode being discarded.
- You can review this moment here: Reply v2.0B (limited access).
In the most recent usability test we ran with people who have experience using Wikipedia talk pages (T246191), @dialmove remarked:
- "I know that the "Visual" and "Code" keywords respectively correspond to WYSIWYG and ki editors, but I'm not sure that they are a good fit to their purpose in this interface. Descriptions like "Styles" and "plain code" would be more universally understood, I think, and they would better fit the limited expectations of writing a single comment in a thread, as well as the limited tool functions. This is not the full-blown Visual editor of Wikipedia articles." | Source
An experienced editor, who has the visual editor disabled, expressed they found the presence of the tool's visual mode to be distracting and unexpected considering the aforementioned preference they have set.
- "The presence of the two modes also adds clutter, more distracting than if it were on a special page, that I rarely visit...Users who want the source only don't anticipate any switching, so why not allow them use what they want. Why should we have duplicate things doing the same thing?" | Source

Related Objects
Search...

Status	Assigned	Task
Open	None	T233443 [Epic] Reply Tool
Open	None	T252445 Consider changing the presentation of the visual mode's editing toolbar
Open	None	T255085 Clarify distinction between the Reply tool's two text input modes
Open	None	T255448 Consider changing the segmented navigation titles (visual/source)
Declined	None	T256166 Test input mode name variants
Resolved	• iamjessklein	T257281 Test the location of Reply tool's input mode tabs

Event Timeline

• ppelberg created this task.Jun 11 2020, 12:48 AM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 11 2020, 12:48 AM

@dialmove, out of curiosity, what does the Reply tool remind you of? It could be a tool on-wiki or off.

I ask the question above to get a sense for how other interfaces address the challenge you described in response to "TASK #5" here (also represented in the task description).

The new Reply tool reminds me of other comment tools in websites with deep nested threaded conversations, in particular Reddit and Slashdot (and to some extent Stack Overflow).

Reddit in paticular has an intuitive comment editor, which resembles a lot what you're building here. They have an advantage though, their comments are shown in reverse order (recent commments first) so they don't have the problem that newer comments in long threads will be thrown all the way down to the end.

Maybe you could temporarily show the new post right below the comment you're replying to, just in the client side, yet still store it at the proper place of the thread, so that it will be moved when the page is refreshed.

• ppelberg added a subtask: T255448: Consider changing the segmented navigation titles (visual/source).Jun 15 2020, 3:30 PM

@Niharika made a suggestion that I think [i] could help lead Junior Contributors to more clearly and quickly understand the purpose the two modes and the relationship between them:

Change the name of the source mode ---to--> Wikitext

i. Thinking: I assume Junior Contributors will find Wikitext or Wikicode to be more obviously unclear and thus lead them to a) investigate, and subsequently learn, what Wikitext or Wikicode means and/or b) use the tool's visual mode which qualitative testing has proven them to be more successful with: T239175#5711067.

In T255085#6216287, @dialmove wrote:

The new Reply tool reminds me of other comment tools in websites with deep nested threaded conversations, in particular Reddit and Slashdot (and to some extent Stack Overflow).

Got it. This is helpful, @dialmove – thank you for sharing this.

Reddit in paticular has an intuitive comment editor, which resembles a lot what you're building here. They have an advantage though, their comments are shown in reverse order (recent commments first) so they don't have the problem that newer comments in long threads will be thrown all the way down to the end.

Spot-on. This issue came up in a recent usability test: T254208#6233779

Maybe you could temporarily show the new post right below the comment you're replying to, just in the client side, yet still store it at the proper place of the thread, so that it will be moved when the page is refreshed.

Interesting. I'm copying this comment over to the ticket where we'll be discussing how and where the tool's text input appears: T254208#6233817.

• ppelberg mentioned this in T256166: Test input mode name variants.Jun 23 2020, 7:27 PM

• ppelberg added a subtask: T256166: Test input mode name variants.

JTannerWMF moved this task from Needs Prioritization to Required after release on the OWC2020 (OWC2020 Replying 2.0) board.Jun 30 2020, 6:56 PM

JTannerWMF edited projects, added Editing-team (Tracking); removed Editing-team.

JTannerWMF moved this task from Backlog to FY2020-21 on the Editing-team (Tracking) board.

• ppelberg added a parent task: T252445: Consider changing the presentation of the visual mode's editing toolbar.Jul 6 2020, 11:40 PM

Ammarpad mentioned this in T255448: Consider changing the segmented navigation titles (visual/source).Jul 7 2020, 6:15 AM

Task description update
I've added the feedback @Ammarpad shared to the task description:

An experienced editor, who has the visual editor disabled, expressed they found the presence of the tool's visual mode to > be distracting and unexpected considering the aforementioned preference they have set.

"The presence of the two modes also adds clutter, more distracting than if it were on a special page, that I rarely > visit...Users who want the source only don't anticipate any switching, so why not allow them use what they want. Why should > we have duplicate things doing the same thing?" | Source