Topic on Talk:Talk pages project/replying

The issues that have surfaced in this thread can be found in Phabricator here:

• T241388: When inserting {{welcome}} reply preview is different to saved content
• T241391: Unable to respond to specific comments
• T241393: Abandon changes dialog appears unexpectedly
• T241396: Unable to publish changes to an outdated beta.wmflabs.org talk page
• T241193: Replies with <gallery>...</gallery> tags do not render in preview properly
• T239861: Bug: Not able to post comment on beta
• T242466: Why does posting a new comment delete </span> from a previous one?

Usability test overview

The team has an early prototype that is ready for testing: https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Cats

In an effort to identify opportunities for improvement, the team has developed a usability test we would value you participating in: Version 1.0 prototype test

If you would like to participate, the details of the test can be found here: Usability test instructions

While we would like to reserve this thread for people participating in the "Version 1.0 prototype test" to share their experiences, please continue to use other threads on this page to share your feedback as @TheDJ, @Aron Manning, and @Jc86035 have been doing.

Feedback questions

After completing the test, please share your answers to the questions below (source) as replies to this post.

1. Do you think that you completed the Task above correctly?
2. Was there anything painful or not obvious about this experience?
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
4. What other additional comments, concerns, or ideas would you like to make known?
5. How do you typically use talk pages (across namespaces)?
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?

Note: The team will be monitoring this thread going forward and will begin responding to comments on Wednesday, 18-Dec.

I was asked to test this tool a while back by @Whatamidoing (WMF): a while ago. I have been unable to submit anything through the tool because of an

Error contacting the Parsoid/RESTBase server (HTTP 500)

I will however state that a problem that I've observed before is still there: not closing wikitext will transfer the formatting over to the signature. I have not tried working with indentation on this tool.

I am using a similar tool, Enterprisey's reply-link.js on Wikipedia, which not only does previews (albeit not live), but can also close edit requests while replying. One downside the tool I use has is that it does not always work well with excessively long discussion pages. If this tool gets past that I think it might be a good contender against reply-link.js.

I've got the same (HTTP 500) error, so I was unable to finish the tasks in the test.

I have some comments about the usability of the form:

- First, I love the concept, we've been waiting it for years, and the current design seems simple and functional. Well done.

- I'm uncertain about the placement for the "Reply" link after the date. It's OK that it's the last thing in the paragraph, but it seems too separate from the name of the user you're replying to. I think it would help if the link had a tooltip that stated "Reply to [username]", to reinforce what comment are you replying to.

- Most important:

I'm a seasoned Wikipedia user who understands the indent rules for talk pages, and yet I got surprised at the placement of the reply box. When replying to comment "This contribution is not indented ... --Honischboy (talk) 20:25, 8 April 2020 (UTC)", the input interface is opened at the bottom of the section. Even though I understand the placement rules for comments in Wikipedia Talk pages, my gut reaction was to expect the input box right where the "Reply" link is placed. This is exacerbated in the "New section" below the page, where replying to "signed edit 105.187.36.38 (talk) 06:08, 21 January 2020 (UTC)" makes the previous comment dissapear because of the long scroll down.

The interface really needs some visual reinforcement for explaining why the reply is placed so far away. I have two alternatives that I think would work for this:

a) After opening the reply text box, put a black line on the left margin of the "<dl>" tag which contains all the previous replies to the same comment. This would visually connect the new comment and the comment you're replying to. (I have my regular Wikipedia CSS template at talk pages set to this style, and works great for following indentation).

b) Do the same before opening the box, e.g. show a black left margin when hovering over the Reply link. Then, open the reply box right below the original comment (so that it won't jump and you can still read the original comment you're replying to), and meanwhile show a placeholder box at the end of the line, where the comment will be placed by indent rules when you press the final Reply button.

Opiton b) would be my preferred solution, as it reduces surprise when opening the intrface and lets you see the contex.

Is your black line meant to do something similar to the blue lines that the French Wikipedia uses (see https://fr.wikipedia.org/wiki/Discussion_Projet:Outils_de_discussion for an example)?

Yes, but only the left margin, not the bands of alternate colors in French Wikipedia. The resulting style is much more lightweight, but still shows indentation quite clearly.

Found another bug: When you start a reply and you turn out to not be logged in, it will tell you so, which is good. If you then login via another tab, so as not to disrupt your message-in-progress, when you come back and do anything in the editing field, it knows you've logged in and will change the IP address in the sig to your username. However, when you try to save the message, it will not let you, giving a farcical error of "You are no longer logged out, so the action could not be completed." So, something about the login-detection routines is incomplete.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:14, 18 April 2020 (UTC)

Other issues: Just from skimming the page, I can see two major problems:

1. Syntax is being misparsed, such that tables in comments are breaking.
2. Syntax is probably being miswritten, if not misparsed, such that after a while new threads are indented to the right and should not be (it's probably due to an unclosed element in a previous post). Using modern markup (e.g. turning every comment into a div or an "article" in the HTML 5 sense) would probably help ameliorate this; even if it doesn't trigger browsers into re-parsing properly, it should allow the MW parser, with a minimal upgrade, to detect and fix such issues on-the-fly.

That said, the main disappointment to me is that this opportunity is not (yet?) being taken to undo the terrible mistake made in WP's early days, of abusing list markup for comment indentation and bulleting. Both : (the dd element, which auto-generates an invalid dl element lacking a dt), and * (an li that auto-generates a ul) wikimarkup a the start of a new line (and when not wrapped in "don't parse this" markup like <nowiki > and <pre>) need to be re-parsed on the fly – on talk pages, not in articles – into divs that use CSS to do visual indentation or apply visual, non-list bullets, instead of manufacturing invalid, mangled list markup. A Phab ticket has been open about this problem for over a decade (ported over from the pre-Phabricator ticket tracker), and the main MW devs are obviously never going to do anything about it, so it's up to the community to fix it with better tools than they will provide us.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  13:23, 18 April 2020 (UTC)

This is a side effect of communities not wanting Flow and having chosen small incremental steps based on wiki text. When you build something on quicksand, you should not expect it to be able to turn into flat concrete any time soon. Can’t have cake and eat it.

also, please provide diffs.

Diffs of what? The page is short, and if you want to look at the table breakage and page indentation breakage, it's right there in the page; rather hard to miss. I didn't do any edits that resulted in either problem, and have not dug through others' comments to try to identify exactly which edits resulted in the errors.

Anyway, I get what you are saying about incremental changes, but at some point this issue (of abusing list markup and making mangled lists) has to be addressed in an actual increment, instead of the buck being passed forever. Maybe now isn't the time to take that step, but it needs to happen eventually, so I will bring it up at every appropriate opportunity of a step being taken to see if it can be that step.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  12:23, 20 April 2020 (UTC)

I experimented on the page before trying to follow the instructions. The breakage was so severe that it became difficult to follow through on the test instructions.

The first thing I tested and found was that posting a comment can corrupt existing content on the page. It appears the content is being round-tripped through Parsoid.

Next I found that the preview is inaccurate. A template rendered with different indentation in preview than it did when the comment was saved. I suspect that indentation markup isn't being actually being generated and integrated as part of the comment-content, and trying to fake it can't handle the general case correctly.

I posted assorted test-content... I'm not sure what part was responsible but it became impossible to reply to certain comments. The reply button would work and I could type a reply and I could click save, but replies to those particular comments would not actually save. I was able to reply elsewhere.

The instructions asked me to fix my comment. I don't know if that was supposed to be done via the new interface - I didn't notice any way to do so. Therefore I tried editing the page as normal. The 2017editor came up, but it would not allow me to edit. I tried multiple times and different parts of the page. The 2017editor was broken and just wouldn't let me type or change anything on the page. All menu items to the left of 'help' were grayed out and non-functioning. I had to edit the URL to force the wikitext editor to load. The real wikitext editor worked fine, and I was able to 'fix' my comment.

Cancelling worked, and page history worked fine.

Thank you for trying the prototype, @Alsee. A few clarifying questions:

posting a comment can corrupt existing content on the page

This is unexpected. Do you recall if this is the comment that caused said corruption? Also, what kind of corruption did you experience?

...I found that the preview is inaccurate. A template rendered with different indentation in preview than it did when the comment was saved.

Are you able to share the contents of the comment you posted that led to the preview differing from what ended up being saved to the page? If you're able to track down a link to the diff itself, that would be even better.

The reply button would work and I could type a reply and I could click save, but replies to those particular comments would not actually save. I was able to reply elsewhere.

Hmm. Are the comments you were not able to reply to, comments 10.0.3.1 16:30, 10 December 2019 and 192.168.122.1 02:50, 12 December 2019? If so, it seems I'm experiencing the same behavior you are reporting [1].

Therefore I tried editing the page as normal. The 2017editor came up, but it would not allow me to edit. I tried multiple times and different parts of the page. The 2017editor was broken and just wouldn't let me type or change anything on the page

Interesting – do you remember what steps you took that led to the 2017editor appearing?

---

1. Actual behavior:

i) Click "Reply"

ii) Compose reply in text input

iii) Type command + enter

iv) Loading animation is overlaid atop text input + draft reply

v) Text input disappears

vi) Highlight appears atop talk page

⚠️ vii) Reply has not been posted to talk page

@PPelberg (WMF) the diff you linked was indeed an example of corruption. Specifically:

• The (first) comment of 14:10, 15 December 2019. Contains the word red, in red style. The red style ends before the signature. Note: The wikitext used is a deliberate test case - if various corruption issues exist, that particular test case generally reveals it in a most dramatic fashion.
• The next edit, during the same minute worked normally. I would guess it didn't affect the first edit because it replies in a different section.
• The edit of 14:13, 15 December 2019 deleted the </span> from the first edit in the sequence, resulting in the red-styling spilling down to the end of the section.

The inaccurate preview edit contains a random assortment of test content. The welcome template previews as indented, but the saved version is not indented. I am just guessing, but something in that comment might be the cause of the inability to reply to the comments of 16:30, 10 December 2019 and 02:50, 12 December 2019.

I don't think I did anything special to get the 2017editor. All I recall is clicking the full page edit button.

I just did a bit more testing and I just ran into a new issue. I saved a comment. I do *not* have any reply-box open. All reply links are blue. However when I try to leave the page I get the warning popup Changes you made may not be saved. Leave/Cancel. It seems that the page thinks I still have a reply-box open. I don't know why. I now select leave option, so I can continue with my next test.

I just tried the full page edit button again. It's still giving me the 2017editor. I still can't edit the page.

I just went to the first version of the page, to get away from the test content that I added to the page. I clicked edit. I am still getting the 2017editor. I still cant edit. It appears that the 2017editor issue is unrelated to any of my test content, as my test-content is not present on the page.

P.S. You said content corruption was unexpected. I did expect it. In my post to you on November 28 I asked:

Is it going to use VE's parser, parsoid, for saving as indicated in Phab task T238218?

That phab task says "Our current approach for saving wikitext replies via Parsoid". Running the wikitext through Parsoid was the source of corruption in Flow. The fix is to not send the content through Parsoid. The page is a text string, the new comment (with indentation and signature) is a another text string, just insert one string into the other without looping through Parsoid.

These links and added details are helpful – thank you, @Alsee. Comments below...

...diff you linked was indeed an example of corruption.

It seems like the markup "spilling" we're seeing here is related to, if not caused by, the issue raised here ("If outer loop counter is greater than or equal to eight, then abort these steps.").

With this said, Edit 3 in the corruption-causing-sequence seems to have been made using full page editing rather than the prototype...do you recall what steps you took that might have caused the `</span>` tag to be deleted, and as a result, the red text styling to be applied to the rest of the section?

(I ask the above in an effort to figure out how we ought to categorize this issue)

The inaccurate preview edit contains a random assortment of test content. The welcome template previews as indented, but the saved version is not indented.

Good spot. Here is the Phabricator task we will use to investigate this issue: T241388

...something in that comment might be the cause of the inability to reply to the comments of 16:30, 10 December 2019 and 02:50, 12 December 2019.

This is curious. Here is the Phabricator task we will use to investigate this issue: T241391

I don't think I did anything special to get the 2017editor. All I recall is clicking the full page edit button.

Thank you for the details here. I'm seeing the 2017 wikitext editor after clicking the full page edit button as well. We're investigating why the beta wiki is configured to have this editor as the primary wikitext editor.

...ran into a new issue. I saved a comment. I do *not* have any reply-box open. All reply links are blue. However when I try to leave the page I get the warning popup Changes you made may not be saved. Leave/Cancel. It seems that the page thinks I still have a reply-box open.

We've been able to reproduce this issue. Here is the Phabricator task we will use to investigate this issue: T241393

I just tried the full page edit button again. It's still giving me the 2017editor. I still can't edit the page.

Are you able to successfully save an edit to the current version of the talk page when using full page editing?

...I wonder if the issue you encountered (not being able to edit a previous version of the talk page) has  to do with how the Beta Cluster is configured.

Either way, here is a task to make sure this issue is documented, regardless of its relationship to the replying prototype: T241396

It seems like the markup "spilling" we're seeing here is related to, if not caused by, the issue raised here

Not related.

The issue raised in that link is that the Foundation changed the parser so that it would incomprehensibly ignore existing markup in some circumstances. The markup spills, but page source is unchanged.

The issue here is that the prototype deleted </span> from an old comment while it was adding a new one.

Edit 3 in the corruption-causing-sequence seems to have been made using full page editing rather than the prototype.

Nope. I definitely used the prototype. I just tested it again with the same result. All of these replies were made with the prototype:

• Reply-1: I posted "Red test", with only the word "red" is in red. It does not spill past the word red.
• Reply-2: I replied elsewhere in the same section. That worked fine, no unusual effects.
• Reply-3: Posted as a reply to Reply-1. This did cause a side effect, corrupting the existing content of Reply-1. It deleted the </span>, as happened before.
• I returned to an older version of the page, so that Reply-1 was undamaged. Reply-4: Posted as a reply to the parent of Reply-1. This reply also corrupted Reply-1.

I've left the page with several comments with the word "red" in red. Assuming they don't all get mucked up by someone else, you can try replying to them.

Are you able to successfully save an edit to the current version of the talk page

The 2017editor still won't let me edit. I can only edit if I manually modify the URL to get the normal wikitext editor.

Thanks for your patience here, @Alsee – some more information and two follow up questions below...

Nope. I definitely used the prototype. I just tested it again with the same result. All of these replies were made with the prototype:

Ok, we see what's happening here now. Thank you for elaborating on this. We were able to reproduce the corruption you initially described.

This is a case where the Parsoid is unexpectedly changing existing wikitext that's been written to the page.

Two resulting questions:

1. In what situations have you found yourself using this wikitext on talk pages?
2. Are you able to share links to the talk pages where you/others are using this syntax?

In the meantime, it seems like the following syntax constructions would have the same output as the problematic string and be Parsoid-compatible:

a) {{#if:x|<span style="color:red; font-weight: bold">|<span style="font-weight: bold">}}red</span> test.

b) <span style="{{#if:x|color:red;|}} font-weight: bold">red</span></nowiki> test.

While the alternative syntax above may work when posting new comments to a talk page, we appreciate there could be instances where this syntax already exists on some talk pages. In which case, using the new replying workflow, as it's currently implemented, could negatively affect those pages.

Like mentioned above, if you're able to share links to where this syntax is being used, we can reassess whether the new reply tool's incompatibility with this specific string is something we need to prioritize fixing.

In summary, considering there is Parsoid-compatible syntax that achieves the same output as the problematic string and we have yet to find examples where this string is being used in practice, this is not an issue we plan to prioritize fixing at this time. But again, we are keen to see examples where this kind of syntax is used so we can potentially change the priority.

More meta: we appreciate you raising this concern and would value you continuing to share examples of unexpected behavior with links to where you see them occurring.

@PPelberg (WMF): I tried to use the prototype, but ran into some problems...

When loading the talk page I get a console error:

Failed to load resource: the server responded with a status of 503 ()
VM36:203 RESTBase load failed: error

Then when I write a reply and click the "Reply" button, nothing happens. Tried it multiple times with the same results. Using Chrome on a Mac. The basic problem is that https://en.wikipedia.beta.wmflabs.org/api/rest_v1/page/html/Talk%3ACats/407862?redirect=false&stash=true returns a server error.

Another problem I noticed is that using <gallery> tags doesn't work right in the preview. Instead of getting a gallery, it shows a bullet list instead.

When loading the talk page I get a console error:and Then when I write a reply and click the "Reply" button, nothing happens.

Oh, thank you for raising this and including these details. I've added them to this Phab task: T239861.

I will reply to this comment once this issue is resolved.

Another problem I noticed is that using <gallery> tags doesn't work right in the preview. Instead of getting a gallery, it shows a bullet list instead.

Good spot. Hmm, this seems to be working properly on the prototype server, but not on ...beta.wmflabs.org. Here is the task to figure out why this is so: T241193

The prototype is now working normally. The issue raised in T239861 has since been resolved.

1. Yes, I think I was able to complete the tasks correctly.
2. I would have expected to be able to edit the comment inline. Additionally, the reply buttons didn't appear upon saving the page with the new wikitext editor, and I had to reload the page to perform step 8; the text box didn't appear when clicking "Reply" after going back to the "Read" tab from the "New section" tab (also with the new wikitext editor); and Firefox gave me the "data you have entered may not be saved" warning on closing the page after saving a comment.
3. It's already a little better in that less effort is required to post comments, and newcomers wouldn't be required to learn wikitext for basic text-only replies. However, the markup issues and inability to e.g. make a new section make it less usable in general due to the limited applications for which the editor can be used.
4. For fun, I decided to post this comment:

   __NOTOC__ __NOEDITSECTION__ __INDEX__ {{DISPLAYTITLE:cats}}{{Infobox person|name=Wikipedia|image=Wikipedia's W.svg|birth_date       ={{birth date and age|2001|01|15}}}}
   {|
   |Lorem ipsum
   |}
   

   Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning. It also appears that the formatting has resulted in: "list gap"; the entire page from that point being indented four times (including the sections below); the infobox being in a different list to the next three lines (it is indented four times, whereas the other text is indented eight times); the failure of the wikitext table formatting; and the disappearance of the {|. I think some of these are probably due to pre-existing bugs. (Infoboxes usually use HTML tables and not wikitext tables, so the infobox was not affected by the indentation.)

   Surprisingly, the preview was visually completely accurate, although it wouldn't have been if the infobox wasn't right-aligned (due to the superfluous indentation of the next two lines).

5. I'm not sure what the question really means, and it would help if it were more specific.

   Aside from making comments (you know, like a normal person), I don't use the banner templates much; I would say I most commonly use them for the links to deletion discussions and GA/FA discussions, as well as the dates that articles were promoted to or demoted to GA and FA. (The discussions have usually already concluded, so this is mainly out of interest than because it makes me more productive or anything.)

   However, I generally use non-talk-namespace discussion pages as much as talk pages; I typically use Project-namespace discussion pages more than all talk pages on the English Wikipedia and Wikidata, and vice versa for Commons, Meta-Wiki and MediaWiki-wiki. Out of the talk namespaces, on Wikipedia it's usually User talk, Wikipedia talk and Template talk, and more occasionally Talk and Module talk; on Wikidata it's usually User talk, Property talk, Wikidata talk and more occasionally Talk; and on the others it's usually Talk and occasionally User talk.

6. I would say I currently use talk pages weekly and non-talk-namespace discussion pages weekly-ish, but in the past it would have been daily for both for various periods.

We appreciate you taking the time to try out the prototype and share your thorough feedback. I hope the time it's taken us to reply here does not signal the opposite.

Now, getting into the points you raised, a few comments and questions...

I would have expected to be able to edit the comment inline.

This is reasonable expectation. Currently, we are planning for this functionality to be included in v1.1. For context, the scope of this release is being defined in this ticket:T236916.

...the reply buttons didn't appear upon saving the page with the new wikitext editor...

This issue should now be resolved now that the new wikitext editor is no longer enabled on the prototype. If you are still not seeing the "Reply" links after saving an edit using full page editing, please let us know.

...the text box didn't appear when clicking "Reply" after going back to the "Read" tab from the "New section" tab (also with the new wikitext editor)...

Are you able to try this once more and see if the issue persists and if it does, let us know? ...I think this should now be resolved.

Firefox gave me the "data you have entered may not be saved" warning on closing the page after saving a comment.

Good spot. This seems to be happening to others as well. Here is the task where the work to resolve this issue is happening: T241393.

...the markup issues and inability to e.g. make a new section make it less usable in general due to the limited applications for which the editor can be used.

Markup issues: are you referring to the issues raised in "4." here?

New sections: How and when the reply workflow supports the creation of == new sections == is something the team plans to discuss before v1.0's release. In the meantime, I saw you've expressed some thoughts around this on Phabricator (T241388#5766816). Tho, I wonder in what situations you notice yourself posting a reply and creating a new section in one edit?

Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning.

Can you expand on this a bit more? My assumption is that magic words, like __NOTOC__ __NOEDITSECTION__ __INDEX__ should work on talk pages and so it's expected that they would work if posted to the page using the new replying workflow. Although, I suspect you're aware of something I'm not...

...you can expect a response about the remaining points you raised [1] next week; I just wanted to make sure we got a start on these before any more time passes. Thank you for your patience and continuing help with all of this work.

---

1. Remaining issues to talk about:

a) Formatting resulting in a "list gap"

b) The content of a reply affecting the indentation of other content on the page

c) An infobox being indented at a different level of depth than the rest of the content the infobox was posted with

d) Inability to embed a table in a comment

By "markup issues", as well as the issues I mentioned specifically, I was also referring to the other markup inconsistencies between the inline editor and the usual wikitext enviroment, mainly those caused by the automatic addition of list items.

I don't add new sections as well as comments very often. I think it'd nevertheless be worth preserving at least some of the more complicated workflows that are currently used, simply because it would provide a better user experience. (If users have to use the source editor as a fallback often, they might as well just use it all the time.) A number of user scripts, such as Twinkle, XfDCloser and VisualFileChange, exist specifically to make it easier to perform such workflows on talk pages, and it would make a lot of sense for the inline UI to be able to make similarly complex workflows easier (although these would have to be limited to generic workflows – such as the ones I mentioned in this Phabricator task – or generic workflow templates, similar to the existing preload feature). Aside from the utility of adding such workflows, one of the reasons I've mentioned these a lot at this stage is that the automatic nesting and signature would prevent users from doing these things, and it's possible that they wouldn't expect it to be a problem.

In Structured Discussions, you would expect magic words like NOINDEX and categories to have no effect. As Jeblad noted in this discussion, it would probably be beneficial to make the new discussion formatting work like that if it were feasible (i.e. by parsing comments specially). I think it makes sense, because previously there was basically no control over the structure of talk pages, whereas with this project at least some of that structure will have to be defined as a prerequisite for the software to actually work. Since the opportunity arises to modify that structure (if new markup is to be introduced), it would be appropriate to make it difficult for users to inadvertently break that structure (and other parts of the talk page) within the inline editor.

I'm sorry it's taken this long to get back to you @Jc86035..

I'm going to respond in a series of separate comments to make these responses both easier to read and discuss...

By "markup issues", as well as the issues I mentioned specifically, I was also referring to the other markup inconsistencies between the inline editor and the usual wikitext environment, mainly those caused by the automatic addition of list items.

This context is helpful. Thank you. A quick update on how we're thinking about the replying workflow's inline editor…

For now, we are assuming the real-time preview will be sufficient in helping contributors understand what markup the replying workflow does and does not support.

In the longer-term, we hope to introduce new wikitext syntax that will expand the range of markup capable of being embedded in list items, and by extension, comments posted using the new replying workflow.

I know you've been actively involved these conversations [1]. I'm sharing this detail here in case it is news to someone reading this thread.

1. https://phabricator.wikimedia.org/T230683

I think it'd nevertheless be worth preserving at least some of the more complicated workflows that are currently used, simply because it would provide a better user experience. (If users have to use the source editor as a fallback often, they might as well just use it all the time.)

This is a great point. I've added the scripts you shared to the thread we have going [2] about gadgets and templates that are used on talk pages. This way, if/when we explore adding shortcuts to the workflow, we have a list of popular tools in one place.

To the potential you raised about contributors being more likely to use full page editing all the time if they find many of their common workflows are not supported by the new replying tool...I think this is a great thing to mention.

Our thinking: once the feature gets deployed on live wikis, it will be important for us to do three things:

1. Keep track of instances when the workflow does not support what contributors expect it to
2. Understand how common and important these workflows are and
3. Determine whether adding support for them needs to be prioritized.

Please let me know if the above does not address the concern you are raising fully. I appreciate this is a point you've mentioned a few times which leads me to think you might be seeing something I am not...

2. https://www.mediawiki.org/wiki/Topic:V9936tycku9n6dt7

I think that makes sense as an approach. Would you track this by measuring when users exit the inline editor and use a different editor instead, by analyzing all discussion page edits made by users who have the extension enabled, or by some other method?

Good question. In an effort to understand the extent to which the new replying tool is not meeting contributors' expectations, we are planning to start by looking at the percentage of contributors who start drafting a comment and who end up actively abandon it before posting (e.g. click "Cancel").

It would be nice for us to be able to answer a question like the one you entered here (phrased below [1] in a slightly different way), but I'm not yet certain whether we're capable of measuring it or not.

---

1. What percent of edits made using Replying feature are "immediately" followed by a non-DiscussionTools edits to the same page by the same person?

In Structured Discussions, you would expect magic words like NOINDEX and categories to have no effect.

Ah! I think the point you are making is connecting with me now. Can you please let me know if how I'm understanding this point matches up with yours?

My understanding: As it's currently implemented, the replying workflow could lead contributors to think their ability to affect the talk page is limited to the text they are inserting into the page. This could lead contributors to be surprised when text they enter in a reply affects the rest of the page.

Yes, that's what I meant. It's probably not a massive concern, though; my mention of this was primarily influenced by Jeblad's reasoning for "armouring the output" (that is, sandboxing each individual comment using an extension tag).

They're talking about that. It'll require a technical RFC, though. Keep an eye out for something about "multi-line comments", hopefully later this month.

Aside from DISPLAYTITLE, all of the magic words worked, which is mildly concerning. It also appears that the formatting has resulted in: "list gap"; the entire page from that point being indented four times (including the sections below); the infobox being in a different list to the next three lines (it is indented four times, whereas the other text is indented eight times); the failure of the wikitext table formatting; and the disappearance of the {|. I think some of these are probably due to pre-existing bugs. (Infoboxes usually use HTML tables and not wikitext tables, so the infobox was not affected by the indentation.)

List gap: Are you able to share what lines of a reply containing this text [3] become separated by a list gap

Issues with table formatting (page corruption and disappearance of `{|`)

This behavior seems to fall into the category of "preexisting bugs" you alluded to, but please tell me if you see it otherwise.

Here's what we're understanding to be happening...

When someone attempts to post a table inside of a list item (read: comment), the rest of the content of the page gets incorporated into that table.

Right now, we are not planning to address this issue for the following reason:

We are assuming contributors attempting to add a table inside of their comment will:

1. See the real-time preview of the comment they have drafted
2. Notice the table markup they have entered does not render/display in the way they intended it to
3. Not post a comment containing a table

With this said, our assumptions could be incorrect. For example, rather than not posting the comment, contributors might assume the preview is broken and post their comment anyway.

If this happens frequently, we would need to come up with a more effective way for the feature to communicate to people the kinds of markup it can and cannot support.

Infobox being in a different list item

This behavior also seems to fall into the category of "preexisting bugs" you alluded to and for the reasons mentioned in the "table formatting" issue. Although, please tell me if there is something I am missing.

---

3. Topic:Vcwvt3bq03o5gv8h

It looks like the list gap was caused by the unclosed {|.

It looks like the list gap was caused by the unclosed {|.

Meaning, that in posting a comment using the new Replying tool (let's call it "Comment A") on a talk page that contains a table, "Comment A" will strip the table's closing table tag ( |}) resulting in a list gap?

Yes, but it happens mainly because the closing tag isn't recognized due to being preceded by colons. I think. It's probably related to how tables within definition lists are parsed specially. (In terms of this project, I don't think it'll end up being especially relevant unless the table-within-a-list parsing is modified as a result of the introduction of multiline list item syntax.)

Do you think that you completed the Task above correctly? - Yes.

Was there anything painful or not obvious about this experience? - My message dont appear on a page

I pressed Reply on first message and entered this text:

---

# first

# second

** second unnumbered

#* second numbered

no list

---

All just dissapear.

PS. Any reply on a first message makes text simply dissapear. No traces in history too.

Well, there is a bug. I can't close the discussion page after the reply publishing, the browser claims I'm in the middle of the edit.

hi @IKhitron – we appreciate you trying the prototype and sharing the issue you encountered. We have it documented in Phabricator here: T241393.

The "abandon edit" warning issue aside, how did you find the rest of your experience trying the prototype? Were there other tasks listed in the "Test instructions" section you found behaved in unexpected ways?

Thanks. Didn't do it yet. Maybe later. Just played and compared with the original one, the CD.

1. Do you think that you completed the Tasks above correctly?
   1. All but the editing one. See below.
2. Was there anything painful or not obvious about this experience?
   1. Not to an experienced Wikipedia editor, but I think newer users coming from other platforms may find it unintuitive to have to click "edit" in the section header or on the page to edit comments. Compare Youtube, Facebook, etc. where "edit" for that comment is next to said comment. In this particular interface, I'd imagine, for example: [my comment] [my username] (talk) [timestamp] (UTC) (reply | edit)
   2. Also, for some reason, when I visit the page on the same browser session I used to edit, I see my comments, as expected. But if I open a different browser session (Guest on Chrome, for example), none of my comments appear. The bug also occurs when opening the page on a different browser (Firefox 72.0.2 (64-bit), Private mode). I use Chrome 80.0.3987.149 (Official Build) (64-bit) on Windows 10. Yes, I did press Ctrl+F5 to clear the cache. My comments still did not appear only appeared on the tab in the same browser session.
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
   1. I've used reply-link on en-wiki, I think it's called? This is better in that replying to a high level comment seems to place your reply in the right place.
4. What other additional comments, concerns, or ideas would you like to make known?
   1. Some edits have the tag "source" in addition to "reply". What does that mean?
5. How do you typically use talk pages (across namespaces)?
   1. To collaborate with other editors. Mostly I perform Gnomish tasks like editing banners, archiving old discussions.
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?
   1. Weekly? I've participated more often this week, but if distributed evenly, probably weekly.

Thank you for taking the time to try the prototype and share your feedback, @Rotideypoc41352. We're glad to hear the Replying tool posted your comment to the page in the place you expected it to.

As to some of the comments you raised...

I think newer users coming from other platforms may find it unintuitive to have to click "edit" in the section header or on the page to edit comments. Compare Youtube, Facebook, etc. where "edit" for that comment is next to said comment. In this particular interface, I'd imagine, for example: [my comment] [my username] (talk) [timestamp] (UTC) (reply | edit)

This is a great point and the workflow you are describing is one we've started work on; you can see a mockup here.

So you're aware, we have not yet set a date when this functionality will be deployed.

...when I visit the page on the same browser session I used to edit, I see my comments, as expected. But if I open a different browser session (Guest on Chrome, for example), none of my comments appear

Comments you posted appearing in one browser and not another is certainly unexpected. To be sure, are the comments you are expecting to see in the second link comments posted using the following IP address: 104.33.84.249?

If yes, then I think it is expected for you not to be able to see the comments you posted as 104.33.84.249 in this second link.

Reason being: that second link is showing an old version of the talk page as edited by Catgirllover4ever at 17:24, 24 March 2020, 12 hours before the first edit by 104.33.84.249 was posted to the talk page.

Please let me know if you think the above does not explain what you are experiencing.

Some edits have the tag "source" in addition to "reply". What does that mean?

"source" refers to the fact that the reply was posted using the "source" or wikitext input mode. This additional change tag will become more useful in the near-term future when there is a second `visual` or rich text input mode.

You can see [and share your feedback about] the proposed designs here: Talk pages project/replying#Version 2.0.

I just want to note that I see my comments now! Not sure what was going on before this. Just in case: still using Chrome 80.0.3987.149 (Official Build) (64-bit) on Windows 10. Thanks again!

Thank you for following up about this, @Rotideypoc41352 – I'm glad to hear your comments are appearing as you expect them to.

And what timing: I was just moving "look into the issue user:Rotiedeypoc41352 reported" to my to-do list for tomorrow...

are the comments you are expecting to see in the second link comments posted using the following IP address: 104.33.84.249?

The second link is an illustration of what I see when I go to https://en.wikipedia.beta.wmflabs.org/wiki/Talk:Dogs. I expect to see what's in the first link, but I don't. No idea what's happening, as clearly the edit history shows my comments.

Thank you again for your time and patience. Stay well!

Before doing my edits I cleared the section and left only the first commet because some unusual insertions made it not working anymore.

Answers:

1. I've used the normal editor to edit my comment in step 6. Was that right?
2. No
3. • It's fine but there's the same issue as in the already existing reply feature on mobile: Comments are signed using ~~~~ and not --~~~~ but the second one is the signature used by the normal editor.
   • The yellow highlighting should appear behind and not in fornt of the text. Because it appeares in front of the text, the text can't be read well (but the highlighting disappeares immediately this is just a minor issue.
4. Users can get confused because replys are auto-signed but new sections have to be signet manually
5. Currently only to write complaints or information to new users or bad gus. Most times I'm adding a new section with a template (that is substituted and often includes an automatic signature) but sometimes I also have to reply.
6. I don't know.

1. Do you think that you completed the Tasks above correctly? No, I wasn't able to edit the comment. Also my Edits seem overblown by bytes. Though it seems I'm not the only one with this problem.

2. Was there anything painful or not obvious about this experience? No, the UI is quite nice. Although the generated code is still using DL, DD, DT-Tags instead of proper paragraphs.

3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop? It's definitively faster. I like it. AND the biggest plus: nobody will ever miss their signature again, this alone is awesome!

4. What other additional comments, concerns, or ideas would you like to make known? Proper HTML-formatting would be nice, though I think this is not in the scope of this project.

5. How do you typically use talk pages (across namespaces)? Quite heavily to discuss all sorts of things. Though the process is normally pretty painful. But that is the communities' fault.

6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly? When I'm working in one of the projects (which I didn't do for the last couple of months) at least once a day I would estimate. Could be more.

Regards --~~~~

1. Do you think that you completed the Tasks above correctly?
   • I think so, but probably given that I was an experienced Wikipedia/wikiHow editor with knowledge of the MW software.
2. Was there anything painful or not obvious about this experience?
   • I could not find the "Edit" button next to my reply, so I had to go into the source code to edit my reply.
3. How does replying with the replying prototype compare with the current experience for replying to comments on talk pages on desktop?
   • It seems very similar to wikiHow's commenting feature, except it was more structured.
4. What other additional comments, concerns, or ideas would you like to make known?
   • I think this is important because new editors may have a difficult time with talk pages, but at the same time, we want a smooth transition from "Posting comments aimlessly on talk pages" to "Being able to post within a discussion properly without missing signatures or indentation".
5. How do you typically use talk pages (across namespaces)?
   • Not that often, but I still raise issues on the talk pages of articles and on other user's talk pages.
6. How often do you typically participate on/edit talk pages? Daily? Weekly? Monthly?
   • Daily to weekly, sometimes monthly.

Hello, when i was not logged in, there is parsoid err: "Error contacting the Parsoid/RESTBase server (HTTP 500)" - and i think, its not very good. :) --~~~~

@Frettie I think you are not supposed to see this yet, when you are not logged in.. How did you enable it ?

@TheDJ Open that beta wiki page. :)

Frettie, can you try again? The servers were having some problems yesterday.

Hello, I just got the same error message as Frettie, while not logged in. I could edit the page normally though.

@Whatamidoing (WMF) yes, its ok!

My IP seems to have went 'bonk' on the test server. I still have no idea why I'm assigned a private-use IP Address that is subsequently autoblocked (JonelleMaier71) by an edit filter. My IP is static, and yet seems to be something completely different on this specific wiki.

Considering most might be using these bogon IPs, I think this is just a case of weird range-blocking.

I am not able to complete the test. What I attempted to post was the following, and the first part of it has much to do with why it failed (the second part reports another problem, in sig processing):

For some reason, I cannot create an account here. No matter what VPN I come in from, I get a bogus message stating 'Autoblocked because your IP address was recently used by "JonelleMaier71".' (And this beta box doesn't seem to be hooked into the SUL system.) Anyway, this is meta:User:SMcCandlish.

PS: It is weird that this automatically adds a sig. I hope that it's smart enough to detect when people add ~~~~ (as I'm about to test), and not double the sig when that happens. In typing it out, this system appears to recognize ~~~ (username only), then add the complete sig after it; and recognize ~~~~ (normal sig) without doubling the sig; but fail to recognize ~~~~~ (date only) at all. It treats ~~~~~ as if it were ~~~~ preceded by a stray, meaningless ~ character. Anyway, I do like the live preview. It has a bit of latency, and it might be worse on a heavily populated server like en.wikipedia, but we'll see.

When I attempted to post this, I got another bogus error stating "Your IP address has been blocked automatically, because it was used by a blocked user." I switched to yet another VPN node, same crap. I tried servers as far apart as Los Angeles and Latvia. So, that's pretty broken.

PS: I also found that the link w:en:User:SMcCandlish would not work, and had to change it to meta:User:SMcCandlish. I doubt that has anything to do with this software and is a server config issue.
 — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  11:38, 14 April 2020 (UTC)

I too am unable to create an account, I keep getting the same message as everyone above "Autoblocked because your IP address was recently used by "JonelleMaier71" (although the name was different yesterday), I did message PPelberg yesterday who also seemed confused by it,

I've deleted all wiki(p)(m)edia cookies however unfortunately that had no effect so unless this is fixed then I'm unable to test this feature, Thanks, Regards, ~~~~

@ToxiBoi, @SMcCandlish, and @Davey2010 first off: thank you for being patient with us and sharing the issue y'all are encountering.

I can think of better things to experience than being asked to try out a prototype only to find out that there was a bug preventing you from doing so.

With this said, I hope we will have this issue resolved soon. Here is the task where work on this issue will happen: task T250245.

In the meantime, could you please have a quick read through the steps below to ensure they match up with what you experienced?

Steps to reproduce issue:

1. Go to en.wikipedia.beta.wmflabs.org
2. Click the Create account link to the left of the Log in in link in the top right corner of the window
3. Enter a username, password, etc
4. Click Create your account
5. ❗️Receive the following message: Autoblocked because your IP address was recently used by (a username that seems to vary day-by-day)

That sounds about right. I just tried it again, and this time got a different error (at the same point, after clicking "Create your account"):

Database locked

The Wikipedia database is temporarily in read-only mode for the following reason:
The database is read-only until replication lag decreases.
[misc. additional boilerplate here]

I'm not sure if that's progress (i.e., I'm not sure if this kind of error would be triggered before or after the previously reported one).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:45, 15 April 2020 (UTC)

Never mind. It apparently "mostly worked". I went back to try again (sometimes these database-lock errors last less than a minute), and it actually already had me logged in. So, it apparently queued the registration form submission then resubmitted it for me as soon as the db lock cleared.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:48, 15 April 2020 (UTC)

Woosh! Thank you for letting us know, @SMcCandlish – I'm glad to hear you were able to create an account. Curious to hear what you think of the prototype if/when you have an opportunity to try it out...

My first situation was a little different, as I was posting a comment in Reply and the error message appeared in the box above. However, I can confirm those steps were accurate the second time around.

It seems to be fine now, I just created an account and it gave me a survey.

It seems to be fine now, I just created an account and it gave me a survey.

Excellent – thank you for being patient with us and letting me know things are working on your end, @ToxiBoi.

Success!! - Account creation worked! :),

My only other problem is that for whatever reason someone took my username - Is there any possible way I can have it given their only contribs are creating a userpage and talkpage ?,

My account over there is "Davey2010EN" but would rather have just "Davey2010" if at all possible,

Thanks PPelberg and those at Phab for kindly getting this issue fixed :), Thanks, Kind Regards, Davey2010

Success!! - Account creation worked! :),

^ _ ^

We have people like @Hashar and @Krenair to thank for this speedy fix...

Is there any possible way I can have it given their only contribs are creating a userpage and talkpage ?,

This I do not know. My instinct would be to one of two things:

1. File a task in Phabricator that describes the change you would like to see made. I'd also recommend tagging "Beta-Cluster-Infrastructure".
2. Start a discussion on the Beta Cluster talk page.

Hi @PPelberg (WMF), Done :),

Many thanks again for yours and everyone elses help here it's greatly appreciated,

Once I know the outcome to my query I'll try this feature either way but in the meantime apologies for the delay on my part, In all fairness I wasn't to know I'd be account creation blocked and then I also didn't know someone would take my username so I guess it's one those things annoyingly but yeah sorry for any delays on my part, Anyway many thanks again :), Thanks,

I'm one massive idiot!, Apparently I created the account back in 2014 (or it was unified) .... if it was the former then I have no recollection of it but yeah I'm in!, Thanks

Whenever I try and reply to a comment I keep getting "Error contacting the Parsoid/RESTBase server (HTTP 500)" however I'm able to create new sections with no problems, Thanks

I'm sorry that you've encountered so many problems with the Beta Cluster. "HTTP 500" errors are basically never your fault or a problem that you can solve. They've got it working again.

Hi @Whatamidoing (WMF), Unfortunately I'm still getting the same error, I give up trying!,

As general feedback I like the reply feature a lot (Obviously couldn't use it but clicking a button and replying is a lot better and much more easier than having to use Wiki markup -

(Don't mind wiki markup but personally I do prefer this feature and it also means I can reply and not have to worry about indents which I still mess up on a daily basis lol)

My only suggestion which I don't think applies here but I'd like to see the feature updated so that when you create a new section it sort of has the same box etc etc and it signs the post for you,

Overall personally I think this feature is a major improvement to what we have and whilst I didn't get to actually use it it looks easy and simple to use, Major improvement for the newbs and major improvement for us normies too :),

Thanks,

Regards,

@JKlein (WMF) is looking at ways to improve the start-a-new-discussion feature at Talk pages project/New discussion (please put that page on your watchlist, if you're interested). I can't remember off hand whether she's already put automatic signing on her list, but I'm sure she'll be interested in knowing that you recommend it.