Most of you probably don't care, nor will it affect anyone, but just putting it out there 
There were three significant UX changes that happened with v3, that alter how users interact with posts:
Two unintentional effects:
toPid, meaning any reply made using the quick-reply box is technically a reply to OP.Both these effects mean more replies probably have toPid set to OP instead of to a more accurate value.
For forums, and especially for NodeBB, this doesn't really much matter. Posts contain a toPid mostly as a curiosity, and posts themselves are ordered by their post time (unless changed by the user setting).
As part of my research into federated instances, I've realized that it would be incorrect for us to send in those values as topics would unintentionally end up shallow, with many small threads branching off of the main post (when in reality, there may be fewer, but longer, discussion threads).
To resolve, I will likely change the behaviour of the quick reply box to automatically act as a reply to the LAST post.
Optionally, if the "direct reply" button is clicked, instead of opening the composer, I could change the toPid of the quick reply box, and redirect focus to that control instead.
J julian moved this topic from General Discussion on
That is a good point, I hadn't considered that.
However, wasn't this already the case with Persona when people were using the in-post reply buttons more often? For example, if we continue to click the in-post reply button for each of the replies in this topic, then each post will have the replies dropdown.
One potential mitigation would be to only show the replies dropdown if there is more than one direct reply. If there is only 1, then only show it if that reply does not come directly after the post in question?
@baris said in [RFC] Change to the quick-reply `toPid` value?:
I will likely change the behaviour of the quick reply box to automatically act as a reply to the LAST post.Hmm, I don't like this idea, it would result in every post to have the replies dropdown.
Circling back to this point, as of this commit, the replies dropdown is suppressed if that post only has one reply, and if that reply happens to be the next post in line.
https://github.com/NodeBB/NodeBB/commit/da02361b13d064763223533368f9b71d998ecf37
So, that's resolved, yes?
@baris, internally, said the following:
hmm im not sold on that one only because its not apparent that its a direct reply
we have direct reply buttons on each post and its explicit
We still have this indicator, which functions well enough, no? 
That indicator shows up after you reply. Right now direct replies are only created when you explicitly click reply button on the target post.
With this change every post made will be a direct reply to the post before it even if the user meant to just post something in the topic.
@julian said in [RFC] Change to the quick-reply `toPid` value?:
- The Harmony theme hides the reply/quote/voting/post-tools buttons until you hover over the post.
- The post bar is sticky and floats at the top of the page.
@julian said in [RFC] Change to the quick-reply `toPid` value?:
Circling back to this point, as of this commit, the replies dropdown is suppressed if that post only has one reply, and if that reply happens to be the next post in line.
I can't help but wonder if some of these preferential features would be better addressed with an option in the admin. Especially the sticky post bar.
For example, I can see how the suppression of the replies dropdown was intuitive, but on the other hand it also has an informative value. Users may come to associate a post with a replies dropdown as a post with replies, and a post without a replies dropdown as a post without replies. If I am scanning a thread with hundreds of posts it is nice to be able to see, at a glance, whether a post has received replies or not. I myself have been making use of the replies dropdown as a way to quickly gauge how many replies a post has received.
(Actually, I am hoping to write something which modifies the replies dropdown to significantly truncate the previews, so that it acts more like a links-to-replies. Perhaps it would only truncate after the number of replies is greater than X.)
@BrotherGlaucon said in [RFC] Change to the quick-reply `toPid` value?:
I can't help but wonder if some of these preferential features would be better addressed with an option in the admin. Especially the sticky post bar.
Looks like we have you beat there too. The sticky post bar is an option specifically because I made a fuss 
Ironically, after turning the sticky post bar off, I later turned it back on. Shh, don't tell @baris.
For example, I can see how the suppression of the replies dropdown was intuitive, but on the other hand it also has an informative value.
Thanks for sharing this. While I agree that there is some informative value in having the replies dropdown, I still feel that its presence takes away more from the UI (in terms of redundancy) than it provides. While it is true that you can know at-a-glance whether a post has replies, I'd want to know what specific value it provides to you as an end user, besides the tautological one (i.e. it provides value when showing a post has replies, because it shows it has replies).
@julian Awesome, thanks for making a fuss. 
The stuff you guys are discussing in this thread is important imo, so I'm glad you're making the effort to think about it out loud. Well-oiled toPid logic is great for providing strong navigation and notifications.
@julian said in [RFC] Change to the quick-reply `toPid` value?:
While it is true that you can know at-a-glance whether a post has replies, I'd want to know what specific value it provides to you as an end user, besides the tautological one (i.e. it provides value when showing a post has replies, because it shows it has replies).
For me one of the primary values of that information is found in picking up the thread of a conversation between two or more users. Traditionally forums have only had back-links, and the only way to read a conversation was to start at the very end and follow the reply-links through to the beginning, perhaps opening each post in a new tab so they could then be read sequentially once you find the beginning. The replies dropdown allows me to start at the beginning and follow the conversation as it bobs and weaves randomly through the thread.
The broader point is consistency of expectation. If users aren't reading each post of the thread and they want to do what I just described, they could train themselves to <first check to see if there is a replies dropdown; if not, check to see if the next post is a reply; if both of these conditions fail then I am at the end of the conversation>. But more consistency makes it easier to accomplish this use case, as well as the simpler use case of gaining information about whether a post has received replies.
(Just my $0.02. I am coming from long-form discussion forums where it can be hard to follow a conversation from post to post, where users generally do not read each post in a thread, and where time zone differences tend to place gaps between responses.)
