Talk:Flow

Jump to: navigation, search

About this board

The Collaboration team has enabled Flow on this talk page (documentation).

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
Polentarion (talkcontribs)

Hi there. I am an WP author from Berlin, working in both the English and German Wikipedia. I am member of the German Wikipedia:Projekt Moderation, which works on a sort of facilitator's toolbox and would like to introduce and easen facilitating in WP discussions. I am interested to touch base here and connect and present our work to the group and receive you constructive feedback and suggestions.

I am an active Toastmaster and I am more about practical Rules of Order than about Software. But Software should enable and regard actual practices in the actual Wikipedia.

We already got a visual editor in article space. Most of the discussions are being led in Usenet mode based on a comparably simple editor.

Some points

  • WP talk pages in articles on recent topics tend to develope facilitation, e.g. section proposals are being proposed and integrated into lists
  • Various communities have already developed and uses different templates and structures, e.g. in opinion polls, ArbCom and featured articles.
  • Any main page section has structured discussion templates, e.g. DYK in the enWP, or SG? in the deWP
  • In ArbCom style conversations e.g. statement fields, not threads are being used. The reslut is about result, less about chat

However, e.g. in the discussion of a lede or disputed section, basic visualization techniques - like a table with the existing version, state of the discussion and a proposal - are not being used on a regular base. Third opinions often get lost. Tools to compare and keep an overview - e.g. the TOC of an article and proposed general changes to it are not being used. Usenet style discussions are so 1980ies - and hinder the introduction of new members outside of the Anorak camp.

It already could be done in a much more constructive and structured way. Practical example - see https://en.wikipedia.org/wiki/Talk:Al-Maghtas#Lede

Point is - the current usenet style tries to keep all and everything visible. Facilitating is as well about hiding, removing and sorting stuff and showing the resulting compromises. If you need the thread, have a look on the version history.

That said, any project intentending to improve facilitating WP discussions should less try to implement Facebook or LiquidFeedback but helping to easen actual needs of the community. And of cause, the actual existing practices have to be involved.

How can Flow be of help in that respect? Have you ever done a survey of existing templates and discussion patterns here? And of cause, if useful, how to implement flow e.g. for the deWP facilitation project or a user page?

Trizek (WMF) (talkcontribs)

Hello Polentarion, and thank you for your message!

Collaboration team had plans to work on Workflows. The original idea was to create a toolbox with a lot of elements, and the combination of these elements can help people to create powerful tools to facilitate all workflows and processes. It has been presented during last Wikimania. For example, with this Workflows system, you can have a poll system which counts automatically every vote and give you real time results, a deletion-proposal system where people just have to give the motive and press a button to start the process and warn everyone, and so.

Flow is a brick on that project. Indeed, we need a structured discussion system to make it possible: the way wiki-talk pages are created make impossible any relevant search, or don't give you the possibility to watch only conversations that interest you. We also need a modern interface, because in 2016 a lot of people are not used to count colons or add signature after their messages! :-D

Flow has been delayed to focus on Notifications (we will release cross-wiki notifications soon) but we will make some improvements to Flow soon after a community consultation (Flow is used on some wikis, in a very active and important way for some of them).

Concerning your project, Flow can help you in many aspects. you can use the Summary field (see the glossary) to have the two sections that you want to compare. The discussion can be done below. The indentation system can be very helpful to create digressions.

If there is a consensus from a wiki-project to try Flow for a specific purpose, please report it to that page. Someone will create a Flow board where you need it. To have Flow on a user talk page, a more global consensus is needed due to the impact of Flow on Notifications (a poll opened to the whole community for example). I can help you to set it up.

And, of course, do not hesitate to contact me if you have questions or if you need clarifications!

Quiddity (WMF) (talkcontribs)

@Polentarion Hi. Just to add to Trizek's reply, I would suggest that you wait before starting a discussion, until after Phab:T125632 is completed. This will get a clearer basis of information for everyone, and enable a smoother discussion. The timeline for that task is not firm, but it will be a few weeks, yet. We can ping you, when it is complete. Hope that helps. :-)

Reply to "Rules of order in the actual WP"
Сунприат (talkcontribs)

If a participant makes a change posts in several themes, then how to check these changes?

For example (from 20:02, 5 February to 20:14, 5 February): https://ru.wikipedia.org/w/index.php?title=%D0%A2%D0%B5%D0%BC%D0%B0:Ssjqpvx32au6o4co&action=history - How can I check all these "edited"? and it is only in one post.

Trizek (WMF) (talkcontribs)

As you point it, the history page is the best place to see all these changes. Or am I not understanding correctly your question?

Reply to "Vandalism"

How do I indent an reply to a particular post?

18
Kghbln (talkcontribs)

Is see that people have maganged to actually indent their reply to a particular post within a flow thread. However when I click on reply I end up at the initial level.

He7d3r (talkcontribs)

For posts already saved, there is no way to change the indentation. See phab:T78253.

Kghbln (talkcontribs)

Thanks for noting this. From my past experience with LQT is was quite rarely necessary to relocate a post. So in my opinion not a front burner thing to have if at all.

Sänger (talkcontribs)

This answer to the original post, that should be in the same indentation level as all other answers to the original post, is in another level, while my answer to a post down the thread, that should be one more level indented, as it's an answer to an answer, looks like it's on the same level as the original post.

You've got to plan this indentation for real discussions, not for simple two-post threads. If it's not capable of working something like a real discussion with several dozens of posts, diverse sub-threads, it's useless. It's definitely not a proper replacement of a real talk page. It's just one more step in the facebookisation, read dumbing down, of the WP.

Edith says: This looks like an answer to He7d3r, while it's an answer to Kghbln, because the indentation is fucked up.

Kghbln (talkcontribs)

So why doesn't this post end up indented?

Kghbln (talkcontribs)

Either I am too stupid which may very well be the case or I am missing something. Dunno if I should be sad or grumpy right now.

Sänger (talkcontribs)

Try to indent 1. level

Edith says: Didn't work as expected, was possible before. Something seems to have changed.

Sänger (talkcontribs)

And answer something in-between, let's see how this will be indented.

Edith says: This is at the proper indentation place, the other answers just look like answers to the original posting. definitely a bug.

He7d3r (talkcontribs)

@Sänger: see phab:T93883.

Sänger (talkcontribs)
Next level indentation.
Trying the usual colon to indent, lets see what happens.

Edith says: Lines do indent, the post doesn't. The second line (scnr) was somehow more indented as I did this edit, dunno why.

Kghbln (talkcontribs)

Seems to be bug then. Let's wait for the fix. I production this would be a near fatal bug if one cannot move particular post to a new location like in LQT but even then. Have not figured out how to relocate posts yet. Probably a matter of user rights.

Quiddity (WMF) (talkcontribs)

See the clearest explanation at I CAN HAZ IDNETATION? - which I'll try to condense down into an FAQ sized answer, next week.

Kghbln (talkcontribs)

Ah, now I get it. I guess there is something to it. Since this is breaking with classic as well as LQT talk (10+ years of habit) it will imho indeed be very important to note this change quite prominently. If people do not know this they will definitively bang their heads against a wall like I did this morning. To cut it short: The issue is not how it will be done here, but telling people that it is done differently.

Hhhippo (talkcontribs)

Agreed. I like this indentation system, but it will only work if people understand what's going on, no matter which other systems they're used to. I suggested a very similar system half a year ago, including some visual clues telling the reader which way the conversation 'flows'. Maybe they can be implemented here?

Qdinar (talkcontribs)

i also wrote similar idea suggestion, in 2009-august-26 , for livejournal comments: http://qdb.wp.kukmara-rayon.ru/2009/08/26/a-suggestion-for-threaded-comments-of-livejournal/ .

Qdinar (talkcontribs)

and i have posted 2 images with 2 comment thread models in Topic:Senq838us190rqlp 1-2 days ago, and with idea to put threads one behind another, to make comments more compact (instead of, for example, collapsing them). these are that images: File:Compact-comments.png File:Compact-classic-comment-threads.gif.

Qdinar (talkcontribs)

there is a bug report page which asks about design: " With the new indentation model (T88501), should we make any visual design changes to the way indentation looks? " : phab:T88865 , - i have posted there about need of more informative labels.

Sänger (talkcontribs)

There is a difference between answering to the last post in a thread, like I do now, and answering the original post in this thread, and now this big difference is blurred methinks. Just have to test it with another answer to the original post.

Reply to "How do I indent an reply to a particular post?"
Quiddity (WMF) (talkcontribs)

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:

Some other recent discussion:

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)

Diego Moya (talkcontribs)

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.

Buzz-tardis (talkcontribs)

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

Sänger (talkcontribs)

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.

Diego Moya (talkcontribs)

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

Oiyarbepsy (talkcontribs)

Thanks, love it. You can see all of my ridiculous testing of this by talking to myself at

Sänger (talkcontribs)

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?

Oiyarbepsy (talkcontribs)

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.

Sänger (talkcontribs)

No it's here, in the sandbox next door, just like this one.

Neolexx (talkcontribs)

If anyone ever needs it, a full Russian translation of Danny Horn's post is here.

Diego Moya (talkcontribs)

I love the new indentation style! But that's no surprise, as I suggested (at this Indentation levels thread: ) 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):

Hovering on a one-comment subthread
Hovering on a several-comments subthread
Sänger (talkcontribs)

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.

My test with some explanations
Diego Moya (talkcontribs)

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.

Sänger (talkcontribs)

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.

Diego Moya (talkcontribs)

@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 (talkcontribs)

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.

Sänger (talkcontribs)

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.

Diego Moya (talkcontribs)

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 (talkcontribs)

"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 (talkcontribs)

Arbitrary break 1

Diego Moya (talkcontribs)

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.

Hhhippo (talkcontribs)

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.

Diego Moya (talkcontribs)

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

Hhhippo (talkcontribs)

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

Diego Moya (talkcontribs)

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.

Hhhippo (talkcontribs)

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

Diego Moya (talkcontribs)

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:

And, the change after adding the new parallel post by "user H"
Hhhippo (talkcontribs)

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.

Diego Moya (talkcontribs)

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

Sänger (talkcontribs)

I like Hhhippos solution better, especially the colapsing possibilities. But Diegos is a step towards better reading and structuring as well.

DannyH (WMF) (talkcontribs)

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.

Hhhippo (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

DannyH (WMF) (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Sänger (talkcontribs)
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).

Diego Moya (talkcontribs)

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.

Sänger (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Sänger (talkcontribs)

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.

Diego Moya (talkcontribs)

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.

Qdinar (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

"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 (talkcontribs)

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.

screenshot of "top" thread
screenshot of sub-thread
Qdinar (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

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 (talkcontribs)

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:

Reply to "New indentation & threading model"

A couple of suggestions - load pattern, link editor

6
Nabla (talkcontribs)

Hi. First time user (on another thread, so really a second time user here :-). As a veteran editor this looks a lot strange, yet, it can be a good thing, both for newbies and oldies. A couple of things that I did not like, may be something to improve.

- there is a grey-wite thin moving stripes pattern that appears while saving. Very bad idea. Unless your point is to make me dizzy, in which case it works just fine :-)

- I really dislike pages that keep on loadin when one reaches what was supposed to be the end. It makes it harder to search, both with the browser functions and visually. Maybe I am getting old... but I can not get the point of that kind of pages, and it always feels weird not to have an end.

. The link editor looks quite good, it felt strange for a minute, but one gets the gtrasp quite fast, and the automatic link checking is very handy. Seems to have a little misfeature (or bug). After we hir "return" to accept the link if we keep on writing we are still editing the link text, so we need to move the cursor to the right (oh well... or I was I doing anything wrong - if so where's the hint I have missed?)

Anyway, not that bad, I've read horrors about it, yet it is not bad.

PS: Just noticed. A drop down ("style text") just for two options is maybe not the best option (unloess you are planning to add more). It currently takes just about the same space ("A" and arrow) as it woud expanded ("B" and "I")

Trizek (WMF) (talkcontribs)

Hi Nabla

Thank you for your message!

As you may have guessed, the stripes are here here to symbolize the loading time. This design is used on other tools, like VisualEditor. I hope you'll get used to it :)

Concerning page loading, it was planed for reading only. A search system was planned but is not developed. Do not hesitate to push for it if you think it is a good idea.

If you like the link inspector, you may be happy to learn it the the visual editor one. :) Have you tried VE? When you want to edit the link label, there is a blue background around. hit right arrow on you keyboard to exit.

I note you suggest to have more options on the style dropdown and, most important, that Flow is "not bad". Thanks! :)

Nabla (talkcontribs)

The Visual Editor was apparently horribly bad the few times I used it, long ago. I will not touch it again even with a very long stick :-) Early release may be good, you may get a lot of beta testers and a lot of input, but... I actually like to chase bugs and propose features, *when and if I volunteer*, I dislike a LOT being *forced*. VE was rolled out on the main site way too soon (Flow still not bad, stripes still not good :-)

Nabla (talkcontribs)

PS: Search function. I am pushing. :-) You write on a high traffic page (or wait a while to get there), how do you find your old message? Or how do you find user:whatever's messages? If you can not easily find messages on a messaging system... something would be terribly wrong. No?

Off topic bug report and feature question - too lazy, not looking where to report: I tried to log in (why does the SUL does not work here?). I received an error message saying I could not log in because I had cookies disabled. That is weird because on a second attempt, changing nothing, the log in was accepted (ok, fine, maybe a bug on the browser?... IT is a beta.) The bad thing is: although I was not logged in in after the first try, my notification messages showed up. Will anyone failing a log in in some user's name get to see their notifications? That would be not good. Really not.

Keegan (WMF) (talkcontribs)

There have been issues with the login system the last week or two. The issue with cookies should be fixed by now.

Trizek (WMF) (talkcontribs)

Haha! I understand your fear about VE! :D But it has changed. A lot. Trust me, you should give it a new chance. ;)

I note you push for Search function. We have a short list of features which are pushed by users: search & filters, tags, move topics to an other board and a kind of inbox with all messages.

Concerning SUL, it works on mediawiki, like on all other WMF wikis. I sometimes have this kind of cookies' message, with notifications which showed up: actually I was logged in for real, but the cookies error message displayed a non logged-in message with a non-logged-in interface. I ping @Keegan (WMF) who worked on SUL. He will help you better than I can do.

Reply to "A couple of suggestions - load pattern, link editor"
Сунприат (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:
***
││***
││***
│***
│***
***
***
Tucvbif (talkcontribs)

bump

Quiddity (WMF) (talkcontribs)

Thanks for the ideas and feedback (both). :-)

There has been a lot of feedback that the current indenting system is a confusing mixture of the main external standard systems. The team is planning to re-examine the indent system, in the future. (Currently they're focusing on Echo/Notifications work). For now, I've added this topic to the (incomplete) list at Flow/Prior discussion-thread-roundup#Indenting Levels.

Diego Moya (talkcontribs)

Hi @Tucvbif, the last time we discussed indentation we arrived to a model that I illustrated with this post.

It was a combination of your "reversal indentation" and "separation rule" solutions, where a second direct reply to a comment would push one level up the the previous thread of replies to that same comment, but this would happen only once per level.

I called that "Dynamic style", and at this later thread I posted an example of how it works with the content of a real conversation. I think that model best respects the expectations of experienced editors (having a real tree of comments), while avoiding deep threads for most conversations. If work on indentation is ever restarted, I'd like to explore that model.

Reply to "In Flow lacking logic breaks"
Aryan hindustan (talkcontribs)

How can we sign?

Tropicalkitty (talkcontribs)

Click on the [[ ]] box, and then use four tides to sign.

Jdforrester (WMF) (talkcontribs)

You don't need to sign, and shouldn't. It's part of the point of Flow. :-)

This comment was hidden by Tropicalkitty (history)
Reply to "How can we sign?"
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.