Adjust the location of the tools within visual mode's toolbar
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	• ppelberg
	Jul 7 2020, 12:21 AM

Description

This task is about making it easier for people to reach the text formatting tools when drafting a comment with the Reply tool's visual mode on a wide screen.

Background

This issue surfaced in the mediawiki.org usability test we ran for Version 2.0 of the Reply tool (T246191). These quotes describe the issues people encountered:

"On a wide screen the styling buttons are quite far on the right edge from the area where my mouse is typically (above the text)." | source
"I needed one big second to find where the style buttons were. I think they are too far to the right (on a large screen like mine)." | source

Approaches

Approach #1: move the text tools to the side of the screen where people start typing [i]; move the text input mode tabs to the opposite side of the screen.
- The order of the text tools should not be changed
- The text tools that are presented within the toolbar should not be changed
- ~~The visual mode should be presented such that it is aligned with the position of the "Reply" button.~~
- In LTR languages, the visual tab should be presented to the left of the source tab
- In RTL languages, the visual tab should be presented to the right of the source tab

Open questions

1, Does changing the location of the text input tabs cause Junior Contributors to be less distracted by them?
- In the testing we did (see T257281), changing the location of the text input tabs did not seem to affect Junior Contributors' focus. This finding, coupled with the finding below, leads us to think changing the location of the visual mode's text tools to the left side of the text input area in LTR languages, and the right side in RTL languages, will have a net positive impact. Read: people will be able to access the text tools more easily without causing any negative side effects that would outweigh this benefit. Note: we acknowledge "negative side effects" alluded to above could surface once the Reply Tool is accessible and used by a greater number of people.
2. Does changing the location of the text tools make it easier for people using the Reply tool on wider screens to "reach" them?
- It appears to. See: https://w.wiki/Xn7 .

Done

"Approach #1" is implemented
"Open questions" are answered

i. Read: on the left side of the screen in left-to-right languages and on the right side of the screen for right-to-left languages.

Details

	Subject	Repo	Branch	Lines +/-
	Swap toolbar and mode switcher	mediawiki/extensions/DiscussionTools	master	+6 -1

Customize query in gerrit

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
Resolved	Esanders	T257280 Adjust the location of the tools within visual mode's toolbar
Resolved	• iamjessklein	T257281 Test the location of Reply tool's input mode tabs
Resolved	• ppelberg	T257888 Invite feedback about revised location of visual mode text tools on mw.org

Event Timeline

• ppelberg created this task.Jul 7 2020, 12:21 AM

• ppelberg moved this task from 📚 Backlog to 👁Needs Engineering Input on the Editing Design board.

• ppelberg moved this task from Needs Discussion / Investigation to Doing on the Editing-team (Q3 2019-2020 Kanban Board) board.

• ppelberg mentioned this in T252445: Consider changing the presentation of the visual mode's editing toolbar.Jul 7 2020, 12:37 AM

• ppelberg updated the task description. (Show Details)Jul 7 2020, 12:49 AM

• ppelberg mentioned this in T254208: Revise position and behavior of Reply tool's text input.Jul 7 2020, 1:07 AM

• ppelberg mentioned this in T257281: Test the location of Reply tool's input mode tabs.Jul 7 2020, 1:33 AM

• ppelberg updated the task description. (Show Details)

Change 609839 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Switch toolbar and mode switcher

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

gerritbot added a project: Patch-For-Review.Jul 7 2020, 2:21 PM

http://patchdemo.wmflabs.org/wikis/d24f36b58213af4b88912a2e8484de95/w/index.php/Talk:Main_Page

Notes from convo with @Esanders:

Does this horizontal switch make it more apparent that there isn't symmetry in the toolbars? When you are in source it's very clear now that there are no tools.
@mention should have the new header which will help when there are no local suggestions
when a user wraps their signature in tags it reduces the button size even further and is itsy bitsy.

Screen Shot 2020-07-07 at 11.02.12 AM.png (144×1 px, 45 KB)

In T257280#6285806, @iamjessklein wrote:

Does this horizontal switch make it more apparent that there isn't symmetry in the toolbars? When you are in source it's very clear now that there are no tools.

Yep, the source mode looks a bit strange (visual mode is probably okay, but that doesn’t matter, as placing the switch at different places in visual and source mode would be a terrible decision). Maybe a dropdown like the one that VisualEditor uses could make it visually more pleasant:

VisualEditor switch menu.png (129×224 px, 3 KB)

In T257280#6285864, @Tacsipacsi wrote:

Maybe a dropdown like the one that VisualEditor uses could make it visually more pleasant:

The dropdown is unnecessary, just replace the pencil icon with the currently active mode. The dropdown needs multiple user actions: 1) click icon 2) hover over intended mode 3) click mode. This is very inefficient UX and VE should move away from it, but that's a different topic.
The toggle should work with one click at the same location regardless of the mode. This is easily achieved by just hiding the inactive tab with CSS and ensuring the two element have the same width.

Note: patchdemo is not loading so I can't evaluate the proposed solution...

Clicking on the current mode’s icon to get to the other mode is unintuitive for me. Clicking the other mode’s icon (i.e. hiding the current mode’s icon) seems better, but I think some user studies are needed to ensure that at least senior contributors can find out how to switch. Also, a single toggle at the far end also looks ugly for me; probably integrate it into the toolbar (in visual mode) and keep it at the near end (i.e. at the left for LTR languages)?

P.S. patchdemo is fine for me. Either it was a temporary issue, or it’s an issue at your end.

MBinder_WMF edited projects, added Editing-team (Kanban Board); removed Editing-team (Q3 2019-2020 Kanban Board).Jul 9 2020, 4:51 PM

JTannerWMF moved this task from Incoming to Design Review on the Editing-team (Kanban Board) board.Jul 9 2020, 4:52 PM

• ppelberg moved this task from 👁Needs Engineering Input to 📢 To Do on the Editing Design board.Jul 9 2020, 6:25 PM

JTannerWMF moved this task from 📢 To Do to 📐 Doing on the Editing Design board.Jul 9 2020, 6:51 PM

Notes from the conversation @iamjessklein and I had today:

In T257280#6285631, @Esanders wrote:

http://patchdemo.wmflabs.org/wikis/d24f36b58213af4b88912a2e8484de95/w/index.php/Talk:Main_Page

@Esanders: the implementation you posted above looks good. Jess and I don't see anything further to be done here [i] for now [ii]

A clarifying question for you that came up: is the reason tool's source and visual mode text input areas have different heights [iii] because we treat the height of the source mode's input area to be the "editable area" + the "preview area" whereas the visual mode's input area is solely the height of the "editable area" alone?

i. @Demian / @Tacsipacsi: we appreciate the feedback you shared about the treatment of the text input mode tabs themselves. Although, revising how these tabs/the switcher is implemented is out of scope for this particular task. @iamjessklein if you have more to share here, please do.
ii. Adjustments may need to be made, but those adjustments should come after we've tested the usability of the current implementation. This work will happen in T257281.
iii.

`source`	`visual`

• ppelberg added a subtask: T257281: Test the location of Reply tool's input mode tabs.Jul 10 2020, 5:24 PM

• ppelberg moved this task from Needs Prioritization to Required for Release on the OWC2020 (OWC2020 Replying 2.0) board.Jul 10 2020, 11:53 PM

Tacsipacsi mentioned this in T255445: Clean up toolbar tab alignment .Jul 10 2020, 11:59 PM

Notes from today's conversation with @Esanders and @iamjessklein:

In T257280#6297415, @ppelberg wrote:

In T257280#6285631, @Esanders wrote:

http://patchdemo.wmflabs.org/wikis/d24f36b58213af4b88912a2e8484de95/w/index.php/Talk:Main_Page

@Esanders: the implementation you posted above looks good. Jess and I don't see anything further to be done here [i] for now [ii]

A clarifying question for you that came up: is the reason tool's source and visual mode text input areas have different heights [iii] because we treat the height of the source mode's input area to be the "editable area" + the "preview area" whereas the visual mode's input area is solely the height of the "editable area" alone?

Ed shared there is not a clear way of making the text inputs in the tool's visual and source modes the same height.

With the above in mind, we are going to stick with what Ed implemented above [i]. Read: we are not going to iterate on the implementation until we have evidence it is necessary. Said "evidence" would come most quickly via the test we will be running in: T257281.

Reason for the above: we do not yet know how people are using the tool's two input modes in relation to one another, and subsequently, whether the text inputs varying in height creates problems for people.

i. http://patchdemo.wmflabs.org/wikis/d24f36b58213af4b88912a2e8484de95/w/index.php/Talk:Main_Page

Meta
I'm moving this task to "Blocked" as it being deployed depends on T257281 being resolved. The task description reflects this.

• ppelberg moved this task from Design Review to Blocked / Needs More Work on the Editing-team (Kanban Board) board.Jul 14 2020, 1:42 AM

• ppelberg updated the task description. (Show Details)Jul 14 2020, 1:48 AM

• ppelberg updated the task description. (Show Details)

• ppelberg mentioned this in T257888: Invite feedback about revised location of visual mode text tools on mw.org.Jul 17 2020, 1:17 AM

• ppelberg removed a project: Editing Design.Jul 20 2020, 5:45 PM

• ppelberg closed subtask T257888: Invite feedback about revised location of visual mode text tools on mw.org as Resolved.Jul 24 2020, 11:40 PM

Dyolf77_WMF subscribed.Jul 26 2020, 12:38 PM

• ppelberg edited projects, added OWC2020 (Reply Tool Opt Out); removed OWC2020 (OWC2020 Replying 2.0).Jul 27 2020, 11:07 PM

• ppelberg moved this task from Needs Prioritization to Required for Release on the OWC2020 (Reply Tool Opt Out) board.

JTannerWMF added a project: Editing Design.Jul 29 2020, 5:35 PM

Let's go with V2.1 (toolbar on the left) - in T257281 we learned through testing with junior contributors on usertesting.com that Reply v2.1 was in fact usable. That fact combined with the on-wiki conversations with Senior Contributors describing Reply v2.0 pain points for large viewports indicates that it's just a better experience.

One tweak that I identified during testing that should be made before shipping is that the tabs should be re-ordered so they read from Left to Right as "visual" and then "source."

cc. @Esanders @ppelberg

To clarify the thought process around the tab switching: I observed many junior contributors get a bit lost in the interface when they were searching for the tabs and/or tools. I'd like to attempt to mitigate that issue by ordering the tools and tabs in a hierarchy that mirrors the users reading patterns.

In T257280#6348792, @iamjessklein wrote:

Let's go with V2.1 (toolbar on the left) - in T257281 we learned through testing with junior contributors on usertesting.com that Reply v2.1 was in fact usable. That fact combined with the on-wiki conversations with Senior Contributors describing Reply v2.0 pain points for large viewports indicates that it's just a better experience.

Sounds good. I've added this outcome to the task description's "Open questions" section.

One tweak that I identified during testing that should be made before shipping is that the tabs should be re-ordered so they read from Left to Right as "visual" and then "source."

I've edited the task description's "Approaches" section to include this adjustment.

cc. @Esanders @ppelberg

Next steps

Adjust the implementation such that the following happens:
- In LTR languages, the visual tab should be presented to the left of the source tab
- In RTL languages, the visual tab should be presented to the right of the source tab

• ppelberg moved this task from 📐 Doing to 👁Needs Engineering Input on the Editing Design board.Jul 31 2020, 7:35 PM

• ppelberg updated the task description. (Show Details)Jul 31 2020, 7:43 PM

Change 609839 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Swap toolbar and mode switcher

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

In T257280#6352680, @ppelberg wrote:

Next steps

Adjust the implementation such that the following happens:

In LTR languages, the visual tab should be presented to the left of the source tab

In RTL languages, the visual tab should be presented to the right of the source tab

Done (I updated the patch before merging it)

matmarex moved this task from Blocked / Needs More Work to Ready for Sign Off on the Editing-team (Kanban Board) board.Jul 31 2020, 8:33 PM

matmarex removed a project: Patch-For-Review.

ReleaseTaggerBot added a project: MW-1.36-notes (1.36.0-wmf.3; 2020-08-04).Jul 31 2020, 9:00 PM

• ppelberg closed this task as Resolved.Aug 4 2020, 12:43 AM

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptAug 4 2020, 12:43 AM

• ppelberg closed subtask T257281: Test the location of Reply tool's input mode tabs as Resolved.Aug 29 2020, 1:06 AM

	F31923589: Screen Shot 2020-07-10 at 10.23.05 AM.png
	Jul 10 2020, 5:24 PM

	F31923587: Screen Shot 2020-07-10 at 10.23.10 AM.png
	Jul 10 2020, 5:24 PM

	F31919756: Screen Shot 2020-07-07 at 11.02.12 AM.png
	Jul 7 2020, 3:02 PM

Adjust the location of the tools within visual mode's toolbarClosed, ResolvedPublicActions