3-Feb update

The task description has been updated to include the requirements from v1.1 (T236916). This means the requirements for v1.1 and v2.0 are now listed in this task's description.

Bundling v1.1 and v2.0 into one set of mockups was an outcome of a meeting on 25-January during which @Esanders, @iamjessklein and I decided it would be easier to design v1.1 (T236916) and v2.0 (T235593) together, considering the relatively small scope of the changes we have planed for v1.1 and the progress we've already made on designing v2.0 (see: T235592#5604770).

Note: while this is a change to how we are designing v1.1 and v2.0, we have not made changes to the order in which are planning to deploy these enhancements.

Very good selection of user stories...

As a contributor I can...

• Adjust the size of the text input area

In my experience adjusting the size of text input fields is a nuisance in most forum software: the triangle to click is tiny - easy to misclick -, the mouse is usually very far from it, etc.
While this adjustment could be an option, it would be best to have a practical auto-sizing default behaviour until the user adjusts the size and after the user resets the size to the maximum.
For a comfortable auto-sizing solution please take a look at how gmail handles long replies:

1. The textfield is automatically sized to match the contents.
2. If the content is more than what fits the screen, the textfield is limited to the size of the screen (minus the surrounding toolbars)
3. The textfield's top and bottom stick to the screen's edges.
4. The content is scrolled together with the page content (all comments). This is just for reference, I don't recommend this.
5. Whenever the textarea's size is changed the text cursor remains in the same position relative to the closest edge of the textarea, unless scrolling reached its limits.

I think point 1. and 2. is crucial. Point 1. for short comments (the most common use-case), so the context is not lost (scrolled off-screen) while editing.
Point 2. for long replies: without a size limit, looking at the previous comment would require scrolling up the whole length of the reply, which can be multiple pages in rare cases.
Point 3. is an implementation detail for this.

Point 4. gives a very fluent feeling to gmail, as if the reply was already part of the discussion, but it has the same issue as if point 2. wasn't implemented: long scrolling up to the previous comment. It might be difficult to implement, too, therefore I wouldn't recommend following that practice.
Instead of point 4. I'd recommend applying point 3. even when the textarea is resized by the user. This wouldn't re-enable automatic sizing, however: when the textarea is scrolled back, the user's preferred size is restored.
Alternatively, if automatic sizing would satisfy most users, the custom sizing feature could be dropped altogether, saving us from a whole class of implementation questions.

Tl;dr: Size the textfield automatically to fit the content, but limit it to keep it on-screen until the size reaches zero. Keep the text cursor in the same position relative to the closest edge as long as that's possible.

In T235593#5847003, @AronManning wrote:

Tl;dr: Size the textfield automatically to fit the content, but limit it to keep it on-screen until the size reaches zero. Keep the text cursor in the same position relative to the closest edge as long as that's possible.

@AronManning, thank you for clearly laying out your thinking. @iamjessklein, @Esanders and I are thinking through the points you raised and will respond later this week.

In the meantime, here are the decisions we came to today (4-February):

• Pre-populate reply text input area with a link to the user page of the person I am responding to

We are going to include this functionality in the mocks ups produced as part of this ticket. Before committing to deploying v2.0 with this functionality included, we need to better understand the trade offs that come along with it (e.g. balancing the potential for it to be easier for contributors to know who is responding to who with the potential for added noise by way of more notifications being sent out to contributors involved in conversations).

• Preview how the comment I am writing will be displayed once it is published on the talk page

In the initial mock ups produced as part of this ticket, the preview will be disabled for contributors writing comments using the rich text input mode.

• Thinking: contributors using the rich text input mode will expect the comment they are drafting to be posted to the talk page as they have written and formatted it and at the correct indentation depth.

Note: I updated some of the language in the task description in an effort to make the requirements more clear.

5-Feb update

ADDED: "See how the comment I am drafting relates to the comment I am responding to

• Rationale: this was a carry over from v1.0, so we will instead include it in v2.0

1. See: T238177#5813231

see the reddit-style comments by @matmarex in T235592

In T235593#5873140, @iamjessklein wrote:

see the reddit-style comments by @matmarex in T235592

(I think you meant T238177#5862388)

Here is a draft attempt of me blocking out all of the features in the requirements for this ticket. There are probably things that are incorrectly conceived here but the reason to look at this mockup is:

a) you are an engineer
b) to identify if there are any technical constraints that I should keep in mind

Thanks in advance!

Looks reasonable to me, I don't think there are any technical constraints that would make these things impossible.

Some notes:

• "Watch discussion" checkbox would actually add the entire talk page to the watchlist, the wording might need to be changed. If you wanted to add watch the specific topic/section, that is actually impossible right now. (I think we discussed this earlier, I'm just summarizing.)
• It is unclear what is the purpose of the preview button, given the live preview being shown below. (I think someone suggested it would toggle the live preview box on and off?)

Thanks @matmarex - yes that's a mistake and the button is similar to the phab eyeball button (but I'm not sold on it yet).

Another thing that I have been trying to process is the editing a comment workflow. I made this diagram to try to understand what might happen if people were to edit a comment and manually add signatures and summary. Can you gut check? I believe this is only one use case and that we have another set to think through in the scenario that a user edited a comment that wasn't theirs in the Full Page Edit mode.

Here's what I believe is the flow for someone who edits someone else's comment using full page edit mode:

This requires feedback from Peter and the Engineers to move forward.

Editing specific comments
During today's standup, we decided the following about our [initial] approach to editing specific comments:

• Contributors will only be able to see the edit affordance on comments they have written [1]
• Contributors will not see an indication that a specific comment has been edited on the talk page (e.g. there be no "edited" indication as there is on Slack for example)
  • Thinking: if we were to implement a feature like this right now, it would only work reliably on comments edited using DiscussionTools, not those using full page editing. [2] In an effort to help contributors stay focused on what they are trying to accomplish, without needing to think unnecessarily about the internals of the system, we think the implications of the action they are taking – in this case, editing a comment – should be as consistent as possible between the Replying and full page workflows.

1. Technically, contributors will only be able to see the edit affordance next to comments signed with the username they are logged in with
2. See T242562#5881933 for explanation of current technical limitation

@iamjessklein someone who clicks the standard EDIT button should never enter any flowchart for the DiscussionTool.

The new tool provides a simplified/automated interface for the most common and basic sort of Talk page edits. However the community wants to retain the current EDIT button as a general purpose, full power, full flexibility editor. It will be used either to make edits that aren't possible with the tool, or when someone explicitly does not want the new tool.

In T235593#5882487, @Alsee wrote:

...retain the current EDIT button as a general purpose, full power, full flexibility editor. It will be used either to make edits that aren't possible with the tool, or when someone explicitly does not want the new tool.

@Alsee I think the bolded portion of the above is a good description of how we, the team, are thinking about full page, wikitext editing...is there something you saw on this ticket that led you to see things otherwise?

Previewing in visual mode
Regarding how the preview is handed in visual mode, in one of the next iterations of the mockups you produce, @iamjessklein, are you able to try out a version that includes the following tweaks?

1. Omits the "eyeball" preview toggle in both text input modes (source and visual) and
2. Omits the preview itself from the visual text input mode

Thinking: T235593#5849890 + T235593#5878188

See how the comment I am drafting relates to the comment I am responding to

(Copying over a comment @Esanders raised on another ticket...)

In T238177#5878900, @Esanders wrote:

I'm not a big fan of the big hockey-stick curve, as it doesn't match with our border radii elsewhere. I'd prefer either a sharp bend, a 2px curve, or something else we haven't thought of that doesn't require the line to turn.

18-Feb update

Documenting outcomes from today's conversations...

Decided

• By EOD this Thursday, 20-February, we will post the latest version of the mockups on the MediaWiki project page (https://www.mediawiki.org/wiki/Talk_pages_project/replying) and invite volunteers to share their input on the initial approach.

Next steps

• Before the mockups can be posted, @iamjessklein is going to:
  • Experiment with changes to the visual appearance and layout of the workflow (e.g. How and where should the "watch page" affordance be shown? How should the text input and preview look?)
  • Change "Watch discussion" --> "Watch page" (or something else that makes it clear that in checking that box you are watching the whole page, not just a particular thread per T235593#5878188).
  • Omit the "eyeball" preview toggle in both text input modes (source and visual) per T235593#5883551
  • Omit the preview from the visual text input mode per T235593#5883551

Here are the updated mockups.

• I experimented with ui a bit (but want to take that even further with regards to the toolbar)
• Changed "watch discussion" to page
• removed "eyeball"
• removed preview

Annotated

Logged In

Logged Out

In T235593#5897563, @iamjessklein wrote:

Here are the updated mockups.

• I experimented with ui a bit (but want to take that even further with regards to the toolbar)
• Changed "watch discussion" to page
• removed "eyeball"
• removed preview

These look good, @iamjessklein. Some next steps/questions below. Before that, a few comments:

• The companion "annotated" mockups versions you've started creating are great. It makes the mockups easier to review.
• I like the addition of the instruction/helper text: "Reply to @RockawayBch4vr"

Next steps

• Are you able to create a mockup that shows how the interface will look when someone selects the Source mode? I suspect this is something you're already considering as part of the toolbar iterating you mentioned doing, but I wanted to mention just in case.
• Are you able to iterate on the "edit comment" affordance a bit more? I wonder if something could be done to make it more clear what comment the edit pencil is related to.
• Are you able to iterate on how we might make it clear to people which comment the one they are drafting relates to? I worry the current implementation makes this relationship a bit ambiguous.

Questions

• What do you envision happening when someone selects the quote tool? AFAIK, inserting quotes is made possible using templates [1] which may vary by wiki? I suspect this may be a question @Esanders is best positioned to answer.

1. https://en.wikipedia.org/wiki/Template:Quote

Re: placeholder text saying "Reply to @RockawayBch4vr"

1. Is the '@' necessary?
2. Should we show it for IPs, e.g. "Reply to 192.168.0.1" / "Reply to @192.168.0.1"

My leanings are

1. Probably not, it doesn't necessarily appear anywhere else on the page (except in some wiki-specific mention templates)
2. Probably, it might be helpful to know you clicked on the right reply button?

What do you envision happening when someone selects the quote tool?

Isn't that the cite tool (it's the same icon)? I assume it was just left in there by mistake. Comment quoting is not in the list of features for 2.0.

Re: placeholder text saying "Reply to @RockawayBch4vr"
Is the '@' necessary?

my thinking here is that the @ would kind of teach a convention, but agreed, this isn't crucial and probably adds unnecessary complexity.

Should we show it for IPs, e.g. "Reply to 192.168.0.1" / "Reply to @192.168.0.1" ..... Probably, it might be helpful to know you clicked on the right reply button?

Can you say more here @Esanders about the "right button"? I'm not sure if I understand you.

Isn't that the cite tool (it's the same icon)? I assume it was just left in there by mistake. Comment quoting is not in the list of features for 2.0.

+1 sorry thought this was in scope - removed it.

Are you able to create a mockup that shows how the interface will look when someone selects the Source mode? I suspect this is something you're already considering as part of the toolbar iterating you mentioned doing, but I wanted to mention just in case.

yes.

Are you able to iterate on the "edit comment" affordance a bit more? I wonder if something could be done to make it more clear what comment the edit pencil is related to.

yes. I explored a few things here, including:

• inline editing ui (colors, cross out etc)
• dimming the opacity on surrounding content to 50%
• pushing in the editing text editing box for the comment edit (note this is different than the affordance for basic replying).

Are you able to iterate on how we might make it clear to people which comment the one they are drafting relates to? I worry the current implementation makes this relationship a bit ambiguous.

can you say more here @ppelberg? what's your concern with the proposed design?

Adding comments to the points @Esanders and @iamjessklein raised in T235593#5916099 and T235593#5920258)...

1. Re: placeholder text saying "Reply to @RockawayBch4vr"
i) +1 to what you (Jess) and Ed arrived at: Do not prepend @ for the reason Ed mentioned in T235593#5916099.

A note: we may revise this if we see the @ convention to become more popular after the introduction of T232601.

ii) I think we should include placeholder text when contributors are responding to a comment authored by an IP editor (e.g. "Reply to 192.168.0.1") for the reason Ed raised in T235593#5916099: having the username of the author of the comment you are replying to within the helper text, could lead people to feel more confident they are responding to the right person.

2. Edit comment affordance

In T235593#5920258, @iamjessklein wrote:

Are you able to iterate on the "edit comment" affordance a bit more? I wonder if something could be done to make it more clear what comment the edit pencil is related to.

yes. I explored a few things here, including:

• inline editing ui (colors, cross out etc)
• dimming the opacity on surrounding content to 50%
• pushing in the editing text editing box for the comment edit (note this is different than the affordance for basic replying).

It's helpful to see what you've played around with. Although, I was referring to the edit affordance itself and its placement. Meaning: as it's currently implemented, I wonder whether the location of the edit pencil will lead people to not know what part of the page it is related to and thus, not be confident what affect click the affordance will have. (I think we talked about this some in yesterday's team meeting).

3. Visual indication showing how the comment someone is drafting relates to the comment they are responding to

Are you able to iterate on how we might make it clear to people which comment the one they are drafting relates to? I worry the current implementation makes this relationship a bit ambiguous.

can you say more here @ppelberg? what's your concern with the proposed design?

Let's see if I can express this...

In its current form, I worry people will find the line confusing...Is it indicating the depth of the thread (as is done on reddit [1])? Is it showing an explicit connection between the two comments (as is done on Phabricator [2] Github [3] and Gitlab[4])?

The hypothetical questions above sprout from the line, to me, being ambiguous because it doesn't explicitly "belong" to any single comment.

reddit lines showing thread depth

Phabricator using a line to explicitly link comments

Github using a line to explicitly link comments

Gitlab using a line to explicitly link comments

Note: I always find reddit's lines (marking thread levels) a mental burden to decipher. Phab, Github, -lab convey their meaning much more naturally, although levels are not demonstrated (used) by those. I can imagine the positioning of the vertical lines like Github does with higher-level lines positioned left to the current comment, not overlayed by the comment.

This comment includes feedback that surfaced during yesterday's team meeting.

Note: I'm continuing the numbering from the comment above: T235593#5924343.

4. Editing comments workflow

• Are you able to show what the editing specific comments workflow would look like if it were implemented similarly to how it is in Flow:
  • 1. On an already publish comment, a contributor clicks an edit button/link
  • 2. The comment changes "state" and becomes editable
  • 3. The "Reply" button changes to "Publish changes"

5. Opt-in/out watching page

• Are you able to change the text that accompanies the checkbox from "Watch Talk page" to "Watch this page"?

@dchan @Esanders @Whatamidoing-WMF, this comment and T235593#5924343 is what I recall us talking about yesterday. If anything is missing please comment as much.

Just updating this ticket with the final annotated mocks for consistency:

@iamjessklein I think this is going in a very good direction. Thank you for your work on it!

Just talking through some of the implementation questions with @Esanders and we need to decide how the tab for visual and source and the toolbar buttons will look. The thinking behind this is that what I have in the initial mockups does not comply with OOUI.

Option 1: IndexLayout (frameless) and floating toolbar. We could still tweak the text alignment here even more.

Option 2: A modified IndexLayout (frameless) and floating toolbar. In this version, there's no line underneath the tab section

Option 3: A boxier table which allows us to use a modified IndexLayout(framed) OOUI tabs and a more traditional OOUI toolbar

I'm leaning towards option 2 or 3 for consistency reasons but I would like to hear your thoughts. cc/ @Volker_E

Option 2: assuming I am a new user unaware of any context my question is: Which one is active? The brighter (blue) or the stronger (black)? I think this is confusing, although it looks the best.
Option 3: The background highlight helps somewhat, but not unequivocally. Personally I think the design so far is very clean and this gray block does not fit into it. Maybe with a different color.
Could you make a sample with the previous comment visible above? I think the gray background would be out of place in the context of other comments.
Option1: the underline is unequivocal and neat.

@iamjessklein, thank you for sharing these.

+1 to what @Demian articulated. Options ranked and re-iterated here:

1. Option 1: I think this approach makes the active state clear and the active switching seem like a lighter action (a good thing).
   • The above is informed by my use of the mobile visual editor wherein we applied a similar approach to the internal/external link dialog switcher. [1]
2. Option 3: I think the active state is communicated clearly here; tho, I wonder if the gray box will lead people to perceive the act of switching as a "heavier" action than it ought to be.
3. Option 2: I think this approach could people to be confused about what text input mode they're in.

1. RPReplay_Final1584405590.mov429 KBDownload

Sharing an image with Deuteranopia blindness filter applied:

What both commenters above already shared, we've introduced somewhat of an issue back when adding the frameless tabs, in that the interactive elements are kept black and the current, active, already chosen one carries our main interaction signalising color Accent50.
As this has been introduced with a very specific and small use case (SDC) in mind, maybe we need to update frameless, selected TabOptionWidget to use active color similar to selected ButtonOptionWidgets:

Option 2 would only rely on color and is therefore not recommended from an accessibility standpoint.

Even though I understand the comments about “fitting” or “heavier” action on Option 3, I'd like to also make sure, that we're ensuring enough whitespace above the tools if Option 1 is given to visually connect the tools and the textarea better. That's an advantage of Option 3. Otherwise no strong opinions on 1 vs 3.

Hey @Esanders can you provide an update on this task as to where you are with this, and when you will need input from Jess regarding the switching treatment.

Feedback from community is happening in the community ticket, so there is no longer a need for this.

Hey @Esanders can you provide an update on this task as to where you are with this, and when you will need input from Jess regarding the switching treatment.

The main part of the work is independent of how we design the tabs, but we will need to decide on a treatment before this is finished.

Feedback from community is happening in the community ticket, so there is no longer a need for this.

Where is that? Given that we haven't decided on a treatment, shouldn't this task remain open?

The main issue with options 1 & 2 is that our toolbars are not current designed to be borderless. We have active states with filled background that look odd when the is no top border:

The active states in option 3 are the only ones we currently have in the toolbar. There is a framed tab widget, but that assumes a grey background:

In T235593#6055989, @JTannerWMF wrote:

Feedback from community is happening in the community ticket, so there is no longer a need for this.

Here is the ticket, "community ticket" Jazmin referenced above: T248629.

Although, after a quick chat with @Esanders and @iamjessklein just now, it's clear there is still an open question to be answered about how the toolbar and input modes ought to be treated (T235593#6071404).

As such, I'm going to leave this ticket open. I've also added the open question above to the task description's "Open questions" section.

Hey @iamjessklein, in Planning it was determined that we are moving forward with Option 1 if that feels wrong in any way feel free to let us know.