Page MenuHomePhabricator

Flow: Indentation model is unclear
Open, LowPublic

Description

I created a topic and four times answered on it
it looks like this

topic
1topic-post
* 3post
* 4post
* 5post
2post

1.first of all (when the initial level of indents) - it turns out that the first comment in topic now become the last one - it's weird
what's the matter:

  • press the "reply" at the main (first) post in the topic
  • reply field appeared indented at the bottom of post

what was expected:

  • the focus moves to the reply field which is at the bottom of topic

2.secondly (when the initial level of indents & in deeper indents) - two different situations show the same
2.1. in one case, I always answer to 1topic-post
2.2. in the second case, 4post - is the answer to 3post
but Flow shows it is equally

Flow should be automatically adjust the levels already wrote a post (suitable as with T94913) or change the "new" model T88501

See also

Event Timeline

Sunpriat created this task.Apr 2 2015, 10:38 PM
Sunpriat raised the priority of this task from to Needs Triage.
Sunpriat updated the task description. (Show Details)
Sunpriat added a subscriber: Sunpriat.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 2 2015, 10:38 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Sunpriat updated the task description. (Show Details)Apr 2 2015, 10:39 PM
Sunpriat set Security to None.
Sunpriat updated the task description. (Show Details)
Sunpriat updated the task description. (Show Details)
Sunpriat updated the task description. (Show Details)Apr 2 2015, 11:57 PM
DannyH triaged this task as Low priority.Apr 3 2015, 12:00 AM
DannyH added a subscriber: DannyH.

The new indentation model is just being used for the first time on Mediawiki this week. It may require some minor changes in convention and adjustment of expectations, as the previous indentation model did.

It's difficult to evaluate the feature by creating sample conversations where you're talking to yourself about reply levels. It's true that the indentation doesn't work the way that you were hoping that it would.

If it helps -- the entry field appears exactly where the new message will be posted, so if you see that it's going to be posted in a location that you don't want, then you've got some information to work with.

Before we make any further changes, I want to see people using the feature in some real conversations that aren't about the indentation levels. The feature should be judged based on whether it helps people have high-quality, productive conversations.

Sunpriat updated the task description. (Show Details)Apr 3 2015, 12:05 AM
He7d3r updated the task description. (Show Details)Apr 3 2015, 12:07 AM

rephrase:
there is a topic (title of the topic and the initial message topic)
usually all the answers to the initial message look like

==topic==
topic-post
:1post reply to topic-post
::reply to 1
:2post reply to topic-post
::reply to 2

for Flov it will be

topic-post
1post reply to topic-post
*reply to 1
2post reply to topic-post
*reply to 2

in Flow response to the initial-topic-post in general should not create an indent
expected

topic-post
1post reply to topic-post
*npost reply to 1
2post reply to topic-post
3post reply to topic-post
4post reply to topic-post
5post reply to topic-post

but by pressing the button Reply to in initial-topic-post Flow creates the following order

topic-post
*2post reply to topic-post
*3post reply to topic-post
*4post reply to topic-post
*5post reply to topic-post
1post reply to topic-post
*npost reply to 1

This button should work correctly, or it should not be in initial-topic-post or I do not understand Flow

Old model


New model

for the initial post, nothing has changed

Sunpriat added a comment.EditedApr 6 2015, 2:45 AM

Proposition for "2.secondly":
On the line (it consists of gray dots) make big gray dot (or backslash of dots) where chat between two users stops and begins new answer to the previous level post.

As usual do it in wikitext

post
* re
*: re

big dot

post1
| 3 reply to 1
| 4 reply to 3
* 4 reply to 1
| ...
post2

backslash of dots

post1
| 3 reply to 1
| 4 reply to 3
\ 4 reply to 1
| ...
post2

also, where begins a chat between two users to put a triangle on the line by pressing which you can fold them chat or their branch

post1
|...
>  3 reply to 1
|  4 reply to 3
|   ...
| ...
post2
He7d3r updated the task description. (Show Details)Jun 4 2015, 3:13 PM
qdinar added a subscriber: qdinar.EditedFeb 6 2016, 10:26 AM

@Sunpriat "or I do not understand Flow" - yes, you did not understand it.

topic-post
*2post reply to topic-post
*3post reply to topic-post
*4post reply to topic-post
*5post reply to topic-post
1post reply to topic-post
*npost reply to 1

should be understood this way:

topic
0post
*2post - reply to 0post, creating a subthread, discussion of 0post
*3post - reply to 2post, in subthread of 0post
*4post - reply to 3post, in subthread of 0post
*5post - reply to 4post, in subthread of 0post
1post - reply to 0post (and to topic) , in main thread
*npost - reply to 1post, creating a subthread, discussion of 1post (i have edited this place, see next comment)
(n-x)post - reply to 1post (and to topic) , in main thread
...

and see my comments and images in https://www.mediawiki.org/wiki/Topic:Senq838us190rqlp . i wrote similar idea suggestion in 2009-august-26 , for livejournal comments , you can read also in russian : http://dinarkurbanov.wp.kukmara-rayon.ru/2009/08/26/ветвление-комментариев-в-жж/ .

qdinar added a comment.EditedFeb 6 2016, 10:45 AM

add: and, here is a error in my explanation at

...
1post - reply to 0post (and to topic) , in main thread
*npost - reply to 1post (and to topic) , in main thread

if there is nothing under "npost" in main thread (with no indentation) this indendation of "npost" is not possible in current new indentation model of flow, (and maybe also was not possible in old model), it is only possible if there are already some posts in main thread below "npost":

...
1post - reply to 0post (and to topic) , in main thread
*7post ("npost") - reply to 1post, creating a subthread, discussion of 1post
6post - reply to 1post (and to topic) , in main thread

why it is so - because last post in classical diagonal thread also does not allow 2 different ways of replying to it.

i have written explanation about new indentation model, but i am not sure about what you model you say, i did not see the old model.

DannyH removed a subscriber: DannyH.Feb 8 2016, 7:22 PM
Mattflaschen-WMF renamed this task from Flow: It is unclear shows indentation to Flow: Indentation model is unclear.Jan 17 2017, 11:50 PM

[I copied this thread over from emails sent around 2/8/17]


Pau writes

The threaded vs. flat model is a recurring topic about discussion systems in general, and Flow in particular.

It is specially interesting to check some of the hybrid models that try to combine the benefits of both paradigms. Recently, Slack (mainly based on flat discussions) introduced the possibility of creating threads following an interesting model: https://slackhq.com/threaded-messaging-comes-to-slack-417ffba054bd

It was recently introduced, so it is not clear that it will be useful even for them (not to mention in other contexts), but it is worth taking a look.

Matt replies

Flow is also a hybrid model, so this is interesting.

Summarizing: The Slack model is now that the channel is a flat discussion. At any time, you can decide to reply to a message in a thread, which essentially creates another flat (AFAICT) discussion called a 'Thread'.

So it's still flat, but there are now two levels. It's analogous to one flat Talk:Earth page, where you could create a flat "Age of the Earth section" by replying to a post about that issue.

Nick Replies

We used 2 level indent in the first iteration, but almost everyone hated it, so we added a 3rd. https://www.mediawiki.org/w/index.php?title=Topic:Rpx4cdyu8bls80rm&topic_showPostId=rq147yo578mk9vwk#flow-post-rq147yo578mk9vwk

Later, we analyzed what external sites do, breaking it down by:

  • Flat, zero levels of nesting
  • One level of nesting
  • Two levels of nesting
  • Three levels of nesting
  • 8-12 levels of nesting
  • 30+ or more levels of nesting

with examples and pros/cons for each.
https://en.wikipedia.org/wiki/Wikipedia_talk:Flow/Archive_6#Request_for_your_feedback:_Let.27s_talk_about_nesting.21

Slack is (IIUC) primarily a real-time semi-asynchronous chat platform, like IRC and gchat and other instant messenger platforms. (I'd like a second level of indenting in IRC, so that multiple discussions could happen simultaneously, with more clarity than they currently do!). I don't think it's not a good comparison for a discrete-topic system (e.g. it wouldn't work well if we tried to force a busy noticeboard into that format.)

In my opinion/experience, flat, or minimally nested discussion systems, are good for small quantities of contributors. However, once more than ~10 people get involved in a topic, especially a long and complex topic, it gets very very confusing.

The only successful true-hybrid model I know of, is stackoverflow (3 level indent), and that only succeeds because it has a single, rigid, *type/format* of discussion, throughout.

  • Question->Answers->Comments.

E.g. this massive topic is somewhat comprehensible, due to rigid/predictable formatting. https://stackoverflow.com/questions/871405/
but it wouldn't work well for complex forking discussions

Quora and Reddit and classic-Wiki-talkpages, which have dozens-to-hundreds of people involved in each of the more complex topics on a busy page, generally use the 8-12 levels of nesting model. (They go deeper, but not often. Reddit collapses anything past 10 levels, or with few/negative votes in big discussions. Our wikis use the {{outdent}} template or just manual indent-resetting, and they "freeze" sections with the {{archive top/bottom}} templates, and they {{collapse}} completely offtopic comments.)
https://i.imgur.com/GBszjoQ.png
(Tangent: Compare https://www.reddit.com/r/askscience/top/?sort=top&t=month with https://en.wikipedia.org/wiki/Wikipedia:Reference_desk/Science ...)

It's a question of scale. We need a system that works when 5 or 500 people comment on a single issue (whether that's a simple Support/Oppose vote, or a more[[ https://en.wikipedia.org/wiki/Wikipedia:Administrators%27_noticeboard/IncidentArchive943#Page_move_ban | in-depth debate ]].)
Anything more than that (i.e. thousands of participants), and we'd probably need to implement an upvote-comment system (which would still be unnecessary on the vast majority of smaller pages/topics).

Threading systems are good at this scale, because they let participants *skim* the discussion, looking for sub-threads with participants or keywords or aspects (e.g. bulky paragraphs) that interest them.
Or visually identify where they were reading last.
E.g. I can rapidly scroll through https://www.reddit.com/r/askscience/comments/5lrjgz/is_there_a_reason_all_the_planets_orbit_the_sun/ and notice a sub-thread that has 5 large replies under each other. This intrigues me, so I see if they're debating anything interesting; I scroll up to the top of the sub-thread and see that it's a debate about a claim made by Neil DeGrasse Tyson. It was easy/quick for me to determine where the tangent started and where it ended.

Sidenote: I was originally collecting related threads in this section, but got overwhelmed in late 2014, partially because it came up in hundreds of topics - humans rarely discuss 1 thing at a time! https://www.mediawiki.org/wiki/Flow/Prior_discussion-thread-roundup#Indenting_Levels

In summary: I strongly recommend we move Flow to the classic threading model.

Pau replies

I don't think that the number of indentation levels necessarily correlates to the scale of the conversation they can support. We have the examples of Discourse or Phabricator which seem to support discussions involving big communities. They use a flat structure model for conversations inside a "topic" and use a quote feature to clarify what replies to what.

In my opinion, more important than the number of levels of indentation is the purpose of such levels for structuring the conversation.

For wikitext talk pages, each reply increases the indentation level. This allows participants to follow the previous conversation as it was before a new comment was added or to continue the new one. This makes it explicit what replies to what, and as Nick mentioned, it has the advantage of allowing to skim conversations and focus on specific parts of it (although when a large tangent conversation gets in the way, it may be hard to find which level you were before).

However, the classic talk page model has also disadvantages: just continuing a conversation results in a diagonal thread that do not distinguish many parts for you to focus and makes it hard to read and participate. As an example, picking the first conversation of the busy noticeboard Nick mentioned we can see that once a tangent conversation is started it evolves quite linearly (growing diagonally but not forking again).

The current Flow model has no limit in the number of indentation levels. The technical implementation may have set one limit, but that is not relevant for the structuring of conversations unless we are talking about instances of such limit being reached, which I don't think is the case (and if it were we could just increase it).

What the current Flow model aims to do is to encourage tangent conversations to be presented more linearly and increase one level of depth only when a reply is clearly not following the conversation and refers to a specific comment. It has limitations (I have created a ticket with an example and a proposal to address such case) but I can also see the advantages. The case of Slack is a totally different execution of a similar idea (prioritise a continuous conversation but allow tangents).

I've been hearing every now and then about obvious problems on the current indentation model of Flow, but I've seen very few examples. If there a ticket compiling those examples, please let me know. If there is not, would it be possible to collect examples of real Flow conversations where the model gets in the way? It would be great to have a detailed explanation on what is problematic on a specific case and how that exact conversation could have been better structured otherwise.

Roan replied

On Wed, Feb 8, 2017 at 8:53 AM, Pau Giner <pginer@wikimedia.org> wrote

I've been hearing every now and then about obvious problems on the current indentation model of Flow, but I've seen very few examples. If there a ticket compiling those examples, please let me know. If there is not, would it be possible to collect examples of real Flow conversations where the model gets in the way? It would be great to have a detailed explanation on what is problematic on a specific case and how that exact conversation could have been better structured otherwise.

I think the greatest gripe that I've heard is that you don't get to choose whether you are replying to the topic itself or to the latest reply. In other words, the type of reply that causes indentation (which Benoît causes a "digression") can only be created in reply to a comment that isn't the latest reply (or in technical terms: a comment that has a "next sibling"). This is frustrating when you do in fact want to start a digression from the last comment.

For example, if I have this discussion:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

When Joe sees that state, he might want to do any of three things:
He might want to reply to me, saying "I would like to do more on ERI"
He might want to reply to Nick (a digression), asking "what specific Flow issues should we work on?"
He might want to reply to Matt (a digression), asking "what specifically is wrong with GuidedTour?"
The problem is that the distinction between #1 (replying to the root comment) and #3 (replying to the last reply) does not exist in Flow. You cannot do #3, and if you try to click the Reply link that looks like it'll do #3, it'll do #1 instead.

To complete the picture, here's what happens if you do #1:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

+--- Joe: I would like to do more on ERI

If you instead do #2, you get this:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Joe: What specific Flow issues should we work on?

+--- Matt: GuidedTour could use some love

And if you try to do #3 it looks like this, which is the same as #1:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

+--- Joe: What specifically is wrong with GuidedTour?

But if #3 was properly supported, you could do this:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

|
+--- Joe: What specifically is wrong with GuidedTour?

This matters in two ways. One, if Matt responds to Joe and they get into a back-and-forth, we want that to not be on the same level as the people answering my question (but instead visibly related to GuidedTour). Two, you can do the right thing for some comments (like Nick's) but not others (like Matt's). The order of operations matters in a way that is unreasonable IMO: if Joe just waits for Moriel to reply to me with her suggestion, then he can reply to Matt's comment properly because it's no longer the last one. (Also, note that this problem is recursive: after doing #2, Nick can't reply to Joe's question, he instead has to reply to himself, except if someone else has replied already, then he can reply to Joe directly and start a digression.)

I agree that it's good to try to flatten discussions out a bit, avoiding every single comment creating a new indentation level. But the way this is done here prevents you from creating digressions in more or less arbitrary circumstances. I'm not quite sure how to clearly/intuitively represent in a UI the difference between replying to the last comment versus replying to its parent other then by indentation, or how flattening can be done in the face of having to support that distinction, but I can identify the current non-existence of that distinction as one of the main problems.

Benoît's sketch suggests that the same conversation could be displayed differently to people with different settings, but for that to be possible, the underlying data still needs to have enough information (the right parent-child relationships) to be able to do that.


Strawman idea that just popped into my mind: offer a distinction between reply-to-last and reply-to-parent, and perhaps make that distinction clear using indentation or lines or something, but when rendering a case where a comment has a digression/child but no next sibling, render it flat instead of indented. In pictures:

If I do #3 and get some follow-up responses, then conceptually the tree will look like this:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

|
+--- Joe: What specifically is wrong with GuidedTour?
     |
     +--- Matt: We should fix Foo and Bar, and maybe also Baz.
          |
          +--- Joe: I don't think I understand what Bar means, could you explain?
               |
               +--- Matt: [explanation of Bar]
                    |
                    +--- Joe: Thanks Matt, that helps.

But we'll render it flat, like this:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

+--- Joe: What specifically is wrong with GuidedTour?

+--- Matt: We should fix Foo and Bar, and maybe also Baz.

+--- Joe: I don't think I understand what Bar means, could you explain?

+--- Matt: [explanation of Bar]

+--- Joe: Thanks Matt, that helps.

Then if Nick also responds to Matt, the tree will conceptually look like this:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

|
+--- Joe: What specifically is wrong with GuidedTour?
     |
     +--- Matt: We should fix Foo and Bar, and maybe also Baz.
          |
          +--- Joe: I don't think I understand what Bar means, could you explain?
          |    |
          |    +--- Matt: [explanation of Bar]
          |         |
          |         +--- Joe: Thanks Matt, that helps.
          +--- Nick: I don't think Foo is important at all.

Then in the flat rendering, the level where this happened would be unflattened to clarify that Matt's comment is a digression but Nick's is not; and the other levels would remain flattened:

Roan: What should our team work on next year?

+--- Nick: I think we should work on Flow

+--- Matt: GuidedTour could use some love

+--- Joe: What specifically is wrong with GuidedTour?

+--- Matt: We should fix Foo and Bar, and maybe also Baz.

+--- Joe: I don't think I understand what Bar means, could you explain?

+--- Matt: [explanation of Bar]
+--- Joe: Thanks Matt, that helps.

+--- Nick: I don't think Foo is important at all.

Nick replied

(inline replies)

On Wed, Feb 8, 2017 at 12:53 AM, Pau Giner <pginer@wikimedia.org> wrote:

I don't think that the number of indentation levels necessarily correlates to the scale of the conversation they can support. We have the examples of Discourse or Phabricator which seem to support discussions involving big communities. They use a flat structure model for conversations inside a "topic" and use a quote feature to clarify what replies to what.

Yeah, that's the classic "flat, with quotes" model. It is impossible to track tangents, e.g. https://try.discourse.org/t/what-happens-when-a-topic-has-over-1000-replies/301 - Are any of the people discussing the same issues? There's no way to know, without reading everything.

In my opinion, more important than the number of levels of indentation is the purpose of such levels for structuring the conversation.
For wikitext talk pages, each reply increases the indentation level. This allows participants to follow the previous conversation as it was before a new comment was added or to continue the new one. This makes it explicit what replies to what, and as Nick mentioned, it has the advantage of allowing to skim conversations and focus on specific parts of it (although when a large tangent conversation gets in the way, it may be hard to find which level you were before).

Not always.
One of the main reason editors use incrementing indents, is for visual distinction.
Many editors try to use a reply-level that indicates who they are directly responding to, if that can be done clearly.
There are many examples of wikitext talkpage discussions where subsequent replies use an equal level of indentation. E.g.

It can sometimes be hard to see this, because each level-x indent will have tangents in between it and the one below.

However, the classic talk page model has also disadvantages: just continuing a conversation results in a diagonal thread that do not distinguish many parts for you to focus and makes it hard to read and participate. As an example, picking the first conversation of the busy noticeboard Nick mentioned we can see that once a tangent conversation is started it evolves quite linearly (growing diagonally but not forking again).

If we implemented a standard threading system, editors would click "reply" for the person they wanted to reply to. Ala Reddit. They wouldn't have to indent for visual distinction.

The current Flow model has no limit in the number of indentation levels. The technical implementation may have set one limit, but that is not relevant for the structuring of conversations unless we are talking about instances of such limit being reached, which I don't think is the case (and if it were we could just increase it).
What the current Flow model aims to do is to encourage tangent conversations to be presented more linearly and increase one level of depth only when a reply is clearly not following the conversation and refers to a specific comment. It has limitations (I have created a ticket with an example and a proposal to address such case) but I can also see the advantages. The case of Slack is a totally different execution of a similar idea (prioritise a continuous conversation but allow tangents).
I've been hearing every now and then about obvious problems on the current indentation model of Flow, but I've seen very few examples. If there a ticket compiling those examples, please let me know. If there is not, would it be possible to collect examples of real Flow conversations where the model gets in the way? It would be great to have a detailed explanation on what is problematic on a specific case and how that exact conversation could have been better structured otherwise.

The problem with the current system in Flow, is that it is unique, but is similar to existing and widespread (external) systems, and is therefore inherently confusing.
It's logical and smart, but completely original to us.
Everyone who has ever used a threading-based-system anywhere else, is accustomed to "reply = indent".
The current Flow model can make sense, once it is explained to people, but it is not intuitive if the people have any prior experience with threading systems.
Teaching everyone how our unique system works, is not practical. It frustrates everyone at first because they feel like either the system is broken, or they're foolish for not immediately understanding it.

On Wed, Feb 8, 2017 at 5:14 AM Matthew Flaschen <mflaschen@wikimedia.org> wrote:

On 02/06/2017 07:31 PM, Nick Wilson (Quiddity) wrote:

In summary: I strongly recommend we move Flow to the classic threading
model.

Thanks for the detailed research. How many indent levels would you
recommend?

Personally, I tentatively think 14/15-levels would suffice for all discussions, and work acceptably in mobile. Anything deeper than that is going to be crazy people arguing, or going completely off-topic.

Wiki editors typically use {{outdent}} after 8-12 levels. However that's mostly because ::::::::: is a pain to count.
Sometimes, they'll mis-use the {{outdent}} feature, in order to highlight their own post. They'll do this with any system, and we shouldn't make it too easy. But we might consider some sort of outdent feature.

Reddit auto-truncates anything deeper than 10 in the desktop (example) - most redditors use unofficial apps for mobile use, which make level 10 indents decently readable, e.g.
https://imgur.com/a/Rn6z3 - this shows it to 9 levels of indent, and ~14 levels would still leave two-thirds of the width for content.

Pau replied

Benoît, being able to present discussions in different ways is definitely something we can consider. But it would be good to identify clearly the problem we want to solve and define more clearly which are the properties a well-structured conversation should have.

Joe, the model Slack is experimenting with leads to a similar outcome as the one you described (but using different means): a clean main conversation with collapsed threads (with the option when participating on a thread to make specific comments also visible at the top level). I don't have all details since I was not involved in Flow at that time, but our community was against automatic collapsing of comments considering it a kind of censorship.

Elena, thanks for the example. It seems that some properties of a well-structured conversation are the ability of focusing on the main conversation or specific tangents, and clarity on who replied to who. I found interesting in your example that it provides an outline of the conversations but gives no visibility on what they are about (until you click on expand on each of them, I guess).

Roan, I think the problem you described is the one I captured in this ticket. I agree that it is a limitation on the current model, and we should not forbid the creation of tangents in our attempt to have conversations more lineal. Making some automatic arrangement as the one you suggests seems worth considering.
My general suggestion was that if this is the only/main problem, we should be talking about it more specifically, referring to "making it possible to create tangents for the last comment in Flow" instead of, in my opinion, a too vague "fix the Flow indentation model".

Nick, when you mention that the system is inherently confusing because people are accustomed to "reply = indent", I assume that the only point of confusion is the same case that Roan described since in other scenarios (replying to other comments apart from the last in a tangent) does cause an increase in the indentation level.

Based on all the input I made a quick mockup of one of the ideas that we discussed previously and may help with this issue: provide options to do both, continue the conversation and create new tangents, but encourage the later by default to avoid discussions to go diagonally for no purpose. I tried to recreate Roan's scenario #3, trying to imagine where everyone would click given the provided options.

Benoit wrote

On Thu, Feb 9, 2017 at 12:37 PM, Pau Giner <pginer@wikimedia.org> wrote:

Benoît, being able to present discussions in different ways is definitely something we can consider. But it would be good to identify clearly the problem we want to solve and define more clearly which are the properties a well-structured conversation should have.

And I think Nick has perfectly defined the problem for our wikis (and you have mentioned it too, Pau):

The problem with the current system in Flow, is that it is unique, but is similar to existing and widespread (external) systems, and is therefore inherently confusing. It's logical and smart, but completely original to us.

But in that sentence, there is "us" as in "experienced wiki editors". But not us as "all wiki users", or "all Web users". That's a first problem: we don't have a system to address all possibilities.

Also, as Roan mentions the issue of having clear parent(s) and child(ren) for every message:

Benoît's sketch suggests that the same conversation could be displayed differently to people with different settings, but for that to be possible, the underlying data still needs to have enough information (the right parent-child relationships) to be able to do that.

I've looked at Nick's example on Reddit, where you have a link to find the parent. That's not the case for Flow?

Joe, the model Slack is expeExample:
rimenting with leads to a similar outcome as the one you described (but using different means): a clean main conversation with collapsed threads (with the option when participating on a thread to make specific comments also visible at the top level). I don't have all details since I was not involved in Flow at that time, but our community was against automatic collapsing of comments considering it a kind of censorship.

What if you, and only you, can collapse what you don't want to see, with no incidence on others?

Elena, thanks for the example. It seems that some properties of a well-structured conversation are the ability of focusing on the main conversation or specific tangents, and clarity on who replied to who. I found interesting in your example that it provides an outline of the conversations but gives no visibility on what they are about (until you click on expand on each of them, I guess).

Invisible messages are only for already read messages, no?

Roan, I think the problem you described is the one I captured in this ticket. I agree that it is a limitation on the current model, and we should not forbid the creation of tangents in our attempt to have conversations more lineal. Making some automatic arrangement as the one you suggests seems worth considering.
My general suggestion was that if this is the only/main problem, we should be talking about it more specifically, referring to "making it possible to create tangents for the last comment in Flow" instead of, in my opinion, a too vague "fix the Flow indentation model".
Nick, when you mention that the system is inherently confusing because people are accustomed to "reply = indent", I assume that the only point of confusion is the same case that Roan described since in other scenarios (replying to other comments apart from the last in a tangent) does cause an increase in the indentation level.
Based on all the input I made a quick mockup of one of the ideas that we discussed previously and may help with this issue: provide options to do both, continue the conversation and create new tangents, but encourage the later by default to avoid discussions to go diagonally for no purpose. I tried to recreate Roan's scenario #3, trying to imagine where everyone would click given the provided options.

That's how I see Flow conversations: linear, with side comments (the ones I call "digressions").
A next step would be to have an option to create a separate thread from a side comment. That way, you can create clean conversations.

We also need to theme a bit blockquotes, to allow people to quote others messages.

@Trizek-WMF wrote:

The problem with the current system in Flow, is that it is unique, but is similar to existing and widespread (external) systems, and is therefore inherently confusing. It's logical and smart, but completely original to us.

But in that sentence, there is "us" as in "experienced wiki editors". But not us as "all wiki users", or "all Web users". That's a first problem: we don't have a system to address all possibilities.

The current Flow system is not the same as the one (previously) used by experienced wiki editors either. It was designed to be a better replacement (for everyone).

[...]

I've looked at Nick's example on Reddit, where you have a link to find the parent. That's not the case for Flow?

We should consider implementing T105438: Move indentation model to rendering so the actual parent is separate from the rendered parent. That will allow different rendering in a proper way.

Restricted Application added a project: Growth-Team. · View Herald TranscriptMar 10 2019, 3:15 AM