Talk:Structured Discussions/2015/04

The Collaboration team has enabled Flow on this talk page.

• Please conduct testing at Talk:Sandbox, retaining this page for discussions and suggestions.
• If you find bugs not yet tracked, report in Phabricator if you can, and here if you can't.

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

JSON data structure

Is there some brief description for view-topiclist query data? Say

https://ru.wikipedia.org/w/api.php?action=flow&submodule=view-topiclist&format=jsonfm&vtlsortby=newest&vtllimit=100&page=Википедия:Песочница/Flow

returns a lot of stuff for a month to meditate thinking what goes where... Some schema maybe with a sample discussion and links to JSON data blocks, like W3C box model (http://www.w3.org/TR/CSS2/box.html) or a like. Neolexx (talk) 10:27, 1 April 2015 (UTC)

Date of the message

If any bot will correct templates in old messages - date of the message will change too? Can Flow-bots not change date of the message? Сунприат (talk) 14:02, 1 April 2015 (UTC)

Ah, good point. (Also bot-edits would bump the "recent activity" for no reason). Filed as phab:T94711 - If you have any examples in mind, please add them there by editing the description. Thanks! Quiddity (WMF) (talk) 16:59, 1 April 2015 (UTC)

Based on my own message "JSON data structure" below it doesn't. I posted first and then corrected a small typo (lof to lot) and it didn't change the original time stamp - rather, a new revision has been added to the history. Try https://www.mediawiki.org/w/api.php?action=flow&submodule=view-topic&page=Topic:Semm2wei2gey0m4o and view at http://jsonviewer.stack.hu/

Surely developpers may know better. Neolexx (talk) 14:38, 1 April 2015 (UTC)

I think this might help: json formatter Jamesjames281 (talk) 08:24, 22 July 2017 (UTC)

So is Flow available for other wikis?

If it is, then how is the extension implemented? RedPanda25 (talk) 19:19, 1 April 2015 (UTC)

See Flow/Rollout#Requesting Flow at a new wiki and also Flow/Volunteers to test. Helder 20:02, 6 April 2015 (UTC)

New indentation & threading model

The new indentation & threading model is deployed to group-2 wikis today (per wikitech:Deployments/One week). Here is the full (blockquoted) description, written by DannyH (WMF), which explains some of the background, and intentions, behind this new configuration:

Wikitext talk pages use indentation for two different reasons -- to create visual separation between people's posts, and to create spin-off tangents that follow a different path than the main flow of conversation in a thread. They're both important functions, but they don't need the same mechanism, and I'd argue that trying to do both with indentations makes wikitext talk pages harder to participate in and understand.

Big, complicated Village pump conversations need lots of room for tangents and subthreads. A simple back-and-forth conversation between two people doesn't need that.

But we've spent years counting colons and fixing other people's indentations, to the point where it feels like a conversation can only be worthwhile if it's diagonal. People look at the interesting, high-quality conversations on wiki talk pages, and the terrible nonsense that people post in the comments on a YouTube video, and the most obvious visual point of difference is the indentation. So when some long-standing wiki veterans look at Flow, the first thing they want to know is how many indentation levels there are, because indentation = good.

Unfortunately, even if we wanted to recreate the wikitext cultural practices, we wouldn't be able to. The guidelines aren't actually systematic; they're a set of principles that need expert human eyes to keep things straight. When there's five equally-spaced indented messages, the question of how far you should indent a new reply to the third message gets fairly abstract. This is one of the reasons why new people are confused and scared off.

The structure that Flow has been using up to now was kind of an unhappy compromise between the two functions of indenting on wikitext talk pages: to separate posts visually, and to create spin-off tangents. It didn't really accomplish either goal very well.

The new model that we're trying out now makes a choice -- the purpose of indentation is to create a spin-off tangent, outside of the regular chronological flow of conversation.

Here's how it works:

If you're replying to the most recent post, then your reply just lines up under the previous message. A two-person back and forth conversation just looks flat, and the visual separation is noted with the user name and timestamp.

If you're specifically replying to a previous post, then your reply creates an indented tangent. If everybody responding on that tangent replies to the last message in that subthread, then it'll stay at the same indentation level. But if someone replies to an older message within the subthread, then that creates a third indentation level. I think we've got it set to a maximum of 8 possible indentation levels, and we just stop it there because there's a point where you can't fit a lot of text in each line.

The big idea of the new system is that the indentation should actually mean something. You should be able to tell the difference between a simple conversation and a complicated conversation at a glance, and using indented tangents helps you to spot the places in a conversation where there's a disagreement or a deeper level of detail.

So that is the Grand Unified Theory of Flow Indentation, in theory and practice. I would be happy to hear what you think about it. There is a very good chance that this model will continue the Flow tradition of pleasing exactly nobody, and if that's the case, then we can keep talking about it and making more changes. But there's also a chance that this is brilliant and solves everything, so I want to give it a shot and see what happens.

<end of blockquote>

Additional information:

• phab:T92400 (Technical description)
• phab:T88501 and phab:T88865 (Design wireframes)

Some other recent discussion:

• "How do I indent an reply to a particular post?"
• http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/82069 (scattered within the 80 posts)
• phab:T93883 (mostly He7d3r and DannyH)
• Flow/Prior discussion-thread-roundup#Indenting Levels (incomplete list of discussions from last 18 months)

See also:

• phab:T93024 (request for a view-toggle between flat&chronological and indented/threaded)
• w:User:Hhhippo/Flow/Compact_nesting (A somewhat similar proposal from many months ago, which could further influence the direction this takes)

Discuss. :-) (Please use talk:sandbox for any random experiments, thanks) Quiddity (WMF) (talk) 22:27, 1 April 2015 (UTC)

This image from the design thread at Phabricator is a very good visual explanation of the new threading model:

In summary, indentation now follows the "Out of order rule": a post is indented at a new level only when it's an out-of-order reply to a post that is not the latest in its subthread. Diego Moya (talk) 11:22, 7 April 2015 (UTC)

This seems like a good spot to jump in...

Ofcourse this message should be inserted at the bottom, i'm responding way later...

So, in the image from the post above, in the 4th and 7th column, the new post should be at the bottom of the (sub)thread, and the messages above indented, not the new one. (I'm sure someone suggested this before, but can't find it again right now because of how out of of sequence this page is...)

(Also, i prefer the signing of messages at the bottom, as is currently the custom. It makes it easier to avoid prejudice. (it's the message that matters, the signature is just so you know who wrote it)) Buzz-tardis (talk) 03:05, 11 June 2015 (UTC)

No, it doesn't. A reply to the original post is put at the end, as if it's a reply to the last post, regardless of it's real status. You can see it in my test over in the sandbox. Grüße vom Sänger ♫^(Reden) 14:28, 7 April 2015 (UTC)

---

@Sänger: How are you testing it? This comment is a reply to the thread's original post, and it's shown here, at the end of the first sub-thread (i.e. the one containing all the replies to Quiddity's except the first one by Oiyarbepsy), but right above all the previous posts that were made in order (i.e. my reply is not posted at the end of the topic as you say).

The threading order is working as intended for me. You must take into account that indentation now depends not only of which is the parent comment of a post, but in which order they are made as well:

- The first reply to the latest post in a thread is shown at the same level, without indentation, in order below everything else in the same thread.

- Further out-of-order replies to the same post, when it's no longer the latest, are shown above the previous in-order replies, indented one level to indicate that they don't follow the default ordering (and shown below the other out-of-order replies to the same post if they exist).

- Every indentation level is a sub-thread that follows the above two rules internally, starting at its current depth. Diego Moya (talk) 22:14, 7 April 2015 (UTC)

Thanks, love it. You can see all of my ridiculous testing of this by talking to myself at [1] Oiyarbepsy (talk) 02:27, 2 April 2015 (UTC)

I tried some more diffuse discussion here, I don't think it's really helpful for not-straight ones.

I won't even mention the missing splitting in several sub-topics once a discussions runs out of bounds.

Edith says:

Why is the second paragraph indented in my edit window now? I never included any tab-stops or whatever.

And why is my perfectly fine link to the sandbox thread red? Grüße vom Sänger ♫^(Reden) 16:41, 2 April 2015 (UTC)

The tabs bug is phab:T93851 and the redlinks bug is phab:T94773. Quiddity (WMF) (talk) 21:05, 2 April 2015 (UTC)

Is the discussion on a different wiki? That would explain the red link. I had to use the full url to link to my testing an English Wikipedia, altho I know there is something like en:Topic:grhagui or something like that. Oiyarbepsy (talk) 20:26, 2 April 2015 (UTC)

No it's here, in the sandbox next door, just like this one. Grüße vom Sänger ♫^(Reden) 20:51, 2 April 2015 (UTC)

If anyone ever needs it, a full Russian translation of Danny Horn's post is here. Neolexx (talk) 16:17, 4 April 2015 (UTC)

I love the new indentation style! But that's no surprise, as I suggested (at this Indentation levels thread: [2]) the mechanism of "only indent replies to in-the-middle comments". ;-) I like a lot the explanation of the "Grand Unified Theory" in terms of two distinct functions ("visual separation" vs "spin-offs"), I think it clarifies the purpose of the design.

It's sad that people find it confusing at first, at least until someone explains them how the layout is working. User Hhhippo suggested a nesting style to clarify how the conversation flows. Maybe it's time to update the visual style to better convey how the posts are connected.

May I suggest darkening the vertical line to the left of the current post under the mouse, when hovering over its text (but not when over the Reply button), to link together all the connected posts in the current subthread? This would create a visual cluster of directly related posts, and also points to the posts immediately above and below at the previous level.

Edit: adding to examples of the hovering behavior I propose (based on this test by Sänger):

Diego Moya (talk) 10:28, 7 April 2015 (UTC)

There are several types of answers mixed and it's not clear, where they are an answer to, if it's a too long and diffuse discussion, as was shown in my test. Grüße vom Sänger ♫^(Reden) 14:45, 7 April 2015 (UTC)

I think I see where you're having a problem. In the new scheme, indentation is related primarily to the order in which comments are made, not the post you're replying to. The main idea is that usually you should think of replying to conversations as a whole (i.e. by adding new comments at the bottom), not to individual posts (doing that is now considered an exception, treated with a different rule - the common case does not create further indentation in the current subthread, but the exceptional case does). I think this is what's causing your confusion.

In your example, it doesn't matter that "Answer by user 5" is a reply to the original post or to "Answer to user 2 by user 4". In both cases it's the last post in its subthread, so it belongs at the end of its indentation level. In this case, those posts are intended at level 1 only because there exists an earlier "This is the first answer by user 1" post at level 0, so your highlighted posts were are all made out of order and thus are indented.

If "This is the first answer by user 1" didn't exist (nor anything below it), all the posts below "This is an answer by user 3" would have been shown without indentation, and that whole subthread would have been rendered at level 0 (except for "And an answer to user 2 by user 3", which mas made after "This is an answer by user 4. it was meant to be an answer to the original post"). It doesn't help to understanding that the content are not real messages but placeholders; in a real conversation, the conversation flow should feel much more logical.

You're right that the interface could make a visual distinction for "Answer by user 5" to show that it's a reply to the original post and not a direct reply to the post immediately above it; but that's not essential to how the model is laid out. Diego Moya (talk) 22:28, 7 April 2015 (UTC)

If I should answer to "to conversations as a whole", they must never get any longer then 10 posts, or the structure is not suited any longer. So Flow is just for snippets, not for real discussions? How should real discussions over several MB take place? It's essential to have a clear markup to which post I answered.

Or it has to be easy to divide the discussions, that get too long for this simplistic indentation model, into proper sub-threads. This new weird indentation model is obviously primarly meant for useless blabber, not real, long discussions. Grüße vom Sänger ♫^(Reden) 15:54, 8 April 2015 (UTC)

@Sänger: You can add visual markup that identifies to which post every comment is a reply to. You can try it yourself in your sandbox test by adding a horizontal rule on top of each "reply-to-base-comment" post:

1. Open this, this and this comments for edit
2. Change to classic Wikitext editor by clicking the </> at the bottom right
3. Add <hr> to the top of each comment, and save.

If you do this, it becomes clear which is the parent comment of each post in the thread:

- Comments without the horizontal line are replies to the post immediately above them in the same or lower indentation level, always (i.e. ignoring any comment in higher indentation levels).

- Comments with a horizontal line are replies to the post in the immediate lower indentation level. Diego Moya (talk) 05:52, 9 April 2015 (UTC)

I've replicated your test conversation here, adding the visual cues that separate direct replies and replies to the base post. Let me know if it's clearer.

If this style is enough to identify the origin of each reply, it could be automated or required by the Manual of Style. Diego Moya (talk) 08:17, 9 April 2015 (UTC)

Definitely looks better and reply target is clearer, in the real solution it shoud just be above the user name, not beneath, now the line separetes the name from the post. Grüße vom Sänger ♫^(Reden) 14:08, 9 April 2015 (UTC)

I couldn't place the bar above the user name in the real interface, but I've changed it on a local copy of the page and this is the result. It neatly identifies all the posts that belong together in each sequence.

Diego Moya (talk) 15:22, 9 April 2015 (UTC)

"They must never get any longer then 10 posts, or the structure is not suited any longer". Why would you say that? Flow topics are not limited in size, just like old talk pages are not limited in size and can keep growing forever. The structure now is the same, except that you don't need any longer to use {outdent} every now and then, as the default mode does not grow to the right, but remains flat instead.

"It's essential to have a clear markup to which post I answered. " You didn't have that in old talk pages either. When several users started cross-posting replies past each other, it was not clear to what post each answer was addressed. The solution in those cases where you want to clarify to which user you're replying to, you can make an explicit {ping} to include the user's name, just like you needed to do in classic talk.

The only change from that model to this one is that linear conversations in Talk pages grow in diagonal, and linear conversations in this new Flow structure grow straight down. Everything else is equal, with unlimited indentation available when needed. There's only a symmetric switch of the default orientation over the diagonal axis; the structure is otherwise equivalent.

In fact, with only adding a visual way to distinguish replies to the base post from replies to the post immediately above the current one, there's a simple way to transform back and forth between the old indentation model and the new one without any loss of information, so they're formally isomorphic. The only practical difference is that the new layout should be clearer to newbies and easier to use. The idea of answering to conversations as a whole is that you don't need to identify the post you're replying to, but you still can do it if that's what you want, as nothing prevents you from doing just that. Diego Moya (talk) 22:11, 8 April 2015 (UTC)

==Arbitrary break 1== Diego Moya (talk) 22:49, 8 April 2015 (UTC)

This is a small test to show that indeed you can split longer Flow topics into separate sub-sections, using the same mechanisms we used at the mediawiki pages. (It would work better if Flow added support for sub-headers ''over'' the post author and/or between posts, but hey, that's what you get for free software still in development).

This topic is already 16 posts long, and it doesn't show any sign of getting cluttered or blabbering - in fact, it looks surprisingly clear to me, and able to absorb a good deal of tangent sub-threads at any of the above posts. Diego Moya (talk) 23:04, 8 April 2015 (UTC)

I agree with Diego Moya that the new indentation system is a step in the right direction. But I also agree with Sänger that it must be clear which post is a reply to which. After all, we have 'reply' links for each post, not just for the whole topic. On classic talk pages this was possible in most cases by correct use of indentation and bullets. And even in cases where it wasn't possible, there's no reason why Flow shouldn't do it better.

I think the case Sänger mentioned is the same as the distinction between 'User E' and 'User F' in my design proposal. Indentation alone is not enough to distinguish between a new (serial) post in a side-chain and a new (parallel) post on the same logical level as the start of the side-chain. It is, however, possible to make this distinction by adding visual clues, like in my sketch. It would be nice if something like that could be implemented so we can try it out. — HHHIPPO 10:16, 10 April 2015 (UTC)

What do you think of my idea of adding horizontal rulers between parallel posts? If I understand your design correctly, there should be horizontal lines above posts by user C and user F.

Also, what would happen in your design if someone else replied directly to user C? Would posts by user D and E become indented one level, and shown below the new post (and left aligned with it)? Diego Moya (talk) 11:50, 10 April 2015 (UTC)

The horizontal bars would be an improvement over what we have now, but I think it's not immediately obvious what they mean. What we need is not only an unambiguous indication of which post replies to which, but these indications also have to be understandable without reading a manual. That's what my model is aiming at, but of course it would need a real live test to judge how well it's accomplishing that goal.

In my example, if a new reply to user C comes in (let's call the new one post H), then that would be placed between posts E and F. Posts D, E and H would be on the third indentation level, and there would be a vertical line down from C, with horizontal connections to D and H. D and E would remain connected by a short vertical arrow. This would be so much easier to see with an interactive prototype... — HHHIPPO 08:42, 12 April 2015 (UTC)

I understand what you say, no need of a prototype. :-) Ok, I see two problems in your design. First, the indentation of a reply can change after it has been first posted - and not by the user who made the post, but by other editors writing after them. This may influence the decisions taken by editors arriving to the conversation, making them wary of adding to the conversation; I know I would think twice before replying to a thread if i know my comment is going to change the replies of others that posted before me.

The second problem is of a visual nature. It's difficult on first sight to tell what's the sequence of posts that belong together and where a block of consecutive comments begins and ends, as the triangles connecting the sequence form a discontinuous, intermittent broken line. You have to look carefully between each pair of posts to see whether there's a triangle or not, instead of perceiving the sequence as a whole. Groups of things are perceived best when there's a visual block joining them.

With horizontal lines, it's clearer to see the sequence: everything between two lines is a block of related comments, and posts at opposite sides of a line are not directly related. The final visual design should take elements of both proposals into account. Diego Moya (talk) 22:59, 12 April 2015 (UTC)

I think the first problem is so intrinsic to the model that we can't really avoid it, but it shouldn't be too bad once people get used to the new meaning of indentation: it's no longer a part of an individual post, and changing the level is not doing any changes to other people's posts or their relationships. The indentation level just tells if there are other 'parallel' posts (replies to the same parent) or not, and this can naturally change. Just like the numer of a post if you count from the top of the page is not fixed, but flowing ;-)

I agree with your second point, the overall structure is more in the details and not so much in the overall layout as it is with classic talk pages. So we should add some more emphasis to separating parallel branches from each other and connecting serial chains internally. There are various options how to do this and it would be nice if Pau would chime in, but I think your idea of combining our two proposals is great! Maybe with different shades of grey for the connecting lines and the separator lines, that could make a very nice combination where the reader gets the overall picture immediately and can still find all the details when needed. (Plus collapsing function in all the triangles and maybe more...)

Danny, can we have one? :-) — HHHIPPO 06:36, 13 April 2015 (UTC)

Now that you've provided a simple concept for the meaning of indentation (a group of parallel replies to the same post), I like it better. As seen at the beginning of this topic, any new structure will require explanation to experienced users, if only so that they are aware that there has been a change.

I've tweaked your design to see how it would result with the mixed style including connecting lines and separators:

Diego Moya (talk) 10:45, 13 April 2015 (UTC)

Hmm, I kinda like the vertical arrows between serial posts and the short horizontal lines connecting to parallel posts I have in my design. I think they give a quite clear indication of who replies to what, since there's always something like an arrow between parent and child. The indentation is then just a natural consequence of making space for the long vertical lines. Plus, the arrowheads can also function as collapsing buttons.

I agree we need a better explanation of the concept. It seems the exact same model has been invented at least three times independently, and it's still hard to explain to each other and even more to others. I'll try to write something up and also tweak the layout a bit, but it might take a while since I'm quite busy in RL. — HHHIPPO 19:41, 13 April 2015 (UTC)

>I kinda like the vertical arrows between serial posts and the short horizontal lines connecting to parallel posts I have in my design. I think they give a quite clear indication of who replies to what, since there's always something like an arrow between parent and child.

I'm afraid they don't work well for that, at least not for me. My first though at your design was "why are there arrows between some posts and not others?", not "this is a sequence of comments". It's just another feature that needs to be explained, it's not visceral. Also, your design is somewhat noisy; current talk pages are extremely minimalistic, with basically no chrome, and the replacement should be made as lightweight as possible.

The best thing in your design is its structure, and how it keeps all replies to the same post in chronological order, maintaining flat threads at the same time. The new Flow threads show the earliest reply to a comment below all the later replies, which is a problem solved with your structure. Diego Moya (talk) 07:02, 14 April 2015 (UTC)

I like Hhhippos solution better, especially the colapsing possibilities. But Diegos is a step towards better reading and structuring as well. Grüße vom Sänger ♫^(Reden) 12:17, 10 April 2015 (UTC)

I'm really glad you guys are chewing this over. The problem that I've had when talking about this is that it's very difficult to evaluate the readability and sense of a conversation design when the examples use filler text -- either Hhhippo's "Lorem ipsum", or Diego Moya's "This is an answer by user 3".

Using filler text means that you can create arbitrary problems like, "If user F wants to specifically reply to user C's 3rd post, and F's reply aligns under B's reply to that post, then how would you know that F's post is a reply to C's post rather than B's?"

The answer to that question is likely to be "context". You can tell what question I'm responding to, because I'm responding to that question.

Example:

User A says, "Are there any good books about the history of jelly-making?"

User B replies, "I don't think so."

User C replies, "The best book that I've read on the subject is X."

Reading those words, you don't need indentation or nesting structures to help you understand who each person is replying to. This is how conversation works -- even complicated conversations, involving multiple people.

In fact, in this conversation right now, I'm responding to points made by Hhhippo and Diego Moya above, and not directly to Sänger. But I made it perfectly clear which points I'm responding to in several different ways -- some explicit (mentioning each person's example) and some implicit (picking up on ideas and questions raised in various posts in the conversation).

You can't get any of that from filler text, so those examples make it seem like the problem is the structure. DannyH (WMF) (talk) 21:23, 10 April 2015 (UTC)

I agree that real life discussions are an important test case, and that context can reveal structure. But: to establish structure through context we don't need software, and it's the software we're discussing here. It's the software that must provide structure in cases where the context is ambiguous, which happens very often. In your example, if just user B posts after user C, it's no longer clear what it is that B is (not) thinking. This is not an exotic constructed use case, it's everyday life on a wiki.

In order to test how well the software rather then the context is revealing the structure of a dicussion, I think it is actually important to use filler text with no context. Real life tests are of course needed, but dedicated designed tests targeting specific aspects of a software can be essential, too. Just think of all the stuff you guys are doing between writing a patch and deploying it to a big wiki. (And anyway, I'd be happy to test by model in a real discussion. Just add these little lines and triangles to Flow, they don't even take extra space ;-)

You seem to be suggesting that it would be better for the software to provide no structure at all rather than an imperfect structure (like one not supporting a single reply to multiple posts). Well, we've tried that. Mediawiki talk pages started out as blank wiki pages, with no structure whatsoever. On top of that the colon indentation system evolved, because structure was needed. The same will happen with Flow if it doesn't provide structure itself. Diego already demonstrated that it's possible to add structural elements that Flow didn't intend to reveal, and a lot more would be possible by user scripts.

The big difference between Flow and wikitext is the data model: in contrast to wikitext, Flow is aware of the discussion structure. In my view, being able to show this structure is the only reason for storing this structure, and thereby one of the main reasons for even thinking about Flow.

About replies to more than one post: if that should turn out to be a problem (it wasn't so far), then there's an easy solution: allow readers to go through the posts within a topic chronologically. By 'next'/'prev' buttons, sorting options, proper watchlist and history functionality or whatever else. I won't repeat the details here, they've been suggested long ago. — HHHIPPO 09:31, 12 April 2015 (UTC)

You're right that context is what makes a conversation make sense, most of the time. But threaded conversations can wreak havoc with context - new posts are intertwined in the middle of a lively discussion, earlier posts at lower intentation levels get pushed down and can only be read after finishing a later tangent subthread, new posts are added to the top after you've already finished reading that part of the page... The problems you mention that appear in those artificial conversations will not be a problem most of the time, but can be baffling some of the time; and the tool should handle those situations as well. (Wikipedia talk pages are certainly known for making good use and taking advantage of such subtleties for collaborative writing, consensus-building and logging decisions taken, benefiting from such detail in ways that other throwaway-conversation systems don't need).

Threaded conversations are a relatively new and rare medium, and unlimited-depth threading is mostly unknown to a majority of internet users. Changing its few established conventions is risky, and having a way to track the origin of each and every comment is helpful for advanced users to be capable of reconstructing the exact history of the conversation when things get muddy.

I also like Hhhippo proposal of collapsible subthreads, and I would like to see it added as a feature to skip uninteresting tangents and get back to the main conversation. Though the new Flow implementation has the advantage of being much more flat, so very long conversations can happen without the need to outdent from a very deep thread that has become unreadable. Typical threaded systems have indentation increasing very fast, as each reply to a comment increases depth by one level. In the Flow model, normal conversation doesn't increase depth, which is only increased by parallel replies when they're made out of order - which is less common, so most of the time, the depth level doesn't increase so fast, as this current topic shows. Diego Moya (talk) 22:49, 10 April 2015 (UTC)

It's possible that Wikipedia conversations get unmanageably complex, because the discussion tool doesn't set any limits on how unmanageably complex they can get. There is literally no limit to what someone can do on a wikitext talk page, so there's all kinds of crazy anti-chronological shenanigans they can get up to.

So when we look at a structured discussion system that actually has rules, we say: But how will we be able to deal with it when somebody does "crazy thing A, B and C"? We won't understand what's going on!

But maybe the conversation would actually be better without doing "crazy thing A, B and C". Maybe those are the things that make wiki conversations muddled and confusing.

Any structured discussion system is going to be more restrictive than wikitext, by definition. It doesn't matter whether Flow uses the old indentation system, or the new one, or any system you could ever dream of. If it's going to follow a set of rules, then it will not let you do every single thing that you can do in wikitext. The upside is that things get more clear, more focused, and more efficient. DannyH (WMF) (talk) 00:45, 11 April 2015 (UTC)

That's a depressing comment coming from the Flow product manager, Danny. Those features are used because they're needed to build an encyclopedia thanks to their flexibility, and it's saddening to hear that Flow designers are still in the mindset of throwing out the crown jewels in their attempt to build a limited system that only works for a single purpose.

>There is literally no limit to what someone can do on a wikitext talk page, so there's all kinds of crazy anti-chronological shenanigans they can get up to.

Absolutely true, but we likes 'em that way; and I think the new Flow threading system shows that this doesn't need to be a problem - in fact, it's handling the amount of out-of-order comments going on on this topic fairly well. Add in collapsible sub-threads so that users can decide when to ignore unimportant digressions, and you're golden.

Wikipedia conversations get complex because there are complex topics discussed by huge amounts of editors for extended periods of time. Traditional discussion systems are designed for adding opportunistic commentary to entries with expiration date at news reels and blogs, and not multi-year collaborations like those we have around here. If Flow restricted the layout in those ways, it would likely be preventing those conversations from taking place at all, not merely making them less complex. The way Flow could help in those situations is by providing a simple default (such as the new threading model) as the path of least resistance, so that conversations will grow with simple structures wherever nothing fancy is required; but then allowing users to change them where complex needs arrive, instead of forbidding them from the outset as you hint at.

> Any structured discussion system is going to be more restrictive than wikitext, by definition.

Lila Tretikov's refreshing reply to the community at her talk page let it clear that someone at the WMF understands how talk pages have many use cases beyond structured discussion, and now we're back at square one?

The thing is, we don't want a structured discussion system at en.wiki, not for Talk pages anyway. Wikipedia Talk pages are not (merely) conversation systems. They are blackboards, where conversation is just one of many activities that can take place. Users need ways to take full control of what's shown, and for that we need the structure to be flexible as clay, not rigid as stainless steel. It's good that there are some layout rules to set the default, but they need to be overrideable.

>Any structured discussion system is going to be more restrictive than wikitext, by definition. It doesn't matter whether Flow uses the old indentation system, or the new one, or any system you could ever dream of. If it's going to follow a set of rules, then it will not let you do every single thing that you can do in wikitext.

I have given examples several times at the various Flow talk pages of how this doesn't need to be true at all. Look for any time where I've mentioned Microsoft OneNote for my ideas about a tool that combines the best of wikis and systems with post-based automatic layout**, and how they could be used to build a conversation tool as flexible as a wiki. Does your design team have a place for long term strategic thinking where such concerns of base purpose can be examined? Is it taking feedback from the community?

The sad thing is that Flow could become the most powerful and easy to use collaboration system, if we could convince its designers to expand their breadth of vision. You're self-sabotaging yourself with those negative thoughts of what the tool could never become.

P.S. ** In fact, the one feature required for such flexibility is deceptively simple: allow posts to be placed on the page through two modes: a relative one, were comments are threaded with automatic rules according to the parent post to which they're linked, and and absolute mode, where each post is placed at a fixed position relative to their base container, but which the user can change with drag and drop.

OneNote shows how the absolute layout provides for wiki-like flexibility while keeping track of all the content that belongs together as a single unit. Merging that with auto-layout threading rules (which OneNote doesn't have, but Flow does) would create a tool that defines a regular structure by default but which users can tweak, deviating from the original structure when needed. Diego Moya (talk) 09:28, 11 April 2015 (UTC)

That's a depressing comment coming from the Flow product manager, Danny. Those features are used because they're needed to build an encyclopedia thanks to their flexibility, and it's saddening to hear that Flow designers are still in the mindset of throwing out the crown jewels in their attempt to build a limited system that only works for a single purpose.
>There is literally no limit to what someone can do on a wikitext talk page, so there's all kinds of crazy anti-chronological shenanigans they can get up to.

I see this Flow more and more as the next step towards dumbing down of the wikiverse, to make it more facebookish (or any other thingy with no relation to an encyclopedia). MV, Flow, Gather, castrated mobile (no talk); and even to some extend VE; all the same tendency: take away flexibility and knowledge of basics, and insert useless social media stuff, that is explicitly not wanted by clear policy. But they don't care about policy by and for the community any longer, they only care for click-count and facebookisation (that's make it as dumb as possible). Grüße vom Sänger ♫^(Reden) 16:07, 16 April 2015 (UTC)

I wouldn't mind having a little good old "dumbing down" (everytime someone uses that despective term, it usually refers to some misunderstood but welcome and needed usability improvements), if only they were using looking at Workflowy, Evernote or even Pinterest as their reference - i.e. a tool for collecting and organizing content in a collaborative way; having an easy to use application for that purpose would be a good thing.

Instead, the applications for they are taking as their role models such as Facebook or Reddit and are oriented towards conversation, intended for informal chitchat, which is not the purpose of discussion at wikiprojects. Diego Moya (talk) 17:39, 16 April 2015 (UTC)

I have another idea, that should be very easy, as it's to be done by the machine:

Why not indent all previous posts, that replied just one after another, to the first indentation level, once someone answers afterwards to the original (or some other previous) post? It would treat all threads the same, only the last one will be kept straight. Shouldn't be that difficult to implement. It would satisfy those, who want to simplify and dumb down the threading for straight discussions, while keep the structure clean and clear on first sight for meandering ones. Grüße vom Sänger ♫^(Reden) 08:50, 11 April 2015 (UTC)

I'm not sure I'm following you, can you give an example?

I think the reason why we shouln't indent all posts is that then you end up with very deep conversations nested through a lot of levels, which was the problem we were trying to avoid.

By indenting only those replies that are made to intermediate posts in a sequence, and keeping all others at the base level, the need to create new indentation levels is greatly reduced.

Also, having the structure of the conversation change dynamically as new posts are added may be quite confusing. With the current and old model, once a post has been posted, it will always remain at the same place and indentation level relative to everything around it. If you rebase previous posts after they've been written, they won't be at the same place where you first read them, so depending on the complexity of the conversation you may have problems recognizing them as the same ones you've already seen.

Dynamic layout is an interesting possibility to test out, though. It may be that this last problem is not severe and may expand the design space with new options. Diego Moya (talk) 09:43, 11 April 2015 (UTC)

But that's what's been done now on talk pages as well: If I insert some answer to a post at the appropriate place somewhere inbetween other posts, I may rearrange the colons to fit this posting. This may not happen after some time, but especially with en:WP:EDC in heavy discussions it's quite common.

Only the respectively last straight thread in each subthread will stay straight at the same level until someone interupts. So only in really extensive discussions this will occure, but there it's definitely needed to keep them structured.

And if this extremely restricted, arbitrary, width of the discussions those folks @Flow forced on this "feature" is not capable of the needed indentation levels, just ditch this restriction, don't force the discussions to dumb down to a facebook-level.

Something aside: The more I read here, the more I think this may be a nice add-on on talk pages for those areas/paragraphs where simple discussions take place, while the main talk page stays as flexible as it's now. In this condition it's not even remotely capable as a raplacement for talk-pages. Grüße vom Sänger ♫^(Reden) 11:05, 11 April 2015 (UTC)

Edit: there has been an interesting case here. I've been writing my long reply above to Danny's post for more than half an hour, and after posting it there has been an "edit conflict", so it has been placed here, after Sänger's post, even though I clicked Reply directly to Danny's (before Sänger had posted it).

Since my reply has been sent later, it should have been indented and placed above Sänger's. (I've since copy-pasted the content that I originally wrote here to the one you can see above, which is now shown where I expected it).

I think the place where a post ends up should be decided at the moment of saving it, not when starting writing it, to avoid such surprising results. Diego Moya (talk) 09:12, 11 April 2015 (UTC)

i have also written similar idea suggestion at 2009-august-26 : http://qdb.wp.kukmara-rayon.ru/2009/08/26/a-suggestion-for-threaded-comments-of-livejournal/. QDinar (talk) 15:48, 4 February 2016 (UTC)

i see this here. but, unlike in the image File:Pjx6fDd.png, there are no "comment" text at upper posts, instead, they are all named "reply", and all have same style (togehter with the "reply"s at bottoms of threads). should not you better style and name these 2 roles/functions differently, and give "comment" function also to the latest posts of threads. and, more informative text, or tooltips (balloons) would be helpful: "start a sub thread, replying to this post" for "comment" , and "post to the thread" for "reply". QDinar (talk) 16:36, 4 February 2016 (UTC)

in the currently popular diagonal threads, users can continue a thread by replying to last reply in diagonal thread, but also can start a new similar thread by replying to the top of the "diagonal thread", so, they can create several sub-threads to/from every post/comment/reply. but this your new model does not allow to do so, because clicking "reply" to the top of thread scrolls/redirects user down to the form at the end/bottom of the sub-thread . QDinar (talk) 16:59, 4 February 2016 (UTC)

this was already reported: Topic:Sjh61at6k8mz21oy .

adding: this post is also an example / showcase for a design bug, which i mentioned, saying "and give "comment" function also to the latest posts of threads". i wanted to make this (almost just a link) a sub-thread, (comment for my latest post), but it has gone to same thread with it. moreover, there were/are separate 2 "reply" interface elements at bottom! one "Reply" near latest post and another "Reply to "New indentation & threading model" " inside a text area, that was/is going to expand! though the upper "Reply" did not open its own textarea, (which also would be moved righter), i did not notice / catch sight of that, and, since i clicked the upper "reply", i thought, separate form has appeared, and after i submitted, i have seen that result has gone to main thread! so that is a misleading design! now, after i have tested it again, i see that upper "Reply" at bottom just activates the textarea underneath. QDinar (talk) 17:15, 4 February 2016 (UTC)

but, in many or some cases, such move of latest "sub thread reply" to main thread by force is good (btw this is also reply to my latest post, to the addition part of it), because, the replies which go below, are written after seeing it, and are affected by it, and, in the currently popular/standart "diagonal" model, only later it appears that the main thread (lower/below part of it) started actively referencing to the post (reply), which is posted as a sub-thread reply, (and, so, people start to think, that the reply should be better posted at main thread, instead). QDinar (talk) 17:41, 4 February 2016 (UTC)

"this is not reply to the my latest post." - this is not true, you can see below, i also reply to it, and this is show case for "are written after seeing it, and are affected by it".

i add several ideas.

some times i want to reply to several posts. in 1 thread boards/forums like phpbb, i just cite them all, and post in the thread, which is only one, or, in some cases, i can start a new topic, citing and linking the posts to which i reply. but in the discussions with "replies" to "replies", "diagonal threads", which are also currently popular, (for example, they are in livejournal, wordress, email discussions), i cannot do so easily, because it is hard to me to decide, to which place i should post, but, i think, i can post to the most near upper comment, sub-threads of which include all posts, to which i reply.

and, another idea, which i think for i have written "are written after seeing it, and are affected by it" (so, as i said, now, later, when i write this long post, i see, that this my post is affected by my previous post, though, when i started to write, i did not think so) : to make some mechanism which allows to mark, which posts are read by user, when he replies. but this is too fantastic. QDinar (talk) 17:58, 4 February 2016 (UTC)

i have found another (referring to "i thought, separate form has appeared") little design bug. it is also visible in the File:Pjx6fDd.png . "reply" interface of thread is different of most external thread and of any of sub-threads. but they are same thing. QDinar (talk) 08:39, 5 February 2016 (UTC)

i have made an image which shows what happens if several sub-threads to/from every post/comment/reply is possible, and creating a subthread for the latest post of a thread is also possible, thus, there is full functionality of classic threaded comments.

and i have shown here idea to put several subthreads one behind another and to put subthreads behind their parent thread, (going behind posts of the parent thread which are underneath the parent post).

feb-6 utc+3 8:59-9:05 : saying this has full functionality of classic threads is not very correct, see my new (today's) post. (this lacks feature of multiple continuations of threads, though, subthreads can be used instead of them).

QDinar (talk) 12:34, 5 February 2016 (UTC)

i have discovered that "subthread for the latest post" is incompatible with classic diagonal threads, if you want to switch view to it (classic thread) and back - unfortunately, it should not be used. QDinar (talk) 14:07, 5 February 2016 (UTC)

the classic "diagonal thread" comment system/interface can be "hacked" by users, if they are in agreement, - and, the "several subthreads" can be used as a thread, and "reply" can be used as "create a subthread", but, if they do so, then that system has the "subthread for the latest post" but lacks "several subthreads". QDinar (talk) 14:31, 5 February 2016 (UTC)

the classic threads system really does not have "subthreads", it has multiple continuations of threads, and second continuation is adopted/interpreted as a subthread in the flow's new indendation model, and third continuation is not possible here in flow.

i have made an image of classic comments modified into compact form, and with multiple continuations put one behind another. see:

QDinar (talk) 05:45, 6 February 2016 (UTC)

What pages can be translated on MediaWiki?

What pages of Flow documentation on the MediaWiki provided with markup for translation? Сунприат (talk) 18:56, 3 April 2015 (UTC)

The current documentation pages, are all too large, or too out-dated, and not well-written for translation. I want to research what the "Best practices" are, but I have not had time, recently.

Do you (or anyone) have favourite pages that you wish Flow would copy? (in layout and structure and wording). Quiddity (WMF) (talk) 22:33, 3 April 2015 (UTC)

Hide, suppress, moderation (Flow/Functional_Specifications/Moderation,_Protection,_and_Refactoring#Moderation_and_Suppression, Extension:Flow/Moderation#States_.26_permissions)

Indentation model Topic:Senq838us190rqlp

Flow - Rationale, Components of the discussion system, Release and features FAQ, Design FAQ

make them as Flow/Nomenclature Сунприат (talk) 23:45, 3 April 2015 (UTC)

Ah, thank you. That helps me understand which pages (and details) you want translatable. Yes, we will try to split the large Flow page into smaller sub-pages.

But I was also wondering, are there any other extensions/pages, that you really like, at mediawiki or other wikis? E.g. I will probably use these extensions, as a model or guide: [[Template:VisualEditor Portal/core]], [[Template:ContentTranslation Portal/core]], other? Quiddity (WMF) (talk) 00:07, 4 April 2015 (UTC)

No, I do not have favorite pages, which could be taken as a model. Сунприат (talk) 03:34, 4 April 2015 (UTC)

Namespace number and contribution counter

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

Based on the script code the Theme namespace is 2600 and then Theme discussion page should be 2601. Yet I don't see it being used anywhere and usercontribs silently ignores any Flow desk/theme post as a project contribution (https://ru.wikipedia.org/w/api.php?action=query&format=xml&continue=&list=usercontribs&uclimit=100&ucuser=Neolexx) Is it a bug or by design? Neolexx (talk) 16:51, 4 April 2015 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Can i change my displayed username?

On most wikis i edit, i changed my signature (and added a DISPLAYTITLE on my user-page) to have better control over the way WikiMedia interprets my username. However, on Flow i don't seem to be able to customize the text that appears as the author of a message. Am i missing some preference somewhere, or was this just not considered? -- ~~~~

PS Where's the "preview" button? -.-

PPS Why the hell are there nowiki's forced around my message?!? Jokes_Free4Me (talk) 20:23, 5 April 2015 (UTC)

@Jokes_Free4Me: see phab:T90055 for the display name on Flow.

You can use the switch to VisualEditor to preview your comment (blergh!)

About the nowiki tags: It is because you were using the VisualEditor and tried to display 4 tilde characters (or you tried to sign your comment, which is not needed as Flow shows the author's name automatically for each comment). Helder 15:48, 6 April 2015 (UTC)

Again, why is this attitude all around?! "We don't really *need* this anymore, so let's ban its use"... BUT: the nowiki also appears if i try to use bold, italic, links, tables... Are they also not needed anymore, since we now have visual (but tooltip-less) sprites for the most of those? Jokes_Free4Me (talk) 18:39, 6 April 2015 (UTC)

Timestamps (or lack thereof)

Please could you stop using these silly pseudo-timestamps?! Let me exemplify with Media:Flow timestamps.png : They lack a LOT of information available in the usual talk-page conversations, like:

• when was the original comment made? (not the edit)
• was Sanger's reply before or after Quiddity's tangent?
• how long did it take for Quiddity to post the links for the two tasks?

Are you expecting me to hover over each of those one at a time and *remember* all the hours and minutes?!? Jokes_Free4Me (talk) 11:21, 6 April 2015 (UTC)

You might want to watch phab:T94648. Helder 15:44, 6 April 2015 (UTC)

Just me, or is the timestamp in that non-readable pm/am format?I have tried to change preference/apperance/date format to "17:32, April 6, 2015" but it doesnt seem to change anything here... Christian75 (talk) 17:37, 6 April 2015 (UTC)

@Christian75: when I hover over the timestamp it says "April 6, 2016 10:37AM", so there must be a user-defined preference intervening.

Sorry for the Green bar to the left. I think I caused that by clicking on "permalink" in the "..." menu. Ancheta Wis (talk) 00:25, 12 April 2015 (UTC)

That's actually the problem... We DON'T really accept your silly date format as a valid choice, and would wish to change it. Preferably to whatever we have set up in our "Preferences", but any non-AM/PM format (like what Christian75 suggested, "HH:mm, MMMM d, yyyy") would be a good start.

About the green bar, don't worry about that. As long as we don't use the same permalink you've accessed, complete with the anchor it provides (e.g., &topic_showPostId=sfa6qcy7pdtiuvpn#flow-post-sfa6qcy7pdtiuvpn ) we won't see it. And if we do use it, then the green bar is the expected result.

PS Now that i'm looking at Special:Preferences#mw-prefsection-rendering, the format you use ("MMMM d, yyyy h:mm am") is not even available... So, actually, my saying that is it not a valid choice was really more correct than i expected. :-) Jokes_Free4Me (talk) 01:09, 12 April 2015 (UTC)

Yep! It doesn't seems to respect our preferences. See also phab:T61919. Helder 19:04, 6 April 2015 (UTC)

Heh, apparently the behaviour changed after September 2014: back then, [quote]note that the "exact" timestamp is the only one available, after 1 month. I.e. There is no more hover behaviour, after 1 month.[/quote] -- not anymore. This definitely doesn't seem to be heading in the right direction. :-< Jokes_Free4Me (talk) 19:10, 6 April 2015 (UTC)

When you hover over the "4 hours ago", the timestamp is a link to the history page. That might be the easier way to see the chronological order of the conversation.

I don't really see the difference between the memory load required when hovering, and the memory load required when you're not hovering. Either way, you need to look back and forth between the two timestamps that you're comparing. It's just a question of keeping your mouse hovering where your eyes go. DannyH (WMF) (talk) 21:33, 10 April 2015 (UTC)

Well, that history page doesn't include what was saidchanged and where in the thread... Don't get me started on that whole "edited a comment in the current thread"!

Maybe for you it's no sweat, but ADHD is a real thing... Not trying to say that it's affecting me, but i'm not too focused either. Let me describe my current attempt: "Ok, first reply... Hovering... at 6:44 PM. Next one... Hovering... 8:37 PM. Now let's subtract. Wait, was that 6:44 or 6:34? Should i hover over the earlier stuff, or should i give up instead, since at that point in the future i won't remember this other one?". And also, "keeping your mouse hovering where your eyes go" doesn't involve only memory. But do keep threads full of dozens of replies all at "4 days ago" or "4 months ago". Actually, why bother with the number? Just have it say "some days/weeks/months ago", it's just as informative. Jokes_Free4Me (talk) 00:31, 11 April 2015 (UTC)

Automatic subscription

When a user places a post he is automatically subscribed to the topic.

Will there be for this setting as were Preferences/Watchlist/[ ]"Add pages and files I edit to my watchlist"?

Can Flow provide Echo notification not on the topic, but for every action "reply to" to His post? Or even subscribe to a separate branch in topic? Сунприат (talk) 21:02, 6 April 2015 (UTC)

We're going to be doing more work coming up to make notifications more sophisticated. I haven't seen any examples yet where there's a separate branch that's interesting enough to subscribe to separately -- can you show me one where that would be helpful? DannyH (WMF) (talk) 21:26, 10 April 2015 (UTC)

@DannyH (WMF): here's a random example: in this discussion, Risker might have wanted to subscribe only to the WMF tangent, and not the moratorium-related discussion. Jokes_Free4Me (talk) 20:07, 12 April 2015 (UTC)

Locking and summarizing

Did anybody consider locking the topic automatically after summarizing? It makes sense to me that the two actions should go together. Amir E. Aharoni {{🌎🌍🌏}} 08:28, 12 April 2015 (UTC)

Or at least indicate somehow that the topic has been summarized. Tomer A. Talk 13:32, 12 April 2015 (UTC)

See also phab:T95174#1183074]] Helder 13:56, 15 April 2015 (UTC)

Meh.. I'm stopping fixing the mess VE is doing with my messages. Sorry for that. Helder 13:57, 15 April 2015 (UTC)

Subtopics

Did anybody consider having subtopics in Flow conversations? On the classic talk pages the topic is usualy denoted using == and the subtopics using ===, ====, and so on. Does Flow offer solutions to the workflows that need it? For example: Policy change proposition, opinions for, opinions against, misc discussion. Amir E. Aharoni {{🌎🌍🌏}} 08:31, 12 April 2015 (UTC)

=== Here's a subtopic ===

So runs of '=='s to format heading levels works.

But maybe you want to have subpages (that by default aren't Flow boards) if you're trying to make structured wiki pages.

==== Here's a deeper subtopic ====

But presumably someone trying to respond to this one section would get frustrated. They could use VE to copy and paste and italicize the original text. Sort of like trying to reply to an e-mail message by selective quoting.

FWIW my biased suggestion is to make "Quote the selection in a new reply" and "Create a new topic from the selection" very easy, kind of how Phabricator's 'Quote' generates a link back like this:

>>! In T94279#1160023, @SomeUser wrote:

> (Their text)

However, my idea doesn't have much traction :)

= We can even go big with H1 =

A Flow post allows most wiki markup, even though some doesn't make sense. SPage (WMF) (talk) 09:32, 13 April 2015 (UTC)

Actually, that's the wrong hierarchy: subtopics in the usual wiki sense allow multiple replies within them, it's not that a long reply needs splitting up into parts.

Though you're on the right track with that "Create a new topic from the selection". Except: does it leave a notice in the original thread about the new one? Can the new one be embedded in the old one, e.g. in an iframe? Jokes_Free4Me (talk) 10:05, 13 April 2015 (UTC)

Non-latin user names

Hi,

My user name is in Hebrew, since he.wiki is my main project. I changed my signature to an English one in all the other wikis I'm working on. Will this be supported in flow, or will only my user name be displayed? Tomer A. Talk 13:38, 12 April 2015 (UTC)

I guess it's the latter. Can anyone comment whether this is going to be fixed? Tomer A. Talk 13:38, 12 April 2015 (UTC)

Hi תומר א., I think they think of this as a feature, not a bug ;)

I can't even say how to read those Hebrew letters, I'm only capable of Latin and Cyrillic, so I had to copy'n'paste it.

I'll try three tildes for a sig, let's see: ~~~~

And some useless software bug introduced nowiki-tags, it didn't help. Grüße vom Sänger ♫^(Reden) 15:04, 12 April 2015 (UTC)

Well, IIRC en.wiki's policy requires users with non-latin names to have a signaure in latin letters. Good luck pushing 'Flow' there. Tomer A. Talk 15:35, 12 April 2015 (UTC)

As He7d3r posted below, there's phab:T90055 ([Spike] Changing the displayed name, in Flow) that they're supposedly working on. Jokes_Free4Me (talk) 19:11, 12 April 2015 (UTC)

Thanks for the answer. Tomer A. Talk 06:37, 13 April 2015 (UTC)

There's also phab:T95759 (Auto-complete for alternate names in Flow mentions).

One of the proposed solutions, is to display both the username as usual, and any alternative name in brackets afterwards. So for example, your posts would/could be labelled as:

תומר א. (Tomer A.)

and anyone could @mention either of those names. That's the goal, at least - a technical solution hasn't been decided on yet (there are a few options, but each of them has drawbacks). Quiddity (WMF) (talk) 02:05, 22 April 2015 (UTC)

What wikisyntax is allowed here (and why not)?

I tested over in the sandbox some wiki-formating, as signing with tildes was impossible in the thread (now) just below.

Some things are possible, some get automagically nowiki-tags around them. All gets weird once you edit, as this stupid software inserts tabs or such at the beginning some lines (it's already in some phab afaik, why this simple task is still not solved is beyond comprehension).

Ah, and one other thing: There is a link called "Vorschau" (Preview) beneath this box (yes, I don't use VE but the normal editor, without any buttons), but it doesn't really gets me to a preview, it just switches to VE, that's something completely different. Grüße vom Sänger ♫^(Reden) 17:51, 12 April 2015 (UTC)

phab:T93851 is solved on beta. Helder 13:50, 15 April 2015 (UTC)

As the whole Flow thingy is beta, what's that supposed to mean? Grüße vom Sänger ♫^(Reden) 14:26, 15 April 2015 (UTC)

Sorry, it is en.wikipedia.beta.wmflabs.org. Helder 14:47, 15 April 2015 (UTC)

No SUL over there, so outside my scope. Grüße vom Sänger ♫^(Reden) 16:14, 15 April 2015 (UTC)

WTF? During the VisualEditor preview the "is solved on beta" was displayed as if it were part of the link. I choose to be lazy and not have the trouble of fixing it, then I saved my reply and... BAM! the text was not part of the link anymore... Who understands that? o.O (Is reading minds a new feature of VE? If so it could really read my mind in a few more interesting cases...) Helder 13:53, 15 April 2015 (UTC)

He7d3r: The VE link continuation bug is phab:T91285. (sidenote: As soon as we click [return/enter], it will also fix the rendering. I've been using that as a temporary workaround)

There are similar (often erratic) problems in many rich-text editors (e.g. googledocs/gmail). If I understand correctly... The few rich-text editors that have overcome this bug, have done so by breaking IMEs (thereby limiting support for non-latin character languages). VE aims to be the first to overcome this limitation. Supporting all the world's languages, makes everything exponentially harder.

HTH. Quiddity (WMF) (talk) 02:19, 22 April 2015 (UTC)

Are you testing this on a LIVE server?!

Jokes_Free4Me (talk) 19:31, 12 April 2015 (UTC)

Hmmm... "File usage: There are no pages that link to this file.", really? Well, let's link then: File:Unprintable chars now visible.png. :-B Jokes_Free4Me (talk) 19:35, 12 April 2015 (UTC)

Re: wikitext into lists, I've tried to replicate, but it worked for me at Topic:Sfwobkvp83ivotff. Are there spaces after the initial '#' characters in your test? Or, to diagnose it from another angle, is it possible to do what you're attempting in VE at all? (test in Project:Sandbox) [Ah, I've shown it to James, and he suspects this is a new bug, as it was working previously. We do need to use the toolbar button to "increment depth, then change to bulleted list") I'll look at this some more in the morning. I've almost hit 12 hours today, so it's time for dinner.

Re: the File usage item not showing up for the embedded image, I've now filed that as phab:T96808. Thanks! Quiddity (WMF) (talk) 02:53, 22 April 2015 (UTC)

1. test
2. # second (yes, i think there were spaces in there... can't remember now the exact think i was doing)
   • third
3. * and now with spaces

-- PS where's the PREVIEW?!? -.- Jokes_Free4Me (talk) 14:20, 20 June 2015 (UTC)

Problems with Flow

• linking to topics produces redlinks
• no reply-level history (that i could find)
• inserting a link makes the text input blue (as if it will be part of the link)... until you press Enter -- and then, the blue text gets cut off at the first space or hyphen
  • very limited pipe-linking -- if you want to change the whole text of the link, you better write the replacement first and then delete the target page's title, or you'll have to re-insert the link. (unless you use the button or the Ctrl+K shortcut)
    • cannot undo an "add link" action
• doesn't accept all wikisyntax
  • no signature support
  • no multi-level indenting (that i could find) -- unless for lists
  • limited (and non-intuitive) multi-level lists (cannot mix them, repeated indents and unindents create blank items unnecessarily, up and down arrows skip the no-text entries, when those are probably the ones needing more input) -- theUI should also add buttons for these actions instead of just relying on TABs and Shift+TABs.
  • cannot unindent after the colon got replaced by a blockquote... Using backspace for the below paragraph makes it part of this list item, and then it can't be moved out of the list unless via cut-and-paste.

Unintended indent... cannot be undone (unless via cut-and-paste again).

There probably are other issues too, but i'm done testing for now. Jokes_Free4Me (talk) 20:34, 12 April 2015 (UTC)

See these tasks:

• T94773 - MediaWiki colors links to some existing Flow topics as red
• T90055 - Changing the displayed name, in Flow Helder 18:32, 13 April 2015 (UTC)

Most of those wikitext issues are VE. The no signature support is intended. You don't need to sign in flow. 121.219.80.119 (talk) 09:14, 13 April 2015 (UTC)

Okay, then the MOST IMPORTANT problem with Flow is that it uses Visual Editor.

Also, the fact that i don't need something is yourthe devs' unilateral decision. The fact remains that some users want to use it, and it's been decided for them that they shouldn't. Jokes_Free4Me (talk) 10:07, 13 April 2015 (UTC)

Flow uses VE as an option (and not even as the default). You don't have to use it, just like you don't have to use it for normal editing.

Signing doesn't make any sense in flow; your posts are already automatically "signed". Having to write a signature manually is a relic from not having a discussion system and by not supporting the signature wikitext, it helps get people out of the habit of having to do it. Having special wikitext which is substituted with your signature is not a valid need. If for some bizarre reason you do want to write your signature in arbitrary locations, you can do so by writing it manually.

What is a valid need regarding signatures is the ability to customize them. Seems like unnecessary clutter to me, just like having avatars, but valid nonetheless. 121.219.247.173 (talk) 10:44, 13 April 2015 (UTC)

Okay, i'll remove the VE-related stuff. Here's the remaining list:

• linking to topics produces redlinks
• no reply-level history (that i could find)
• doesn't accept all wikisyntax
  • no signature support
  • Syntax highlighting doesn't work, despite being just fine in Talk pages. On the bright side, though, <Hiero>s and <Score>s do work!
• (noticed a new one) ULs and OLs are not using the same indent.

Posts are indeed automatically signed, at first. How about edits to posts? And who ever said anything about "having to write a signature"? We just want to be allowed to do it. And doing it manually doesn't cut it, since timestamps cannot be added manually.

PS Does the fact that after a preview (of a long post) the scroll-bar disappears (which disables the scroll-via-mouse-wheel) relate to Visual Editor or to Flow? I'd be inclined to say the latter... Ditto for the preview mode isn't WYSIWYG for when multi-level indents "reset" to "Level 0". Jokes_Free4Me (talk) 12:43, 13 April 2015 (UTC)

And when you edit a post, the timestamp is updated automatically. What else would you want to change when you edit your signature?

Of course timestamps can be added manually, you can write whatever text you like here. Is it convenient? No. But it's really doesn't make sense as a feature. When would you want to do it? At most, you could argue you want the five tilde syntax to work to allow easily writing a timestamp anywhere. But the 3 and 4 tilde syntax aren't relevant in flow. 137.147.135.51 (talk) 04:48, 14 April 2015 (UTC)

That's exactly the problem: it updates the whole post to the new timestamp, when there are quite a number of cases when the post will be clearly left in a multi-part state, and currently there's no indication about when were those parts written. Especially if a second user edits a post, and clearly keeps their changes separate from the original user's content. (I'm sure i've seen a great example of this somewhere before, but can't find it right now)

And the 3 and 4 tilde syntax will become irrelevant only after the deployment of T90055 - Changing the displayed name, in Flow (if it manages to get to that point -- there are still some unclear bits about it). So, presently, your statement isn't accurate. Also, of course the five tilde suntax should work. Why shouldn't it? Jokes_Free4Me (talk) 05:45, 14 April 2015 (UTC)

I would just reply to the comment instead of editting it if I wanted a comment to have a new timestamp. No need for multiple timestamps for a single (edited) comment. Helder 09:37, 14 April 2015 (UTC)

New bummers:

• all those stupid TABS your parser/JS/whaever adds each time a reply is edited, mess up the diff...
• Having a topic link for each entry on the topic's history page is lazy.
• Having no way to compare non-successive revisions is a PITA. Jokes_Free4Me (talk) 06:21, 14 April 2015 (UTC)

The TABs are a known issue, which is already fixed on beta Helder 09:48, 14 April 2015 (UTC)

notifications and finding new

When I get a notification I go to the page. Last time was https://www.mediawiki.org/w/index.php?title=Topic:Sexu2st74jdned37&topic_showPostId=sf7oy7og92pbs67a&fromnotif=1#flow-post-sf7oy7og92pbs67a (guess the topic), and without history its diffucult to find the new post (it will be imposible in the future when the topics gets hugh) Christian75 (talk) 18:09, 14 April 2015 (UTC)

New posts are marked with a blue line on the left Сунприат (talk) 18:13, 14 April 2015 (UTC)

Ok, thanks :-) Christian75 (talk) 18:17, 14 April 2015 (UTC)

So the link I posted shows last time I checked Mediawiki, because there are four new posts... (I think you can see it too) Christian75 (talk) 18:18, 14 April 2015 (UTC)

It would be great to have a "next unread" function to navigate forward and backward between highlighted comments with a keypress or toolbar button, to quickly skip past everything you've already seen. Diego Moya (talk) 09:48, 16 April 2015 (UTC)

Thanks for the suggestion. Filed as phab:T96948. Mattflaschen-WMF (talk) 01:53, 23 April 2015 (UTC)

No indication of topic length in the ToC

The new Table of Contents, combined with the lack of page structure brought by infinite scrolling, cause a loss of intuition about the relative length of discussions. Old talk pages give an spatial indication of the size of topics (using the number of sub-sections and the amount of scrolling in the scrollbar) which is now lost, making it hard to find the most lively topics - everything looks the same in the new ToC.

You could add some secondary notation to convey similar information. The most obvious is adding the number of replies to the right of the topic title at the ToC. There could also be some visual cues, giving more weight to longer threads - for example, adding color to topics with >5 comments, and bold typeface to topics with >20 comments or several indentation levels. Diego Moya (talk) 09:46, 16 April 2015 (UTC)

Or... the menu which currently shows "Recently active topics" could have more options, one of them to sort the topics by the number of replies, and other by the sum of the length (bytes) of the replies. Helder 17:58, 16 April 2015 (UTC)

In fact, I find it quite difficult to find the topic "New indentation and threading model" in the ToC every time i want to revisit it, despite I know it's one of the longest threads.

Topics with the most activity should be more salient; the current list of topics in the ToC makes all topics look exactly the same. Diego Moya (talk) 06:35, 4 June 2015 (UTC)

I've copied the above to phab:T99785 ("Show richer info on Flow topics at the Table of Contents"). Quiddity (WMF) (talk) 18:20, 16 June 2015 (UTC)

Thanks, Quiddity. Is it best that we post these actionable suggestion at phab, or propose them here to discuss them first and wait for someone in the team to turn them into formal proposals? Diego Moya (talk) 21:01, 16 June 2015 (UTC)

@Diego Moya: Either is ok, but I think it's best to discuss things here, for increased visibility and input from editors. Each platform has pros and cons, but Flow needs all the testing and activity (of real discussions) we can throw at it, to decide what features are most needed next, which is one of the other biggest reasons for continuing most of the discussion here :)

On-topic: I personally like both ideas. Another sorting option, and a graphical indicator in the ToC to indicate topic size, could both work well.

The sorting options would probably be more complicated, because we would have to decide what defaults to show, out of full/limited timespans, and full/limited other filtering options (such as Open/Resolved status). E.g. it wouldn't help on WP:VPT to just list all topics by a size metric.

The graphical indicator is worth brainstorming a little more... Personally, I think I'd want it to be non-alphanumerical, e.g. showing a ■ for every 10 posts in a topic, because the point is for an "at a glance" distinguishing feature, rather than having to read the difference between "10" and "70". Thoughts? Quiddity (WMF) (talk) 22:31, 16 June 2015 (UTC)

I don't like the Echo notifications

I don't really like the Echo notifications at all for the fact that someone created a new discussion on a page that I'm watching. (Why can't I have an inbox/new messages/feed yet?)

However, I really dislike the little 'x' in the notification. What it seems to do is mark that message as being read, but it feels like I'll be removing the page or discussion from my watchlist and/or Echo notifications list. Whatamidoing (WMF) (talk) 18:25, 16 April 2015 (UTC)

We're planning some work to improve the experience for Echo messages in a while.

The X does indeed mark the message as read.

@DannyH (WMF): Mattflaschen-WMF (talk) 01:49, 23 April 2015 (UTC)

Similar problems (just the fact that someone created a new discussion): I got a notification about Topic:Sg1s5cm5fffzhx58 (in preview, it linked to .../w/Topic instead of .../wiki/Topic). It happened to be an experiment, was marked with {{delete}} and:

1. maybe Flow should provide sth what Facebook does -- a notification about cancel/deletion? in that case, after the deletion, Echo would send a notification without the link,
2. does Flow support separate categories for topics? I can't see Topic:Sg1s5cm5fffzhx58 in Category:Candidates for speedy deletion, despite it was marked 3 hours ago and is still pending. Tar Lócesilion (queta) 12:46, 24 April 2015 (UTC)

Categories do not work. See phab:T94617. Helder 17:36, 24 April 2015 (UTC)

The link issue will be fixed by phab:T96492 .

Categories are supported, but only for headers and topic summaries (the latter would be used in this scenario). Hover the ... menu in the topic bar, then click "Summarize" (or "Edit the topic summary" if there already is one).

Issues with deleted pages and topics are one of the things we will look at in the future. Mattflaschen-WMF (talk) 02:53, 25 April 2015 (UTC)

Back-and-forth editing between visual and wikitext

I've been using Flow's bi-directional switching between VisualEditor and wikitext to get some tables posted today. It's pretty handy: Open VisualEditor and drag in a .csv file from my desktop. (That's one way to import a table in VisualEditor.) Use VisualEditor to delete irrelevant columns and rows. Flip back to the wikitext editor to set the class. Switch back to VisualEditor to set some cells to header formatting and merge a couple of cells together. Switch back to wikitext editor to get something that I can paste into the middle of a translated page. I like it.

However, at one point the switch ended with a blank page (something timed out? I couldn't replicate it) and the wikitext box is too small for editing a table that contains more than 100 cells (one line per cell). Whatamidoing (WMF) (talk) 21:00, 28 April 2015 (UTC)

Personally I find it annoying having to switch to wikitext before I can write my comments and have to use VE to preview it. Most of the time, when I realize I'm not typing in a wikitext field, it is already too late and the wiki syntax I wrote didn't work (usually links, as in [https://www.mediawiki.org/w/index.php?title=Topic:Sfaxltcu5v4yqj1a&topic_showPostId=sfi4gfccdkct575u#flow-post-sfi4gfccdkct575u this comment]). Helder 15:17, 2 May 2015 (UTC)

Eh... in fact, the comment above is another example of what I just said. I know the wikitext syntax, I typed it correctly, it should just work without requiring me to fix VE changes which added nowiki tags to my comment. Helder 15:19, 2 May 2015 (UTC)

Another example, where I tried to just paste the phab:link inside a double pair of brakets which I typed: https://www.mediawiki.org/w/index.php?title=Topic:Sgo3wuoyh9qjkjda&topic_showPostId=sgoiqa64hpm5dvwn#flow-post-sgoiqa64hpm5dvwn Helder 14:43, 4 May 2015 (UTC)

The wikitext editor is the default at some other projects.

Quiddity, is the editing environment in Flow going to get a 'sticky' pref any time soon? It should either be what I tell it to use as the default, or it should be whatever I finished in last time. Whatamidoing (WMF) (talk) 03:37, 4 May 2015 (UTC)

Except if last time I used the previewVisualEditor to see what my message would look like, and then just clicked on reply before going back to wikitext... Helder 14:09, 4 May 2015 (UTC)

See phab:T94956 ("VE on Flow: Don't change sticky preference if user just switches to VE for a preview") which should cover both the original issue, and then aspect that He7d3r mentions. :) Quiddity (WMF) (talk) 22:52, 5 May 2015 (UTC)

(Aside: I've changed the title from "bidirectional" to "back and forth editing". "Bidirectional editing" has a different meaning regarding bidirectional text, and I thought the topic was about that.) Diego Moya (talk) 12:42, 4 May 2015 (UTC)