Topic on Talk:Structured Discussions

I've crafted a small field study to compare how a moderately complex conversation is laid out following three different styles of indentation. The experiment is based on the topic "It's more difficult than it used to be to figure out who is responding to whom" at this page.

• Flow style. This is the original conversation. Comments are posted in sequence, except for replies to previous posts, which are indented in the middle in the thread - interrupting the main sequence.
• Classic style. Same conversation, copied to Mediawiki and following Talk page conventions. You should ignore remarks about where comments are placed, as those were originally made for the Flow-style layout.
• Dynamic style. Based on HHHippo's proposal. A classic threaded model, with the twist that comments in a sequence don't increase the indentation level. Instead, when a single post gets several replies, those are separated by horizontal bars at the adequate indentation level (by limitations of the software - you should imagine it using this visual style instead). This model resembles the classic style more closely than Flow.

I would love to hear your comments about how the different layouts compare to each other.

See also: phab:T93024 and en:Wikipedia:Indentation.

This is interesting to see, and I do prefer the classic style, but could probably live with the dynamic style. I will note, however, that Jamesofur's comments are not a response to anyone, they are a comment on the original post and should be left-aligned (possibly with a bullet point), and then the trail of comments beneath it also shifted. See what I mean about not being able to tell if a post is a comment on the topic or a response to a specific user?  :-)

Yeah, I had to be creative when deciding where to put the outdents, as the mediawiki threading model doesn't have a rule for those. Jamesofur placed the comment right below Risker's, and said "I agree", that's why I considered a reply to it.

This distinction doesn't really matter much in Flow, as replies to the last post and comments which aren't direct replies end up at exactly the same place. This makes it easier to newcomers to participate in the thread (they don't need to decide between two different indentations), even if it's more difficult for veterans to figure out (I still don't understand why; does it really make a significant difference?).

It does make a difference. Think of a discussion like an AfD or a proposal at a Village Pump, where there are responses to comments ("side discussions" or potential tangents) as well as people commenting on the key topic. When assessing consensus, those side discussions/tangents are normally not included in the evaluation. Keep in mind that an editor may express an opinion on the topic (their "vote") but also respond to other people's opinions/votes; differentiating these is important. It is another reason why responses should always be indented, leaving only topic comments at the far left.

Oppose! I'd like to think that those side discussions are included in the assesment ;-) More often than not, their arguments are more interesting than the base not-votes, and often invalidate those.

The Flow model in its current form is not intended for straw polls and requests for comments amenable to not-voting; it lacks support to mark those special posts like they do with bullet points, icons and bolded comments (which is how you distinguish different !votes from badly indented comments in current talk pages). I've heard they're planning to add suport for that in future versions.

Ooops, I wound up editing my comment while you were posting, so you may want to review that. But really...where would Flow be useful if it is unable to 'support' these types of discussions? I cannot think of a talk page or discussion page on the enwiki project that doesn't need to have that ability. We see RFCs on article talk pages and wikiproject talk pages regularly, for example. I'd consider it a baseline requirement.

Flow does not support those types of discussions because it is unfinished, but I don't think the lack of indentation on every post is critical to differentiate between !votes and replies to them; they can always be distinguished by using other visual features.

The problem with abusing indentation as styling is that it composes - if all posts are shifted a few pixels to the right, the whole discussion soon falls off over the right edge of the screen. The visual features that classify different kinds of posts should be a static "on/off" property, that all posts can use without altering their surroundings (such as color, font weight, special markers...). Indentation is simply not a very good choice for that purpose.

I'm sorry, I'm just looking at what you've written there and it comes across as "let's make discussions even more complicated by insisting that people learn a whole pile of new, Wiki-specific behaviours, symbols, and processes". It's pretty much the antithesis of what the people actually having discussions now want, and it doesn't support the "let's make a discussion system that's easy for newbies to figure out" principle that Flow was initially founded on.

Well, your comment of "let's make discussions even more complicated by insisting that people learn a whole pile of new, Wiki-specific behaviours, symbols, and processes" comes across as "this is what editors need to do right now to participate in AfDs" ;-) I wrote the previous comments as an example of what people would need to do without specific software support, which is the case at mediawiki.

The idea would be to substitute (or better, complement) that with a toolbar or other similar easy-to-learn GUI that highligthed the possible ways to engage in such structured conversations, without having to check the Help page first.

I think that this indentation model will fit the AfD style pretty well.

An AfD conversation is a flat list of votes, and then side discussions break out when someone replies to a specific vote. That's what this model does. The difference is that in a wikitext AfD, those tangents keep indenting one after the other. In Flow, they would indent once and then continue below, until someone replies to a previous post in the tangent, which would then fork into another tangent.

The design principle behind this version of Flow is that a two-person or group conversation can keep going chronologically down the page, and readers can use context and social cues to parse what's happening in the conversation. The indentation tangent indicates the spot where somebody in the conversation went out of chronology, creating a separate subthread.

So when I look at this thread right now, I see Diego and Risker having a conversation with each other, with several exchanges back and forth. The only indented tangent is Helder -- stepping outside of chronology to tell Diego to check out a Phabricator ticket. It's easy for me to see the normal flow of conversation, and the moment when something in that flow changed. (At least, that's how it looks to me right now; people may add other tangents above after I've posted this.)

Also, I want to point out that this conversation is perfectly understandable. You are currently having a sensible conversation, and now I'm joining in. I think that the bad experience of not understanding who's talking to who may fade after having a few conversations, over a few days.

> The difference is that in a wikitext AfD, those tangents keep indenting one after the other. In Flow, they would indent once and then continue below, until someone replies to a previous post in the tangent, which would then fork into another tangent.

Risker is right that there's a problem though, in that editors now can't decide when to create an indented tangent, it's decided automatically from the chronology of posts. The difference between a direct reply to the last post and a new comment to the main thread is important for such advanced structured conversations (and it's part of what makes them advanced), and it's not under user's control right now.

For example, say Anne posts a new !vote Supporting a proposal. Editor Bruce, who has already !voted, wants to reply to Anne and start a tangent in a subthread, but he will need to wait until a third editor Carol posts a !vote of her own; otherwise the tangent would not be indented, but laid out flat at the same level of the sequnce of !votes. So the decision of whether to start or not a subthread affects the final structure. As some have pointed out, this is important for scanning the whole conversation, without having to read it in full each time you want to revisit it and find (or skip) a particular exchange of ideas.

It's encouraging that Risker said that he^(?) could live with the Dynamic style. I think it's the first time an experienced editor with a strong dislike for the Flow structure and a preference for classic threading has accepted a design for a potential simpler layout. If Flow ever wants to serve as a tool for talk pages at en.wiki, it will need to be as close as possible to the current workflow. Tools with a large user base come with an inertia that restricts what redesigns are viable substitutes, in a way that new tools don't suffer.

The current simple layout could be introduced for new collaboration spaces, and maybe select user pages, and I like it better for newbies, but I'm afraid it will always produce strong rejection if used for the Talk space. A structure similar to the Dynamic style is much closer to the current Talk convention and has a higher chance of acceptance.

She, but I'm not obsessive about it. :)

I recognize there will have to be *some* give and take, and it's difficult for me to say definitively that I would be as willing to participate in discussions using a different format, but the dynamic style is an improvement over the current style, which I find so unhelpful in reading that I would dramatically reduce my participation in any discussion forums where it was used.

@Diego Moya: That's a great demo/example set. Much thanks for putting it together.

@Risker: The issue of !votes is one of the "not created yet" aspects of Flow. The plan is that it will be a different type of "module" (or workflow) from this one (which is "a simple discussion" style of workflow). The !vote type workflow will need a more extensive set of configurable options (for per-page/namespace/wiki setup), but also be generally more consistent. I.e. Pages like d:Wikidata:Property proposal/Authority control and w:Template talk:Did you know and w:Wikipedia:XfD today and etc, all follow some generalizable patterns, which are well-suited to clearer structuring (and hence reducing the confusion for newcomers to those pages). Some use *bullets, some use #numbers; some have local traditions of plaintext replies, and some have traditions of using icons to begin each response (e.g. from the huge list). All of this (within reason) can be made standard (per page), so that when I/we/you/they encounter a new process-page, it doesn't take 10 minutes of uncertainty before proceeding. More software-wizard, and less "read this, and then copy this to here, and copy that to there, all whilst continually referring back to this wall of instructions", which is how the processes usually feel to me if I haven't encountered them recently. It shouldn't be too easy, but it should be a lot easier to do everything involved in an XfD: opening, announcing, participating, reading, closing. Once we have things like !votes in a structured format, we can do fantastic things like "find me all the XfDs related to biology chemistry and medicine wikiprojects, that have 3 or less !voting participants, and have been open for more than 2 days." It needs to be easier at Enwiki, because we want more people to participate in the sea of "Relisted to generate a more thorough discussion and clearer consensus." items. It needs to be easier at most other wikis, to save editors the intense hassle of setting up (and maintaining) hundreds of templates and dozens of bots. It's not an easy feature-set by any stretch, which is why they've been concentrating on more fundamental/architectural things, but it is on the horizon of planned work.

Well, I suppose this actually gets to the heart of the problem (from the perspective of experienced users) - the advantage of the wiki is its flexibility and its ability to allow multiple format processes ("workflows") on a single page that has a single name and doesn't duplicate itself anywhere else. If the "grand vision" of Flow actually occurs, I won't be watching anything, because my inbox simply isn't big enough to handle all the notification emails.

@Risker:There are plans to improve/solve that, too.

One main aspect will be phab:T100528 ("Improve organisation and control for (flow) notifications") See the embedded phab:F169936 mockup in particular - feedback there would be greatly appreciated! We need something that is:

• Ignorable for those who don't want it (yet) - business as usual, or as-close-to-as-possible, in the watchlist
• More powerful for experienced users, in a variety of ways
• More intuitive for newcomers, than the watchlist or enotifwatchlist are

Another aspect will be phab:T100858 ("Flow: Personal feed v1") which is going through more initial-level re-brainstorming.

Wasn't the script supposed to archive the existing content of pages such as Talk:Snippets?