Jump to: navigation, search

About this discussion

The Collaboration team has enabled Flow on this talk page.

Previous feedback is on Talk:Flow Portal/Archive2 (using old Liquid Threads), and on our labs server.

By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL

Accidentally converted User pages into Flow talk pages.

3 (talkcontribs)

Just installed flow, got it working great on my talk pages however upon trying to get it to work with User_Talk pages I accidentally used the "User" namespace when converting via "convertNamespaceFromWikitext.php".

Is there a way of easilly converting back? I assume not which is a bit unfortunate. If it means losing the content on the User pages is there perhaps an easy way of just destroying all the flow pages? (talkcontribs)

Ok, got it all fixed, had to edit via the database and so far it doesnt seem to have broken anything which is good!

(If anyone is wondering how I even managed this to begin with, its because I accidentally used a space between User and Talk which was fairly stupid of me. Should have made a back up before doing changes like this... live and learn though).

Some caveats are you still have the template at the top, but I guess thats easier to fix than rewriting the content in the destroyed namespace.

First up, get the namespace ID for the namespace you want to revert back. In my case it was "2"

SELECT * FROM `page` WHERE `page_namespace`=2 AND `page_content_model`="flow"

Double check you have the right rows before proceeding, dont want to make an issue even worse.

Then run the query:

DELETE FROM `page` WHERE `page_namespace`=2 AND `page_content_model`="flow"

Now to convert the archived pages back to what they should be:

SELECT * FROM `page` WHERE `page_title` LIKE "%/Archive_1" AND `page_namespace`=2

Double check again with the above select that you have the right rows.

UPDATE `page` SET `page_title`= TRIM(TRAILING "/Archive_1" FROM page_title) WHERE `page_title` LIKE "%/Archive_1" AND `page_namespace`=2

Once sure, run:

UPDATE `page` SET `page_title`= TRIM(TRAILING "/Archive_1" FROM page_title) WHERE `page_title` LIKE "%/Archive_1" AND `page_namespace`=2

Mattflaschen-WMF (talkcontribs)

First, backups are a good suggestion, especially on small wikis when it's pretty fast to make a backup before running such a script.

As far as repairing it, if someone else has this issue I would recommend instead using Manual:DeleteBatch.php and Manual:MoveBatch.php . That will leave your wiki in a more consistent state (the move logs should reflect reality, etc., deleted pages will be in the delete logs and can be undeleted).

You can build the required text files from the DB.

Reply to "Accidentally converted User pages into Flow talk pages."
DannyH (WMF) (talkcontribs)

We're releasing a new feature this week: Mark as resolved, an update to the moderation feature formerly known as Lock. It's out now, and you can test it out on Talk:Sandbox.

There were a couple problems with Lock that we wanted to solve:

  • There were two fields -- a topic summary, and a reason for locking -- and it wasn't really clear which one you should use when you're closing a discussion.
  • The visual difference between locked and open topics was a bit confusing; it wasn't obvious which one you're supposed to be paying attention to.
  • When you're scrolling down the page looking for open threads, you had to scroll through closed threads to find them.

In the new feature, when you choose "Mark as resolved" in the topic menu, a checkmark is added next to the topic title, and you're prompted to write a summary for the conversation. When a topic's resolved, the entry fields go away, and you can't write new posts. Resolved topics are collapsed by default, just showing the title, date and the summary. You can click on the header to see the whole conversation.

If you reopen a resolved topic, you're prompted to add a summary, or edit the existing summary. You can also add, edit or delete existing summaries at any time.

There's an additional piece that will be out in a couple weeks -- a byline for the summary, so you can see who wrote it, or who last edited it.

I hope you like the new feature, and please let me know what you think!

Eloquence (talkcontribs)

Neat! :-)

Сунприат (talkcontribs)

Where "Cancel" button? This is strange. 1) I tried to close the first topic "New topic" (Mattflaschen-WMF ) in the sandbox 2) In "New topic" no button "Skip summary", but there is in other topics 3) From the menu choose "cancel the closing thopic", I think that the closure has not happened, but in the history I closed it and restored. 4) I want to see the conversation to write a summary and do not remember there was towards the end of the conversation 5) When I click "cancel the closing thopic" in menu the edit summary does not disappear, but remains

Diego Moya (talkcontribs)

I like its new simple interaction flow :-)

It is not at all obvious that you can expand the "solved" thread to read it by clicking on the background box (there's not even feedback with the mouse cursor to show that it's clickable). Either an "expand" button or an entry in the menu should be added.

I think a good design for this would be a call-to-action button or link besides the summary; expanding the thread to see the comments after reading the thread's summary seems a primary action.

Сунприат (talkcontribs)

"It is not at all obvious that you can expand" I agree

Diego Moya (talkcontribs)

Also, the text in the Terms of use notice is wrong. It says "By clicking "Summarize", you agree to...", but the button label is "Update summary".

Is there a way to generate both labels from the same string, so that they will always be in sync even when a designer changes the copy? This is a bit that can never be wrong, as it has legal implications.

DannyH (WMF) (talkcontribs)

@Сунприат: The idea is that once you select "Mark as resolved", then the topic is resolved. There isn't an extra "are you sure, click Cancel or OK" step. The prompt to add, update or skip the summary is separate -- you can choose any of them, and the topic is still resolved. But it looks like that wasn't clear for you, which is good feedback for us to know.

Also, you were selecting "Reopen topic" while you were still involved in resolving it -- that didn't occur to us as a thing someone would try. :) I'll see if we can make "reopen" inactive while the summary is being edited.

@Diego Moya: Yeah, it's not really obvious that you can click to expand. I'm glad you guys brought it up, we'll talk about what we can do. The same for Сунприат's point about the messages collapsing while you're writing the summary. I bet we can do something for that as well.

Also, Diego - thanks for catching the Terms of use inconsistency! You have sharp eyes, and I appreciate it very much. :)

EBernhardson (WMF) (talkcontribs)

Clicking in the area that says '3 comments. timestamp' doesn't do the click to expand, only clicking other parts. chrome 43.0

Mattflaschen-WMF (talkcontribs)

"2) In "New topic" no button "Skip summary", but there is in other topics"

I believe this is because there already was a summary.

"3) From the menu choose "cancel the closing thopic""

There is no "cancel the closing topic" (with either spelling) in the i18n. What localization are you using? Perhaps there is a mistranslation of 'Reopen topic'.

Сунприат (talkcontribs)

so I have no choice. if I click on the green button resume updated. create a new record without any changes as zero correction, but with a record in history. What if I do not want to change the resume and all wrote in the last post ...

Oh, there have replaced Unlock

Vriullop (talkcontribs)

I really like it. It makes more sense than lock topics, it helps browsing on pending ones, but I miss a filter in the table of contents for resolved/pending topics.

Reply to "Updated feature: Mark as resolved"
Сунприат (talkcontribs)

The way the branches logically separated text before Now it is not. Now it is a wall of text.

wiki -- flow

In these places it turns out that the user does not continue the conversation, does not respond to the last / the last few posts, he he begins a new mini talk, a new branch. The plain text of this moment of this transition does not markedly. It is difficult to understand.

Tucvbif (talkcontribs)

Your discussion is not good example for illustration of flow's indentation bug. Compare two themes: ru:Тема:Sjnbtu70fpp8c990 and ru:Тема:Sjnbzj23r6t4lrs8 This themes looks equal, but in first one, replies sequence is like this:

│ └***

and in second - like


I came up with three solutions:

  • tree structure diagram. If I reply on higher level message, it creates a node on left vertical line that connects to my message. Like this:
│ ***
│ ***
  • seperation rule. If I reply not on the previous message, but on higer level, it will divide my one. Like this:
  • extra indentations. Every next branching makes an indentation (reversial indentaiton system). Like this:
Reply to "In Flow lacking logic breaks" (talkcontribs)

이것이 뭐시당가 (talkcontribs)

여기에 토론거거

Reply to "오마나"
Diego Moya (talkcontribs)

The discussion at Comparison of thread styles has given me an idea for a middle-ground solution that maybe, just maybe could satisfy the needs of both newbies and veterans. Here's a mockup:

It recovers the idea of separate "reply/comment" actions, but now it allows the editor to control whether to create a subthread.

The text "Add notes" is intended to suggest that the comment will have several replies attached at the margin (I'm not sure about the wording, it would require testing). Pressing it would always create a new indentation level, even at the last post.

The explicit "Reply to..." box at the end of each thread or subthread entices the user to keep replies at the same level, though Wikipedia editors can still create as many levels as they wish at any time if that's what they want. The path of least resistance creates a sane threading, but experts can override it; just as simple yet powerful interfaces should behave.

(There are two options for what happens after pressing "Add notes" at (2) in the example. It may work the same as "Reply to 5", or it might create a new separate block of notes below the first one at the same depth level, to keep the same structure of the Dynamic style which is isomorphic to the convention of Talk pages at Mediawiki).

Now tear the design appart...  :-)

DannyH (WMF) (talkcontribs)

I've seen a lot of models and examples for Flow indentation over the last year, and I'm always happy to keep talking and thinking about this. There's a couple things that make it hard to evaluate a suggested model.

First, you need to show where the reply fields or links are, so we can see what choices the user would be presented with. Second, it needs to be a "real" (made-up) conversation. Every model looks baffling when the messages are "B responds to C" and "C responds to A". We need to see real sentences, and some idea of why 4 is responding to 2, rather than 3.

With all of these, the hardest nut that we have to crack is having two different ways to reply to the same post. Under the last message, if you have a "Reply" link right above a "Reply" entry field and they do different things, it's a confusing interface. Product design is hard.

Diego Moya (talkcontribs)

Yeah, I know all that. That's why I thought of using a completely different metaphor for allowing the user to start a tangent, like "add notes" or "start thread". Attaching notes to an item in a document is a recognizable action.

And I wanted to try how this idea looks like, that was closer to the current design than the Dynamic style but keeps its flexibility. After this time testing the new Flow threads in the wild and watching the reactions to it, I'm certain that the bulk of veteran Wikipedians will never accept this exact model for talk pages.

Reply to "New threading style"
Diego Moya (talkcontribs)

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.

Risker (talkcontribs)

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?  :-)

Diego Moya (talkcontribs)

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?).

Risker (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Risker (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Risker (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

DannyH (WMF) (talkcontribs)

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.

Diego Moya (talkcontribs)

> 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, 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.

Risker (talkcontribs)

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.

Quiddity (WMF) (talkcontribs)

@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.

Risker (talkcontribs)

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.

Quiddity (WMF) (talkcontribs)

@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.

Reply to "Comparison of thread styles"
Diego Moya (talkcontribs)

I've added a custom script that adds a hover effect for highlighting the vertical indentation bars of related comments, which I've talked about here (sort of; all previous levels are highlighted, not just the current one).

I think it could help editors to understand the new threading model.

If you want to try it, just add the following to your User:USERNAME/common.css page:

/* hover effect on thread bars */
.flow-replies:hover { 
	border-left-color: #333 !important;
	border-left-width: 2 !important;
	border-left-style: solid;
Сунприат (talkcontribs)

Can you do something like this for Flow?

Diego Moya (talkcontribs)

Try adding the following quick hack to User:Сунприат/common.css (it only works up to depth level 4):

.flow-replies  { 
	background-color: #F5F5F5;
	border-left-style: solid;
	border-left-color: #AAA !important;

.flow-replies .flow-replies { 
	background-color: #FFFFFF;

.flow-replies .flow-replies .flow-replies  { 
	background-color: #F5F5F5;

.flow-replies .flow-replies .flow-replies .flow-replies { 
	background-color: #FFFFFF;
Diego Moya (talkcontribs)

You can try it at the "Mobile version" thread, BTW. It has three depth levels near the top.

Сунприат (talkcontribs)

Interesting, Thank you :D

Diego Moya (talkcontribs)

@DannyH (WMF): Please see this exchange, it seems that the grey vertical lines in the design that represent threads are too light to be seen in its default setup.

DannyH (WMF) (talkcontribs)

Yes, good point. That's something that I've been meaning to fix.

Thanks for the reminder, and the excellent example of somebody not seeing the lines. It's always helpful when I can show an example like that to our designer. :)

Reply to "Hover effect for threads"

It's more difficult than it used to be to figure out who is responding to whom

Risker (talkcontribs)

I have this philosophy about taking time away from new extensions after I've played with them a bit and given feedback, because otherwise I get frustrated when things don't move at "my" pace. And usually, when I come back weeks or even a couple of months later, I can see improvements and am happy to try them again. (Heck, it worked for VE and MV - They both got noticeably better and more usable over time, and the improvements were more obvious when I stepped away then returned.)

This extension is almost the opposite. I've yet to return to it to find it improved as a communication tool. I read the sections below, and I honestly cannot tell who is talking to whom, who is responding to what, without really having to work at it. It is significantly more difficult for me to figure out this page than it ever has been in even the most convoluted discussion on a normal wiki talk page. It's one of the few times where I've looked at something and been completely unable to give any constructive criticism. I've been able to figure out dozens of discussion systems pretty quickly over the years (going all the way back to the bulletin board days, probably before some of you were even born)...this is the most difficult one I've run into for at least 10 years. I know lots of people are really working on this, but from what I'm seeing here, your objectives are so divergent from what I as a user expect from a discussion system that never the twain shall meet.

Incidentally, what brought me here today was an email message informing me that User:Flow_talk_page_manager had moved a page called Talk:Flow Portal/Archive2 (a page that as far as I knew wasn't on my watchlist), and when I followed the link....there was nothing there. I can't tell what got moved where, and there is nothing on that page to tell me what the heck this "user" is. (A bot of some kind? who is running that obvious role account?)

He7d3r (talkcontribs)

See also the WONTFIXed phab:T93883.

Risker (talkcontribs)

Oh wow, He76d3r. That is one of the saddest phabs I've ever seen. Seems to me that what they've failed to recognize is that they're not getting as much criticism because fewer and fewer people are actually trying things out. I see that Short Brigade Harvester Boris was making the same point as me here, about the visual cues being very important in reviewing Wikipedia talk pages; as he says, they're usually scanned as opposed to being read.

EDIT: Oi! And why, when I have VE not enabled on this wiki (deliberately - I use it elsewhere), is this page not properly handling wikitext? Geez.... EDITED AGAIN: It's only because I was certain there *had* to be a way to switch to wikitext that I tried the </> symbol, and that certainty only came with years of having been around. All the mucking about I've done with VE, I still haven't found the process for making piped links.

Diego Moya (talkcontribs)

Which thread(s) are you having problems following?

Christian75 (talkcontribs)

E.g. the thread named "New side rail". It looks like DannyH (WMF) replys himself. (looks like copy paste has some side effects - at least in the editor - I am not going to figure which icon I should press).

You can not expect people to read the threads from a to z. I read the first message in a thread, if interesting I read the first reply, and if its not interesting I skip to the next reply to the original message and so on...

(This replys is a good example - I replied to Diego Moya, but it looks like its to Risker)

Diego Moya (talkcontribs)

Why do you think your comment looks like a reply to Risker? It's right below my comment, so it feels natural to associate it to the text that is closest to it (immediately above), and to read the thread as a sequence of posts at the same indentation level.

This is the standard layout of new posts at internet boards and comment sections in blogs (i.e. most of the Internet). Reading text in order is fairly natural, we've been accustomed to doing that in books and magazines for ages.

Christian75 (talkcontribs)

But most blogs (like Facebook) have a philosophy that the users should not discuss, but just leave a comment. And I think most people do not read the internet like a book. Stay on one page, read it all, before going to the next page.

Diego Moya (talkcontribs)

Yes, I agree with that, and that Wikipedia talk pages should be forum-like rather than blog-like. But this model is not that of Facebook, it's closer to forums and bulletin boards.

BTW, boards a la BBCode have a philosophy that users should discuss, and they've managed to support it quite well through the years - mostly by the use of quoting previous comments. The current threading model is an attempt to improve on that by reducing the amount of quoting required.

Risker (talkcontribs)

User:Diego Moya, I cannot tell strictly by observation if Christian75 is replying to you, replying to me or simply making an additional comment to further the discussion; only his parenthetical comment tells me that he was replying to you. This formatting is aberrant; it is unlike any other discussion system I have seen in a very long time. The wiki system, for all its ease of screwing up indentation, gives visual hints as to who is responding to whom, or if they are just making an added comment to the topic area. Forum software allows (and generally encourages) quoting. Comment systems for most media indent the first response to a comment and (depending on the system) keep all the rest of the related responses (including responses to responses) at the same indent level, indicating that a "side conversation" is taking place, or allow indentation of responses to responses to a specified level (sometimes 2 or 3 indents). This system gives absolutely no visual clue as to who is responding to whom.

As an aside, I have this thread on my watchlist, yet I have received no notifications that there have been further responses. What's with that?

Diego Moya (talkcontribs)

The new threading model does provide visual cues for side conversations, it just excludes the first reply from them and considers it part of the main conversation. If Christian75 had replied to you instead of me, his comment would have been indented one level, right below yours; because his comment is not indented in such way, I can tell that it was posted as a reply to the main thread just after my first comment, and thus he was not replying directly to you.

The visual hints you talk about are not part of the wiki software, it's a convention adopted by its users using formating tools, not any specific feature of the software to support conversations; it's a by-product of its flexibility, not something designed for collaboration.

Flow merely uses a different convention; the current threading model decides to apply subthreading to all replies to a post except the first one as a way to separate the main sequence of ideas from isolated remarks about a particular post (see the new reply by He7d3r to your fist post).

At this previous topic there was a proposal (initiated by Hhhippo, tweaked by me) to adapt the model to something more similar to mediawiki talk pages, see if you like it better (it works as you describe, creating a single indent level for each new group of parallel posts including the first).

Aside - have you clicked the star at the topic title to add it to your watchlist? If you did, you should report the lack of notifications as a bug (I've received the notification for your replies).

He7d3r (talkcontribs)

Even Poor man's Liquid Threads indents comments correctly: wikt:User:Yair_rand/addcomment.js

Diego Moya (talkcontribs)

That would depend on your definition of "correctly", wouldn't it? ;-)

Risker (talkcontribs)

User:Diego Moya, I do understand the convention being used. I disagree that it is a sensible one, because right now there are two replies to my initial post, but only one of them is indented; thus, it looks like one person answered me and another person (your first post) was simply a comment to add to the discussion. I cannot tell visually or by any other indicator than the postscript of his post that Christian 75 was replying to you: his comment could be a standalone, a response to me or a response to you. He7d3r has commented directly above where I am writing now. I cannot tell if he is responding to your previous post, or to my earlier post but not clicking "reply" or if he is adding an entirely new comment. He also responded to my first post and his response is indented, but it comes above your response to me and is thus no longer in a logical time sequence. There is no sense of conversation, of discussion as opposed to a bunch of people adding comments on a topic. There is no logical progression. Indenting responses makes sense to differentiate them from comments that are not responses.

I do understand that the use of indentation and bullets on wiki pages is a convention as opposed to a forced software option; that's appropriate, since the pages are used for so many different things. However, we've also known for years that adding an "INDENT" button that automatically added the correct indentation for a section was entirely possible, and that it could even be designed to automatically outdent (and add the "outdent" markings) after a specific number of indentations. But no volunteer decided to write the software, and the person in charge of engineering and product for many years was always extremely clear about how he really hated talk pages, so there was no reasonable chance that anyone from the WMF side would be tasked to improve the talk page software. I certainly won't complain that nobody was interested in committing career suicide over talk pages. What applies to content - i.e., that we're seriously falling behind in maintaining and improving existing content because there's so much more reward in making new content - applies to software too. Everyone know's it's much more interesting and fun to create something new than to rebuild something that already exists, and it's usually also easier.

As to the watchlist issue, this thread (and actually the whole page) is on my watchlist, I have been getting email notices for a bunch of page moves and other activities that have been happening recently to other pages on my watchlist, I am just not getting anything for this page or this thread. I'll take your advice and submit a bug report later tonight.

Diego Moya (talkcontribs)

IIRC those "INDENT" buttons for mediawiki do exist (the Wikipedia:Teahouse uses a variation of it, and I remember seeing a full kit of components for conversation at talk pages). Sadly, its usage never took off.

DannyH (WMF) (talkcontribs)

I'm confused about why this conversation is unreadable. This is a group conversation taking place between four people. If this is post #8, then I'm not directly responding to message #7. I'm responding to message #1-7, as people do when they're having a group conversation.

You can tell which sentences in the conversation that I'm responding to by the content of my response. At the moment, I'm disagreeing with Risker, and agreeing with Diego Moya. I don't think this would be any clearer if I had to specifically choose which of Risker's three and Diego M's three comments I'm replying to.

DannyH (WMF) (talkcontribs)

By the way, Risker: you can tell that Christian75 was replying to Diego Moya's comment, because Diego asked a question, and Christian75 answered that question. That seems pretty basic to me. Similarly, you can tell that I'm replying to a sentence in your post right now, because I said your name, and I'm answering your question.

Risker (talkcontribs)

Why would I have to name the person I'm responding to? Why isn't it visually obvious? Why do the replies to comments not appear in the order they were written, so that the first reply appears before the second reply? Is not the purpose of this entire exercise to make communication clearer rather than more obtuse?

Diego Moya (talkcontribs)

Why do the replies to comments not appear in the order they were written, so that the first reply appears before the second reply? Is not the purpose of this entire exercise to make communication clearer rather than more obtuse?

That "posting everything in order" doesn't happen either at mediawiki talk pages, where later comments made in a deeper indentation level are placed above shallower posts made earlier. Every time you "outdent" one level you may or may not return to earlier comments; in Flow, it is guaranteed that the outer post was made before all the comments in the subthread, and thus can be seen as a return to the main conversation that was interrupted by the aside.

The problem with defining 'clear' is that it varies with each user's expectations. We have reports of newcomers not accustomed to WP's conventions for talk pages that find them utterly confusing, especially regarding how to indent their comments in order to reply to a specific post.

P.S. By the way, comments shown at the same indentation level are always shown in chronological order. If you ignore at any location everything with a higher depth level, you get a clean main sequence of ordered posts, equivalent to a classic flat forum.

DannyH (WMF) (talkcontribs)

I'm sorry that you don't like that aspect of the feature. I think in general it seems to be working as it's intended, because people are having successful conversations using this system. In fact, we're having one right now, and I think it's working fine. But I get that you disagree, and that you don't like it.

I think the questions you're asking are rhetorical, so I don't need to actually answer them all, but let me know if I understood that wrong.

Risker (talkcontribs)

I'm sorry, DannyH, but they're not rhetorical questions, they're serious ones, and I do think it is reasonable to expect answers to them. The current discussion system uses social convention for users to respond in specific ways (indenting or bulleting); while they don't always do it right, the software is not able to force the behaviour. Here we have the opportunity to actually design the software to force the behaviour, and I'm at a loss to understand why it is not only not being done, but that for some reason the behaviour is essentially being treated as dysfunctional. I'm having a hard time with five people in this discussion, and I cannot imagine the challenge in sorting out a 15-person discussion with a heavy mix of standalone comments, responses to comments, responses to responses, and a subtopic or two that should remain a subtopic and not its own topic (common in many discussion areas), or differentiating between "votes" and comments and replies when analysing, for example, a very active Article for deletion discussion or RFC.

Diego Moya (talkcontribs)

Have it occurred to you that your difficulty may arise from you being strongly accustomed to mediawiki's "pure threaded" model, which you're trying to apply here where it is not relevant? This certainly may be a problem for adoption of the new convention by experienced editors, but it's not inherent to the model.

Why do you think there is a relevant distinction between posting a general reply to the whole thread, and posting a direct reply to the last post added to the thread? In both cases the post is placed right below the previous one at the same indentation level and in the same order. Again these are not rhetorical questions, your answers may be useful for a possible redesign of the threading model.

(For comments that are replies to posts other than the last one, you get all those "responses to responses" and "subtopics of subtopics", so that aspect in particular is not different from the old model, only the existence of a "main" thread were new "first" comments are located by default, in order. The new software is enforcing a convention, just a different one than the convention used at WP:Talk).

As for a complex conversation with multiple editors and several levels of responses to responses, "New indentation and threading model" at this same board is one of the more complex discussions held with the new model, and it manages to remain at two levels flat despite its interleaved interactions at various times. Do you have problems following its sequence?

Risker (talkcontribs)

Well, Diego Moya, I'll put my hand up in admitting I've probably read more threaded onwiki discussion than most people; easily over 100,000 talk pages and talk page archives, sometimes going diff by diff to catch subtle changes, while I was on Arbcom. And there were plenty of times in all those hours that I found the incorrect use of indenting/bulleting to be frustrating too. But even bad indentations were what made the pages readable, especially when going through very active talk pages or lengthy and convoluted discussions. I cannot fathom going through one of those 15-20 person ANI threads without some sort of visual variation.

I get that this system is meeting the expectations of the people who designed and implemented it - good on them for successfully meeting their own expectations, I know it can be a challenge sometimes. But this page looks more like a wall of text than ANI does, and that's saying something. This system is probably fine for WikiProject Hampshire, but not a busy page.

And why is it that in order to preview, I come out of Wikitext again and wind up back at VE?

Diego Moya (talkcontribs)

To be fair, lengthy and convoluted conversations do produce lots of visual variation with the current Flow threading as well, it's just that we haven't found any such conversation yet. One thing I think we're learning at this talk page is that most discussions happen to have extremely simple structures, with almost all comments getting a single direct reply; it's just that the old talk page convention makes the layout in those cases quite complicated.

What do you think of the layout model suggested by HHHippo? That one is mathematically equivalent to the mediawiki talk page convention, it's always possible to convert between them (except for the usage of the "outdent" to rebase deep threads).

By the way - The problem with porting the classic convention to software is that it can't really be fully automated; there are rules which are left to the gut feelings of the editors, in particular for when to outdent threads that run too deep. The only other platforms I know that try a large scale threaded model are Slashdot - which doesn't really show all the comments at once, it hides the deepest levels by default - and LiquidThreads - which produces an unreadable mess by trying to strictly follow talk page conventions without their safety valves/manual overrides. (P.S. Oh, and reddit, of course. It uses the same trick as Slashdot of hidding deeper threads and being difficult to follow in the middle ones.)

He7d3r (talkcontribs)

"unreadable mess", except that it is readable, and easier to understand than Flow's new structure.

Jamesofur (talkcontribs)

I have to admit I agree, even this specific thread was an enormous pain in the ass to read and figure out who was responding to who. The plain flat threading has been one of the primary reasons I avoid editing flow boards if I can possibly avoid it (to the point of just not saying things sometimes for example on officewiki where I resort to email if I can or just let the thread happen it's why I'm opposed to moving things on wiki from the staff mailing list). It was already pretty bad by default earlier to be honest but this is significantly more frustrating :-/ It's frustrating and confusing on youtube and it's frustrating and confusing here. Danny, you may consider this a successful conversation but I'm 100% honest when I said that reading and following this conversation was incredibly difficult. It is unlikely I will ever use flow if I can avoid it in this situation, it just isn't worth the effort :-/.

Diego Moya (talkcontribs)

Jamesofur, Flow is not a flat forum (I also happen to hate those BTW), it's just disguised as one. The software still keeps track of what post is a reply to which one, and when a single post has several replies, it gives you all the visual clues needed to know who's replying to whom; it merely avoids moving comments to the right when that's not needed. It has nothing to do with Youtube's. In fact the rule to know the parent comment of any given post is simpler in Flow than in talk pages (look for the post immediately above left-aligned with the same depth level), and it has no exceptions.

I have prepared for your benefit a comparison of this conversation using the various layout styles, I have posted the links here.

Сунприат (talkcontribs)

"I have to admit I agree, even this specific thread was an enormous pain in the ass to read and figure out who was responding to who." +1

Diego Moya (talkcontribs)

May I ask you and Jamesofur too what do you think of HHHippo's layout proposal, and my cleanup of it?

Сунприат (talkcontribs)

I think (phab:T94924), we are talking about one and the same. We used to see branches in discus. And Flow breaks logic branch or branches in it not at all. We're trying to add a logic branch in Flow but DannyH seems think somehow different.

Diego Moya (talkcontribs)

The model by HHHippo does have branches, and it does not move the first comment to the last position, so it doesn't have the problem in phab:T94924; that model has not been tried out yet. BTW Danny said the current model is experimental, not definitive; it's still open to changes (such as adding branches which are easier to see than the one we're using right now).

Сунприат (talkcontribs)

I have an example of a real discus, translated into Flow. Not "lorem ipsum...". vs () And that's bad. Try to make the image "Flow branch" for any real wikitext discussion from the archives of your wiki. Then we see whether it is better.

Diego Moya (talkcontribs)

@DannyH (WMF): Christian75 has pointed out what may be the single major benefit of threaded conversations, which is missing in the current threading model. When all replies to the same post are grouped together as a subthread, it's easy to skip the whole subthread if it's not interesting. You can't do that with the current "main flow of comments plus interleaved digressions": here you can't say from layout alone at what point the main track deviates from the original idea and delves into a new line of reasoning.

I think it's time to start exploring the dynamic model proposed by Hhhpo. I happen to like its final layout better, as all direct replies to the same post are shown in the order they were made, instead of the first reply being demoted after all the later ones.

It has a huge drawback though, as it heavily depends on people getting right the distinction between "reply to the last post" and "add a new (independent) comment to the thread".

Solving this would require exploring again the reply/comment distinction of the prototype, maybe with a more explicit message ("create a subthread" or similar), and adding stronger visual cues of what comments are part of the subthread (similar to Stackoverflow).

I agree with Risker and Jamesofur that we will need a way to split very long conversations into smaller components, maybe reintroducing the concept of subthreads. Surely a new formatting convention may develop to achieve that (using headers inside of comments, reordering posts...) but it would be better to have software support for that in the platform itself.

Reply to "It's more difficult than it used to be to figure out who is responding to whom"
TMg (talkcontribs)
  • I'm happy to see that editing is finally allowed.
  • However, I have to stress this again: How to undo vandalism and spam? Not "hide", but undo a.k.a. revert, without being an administrator.
  • How can I revert an accidental click on one of the "Thank" links? From other parts of the software I'm now used to a warning (it even warns that the Thank will be "public", which I find pretty scary, but that's an other issue).
  • Where did the collapse feature go?
  • When switching back and forth between visual and source editing (a feature I honestly applaud you for, VE itself is still missing this, which I consider a major acceptance problem that should not have been there in the first place, but this is off-topic) ... so if I'm switching back to source editing the edit window is sometimes to short (not always, seems it only happens when I do not edit in visual mode and only use it as a preview). It resizes when I start editing linebreaks in the source, but still.
  • The watch stars are missing tooltips. Personally I would classify this as a bug since this situation leaves people with zero information. They have to guess and try.
  • Same for a click on the timestamps (history). No tooltips.
  • At the same time the menu items (e.g. "Edit title", "Summarize" and so on) do have tooltips that do nothing but repeat the text that's written on the menu item. Please remove such duplicates.
  • The tooltip on "Permalink" reads "topic". Odd, isn't it?
  • What's wrong with the page width on history pages? It just looks broken and wrong and doesn't make much sense to limit the line length on history pages to half of the screen. There is plenty of space. Please let me use it. This especially looks like a bug since the rest of the software is not restricted to a arbitrary width any more.
  • Hovering all these "3 days ago" timestamps gets frustrating pretty fast, as already mentioned below. I like the fact that this saves space by hiding unnecessary information, but at the same time it becomes useless if all timestamps in a topic are identical. A very simple suggestion to improve on this is to show "3 days ago, 16:30" instead. Win-win.
  • Same for "a month ago". If you scroll down, you find hundreds of posts with the same timestamp. Again, an extremely simple suggestion: Use short messages for seconds, minutes, hours and days, but then stop and show the full time when a post is 1 month old or older.
  • How to scroll down to the links at the bottom of the page? I know, this is not a fair question, but since it's one of the reasons why Flow feels out of place I have to ask.
DannyH (WMF) (talkcontribs)
  • Great, I'm glad you like it.
  • Hiding a comment or a post is the closest equivalent to reverting a bad talk page edit, especially for threads. It takes the bad post out of public view, but keeps it accessible in the history so that people can follow the trail of a vandal, or restore a good post that shouldn't have been hidden. Also, if the vandalism was an edit to a good post, you can undo that through the history/diff pages. Can you tell me more about the function that's missing?
  • Thanks confirmation: That's a good question, I don't actually know. I created a ticket, and we'll figure it out. The ticket's at phab:T101196 if you're interested in following it.
  • We took collapse out because it was originally intended to be a kind-of substitute for a Table of Contents, except it wasn't a very good ToC and people were generally baffled by the collapse icon. Now we've created a real ToC at the top of the page, so we took out the collapse. We're working on a new version of marking a thread as resolved, and that's actually going to bring the collapse function back for resolved topics.
  • Thanks, I really like the VE/source toggle too. The small size of the source entry field is a bug, filed here: phab:T100074.
  • Good point, I filed a bug -- phab:T101197
  • Also a good point -- phab:T101198
  • Good point -- board history is full-width, but topic history isn't. phab:T101200
  • Adding a time after the 3 days ago is possible, but I think the usefulness of that information decreases as time goes on. When it's 30 minutes ago vs 9 hours ago, knowing the time helps you participate in the conversation -- the person who wrote the post 30 minutes ago is more likely to still be online to read your response. When the conversation was 3 months ago, how would knowing 3:00 vs 10:00 help you?
  • We're going to put the bottom links at the bottom of the side rail -- that's phab:T97371
  • Thanks for posting all your thoughts and questions; I appreciate you taking the time.
TMg (talkcontribs)

This weird indention behaviour can't be intended. Currently I see three "Reply" buttons in this thread. They are all on the same level. They look identical. When you are not expecting the difference (and why should you?) you are missing the small graphical difference of the input box not being indented.

The first two "Reply" buttons do what I expect and create an indented reply. But the last one is different from all others.

I'm allowed to write direct answers to older posts only?

The last "reply" button in a thread tricks the user into something he did not meant to do? And there is no way around, other than creating a dummy post, do the intended reply and delete the dummy post? This usage pattern is just broken. Sorry to say that. I do not want to offend anybody, I just want to express how this feels to a user.

TMg (talkcontribs)

I'm afraid you missed a point I wanted to make when you write: "When the conversation was 3 months ago, how would knowing 3:00 vs 10:00 help you?" What I can tell from this is that the 2nd post was written 7 hours later than the 1st. The current situation does not tell me anything. There is literally zero information because it looks like all posts in a thread are written at the same second "3 month ago". Please either fix this (as I suggested above) or just remove the useless timestamps from the individual posts and replace them with a single timestamp per topic.

TMg (talkcontribs)

Oh, what? Why is this not indented? I clicked "reply" on the last post by Danny and wanted this to be indented. I guess this is a known bug since quite a lot of topics here on this discussion page seem to cover exactly this confusing behaviour. Just wanted to add my +1 on this.

Quiddity (WMF) (talkcontribs)

Hi TMg. The current indenting structure is intended to prevent long diagonals (such as those that consume reddit, and we avoid onwiki with {{outdent}}, or just starting at the root level again via a fuzzy 'social custom').

Hence, replies in this Flow structure will always be at the same level, if at all possible. They only add an indent, when unavoidable.

This is intended to encourage people to read and reply to the full topic, rather than considering every single post as being something to "fork off from". So, clicking the very bottom "Reply" link will always have the same result as just clicking in the Box. (Someone has suggested we just remove the bottom "Reply" link, or the Box, but either of those options might also be confusing... That definitely is a problem to be examined.)

The main topic discussing it, is Topic:Senq838us190rqlp, with some additional discussion at Topic:Sinpglgkf9wu3qlt and Topic:Siiavth54u8a0rm8. As a few editors there have said, it does make sense once we get used to it (but can definitely be confusing at first!), though it does need some small tweaks to be as good as it can be.

Hope that helps add some context and nuance. :-)

TMg (talkcontribs)

The last "reply" button in a topic is broken. It may be broken by design, but it is broken. Simple as that. "Encourage"? You call tricking people into something they do not want, do not mean and do not expect "encouraging"? And you expect everybody to get "used to" this enforced broken behaviour? Oh...

I'm afraid this discussion will not lead anywhere since we are using different vocabularies.

Note that I'm not exclusively expressing my opinion. I'm sure you are aware that the communities, especially the more experienced ones, love hating Flow. I always wondered why this is because I found and still find most aspects of Flow impressive and promising. I'm starting to understand...

I don't want to be unfair. I agree that it's a good idea to help users that carelessly indent no matter what. This is not the problem I'm raging about. I'm raging because I do want my comments to be indented because I want to express something with that. I care. A tool that thinks it knows better than I, without giving me a way out (oh, there is a way, see my hidden comment below, but this is obviously a hack), is not helpful.

My expectation is simple. Super simple: Writing something in the box that's shown at the end of each topic does not indent. Hitting a "reply" button does indent. It can't be much simpler than that.

(I'm also starting to understand why users love hating VE because this is the 3rd time in 10 minutes I have to delete unwanted <nowiki> tags. Part of this problem is that the two modes are nearly indistinguishable. Can you please make the source edit window light gray? This would help a lot.)

Quiddity (WMF) (talkcontribs)

Thanks for the details, they do help, a lot.

At a specific level: I agree with and understand your expectation - the problem is: How do we balance that expectation, with the desire to keep the already indented subthreads, as flat as possible? E.g. if we always indented, then if we click "reply" to each other a few more times, in this subthread, we're back to the problem of "every discussion becomes a diagonal"...

The only obvious solutions (afaik) are:

  1. to add an extra placeholder "box" at the end of each subthread -- However that would create a very cluttered UI... :-( (e.g. adding 2 more boxes, for flat-level replies, at the 2 subthreads in Topic:Sgopn8j210lt00xw )
  2. to let editors choose their indent level for every comment -- However then some of us will just apply our old habits and preferences, which would lead to an inconsistent and even more confusing style!
  3. the current system, where the bottom "reply" link (in the main thread, and subthreads) creates a flat-level response, but where any earlier "reply" links create an indent.

At a general level: Personally, I like reddit's long diagonals! Other people prefer the stackoverflow style, with specific indent limits, and font-sizes for each indent-level. Some other people prefer the completely flat style used in bugzilla and many bulletin board style forums.

The indenting style used here currently, is hoped to evolve into something that works best for all of us, whilst avoiding the limitations or flaws of the other 3 main styles. I believe (personally, as an editor) that it does have the potential to become something the communities can all accept (and adapt to), with a few more tweaks. But I'm not sure what those tweaks ought to be.

Sidenote: Each of the new ideas (innovations, experiments, etc) has to get feedback from a handful of people (because there's an understandable reluctance to "just change everything, about sub-feature [x]", based on only 1 or 2 negative responses...), so you adding your comments/perspective/individual-phrasing here, really is immensely appreciated.

Diego Moya (talkcontribs)

>@Quiddity (WMF): How do we balance that expectation, with the desire to keep the already indented subthreads, as flat as possible?

With respect to that question, we have so far two models that solve the problem of keeping threads flat.

- The current "Flow style" (indenting the second reply, keeping the first flat and out of order) is known to freak the hell out of editors accustomed to threaded systems.

- The alternative - HHHippo's "Dynamic style" (indenting both replies, in order, when a single post gets parallel replies) maintains the same structure of the classic threaded system while solving the one-indent-per-comment problem. (This would be option 4 in your list of three).

Is there a possibility to explore the second model with some development support, or is the budget dedicated to this subject closed for now? I'm working on a mockup of how the dynamic style could look and behave (without the need of intermediate "post boxes"), I'll post it as a new topic one of these days.

TMg (talkcontribs)

My personal theory is that this idea (number 3 in your list) just can not work. You are creating a system that obviously supports indention. Users see it. Users expect it. But when a user tries to make use of this feature it won't work most of the time. But sometimes it will work. The user does not understand what's going on and is, in the worst case, pissed.

The system even creates the impression that the right to use certain features is bound to a user right or something. For example, look at the first responses I got from Matt. Why was he allowed to use indention before the later, unindented response by Danny was written? I just can't wrap my head around this. Does the system actually change the indention level whenever it feels like? Based on what information? Are posts moved??? This is sooo confusing. And again, this leaves users in a situation where they have no control over what's going on. They will even feel like they need to fight the system because the system actively disrespects what the user wants. There is a reply button. I click it. The system knows exactly what I want. Still it disrespects my decision.

Such a system is nice in discussions where thousands of users constantly come and go. Most of them do not care anyway. They just want to say something. They do not read what was written before. It's very unlikely they will ever respond. Most user are not even interested in getting an answer. In such a world indention is worthles.

But Wikipedia discussions are not like this.

The more I write the more obvious the answer becomes to me. Users love hating Flow because it disrespects well-established cultural aspects.

Diego Moya (talkcontribs)

This is intended to encourage people to read and reply to the full topic, rather than considering every single post as being something to "fork off from". [...] As a few editors there have said, it does make sense once we get used to it

It does make sense, but it's inferior to a traditional threaded conversation, where the possibility to fork the conversation in several is a boon - an advantageous possibility that's impossible to achieve in traditional spoken conversation. Having a single sequence of comments and forcing readers to read it in full is not a natural model for the way people participate in online forums.

People scan for content, and reply to the points where they have something to say that can add value, skipping sequences of ideas on which they are not interested. The current threading model does not support the way people wants to use it for best collaboration.

This comment was hidden by TMg (history)
Reply to "Still unable to revert spam"
DannyH (WMF) (talkcontribs)

Today, we released a new Flow feature -- a side rail, which holds the content that was previously in the header, at the top of the page. You can choose to close the side rail on a board, which gives you an almost-full-screen width for the board.

There are two problems that the side rail is intended to address.

First, we know that it's important to have announcements, warnings and metadata easily available at the top of the page. At the same time, the header boxes can get very long on an article talk page, pushing the conversations well below the edge of the screen. This is baffling for new users, and it can be a hassle for experienced people, too. Putting those templates and instructions in the side rail keeps them visible, without getting in the way of the discussions on the page.

Second, we've had lots of feedback about the fixed width on Flow. Some people like the fixed width and some don't, and we wanted to give people more choice. The side rail gives us an opportunity to add a toggle that changes the display width.

There's one piece that's coming soon -- the toggle should remember the last state that you've chosen, across all the Flow pages that you visit. Right now, it gives you the default on every page, with the side rail open. We're going to add that preference in a few weeks.

So what do you think -- helpful or not?

Tar Lócesilion (talkcontribs)

Strong support. It's extremely helpful. To be honest, I'm looking forward to enabling it on other namespaces, too. Probably, we -- volunteers -- need to adapt some templates to the new width, but I'm going to do it gladly, since the feature is really useful.

I think the smaller font size looks inconsistent and thus a bit confusing. #accessibility #typographyrefresh

Diego Moya (talkcontribs)

That is... an elegant solution to the original controversial decision to have a fixed layout. Well done, team.

DannyH (WMF) (talkcontribs)

I'm glad to hear it looks good to you. I've been excited to get this out.

I've been wondering about the font size in the side rail; I'd like to know what people think of it. Does anyone else have thoughts on that?

Tar Lócesilion (talkcontribs)

Another problem: the side rail doesn't show up in a single thread view, and I think it should do.

Imagine a frequent case, a new notification about a response, or a ping. The user isn't necessarily aware of the discussion, whole page itself, maybe its generic rules etc. (An example? One's first article and articles for deletion.) The user can see one, pure thread, no documentation. Unless he is a regular user, he's likely to get lost without documentation provided by the side rail.

Sänger (talkcontribs)

Yes, it should. But as a design premise of this forum impersonation is, that single threads should be available on different talk pages, at least that was given as one advantage of this enterprise, what side rail should be shown for those threads that are on more than one talk page? Perhaps a listing of all pages that it's on? Or all side rails in chronological order?