As we talked about during today's meeting, we are seeking more information about what use cases would benefit from the "simultaneous approach." [1]

We think posting sketches of the different approaches [when they're ready] on the project page (https://www.mediawiki.org/wiki/Talk_pages_project/replying) will help with this.

Notes
So far, contributors have cited the following reasons as justification for the "simultaneous approach":

• Speed: "...wait several seconds for the application to switch context between the two views." Source: T155732#2964588
• Comparing wikitext with preview is difficult: "...new wikitext editor shows preview in place of wikitext, therefore an editor can not compare code with preview at all." Source: T155732#2961909

1. "Simultaneous approach": Contributors are be able to view their text input and a preview of how that text input would be rendered on the page simultaneously

As @matmarex noted in T235592#5646728, the "simultaneous approach" could be helpful in communicating to contributors they don't need to manually indent/outdent their replies or sign their comments.

I think the way User:Thnidu articulates why they value previews is helpful: "...a large part of their value for me is spotting errors of execution as well as errors of intention." See: this thread

Update: 4-Dec

• We are working to define how much of the previewing workflow we can design by EOD Friday, 6-Dec. Having minimal designs by this Friday should leave us enough time to have them implemented and live on the on the prototyper server by EOD Friday, 13-Dec, the time we're targeting for the initial round of usertesting.com testing to begin.
• In discussing the above this morning, we arrived at the following ranked open questions, which are now documented in the task description:
  • 1. Where is the live preview shown in relationship to the text input area? Above it? Below it? Somewhere else?
  • 2. How should the live preview be styled?
  • 3. What should be shown within the preview window as the preview is being populated?
  • 4. When should the preview window become visible to the user?
  • 5. Should there be a "fallback" experience on slow connections? What should this experience look like?
  • 6. Should contributors be able to hide and/or disable live previews?

Still open: what are the answers to the above questions in the context of mobile?

Task description update

• ADDED: link to the on-wiki conversation where we are asking for community members' feedback.

In T238177#5713661, @ppelberg wrote:

Update: 4-Dec

• We are working to define how much of the previewing workflow we can design by EOD Friday, 6-Dec. Having minimal designs by this Friday should leave us enough time to have them implemented and live on the on the prototyper server by EOD Friday, 13-Dec, the time we're targeting for the initial round of usertesting.com testing to begin.

6-Dec: update and next steps

• We are going to run the initial user test without making any significant changes [1] to the current UX
• Next week, we will test the live previewing functionality to be sure there is nothing fundamentally broken or confusing that needs to be fixed before the initial round of user testing begins on Friday, 13-Dec.
• Next week: we will start sketching ideas for what previewing could look like when it is implemented for real

cc @Esanders @iamjessklein

1. "Significant changes": e.g. we're not going to implement any new designs between now and the time we run an initial user test of the prototype

This will be high priority for next quarter.

As we talked talked about during this morning's meeting, this iteration of the preview should fulfill the following:

As a contributor, you can...

• Easily differentiate between the reply you are drafting in the reply text input area, the preview of said reply draft and the content on the rest of the talk page

• Know, at any given moment, how the reply you are drafting will look once it's posted to the talk page.
  • Know whether the wikitext you wrote is rendering properly. Said another way: you can depend on the preview to identify when something is behaving in a way you didn't intend it to.
    • e.g. a link is invalid, there is a line break in a place you didn't intend there to be one, etc. (see: Topic:Vcehezaiyl3znf0d).

• Know when the software has done something you did not expect.
  • e.g. == Welcome == not saving to the page in a way you expect (see: T241388#5762825) or the content of a reply affecting other parts of the talk page (see: Topic:Vcwvt3bq03o5gv8h).

Note: the above has been added to the task description under "Details" section

I posted a few iterations for preview on Freehand.
Please provide high level feedback here and drop in anecdotal comments there.

V1:

V2:

V3:

cc @Esanders @ppelberg

V2 looks better but I’d like the logged out warning in the V3 style but on top of the reply box personally

Thanks for the previews, great work!

1. I prefer preview immediately below the edited textarea (V3). On V1 I had to look for the preview, on V2 there's no clear boundary, that's confusing, on V3 the preview could have white background just like on V1 and V2; or maybe it has? no it's #fbfbfb.
2. The blue/gray border is very helpful on V3.
3. The login warning is better outside (above) the box, but I'm ambivalent about V1/V3. Technically It's more practical to save space (small displays, long comments), so I'd prefer thin warning (V3) above the box (V1), as RhinosF1. The highlight (background) color should be the tool used to attract the user's attention. In my theme I use dark orange with a few pixel glow around. Can't be missed.
4. One-line textarea initially (V1 and V3 somewhat). Saves space, expands dynamically.
5. "Reply Anonymously" -- Great! No mistake shall be made.

+1. I would make the buttons more compact (2-3px vertical padding, same font size as the textarea) and move the line with the legal text up, closer to the box so it almost touches and to the right to have the same left margin as the textarea and the preview.

Also related: Location of reply box: above or below previous replies?

Re: preview iterations

In T238177#5791165, @iamjessklein wrote:

I posted a few iterations for preview on Freehand.

+1 @AronManning , these are looking good, @iamjessklein. I find the "Preview" copy in V1, V2 and V3 makes it more clear this component is in fact a preview of the reply I am composing.

Question: What led you to displaying the preview beneath the text input (where contributors will type their comment) area?

I ask the above with the following thoughts in mind:

• Considering a key function of the preview is to help contributors understand how and where (e.g. indentation depth) their reply will be posted on the page, I'd assumed having the text area above the text input area, rather than below it, would communicate this most effectively. With this said, maybe the text input area and the preview being indented on the page to the correct depth solves this? Also, @RhinosF1 and @AronManning, y'all seem to prefer the preview below the text input as opposed to above it and I'd be keen to hear why this is so.

• Scenario: I am imagining a situation in which someone is composing a long comment. As their comment gets longer, the preview of their comment gets larger as well. Okay, now this person has finished writing their reply and they want to make sure their comment adequately addresses all of the points the person they are responding to raised. To do so, they'd like to be able to look at the preview of their drafted comment as well as the comment they are replying to, simultaneously. If the preview is presented beneath the text input area, I wonder if this task is becomes difficult considering this person will need to scroll down to see the entirety of their reply and then scroll back up to see the comment they are replying to. [1]

1. This scenario assumes the text input area continues to be shown beneath the comment a contributor is responding to, as it currently does on the prototype.

EDIT: adding "(where contributors will type their comment) "to clarify what I meant by "text input area" cc @aronmanning

In T238177#5791951, @ppelberg wrote:

1. This scenario assumes the text input area continues to be shown beneath the comment a contributor is responding to, as it currently does on the prototype.

@ppelberg I'm a bit confused as the current version of the prototype shows the text input below the previous replies to the comment being replied to, not directly below the comment. The +1 mock shows this scenario, the 3 previews of @iamjessklein could be either scenario, as there are no previous replies in the images
Also: I hope I understand properly that by "text area" you mean the preview. This is a bit confusing as the html textarea element is used to implement the text input area. Please clarify this in your comment.

I see 2 variables: (A) show the whole widget (.replyWidget) (A1) directly below the replied to comment / (A2) below previous replies, (B) show the preview (B1) above / (B2) below the editbox (text input area).

Depending on the primary purpose:

• To show where the reply will be posted A2+B1 (below previous replies, above editbox) is the preferable choice. Indentation is not influenced by these choices. (I prefer this to be the secondary purpose.)
• To make it easy to see the replied comment if there are more than 10 lines of previous replies - to remove the need to scroll up and down -, A1 (above previous replies) is preferable. There could be a sign "Your comment will appear here" below the previous replies to communicate that.
• If A1 (above previous replies) is chosen., both B1 and B2 are reasonable:

Regarding the preview/editbox order:

• In your scenario the user reviews their reply preview in the context of the replied to comment, thus the preview above the editbox and closer to the replied comment are preferable (B1).
• My practice is to read the comment point-by-point and reply to each, thus I need to see the replied comment and the editbox close to each other. When I'm satisfied that I responded each point, then I look at the preview to check the result. By that time I don't need to look at the replied comment that many times. This scenario works well with A1+B1 (editbox directly below replied comment).

Note that this board (phabricator) does A2+B2 (preview below editbox). We can compare the two scenarios by moving .phui-comment-preview-view up one div: I need to scroll a lot to see your comment, but the benefit is that I see what I type previewed immediately, whereas in the other scenario that part was scrolled off-screen.

Also note that the relevancy of these questions are only experienced when there are (1) many replies to a comment, (2) long comments. This happens in serious discussions, but less often in ad-hoc testing with short comments. I've set up a boilerplate discussion here to try these approaches: https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Discussion_tool_test?oldid=410578#Order_test

Thanks for your feedback @ppelberg @AronManning and @RhinosF1. After reading through your replies I see four main things to discuss:

• Placement of preview: I moved it to below so that it didn't distract the user from their primary task at hand (writing the comment). As the preview is validation of the comment creation, I wanted to reduce it's prominence in the hierarchy.

• Relationship of reply/preview to comment: I agree with the framing that @AronManning provided in terms of the options that we have - but I'll throw in another one - we can keep the version that we have in iteration v2 or v3 and draw a stronger relationship to the reply a la reddit. Something like these options:

• Warning Message: Some of my proposals (such as the smaller warning size V3) are not in compliance with OOUI. I'd have to confirm if this is something that we could tweak for this purpose if we choose to go in that direction.

• Comment length: We do have some options in terms of optimizing display for comment length. For example if they write a multi paragraph response we could use an ellipsis or some opacity dimming to indicate that this is a portion of what has been written.

Please let me know your thoughts.

In T238177#5793277, @iamjessklein wrote:

• Relationship of reply/preview to comment: I agree with the framing that @AronManning provided in terms of the options that we have - but I'll throw in another one - we can keep the version that we have in iteration v2 or v3 and draw a stronger relationship to the reply a la reddit. Something like these options:

That's a good option too. Is it correct to say that's the "preview below editbox" variant with the border between the two removed + a darker background to distinguish the preview?
I feel the difference should be more accentuated (a tiny bit darker background) and/or possibly a sublime border that's hardly noticeable. On this preview, I have to think twice which text can be edited.
It seems to me this is a styling question - one worth exploring, to more intuitively communicate the tool's usage.

Warning Message: Some of my proposals (such as the smaller warning size V3) are not in compliance with OOUI. I'd have to confirm if this is something that we could tweak for this purpose if we choose to go in that direction.

Is there some constraint to use only already existing styles? Those were designed for dialogs, not inline editing. This is a more compact environment and usability requires to keep it that way. I assume css rules specific to the .replyWidget can be added without concerns.

Comment length: We do have some options in terms of optimizing display for comment length. For example if they write a multi paragraph response we could use an ellipsis or some opacity dimming to indicate that this is a portion of what has been written.

Interesting. The scrolling behaviour should also be decided. I personally find scrolling the editbox very uncomfortable (I usually want to scroll the document instead), thus I would prefer a dynamically growing editbox, however in some cases scrolling has its benefit.
Maybe the best would be dynamically growing that can be resized with mouse, then it becomes static. If resized to full, becomes dynamic again.

After getting some more feedback, I did another round of iterations. Essentially, there are 4 deeply related issues:

• How realistic should preview look?
• How might we emphasize the connection of the preview to the conversation?
• How should we treat longer replies?
• How can we make preview less distracting for the contributor?

In terms of realism, I think that we can get a step away from an inline response to create that hierarchy of content that we were discussing earlier and to reduce general cognitive overload from the warning, preview, textbox, legal messages and buttons! So for this iteration I took the concept of the coupled textbox/preview unity and tried it out in two different ways (with preview above the text and below). There has been some back and forth about which approach is best so I mocked it up - and mocked it up and created longer content versions as well. Note that I changed the button from saying "anonymous" to "with IP address" because @Whatamidoing-WMF pointed out that "anonymous" isn't accurate.

A - preview on top (short comment)

A - preview on top (long comment)

B -preview below (short comment)

B -preview below (long comment)

C- variation on B placement (short comment)

C- variation on B placement (long comment)

D - After doing these mockups, I began to think more about options that we might have for displaying the long comment. I want us to reduce amount of space that is taken up, so in mockup D I experimented with a few things: minimizing text preview content with expandable copy, using a scroll bar and a text box extender:

E - final experiment to address the question "How can we make preview less distracting for the contributor?" I have an ellipsis animation that shows in preview while characters are being typed and that quickly transforms into the true preview after the word or phrase is finished - a la Google Translate.

Please let me know your thoughts.
I am particularly interested in which varient you are most drawn to and why.

Hiding the "2 more paragraphs" is a great idea. With a slow transition, when it is hidden...
I find the (blue) border between the editor and the preview important. The scrollbar above a certain size (1/3 or 1/2 screen) looks good.

I still would like to see the comment that I'm replying to, while I edit, even after 2 paragraphs. I would put the editbox right below the comment, then the preview, then the warning with the buttons. The warning and the buttons are closely related in the workflow: one should see the warning before clicking the button. If the warning is right above the buttons, it could be smaller and task up less space.

Nice work on these iterations, @iamjessklein.

Two things below:
A) What I'm understanding to be the the decisions [i] that need to be made about the preview.
B) My thoughts on those decisions

1. Where should the preview be displayed on the talk page?
   • I changed my mind; I think the preview should be displayed below the text input area [ii].
     • Thinking: it's important for contributors to be as "close" as possible to the comment they are responding to while writing they are writing their response. Maybe the approach we take will change as we think about Topic:Vcpciv1kcnows4p5 in a future iteration.
2. Where should the metadata preview (author + timestamp) about a comment displayed?
   • I think the author of the comment and the time their was comment was posted should be displayed within the preview. See: "B -preview below (short comment)"
     • Thinking: it's important for the preview to look as close to how it will be published on the page as possible
3. How should the preview and text input area [ii] adapt to longer comments?
   • Preview: I think the preview should show the contributor's drafted comment in full. Read: for now, the preview should not include any expandable copy.
     • Thinking: let's wait to see if this becomes an issue
   • Text input area: great spot on the text box expander. I think this should come in version 1.1
     • Thinking: I assume the box's current behavior (automatically expanding to a max height of ~191px and then becoming scrollable) is sufficient for this first release.
4. How should the preview be presented so it does not distract contributors?
   • I don't think we should make any adjustments to the preview updating logic/animation (e.g. ellipsis) in v1.0.
     • Thinking: let's see if the preview is in fact distracting before taking any action. I also wonder if the potential for distraction will be minimized if the preview is below the text input area.
5. How should the text input area and preview be displayed so it is easy to recognize and differentiate them?
   • I like the blue border shown in D.
     • Thinking: I find the blue line makes the text input area and preview more visually distinct.
6. How should the text input area and preview be displayed so it is clear to contributors how the comment they are writing relates to the rest of the page?
   • I think we should experiment with the line that is is shown in "B -preview below (short comment)."
     • Thinking: I think the line will help contributors focus more on the comment they are writing by relieving them of having to think about/remind themselves what comment they are in fact replying to.
7. Where should the IP warning be displayed?
   • I'm not sure. Is there a best practice here in OOUI?

i. Stating these explicitly [at the expense of potential redundancy] in an effort to organize and make my thoughts more legible.
ii. Where contributors write their comment

I concur @ppelberg's answers to these questions.

In T238177#5813231, @ppelberg wrote:

7. Where should the IP warning be displayed?
   • I'm not sure. Is there a best practice here in OOUI?

• I think the warning is the best placed between the preview and the submit-cancel buttons. Possibly on one line, if there is no legal disclaimer (about freely licenseing the contribution). In that place it will be immediately visible when the reply editor opens and still visible before the final decision to submit the comment.
  • Thinking: When I finish writing a comment, I move on to the preview (below) to check the formatting, then move further below to click Submit. Before I make that decision (after which there's no revert), it's best that I'm reminded if I have forgotten to log in and I'm about to disclose my IP.

Here, is what I believe to be the final mockup for v1.0 - can I get confirmation on this @ppelberg ?

In T238177#5813231, @ppelberg wrote:

7. Where should the IP warning be displayed?
   • I'm not sure. Is there a best practice here in OOUI?

I've mocked up the MessageWidget (type: 'warning') as you can see on the OOUI Demo page with standard copy. I am not sure, however, if the treatment that I provided for the copy in the button is approved by legal (cc @JTannerWMF )

Please explore the idea of moving the warning directly above or below the buttons, reduce the vertical padding to about 2px and the horizontal to 1em. As it stands now it takes up significant, valuable screen space and turns it into empty space between the editors and the responded comment that we wanted to keep close together. I'm sorry to repeat my previous comment, it might have been missed.

Those sample MessageWidgets - with the significant padding - were designed to break up the document flow of the full article and grab the attention of the viewer at first blink. In this context, the viewer's attention is already there and a more subtle warning could have a less discouraging effect.

In T238177#5817080, @iamjessklein wrote:

Here, is what I believe to be the final mockup for v1.0 - can I get confirmation on this @ppelberg ?

The mockups in T238177#5817080 look good, @iamjessklein. There is one change I think we should make before these are ready for development:

• How should the text input area and preview be displayed so it is easy to recognize and differentiate them?"
  • In "version D" in T238177#5808037, there is a blue border around the text input area (the place where contributors write their comments) so as to differentiate it from the preview. I think this is the treatment we should apply to the preview in v1.0 (in T238177#5817080, it looks like the blue border surrounds the text input area and the preview).

Thanks @ppelberg - I've made the correction
@AronManning - You've made a good point regarding proximity to content, so I made an iteration with a re-positioned warning message (it's also resized as is the input and preview).
Again, I'm not sure what we are legally required to do here, so this would need more review.

with the input area in blue

with the warning below:

In T238177#5819416, @iamjessklein wrote:

Thanks @ppelberg - I've made the correction

👌

After thinking about it more, I think that this mockup is the direction that we should go in. My thinking is that (ideally) a user needs to read the message before they start writing a response because if they do choose to log in, they will most likely lose their reply.

In T238177#5819416, @iamjessklein wrote:

@AronManning - You've made a good point regarding proximity to content,

+1, @iamjessklein...I'm glad you raised this issue, @AronManning.

With this in mind, for the reason Jess mentions [1], I think we should start by presenting the warning above the text input area, as is shown in T238177#5821313.

In T238177#5821313, @iamjessklein wrote:

...(ideally) a user needs to read the message before they start writing a response because if they do choose to log in, they will most likely lose their reply.

In T238177#5821313, @iamjessklein wrote:

After thinking about it more, I think that this mockup is the direction that we should go in. My thinking is that (ideally) a user needs to read the message before they start writing a response because if they do choose to log in, they will most likely lose their reply.

That's good reasoning that I've thought about too. For me, the warning is just as noticeable below the editbox, but you're right it's timing is more appropriate before writing the message.
Both positions are reasonable and my primary concern is to occupy less space with it. If you would minimize the huge vertical padding and lower the horizontal padding to 1em, it would be less in the way to see the original comment. On a wider screen than the screenshot, it would fit into one line, further reducing the impact.

Mock:

Css on the prototype:

.oo-ui-widget.oo-ui-widget-enabled.dt-ui-replyWidget {
    display: flex;
    flex-direction: column;
}

.dt-ui-replyWidget-anonWarning.oo-ui-widget.oo-ui-widget-enabled.oo-ui-labelElement.oo-ui-flaggedElement-warning.oo-ui-iconElement.oo-ui-messageWidget-block.oo-ui-messageWidget {
    padding: 1px 1em;
    margin: 0 auto;
    /* align-self: center; */
}

span.oo-ui-iconElement-icon.oo-ui-icon-alert.oo-ui-image-warning {
    background-position: center;
}

.dt-ui-replyWidget-preview {
    background: #f8f8f8;
    border: 1px solid gray;
    border-top-width: 0.1px;
}

.dt-ui-replyWidget-preview {
    margin-left: unset;
}

Thanks @AronManning I just iterated a bit more (and also considered the localization factor of the copy on the buttons probably doubling or tripling the size). @Esanders and I came up with:

what it will look like prior to an input

what it will look like with an input

Awesome. I love the enlarged exclamation mark icon, the proportions feel balanced. "Ready to ship", my boss would say.

Change 569638 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/DiscussionTools@master] Re-style preview

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

Just dropping the logged in version without for good measure:

Change 569638 merged by jenkins-bot:
[mediawiki/extensions/DiscussionTools@master] Re-style preview

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

That patch implements the mockups, and the result should soon be visible on https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats – except for one thing, which we should discuss.

I think the mockups don't properly consider what happens with the indentation of the reply. You've got the light-blue line on the left, which I assume is supposed to connect the reply box to the comment which we're replying to, but it can't be rendered exactly like this in practice, because the reply box is indented.

The reply box in your mockups is not indented, but I'm not sure if this is accidental, or if you mean that we should actually stop indenting the reply box? If so, then should we or shouldn't indent the preview of the reply? The real reply in the end will obviously be indented.

Some screenshots of the current implementation, to help visualize this (…or maybe to doodle over them):

• We have a discussion like this: (please imagine that all these comments were posted by different users)
  
• After I click "Reply" on comment 2, and start typing:
  
• After I submit the reply (with the temporary highlight):
  

I copied this imaginary discussion to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats#Test_discussion, so you can play with it (and with indenting of replies to the other comments).

I went ahead and tried to reconcile the mockups with the existence of indented replies. What are your thoughts on the below?

(These images are all of the same design, just demonstrating what happens when replying to different comments.)

In T238177#5861418, @matmarex wrote:

I think the mockups don't properly consider what happens with the indentation of the reply. You've got the light-blue line on the left, which I assume is supposed to connect the reply box to the comment which we're replying to, but it can't be rendered exactly like this in practice, because the reply box is indented.

Great spot, @matmarex.

"How should replies be visually related to the comments they are responses to, considering the indentation of the text input area?" is a question we need to answer.

Although, this is something we can revisit as part of v2.0. Context: T235593#5854638.

By the way Bartosz, the way you laid out the scenarios with their accompanying screenshots in T238177#5861418 and T238177#5862388 made responding to this ticket a cinch.

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.

The mockup has been created. See them here: T238177#5830223

As for the comment @Esanders raised RE the approach we take to visually relating the comment someone is drafting to the comment they are responding to [1], I've moved that over to the v2.0 ticket for us to discuss there: T235593#5890999.

1. T238177#5878900