Talk:Structured Discussions/2014/09

The Core Features 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 Bugzilla 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.

Unable to see the subject of a new topic

On watchlist, I can see the title of the section (or the name of the topic, in the system used on Village Pump of ptwiki ), but in Flow notifications I can't. It just says "<someone> created a new topic on <somewhere>", and since the URLs are confusing, I can't use the hover on "new topic" to get that info either. Helder 15:54, 1 September 2014 (UTC)

Helder.wiki: Filed as bugzilla:70290 —TheDJ (Not WMF) (talk • contribs) 13:56, 2 September 2014 (UTC)

And bugzilla:63713 to get navpopups working. :) Quiddity (WMF) (talk) 17:38, 2 September 2014 (UTC)

"Edited N ago" ----> rollover to "Edited <timestamp>"

Right now "Edited N ago" becomes "<timestamp>" on rollover, just as the time of creation does.

That's slightly confusing: clearer would be to leave "Edited" at the start on rollover. Sj (talk) 21:37, 1 September 2014 (UTC)

Sj: Reported as bugzilla:70289 —TheDJ (Not WMF) (talk • contribs) 13:52, 2 September 2014 (UTC)

The "page" and "history" tabs appear but are non-functional on Talk:Flow page when using the Monobook skin

At the top of this page, the "discussion" tab is the only one I can click on. The other two tabs are visible but can't be clicked on.

OS X, Chrome 36.0.1985.125 Sj (talk) 21:41, 1 September 2014 (UTC)

Sj: And most importantly. You use monobook :)

In monobook, pagetabs indeed do not seem to work.. Reported as bugzilla:70288 —TheDJ (Not WMF) (talk • contribs) 13:49, 2 September 2014 (UTC)

TheDJ: Yesss, thanks for the catch. Somewhere someone is expounding on the upkeep of heterogeneity. Sj (talk) 01:08, 3 September 2014 (UTC)

Modern?

Re:"Flow is a project of the Core features team at the Wikimedia Foundation to build a modern discussion and collaboration system".

This system doesn't look very "modern" to me at all! Over half of my 1920 by 1200 monitor is filled with nothing but white space. What it brings back to memory is working in 40 columns on my Commodore 64. This will set Wikipedia back in time to before the world wide web even existed. Wbm1058 (talk) 23:32, 1 September 2014 (UTC)

Past discussions; a redesign should be done soon -- it's in the plans I believe. Gryllida 22:38, 2 September 2014 (UTC)

Thread display mode for single thread view

In single-thread view, Flow appears to follow whatever thread display setting is set on the board - even if it's set to compact. This is not very sensible, I think. It could make more sense to default to a full mode in single-thread view, and I don't even see any sense in supporting anything else there. Gryllida 00:29, 4 September 2014 (UTC)

That's a very good point. I'll bring that up with the developers. It doesn't seem like it would be a difficult change, and you're right, it's the only sensible thing to do. DannyH (WMF) (talk) 00:31, 4 September 2014 (UTC)

+1. Helder 03:14, 9 September 2014 (UTC)

This should be almost finished. https://trello.com/c/NdRgfEAO/ or https://gerrit.wikimedia.org/r/159246 Quiddity (WMF) (talk) 02:19, 11 September 2014 (UTC)

זה ניסוי כדי להדגים את התמיכה מימין לשמאל

הטקסט הזה should be on the left וזה מימין Matanya (talk) 09:20, 4 September 2014 (UTC)

וזה כדי לראות איך נראית תשובה that with שתי שפות Eitan96 (talk) 13:07, 4 September 2014 (UTC)

Flow in Monobook, 2014

You know, LiquidThreads looks better. (Though it looks better even without that bug anyway.) — Keφr 16:31, 5 September 2014 (UTC)

Idea's OK, but there are usability problems

I came across Flow by accident intending to comment on another Wikimedia page. I've been fiddling about with it for about ten minutes now, so I'm probably fairly close to the sort of person you want to encourage to comment more - someone who can just about remember basic Wiki markup, but who doesn't edit regularly. I use a modern browser with Javascript turned off

There seem to be some usability problems at the moment:

• There's no indication of what (if any) wiki markup code you can use in a comment. The only thing that indicated it could be used at all was links in a few comments.
• There's no preview facility, so I've no way of knowing whether this is going to look right (except writing it in a sandbox and pasting the markup into the comment box - which I'm not likely to bother doing).
• You can't see a whole discussion on a single page. (I tried to alter the URL to get the next 10000 comments hoping it would stop when it ran out, but it just gives an error. Of course, a "Load all" button would be better.) I suspect this will lead to lots of comments that say much the same thing, that were written in good faith because the user simply didn't see that someone else had already made their point. (This may be true of the whole of this post!)
• It doesn't seem to allow for differences in people's signatures - which is the sort of fault that's going to cause controversy among the experienced users. Considering the comment authors already have a rollover on them, how about using the user's standard wikitext signature for the normal display and adding the username in a standard format to the rollover text?

TL;DR: it's OK for casual conversations, but for serious discussions it needs improvement. 86.179.194.211 (talk) 18:31, 5 September 2014 (UTC)

Unless you have deactivated the JavaScript, you should have the preview.

I think this feature should be available even without JS. — Ltrlg (talk), 08:52, 7 September 2014 (UTC)

Hi IP - I'm glad you found this area, then! The goal of this is to improve it before it's rolled out, as this is not ready yet. We need this feedback in order to make this tool better, so thanks :) Keep checking back on this as it iterates, and if you would like to keep giving feedback the product team working on this would be grateful. Rdicerb (WMF) (talk) 01:26, 8 September 2014 (UTC)

Assortment of Flow Bugs I've found

Hey Flow Team, just been testing Flow a bit and wanted to show some screenshots that illustrate some errors or unexpected issues I came across. Some of these are not-so-critical, but others probably are:

Above,we have an error at the top when I tried using the hiero template. Perhaps unrelatedly, the pad template was not available for use, probably because it's unrecognized on MediaWiki here.

---

In the above images, the first image shows some bizzare behavior when attempting to center an image amongst justified images. The expectation was to show images directly beneath one another with text clearly denoting the type of image below it. The second image shows the text I used.

---

The first above image shows, in preview, that the ISBNs that do not use hyphens are unrecognized automatically, but that ISBNS with hyphens and piping them with a book titles are recognized. However, they cannot be put into text on Flow, as shown by the error in the second image.

---

The score HTML tag works in preview (image 1), but an error is produced when trying to post it. (image 2)

---

I start writing a summary for the summarize function (image 1), attempt to preview it but nothing shows up (image 2), and post it (image 3) where it is correctly posted nonetheless.

---

Using the syntax highlight HTML produces a bizzare error preventing me from posting.

Sorry that this is a lot, but I wanted to get it all out there at once. Thanks! I JethroBT (talk) 07:02, 6 September 2014 (UTC)

and the media viewer doesnt work together with flow? Christian75 (talk) 08:20, 6 September 2014 (UTC)

Not sure what you mean by that. The images from that one set are all just the same image I chose. I JethroBT (talk) 10:37, 6 September 2014 (UTC)

If I hit one of your images it isnt displayed with Extension:MultimediaViewer like images from normal wiki pages are. Christian75 (talk) 17:40, 6 September 2014 (UTC)

Christian75 (talk) 17:39, 6 September 2014 (UTC)

wm-l msg 1

quote from wikimedia-l this week

On 5 September 2014 13:29, Wil Sinclair wrote:

This somewhat circuitously brings us back to the subject. We have a chance to rollout Flow the right way. There are some questions that come to mind that might tell us if we're headed for a big win or a bigger debacle:

1) Is the WMF working with the community as closely and substantially as possible to make sure Flow is ready for primetime?

2) Is the community preparing itself for a major change, not only in interface, but to some degree in wiki-philosophy about how discussions are conducted- not to mention the notion that, while wiki software can do almost anything involving asynchronous online communication, it can't do everything as well as other interfaces?

I think Flow will be particularly challenging. I deployed Liquid Threads on another site. I liked the threaded interface, as did others. But overall it was roundly rejected because it was harder to search (I only found out you have to add the namespace to the searchable namespace in LocalSettings.php later), and it invasively took over all discussion pages, among other headache. Problems like these could easily be addressed before a rollout, but they should be addressed as early as possible. It is notable, however, that the more our users used it, the more they seemed to like it.

What can we do to make the Flow rollout as smooth as starting now?

,Wil Gryllida 12:35, 6 September 2014 (UTC)

wm-l msg 2

Quote from wikimedia-l this week 6 September 2014 3:58 AM

---

I think there have been some pretty strong indications over the years that the current talk page system needs to be improved. However, there's been little discussion at all about whether Flow is that improvement. I have been following the development for quite a while, and it really looks like the system was developed backwards: essential functions for effective discussion that already exist and are used on a daily basis were not included in the initial designs, while the design incorporated plenty of bells and whistles that were considered desirable (although the reasons for desirability weren't necessarily universally held or particularly clear). This has resulted in a huge amount of re-engineering to incorporate (some of the) needed functions , and a lot of downplaying of the feedback given because the feedback has conflicted with the "bells and whistles" of the original design. There is also the fact that it would add another completely different user interface to the editing process, which increases barriers for existing users but even more so for new users.

In other words, the issues with Flow are so deeply rooted in its core design and philosophy that it may not be possible to come up with a product that is actually useful on the projects we have to replace the discussion system we have. It seems that the Flow team has assembled the ingredients to make a chocolate cake with the hope that it will be a suitable replacement for vegetable stew.

Risker/Anne Gryllida 12:36, 6 September 2014 (UTC)

I'm trying to give helpful input in other comments, but yeah.... I'm seriously worried that the whole Flow design process came at this backwards. They're building a beautiful Facebook chat board with neat chat board features, then trying to implement "bugfixes" to kinda sorta support editing work. Alsee (talk) 10:41, 7 September 2014 (UTC)

Flow failure case

Let me demonstrate a rather Catastrophic Flow fail with an example taken from recent article work I was involved in. Rather than nuke this message board, I'll link you to a test Flow board where I posted it:

Example: Flow Fail

Here's the Article Talk page that the example came from. That table is BIG, but the Talk interface is perfect. You can view that table exactly as it would appear in the article. You can view the entire contents of the table just by slowly dragging the browser scroll bar down. Or using just a mouse wheel. Or by simply clicking the scroll bar several times going down page by page. Or similarly by tapping the PAGE_DOWN key several times. In Flow that table is mangled beyond recognition because the Flow "low density interface" is too narrow for editing work. Trying to view that table in Flow means battling the interface. Fully viewing the table contents in Flow requires anywhere from fortyish to several hundred mouse-actions, constantly switching between the browser vertical scroll bar and the Flow's horizontal&vertical scroll bars. Try it, and count how many separate mouse actions it takes to view everything, row by row. And don't overlook that you have to Flow-scroll-right to see the text column on the right.

I haven't be able to find up yet what scratchpad is supposed to be... maybe that table should have gone inside a scratchpad? I have no clue. Was scratchpad planned to be full width? (Matching current Article and Talk Width)

Support that table, at full width, with multiple people editing it. If you want Flow to replace Talk pages for editing discussion and work, that's what we need. A collaboration and work system, not just a beautiful message board.

Alsee (talk) 12:37, 6 September 2014 (UTC)

With or without flow, I think that table would be better placed in the sandbox, where it would not pollute the talk page. In the talk you just need to add a link to it. More than one user can edit a sandbox page, if the table is supposed to be edited collaboratively until you get a final version. Helder 13:54, 9 September 2014 (UTC)

I just double checked the page, no one gave any indication that they thought it "polluted the talk page", or in any way commented negatively on it's presence. Considering that it was the center of an RfC, I think everyone considered it valuable and expected that it was immediately visible. Alsee (talk) 20:01, 9 September 2014 (UTC)

That's a good example, thanks. That is really hard to work with. I think part of the problem there is the indentation -- it looks like that table is being treated as if it were the "full width" of the Flow margins, but the indentation is then pushing the display to a smaller width, so you get the horizontal scroll bar.

I know that it's not a very satisfying response when I say "we're going to have to think about that", but it's probably better than making up an answer just for the sake of an answer. So... we're going to have to think about that. Thanks for pointing it out. DannyH (WMF) (talk) 17:30, 6 September 2014 (UTC)

Edit: Clarification the problem is that "full Flow width" is ~55% of "full Article/Talk Width". It's because you're imposing a low density design.

I deliberately posted it with indentation to amplify the effect, but it was still rather bad when I tried it with no indentation. With no indentation Flow still gave an annoying-but-mostly-harmless horizontal scroll bar. (It went left-right only a few characters in distance.) The table was still badly squished, and viewing the full contents required:

Carefully use Flow scroll bar to go down 8 pages.

Switch to using browser scrollbar. Jump down 1 page. Switch back to flow scroll bar.

Carefully use Flow scroll bar to go down 9 pages.

Switch to using browser scrollbar. Jump down 1 page. Switch back to flow scroll bar.

Carefully use Flow scroll bar to go down 8 pages.

-------

I'm good with "we're going to have to think about that" as reply, as long as you're taking it as important :)

Many of us are concerned that you guys seem focused on building a beautiful social message board. We need a work area. On Mediawiki and Wikimedia you guys seem to use the system mainly as a discussion board for discussing on off-wiki content (i.e. software). That's the use case a lot of you are most familiar with. For us Wiki is the work area, and Wiki content is what we're working on. Wikitext makes for a rather lousy discussion forum, but the fact that Article_space = Article_work_space = Community_areas is very powerful for us. If the goal is for Flow to replace article Talk pages then people are going to have very high expectations for Flow as a work space.

I have some related concerns, but I'll start a new thread later. Alsee (talk) 10:22, 7 September 2014 (UTC)

For a long time we have being using wiki pages do do many things which are better handled by other systems (seriously, users from non-Wikipedia WMF wikis know that very well), and while Flow is supposed to be a better system for one of these things (discussions), if we try to use it for something it is not designed for, we can't blame it for not being a good system for that.

Flow won't stop us from continuing to use wiki pages (like sandboxes and personal test pages) for the task of creating and improving collaboratively a draft version of something (a table, a template, a gadget). IF we need a better system than wiki pages for those tasks, then we should request a new system for that, not to expect that Flow will be the solution for them. Helder 14:12, 9 September 2014 (UTC)

But talk-pages of articles are sandboxes of those articles as well, the syntax implemented there has to work for this purpose, otherwise it's got to be thrown away as not fit for the job.

The current flow is just capable of dealing with blabber pages, not article talk pages. Those kind of pages are by no way essential for creating an encyclopedia, they are at best "nice to have" in some certain areas off-sight. Grüße vom Sänger ♫^(Reden) 15:39, 16 September 2014 (UTC)

wm-l msg 3

Quote from wikimedia-l this week

---

6 September 2014 6:48 AM

IMO the WMF should stop focusing on English Wikipedia as a target deploy site, and stop allowing its product management team and WMF staff in general to be salesman for it - it is scaring the community that all WMF staff seem to be so heavily vested in this 'product' as the salvation of the wikis.

Risker's assessment of the design problems is spot on. As such, a typical WMF-style big bang deploy of Flow is going to be the most almighty bang the WMF has ever seen. And the community is rightly worried that 2015 is going to be the year that WMF forces Flow onto the projects using its typical deploy methodology.

Start development of a rollout plan, and gain consent from the communities on that rollout plan.

After rollout on MediaWiki has stablised, Meta-Wiki should be high on the deploy list, as should any wiki which has LQT enabled by community request. Until discussion-focused wikis, such as Meta, universally

• likes* Flow, trialling it or rolling it out onto any

'work'/content-focused wiki without community consent is silly. Until it is satisfactorily deployed onto at least one non-English language content project, it shouldnt be deployed onto English Wikipedia, as it is safe to assume that the design will be too English Wikipedia specific, and will fail badly on non-English projects, becoming another WMF tool which looks nice on English Wikipedia but other projects cant have it because it is designed wrong.

Allow project level opt-out of the Flow rollout plan. Focus on the projects that want it, and find/employ community advocates with the necessary language skills for the projects at the top of the rollout plan. They need to start work *now*. They need to document existing project workflows, talking with bot operators and site admins especially when developing a migration plan. Bot and gadget software will need to be re-engineered *before* the deploy.

-- John Vandenberg

---

Gryllida 12:38, 6 September 2014 (UTC)

wm-l msg 4

quote from wikimedia-l this week 6 September 2014 9:55 AM

---

FWIW, ironically the tangled discussions about MediaViewer across multiple pages have made me think that having a more organized way to read discussions would be a good idea. My understanding is that this is one of Flow's objectives. If Flow can achieve this in a way that is helpful and non-disruptive then I think Flow may save power users time because we may be able to follow multi-page discussions easily. I would appreciate it if Flow helped with that. Of course, the design, implementation and testing need to be done carefully, and I hope there is heavy community involvement in reviewing Flow long before it gets sent to the largest and most sophisticated wikis.

Pine

---

Gryllida 12:39, 6 September 2014 (UTC)

the below

I've dumped a few quotes from wikimedia-l below, as they appear to potentially contain some actionable feedback. I've put them here so that the Flow folks get them. I've not processed it though, myself; I'm in the middle of fixing some hardware and software which should take a few days. Gryllida 12:46, 6 September 2014 (UTC)

Notice that there is nothing "below" when a topic like this is viewed on its own page (e.g. by someone which clicked in the Echo notification icon). It is better to post links to the specific topics you are mentioning. Helder 14:57, 9 September 2014 (UTC)

Where's the contents box, to see what's already been written

I fail to see the content box at the top, how am I supposed to know where something I'd like to write about has already been written about?

This question has been asked probably as well some time before, but it's nowhere to be seen. I's tried the toggle button up right, that switches between threads, short threads and just headlines, but as the headlines are far too huge, that's not that usable as well, far too much scrolling.

I also miss sub-headlines, that structure discussions on WP-pages, where are they?

Just saw something else:

I clicked on prewiew in the "Headline only" view, and my post was hidden as well, what's that supposed to achieve? "Preview" should always show the whole post, not just the headline.

And another missing feature: Where is help for layout tags? OK, I know that ''' makes somthing bold, but that's in no way userfriendly. Grüße vom Sänger ♫^(Reden) 17:09, 6 September 2014 (UTC)

By "help for layout tags" do you mean the help section from WikiEditor's toolbar? Helder 14:55, 9 September 2014 (UTC)

I mean the buttons on top of the editing field, and/or the clickable wikisyntax below that, the stuff that is there on a usual editing page. This here is sub-optimal, only usable with a lot of former knowledge.

Theere is no toolbar at all, no hints for wikisyntax at all, there's just a plain box with no help at all. Grüße vom Sänger ♫^(Reden) 11:03, 13 September 2014 (UTC)

Notifications for new topics totally uninformative

Example: "Reaperman created a new topic on Talk:Compact Personal Bar."

Problem: Well, nice that you tell me a specific user created a new topic on a board that I'm watching, but the essential information – what is the title of the newly created topic??? – is simply missing!

Solution: Think about what you're doing and present the user with useful information instead of drowning him in useless noise... Patrick87 (talk) 23:13, 6 September 2014 (UTC)

Agreed. This is quite frustrating. Honestly, while Flow works quite well in general, its notifications and watchlist support is quite bad. Jay8g (talk) 00:34, 7 September 2014 (UTC)

See bug 70290. Helder 14:59, 9 September 2014 (UTC)

Edit button placement is inconsistent and therefore unintuitive

Prerequisite: Somebody thought it would be a great idea if the "edit" button was easily accesible for every post – therefore it is positioned directly besides the "reply" button.

Problem: The natural way to edit a post is to look into the action menu of the post – were "edit" is simply missing. This is also where "edit title" is placed and would increase consistency. Placing a button that edits an existing post next to a button that will create a new post is unintuitive.

Solution: Don't try to make each and every action directly accessible you deem useful to the user but think about where to place it intuitively – Wiki users are not dumb and if they want to perform an action on a post (edit it) they'll find and use the actions menu as sure as hell! Patrick87 (talk) 23:19, 6 September 2014 (UTC)

I like this idea. Jorm (WMF) (talk) 01:29, 7 September 2014 (UTC)

+1 agree. Putting EDIT inside the ... makes great sense. Editing a post is a special action. Alsee (talk) 10:45, 7 September 2014 (UTC)

+1. Helder 15:01, 9 September 2014 (UTC)

You raised a good point, indeed. Klipe (talk) 14:49, 28 September 2014 (UTC)

Preview for new topic not working

Problem: Preview for new topics is not working since ages (at least it feels this way). It worked before but got lost in some update to Flow in the past.

Solution: Fix preview function for new topics! Especially on creating a new topic, preview functionality is essential. Patrick87 (talk) 23:24, 6 September 2014 (UTC)

I'm not seeing this in Firefox 31/Windows 7. What OS and browser are you using? Jay8g (talk) 00:37, 7 September 2014 (UTC)

Ah, I figured out what is happening:

I have set topics to be shown collapsed. When clicking preview, the preview is created, but the topic is in the collapsed state. Therefore the actual post content of the preview which is meant to be shown is not visible.

Quite confusing if you ask me... Patrick87 (talk) 01:00, 7 September 2014 (UTC)

Thank you for pointing this out -- I saw a couple of those reports, but wasn't able to reproduce. This may be what's happening for other users as well. Definitely confusing. Erik Moeller (WMF) (talk) 06:45, 7 September 2014 (UTC)

What is Scratchpad?

I see one mention of scratchpad in the roadmap but I have little idea what it's supposed to be, what sort of capabilities you have planned for it. Alsee (talk) 10:54, 7 September 2014 (UTC)

If memory serves me right, it's supposed to be a canvas of free-form wikitext that appears at the top of topcis and/or boards, so that it can held any kind of content that isn't fit for Flow comments.

It was not very detailed because it's not clear yet what its use cases would be. Diego Moya (talk) 16:40, 9 September 2014 (UTC)

If I remember well, it was also supposed to be an area for collaborative editing, as opposed to individual posts/replies that can be edited only by their creator. However, this current restriction is just a setting and may still evolve in which case the notion of scratchpad may become less relevant from that respect. Klipe (talk) 14:52, 28 September 2014 (UTC)

At one stage it seemed that Flow might not support advanced markup such as mathematics and so a scratchpad would be required for any form of collaboration: see Talk:Structured Discussions/2013a#c-Jorm_(WMF)-2013-08-18T19:22:00.000Z-Spectral_sequence-2013-08-18T19:16:00.000Z for example. Deltahedron (talk) 18:24, 28 September 2014 (UTC)

By the way, for added comedy value, see Talk:Structured Discussions/2013a#c-WhatamIdoing-2013-08-21T21:06:00.000Z-Spectral_sequence-2013-08-18T19:57:00.000Z a short way down the same thread. Deltahedron (talk) 18:29, 28 September 2014 (UTC)

Public chat boards

Currently virtually no one posts on our message boards unless they have a genuine interest in collaborating on the Encyclopedia. If our Article Talk pages were replaced by Flow, a lot of those pages are going to get flooded by people wanting to fight over the topic itself, rather than improving the article. Is that an issue you've considered? We already have difficulty functioning when activists flood in on hot controversial articles. Have you looked at the possibility that hot message boards could get swamped to the point that we effectively can't use them? Alsee (talk) 17:17, 7 September 2014 (UTC)

1. Currently virtually no one posts on our message boards unless they have a genuine interest in collaborating on the Encyclopedia. that is your assumption @Alsee: or hypothesis, it could be a nice research topic;
2. If our Article Talk pages were replaced by Flow, a lot of those pages are going to get flooded by people wanting to fight over the topic itself that is your conclusion @Alsee: . Currently a lot of talk pages are flooded by people fighting over the topic itself. That is my, and probably slightly distorted observation.
3. We already have difficulty functioning when activists flood in on hot controversial articles. that is a statement confirming my observation. Activists do flood in on hot controversial topics and articles. That doesn't depend too much on the software provided.
4. Have you looked at the possibility that hot message boards could get swamped to the point that we effectively can't use them? The short answer is Yes. My guess is one of the reasons people got thinking about redesigning talk pages was based on their observation that hot message board get swamped to the point that we effectively can't use them. In the current state of Flow there are some experimental features like the possibility to hide posts, threads, close topics, and summarize topics.

• Empathetically writing: yes it can be very annoying that certain users flood certain talk pages who in your view don't constructively contribute. Would it be worhwhile to consider a system of settings per user for following and unfollowing messages from certain other users, maybe even on a page, article, topic level of granularity? There is already a possibility to block certain users.
• There will always be hot controversial articles and topics, independent of the chat system in use. We have to work together to remain calm, polite, friendly and respectful.
• The current long form editing poses a huge barrier to entry and to participation. The aim of Flow is to drastically reduce that barrier. So yes, do expect boards to get swamped. However, it is more of a community issue to deal with in my opinion than a software issue. Raising the barrier to entry will not eliminate hot controversial topics in my opinion.
• Dear @Alsee: , what are your suggestions how to deal with people who flood talk pages on hot controversial articles and topics irrespective of the chat system in use? Ad Huikeshoven (talk) 08:42, 12 September 2014 (UTC)

You assumed/asserted I was hypothesizing. No. For purposes of our discussion here, Flow is equivalent to Liquid. They are "Chatboards" rather than wikitext workspaces. We have existing projects with public Liquid pages, wikinews for example. The population on chatboards, the usage of chatboards, the behavior on chatboards is, is very different than on Talk pages. People on wikinews refer to the Liquid chatboards as "trollspace". The only way they get any work done is by ignoring trollspace and doing their work on Talk pages.

Currently a lot of talk pages are flooded by people fighting over the topic itself.

Not the same way people argue and fight on chatboards. A large proportion of people who engage in general editing share the ideal of putting neutrality and productive collaboration ahead of their personal views on an issue. They view themselves as part of a community, and they willingly make significant efforts to hold their behavior to a high standard. We have an environment that promote those social norms. Those who are less idealistic still assimilate those social norm, and understand and respect the community processes to support and enforce those norms. They try to abide by those expectations because they know it is expected, and because they need to. It is relatively uncommon that sanctions need to be applied against disruptive individuals, and when sanctions do need to be applied it is often very costly in community-man-hours (for good reasons).

Activists do flood in on hot controversial topics and articles. That doesn't depend too much on the software provided.

Chuckle. Try putting a chat board next to the articles for Democratic or Republican Party, or Fox News, or evolution, or abortion topics. 99% of people posting there won't care squat about neutrality or collaboration or building an encyclopedia or idealism or good behavior. Their only interest will be in arguing the subject, or demanding that the article be re-written to glorify their side and to attack the opposing side.

experimental features like the possibility to hide posts, threads, close topics, and summarize topics

People on opposing sides of an issue will wildly conflict on which posts to hide and close, and anyone who has their post hidden or closed is going to scream CENSORSHIP! If people aren't hearing each other, collaboration is impossible, consensus building is impossible, stable article development is impossible. And summarizing topics only works if the people doing it exhibit an extraordinarily high level of impartiality, and it only works if substantially all participants have already adopted a very high standard of respect for collaborative-results-they-dislike. In the current community we have achieved that standard, to a reasonably good approximation. But there's no way that's gonna fly on a generic public chatboard.

Would it be worhwhile to consider a system of settings per user for following and unfollowing messages from certain other users, maybe even on a page, article, topic level of granularity?

Only if your goal is for Wikipedia to go up in flames. Ignore people who can make conflicting edits to the article is catastrophic. A core element of collaboration is that people need to listen to each other, even when they intensely disagree with the other side. They need to listen, even when they feel the other side is being unproductive. Consensus building is impossible if people start muting or ignoring each other. That just makes people angrier. That just provokes wildly conflicting and damaging edit warring of the article.

There is already a possibility to block certain users.

Yes, and it is only invoked at substantial cost and only after persistent and indisputable behavior problems. Heroic efforts are expended to avoid the slightest appearance that anyone gets hit merely because they have an unpopular view on some topic. That is utterly indispensable to support an atmosphere of collaboration and neutrality.

We have to work together to remain calm, polite, friendly and respectful.

Public chatboards are notorious for promoting the exact opposite. There are two types of chatboards - opens ones where contentious topics turn into flamefests, or hivemind chatboards that use some sort of moderation to silence unpopular views. Neither is compatible with a neutral Encyclopedia.

do expect boards to get swamped. However, it is more of a community issue to deal with in my opinion than a software issue.

I'm telling you the community does not have the volunteer-man-hours to handle it, and even if they did, the process itself would be toxic to collaboration and neutrality.

Raising the barrier to entry will not eliminate hot controversial topics in my opinion.

I never asked to raise any barriers. I merely said that replacing Talk pages with Flow is incompatible with maintaining current article pages... unless you have some solution that no one else has mentioned yet.

suggestions how to deal with people who flood talk pages on hot controversial articles and topics irrespective of the chat system in use?

We have a system that currently works acceptably well. However I don't know of any magic wand that will suddenly make the whole world suddenly put neutrality and collaboration ahead of their personal beliefs. Alsee (talk) 20:44, 16 September 2014 (UTC)

Interesting concept, Alsee (can I ping you yet within Flow? If not, I'm sure it's in the plans. If not...I'll lobby for it :) )

So when you say that Flow will increase disputes, I'm curious as to why you think so. I am not challenging your concern, but I'd like some reasoning to better understand the communities.

I know there's a "hide" feature but I just un-hid something. I'm sure that's a very early-stage example and I know that admin tools need consideration, but I would love to learn more about your concerns about arguments. Thank you for your help with this!

(side note: I see I can also Edit, and just added this sentence to my post.) Rdicerb (WMF) (talk) 00:56, 8 September 2014 (UTC)

I was actually coming here to edit a better explanation into my post :)

Use case: My personal Experience attempting to assist on EN:Expelled:_No_Intelligence_Allowed. This was a Hot article. This movie was a big event in the social conflict between evolution and creationism. Using my Neutral Point Of View voice here:

• This movie was widely described by Movie Reviewers a propaganda film.
• This movie was widely described by Scientists as a propaganda film.

This movie was pushing a conspiracy theory that Evil Scientists were persecuting creationists. The movie was basically a Call To Arms for creationists to wage war on this issue. A huge number of angry people viewed that article... people who have no interest in building an encyclopedia... people who merely want to fight a battle... people who merely want Wikipedia to promote their side of a social battle. We were mostly protected from the firestorm. People with no interest in collaboration on an Encyclopedia had never taken the time to learn how to disrupt the content of the page, never learned how to jump into our discussion areas. None the less, the discussion area still became a toxic environment. The discussion area became a battlezone between Good Editors trying to properly (neutrally) develop the article, and people battling to win the evolution-vs-creationism issue. I jumped in wanting to help protect the article from agenda-warriors. I knew it was a HotZone, I was fully prepared to take heat from disruptive editors. What I was not prepared for was having my head bitten off by an otherwise Good editor who should have been an ally. The agenda-warriors created such a toxic situation that good editors hit the breaking point and started attacking other good editors. Not only was I put off from helping in that article, I was largely driven off from editing at all.

Use case2: I saw another editor commenting on how things work on boards with Liquid (I believe it was Wikinews). They have the article page, they have a Wikitext Talk page where the community does their work, and they have Liquid which they call "troll space". This person was specifically recounting how (for example) neonazis show up to rant on the Liquid pages. These are people with no interest in productive collaborative work. Their only interest is to rant on their pet issues. If they did try to edit.... well I assume you can see how Neonazis re-writing news stories to their liking might not be viewed as desirable, chuckle. The way editors get productive work done is by staying on Talk pages and ignoring the public-chat Liquid boards.

Now imagine merging those two cases. You have a public chat board, and that public chat board replaces Talk pages. On any Hot topic, the boards are going to be flooded by people who have no interest in collaboration, people who merely want to rant or battle for their pet-issue. I'm sure some of you find it stressful with heated comments from a handful Community members posting here - now try to imagine the general public using this message board the same way people post Youtube comments. This message board would become unusable.

I am all in favor of making it easier to get more people into the Good-Editor community. I'm just trying to warn you that if you simply put up a Youtube-style chat board on all our pages, then the general public will use it like a youtube chat board. I'm concerned that situation would be.... I think the phase is "a critical block to workflow". Chuckle.

Actually, to be more specific, my post was a question. I wasn't ranting or attacking or criticizing. I was sincerely asking whether this kind of thing had been discussed during your design and planning? Alsee (talk) 05:31, 8 September 2014 (UTC)

Rdicerb, I just realized that you probably aren't familiar with my use of "Neutral Point Of View" (NPOV) in my last post. In Wikipedia NPOV is a big thing. NPOV means that I'm not giving my opinion about the movie. We aren't supposed to put our personal opinions into encyclopedia articles. When I said "This movie was widely described by Movie Reviewers a propaganda film", that is a neutral objective fact supported by Verifiable sources. When I said "This movie was pushing a conspiracy theory that Evil Scientists were persecuting creationists", that was my personal description of the movie. Editors on opposite sides of the issue will never agree whether the movie was filled with Truth or Lies, but we can (eventually) agree on the fact that many movie reviewers and scientists called it propaganda. Alsee (talk) 10:01, 8 September 2014 (UTC)

I aslo just discovered diffs! https://www.mediawiki.org/w/index.php?title=Topic:S1wcwqem224dxoi0&action=compare-post-revisions&topic_newRevision=s1wnonxv3phl7azm

(Added later)

Oops - I meant that I discovered the Flow diffs :) Rdicerb (WMF) (talk) 00:57, 8 September 2014 (UTC)

Grin. Welcome to the world of Wiki!

Check out this diff. Someone had asked:

I have, in fact, already created a draft page. By the way, how do you get editors to collaborate on your article? Writing Enthusiast (talk) 02:51, 6 September 2014 (UTC)

My edit was:

I have, in fact, already created a draft page. By the way, how do you get editors to collaborate on your article?" Writing Enthusiast (talk) 02:51, 6 September 2014 (UTC)

I linkified "draft page" for you. I assume you won't mind :) Now this entire section serves as an advertizement for anyone interested. (additional advice) Alsee (talk) 15:59, 7 September 2014 (UTC)

Note that part of my edit was to edit his post! I could have put that link in my post, but I was showing him the answer to his question. The way to invite collaboration is to just linkify "draft page" to point to your draft, along with the request for help :) Alsee (talk) 09:41, 8 September 2014 (UTC)

this is the diff you wanted to refer to @Alsee: . Flow doesn't allow editing comments by someone else. Some people still like the idea that on talk pages you shouldn't edit comments by someone else. Flow implemented that idea. In Flow your answer could be: post a link like this one: w:Draft:Zorin_OS and ask people to collaborate by way of advertisement. Ad Huikeshoven (talk) 08:08, 12 September 2014 (UTC)

I think the concept of people flooding comes from how easy it is to add a new message. Gryllida 05:22, 8 September 2014 (UTC)

Alsee: Your thoughts on flow moderation notes are welcome, as are anyone else's, really. Gryllida 05:38, 8 September 2014 (UTC)

Alsee, thank you for bringing this up, and I do see your points - if I'm reading you correctly, it's that updating the system and making it easier and faster to post content will simply bring in more volume which will heat up already heated pages.

The Core Features team has been considering the abuse and moderation factor and will continue to consider it, and we definitely need community feedback where this is concerned. Gryllida, thank you for the moderation page - many good ideas in there and I hope that others can add to them. I've worked in abuse mitigation and community moderation so I'll think on this and post some ideas if I think of anything worth considering. Rdicerb (WMF) (talk) 00:25, 9 September 2014 (UTC)

I'm not really talking about volume of comments, although that is related. I'm saying the usage of the message board will be fundamentally different. For example Republicans and Democrats will show up to argue politics. They have no interest in building an Encyclopedia. To the extent that they edit articles, or comment on article development, they will do so as warriors dedicated to spinning the article to favor their political team. They will do so as warriors dedicated to using the article as an attack page against their opponents.

When that sort of thing happens within the community it is extremely disruptive. However current participants are almost unanimously dedicated to developing the Encyclopedia as an Encyclopedia. We are almost unanimously dedicated to the an extensive set of principals on how to do that. One of the core principals is NPOV - Neutral Point Of View - core ideal that editors need to put neutrality ahead of our personal views on a topic. It takes time for a new editor to become a good editor, to learn how to collaborate, to learn how to apply a Neutral point of view, to learn what Notability is, to learn what Reliable Sources means, to learn No original research, to learn What Wikipedia is not. And a far far more. These are the things that prevent Wikipedia from becoming a scribble board. These are the things that ensure collaboration. These are the things that ensure article contents are valuable and respectable.

The current situation is that Talk pages are used by a community that shares the WMF's mission. They are used by a community with a special interest in Noble volunteer work improving an encyclopedia. Editors joining the community are not yet familiar with the things I linked above, but in general they share that vision. When I first read the policies linked above I thought yeah, that makes sense, those things are vital to making this an encyclopedia, that is how I want to build the encyclopedia, those are the policies I would have put in place if I had thought of it first.

From what I hear, on Wikinews the way they get work done is by ignoring the Liquid chat board. The commenters on the Liquid chat are motivated to argue the topic itself, to the extent they want to "edit" they have no desire to do so collaboratively. They simply want to advance their personal agendas.

I'm all in favor of making it easier to for people to join the Encyclopedia Anyone Can Edit. I have no fundamental opposition to putting great message boards next to the articles. I'm just trying to say that you can't do that and imagine that it will be used the same way Talk pages are used now. People will use it the same way they use other internet chat boards. I don't see how productive editing could be done in the same place thousands of people are arguing over the topic. I don't think that simply adding moderation tools will solve that. The amount of moderation labor required would be enormous, and furthermore anyone getting hit by moderation will become enraged and become more disruptive.

I'm still trying to pose this as a question rather than an argument or criticism or anything.... I'm trying to ask if the WMF has thought about this sort of thing. Alsee (talk) 06:09, 9 September 2014 (UTC)

Oh, no worries :) - I'm not reacting to your concerns as an argument or criticism (constructive criticism is certainly OK) - but your consideration in reiterating that is really appreciated, thank you!

I don't work on the Flow team but I'll raise this as a conceptual conversation.

"From what I hear, on Wikinews the way they get work done is by ignoring the Liquid chat board. The commenters on the Liquid chat are motivated to argue the topic itself, to the extent they want to "edit" they have no desire to do so collaboratively. They simply want to advance their personal agendas." - this is an interesting observation. Obviously Liquid threads is not used on most systems, so whether I could point to the culture of Wikinews vs. the particular features used there contributing to this can vary depending on one's perspective, but in this case let's go with considering that it's the feature that causes the need to ignore the threads. I'll point that out to Danny, the PM for Flow. Rdicerb (WMF) (talk) 21:45, 9 September 2014 (UTC)

I think you followed my point, but just to clarify, I was equating Liquid to Flow. They are the kind of common message boards that a random internet commenter will post on. Newbies who look at editing the Encyclopedia see Wikitext. If they have a genuine interest in editing, then picking up the minimal basics of Wikitext and using it on talk pages is zero-cost for them. If someone isn't going to edit articles then they're not going to edit Wikitext Talk pages either. Alsee (talk) 18:14, 10 September 2014 (UTC)

Yeah, it's definitely a question that's at the heart of this project. As we work on Flow, it is absolutely our team's responsibility to make sure that the feature encourages and facilitates productive and collaborative wiki conversations, and doesn't encourage foolish or time-wasting conversations.

There are some subtle distinctions in designing discussion software, which can have a big impact on the kinds of discussions that are encouraged. The simplest example is whether comments are presented in chronological or reverse chronological order.

In a single discussion thread (like this one), displaying the comments in chronological order creates a conversation between the participants, as we're having here. It encourages thoughtful response, and creates the expectation that the person that I'm speaking to will be back to read my response. If the posts are displayed in reverse chronological order -- as they are on many news and blog comment sections -- then that design encourages knee-jerk reactions, just a string of single comments rather than a conversation with a beginning, a middle and a successful resolution at the end.

I would challenge the idea that we have to put artificially high barriers in the way of people who want to participate and be a part of the encyclopedic work. I agree that in order to have a successful, productive community, new people need to learn the norms and values of their new colleagues, as anyone does when they enter a group. But the way to do that is to give people tools that allow them to speak to each other, learn from each other and keep growing as a community. Signing with four tildes was never supposed to be an intelligence test that we use to keep stupid people out. Having interesting, thoughtful and productive conversations is the thing that brings smart people in. DannyH (WMF) (talk) 23:52, 9 September 2014 (UTC)

yep. we have a reader versus editor divide here. saw some of the same thing in reader feedback tool. it would be nice to have a teahouse group to mediate with new readers leaving threads so that we can explain the wiki-culture. there are a lot of folks used to facebook, and comments sections, who may not understand the encyclopedia purpose, and policy. Slowking4 (talk) 00:55, 10 September 2014 (UTC)

I'm not saying we should put artificially high barriers in the way of people who want to participate. I'm saying that, for entirely natural and valid historical reasons, talk pages have been used by people motivated to build and collaborate. That is the environment that Wikipedia was born and flourished in. I don't see how you can put up a generic internet chat board and expect the average internet poster to behave any differently than they do everywhere else.

Having interesting, thoughtful and productive conversations is the thing that brings smart people in.

Right. Internet chat boards are notorious for being thoughtless and unproductive. Wiki discussions do have their low points, but on average they are miles above general internet behavior.

Signing with four tildes was never supposed to be an intelligence test that we use to keep stupid people out.

Agreed! One comment I keep seeing over and over again, so many people wishing that instead of Flow that you'd do stuff like adding default signatures in talk areas. That would take a HUGE source of stress off of newbies, and it would be a nice convenience for us all. (Implied: it would be trivially easy to turn off signatures when the edit was not itself a comment. Either give a check box, or separate comment and edit buttons.)

---------

I think one of the things that has helped build a collaborating community is when people see how easy it would be to abusively edit other people's comments. It quickly comes to mind that it would be a bad idea, that it would be socially unacceptable. It's very rare for anyone to need to be told this. They immediately see a powerful example of social norms - abusively editing other people's comments would be disruptive - don't be disruptive. There's a social expectation that people's comments should be treated with respect, and the people making the comments should be treated with respect. They see a community where we built something amazing, where we work together productively, where people work hard to live up to high standards. And people decide they want to join that, they want to be like that.

But I see a much more fundamental difference in Flow. The community essentially has one workflow. That is:

We build stuff out of Wiki.

Wiki is our clay. We organically build articles out of it. We organically build our talk pages out of it. We organically build all of our workflows out of it. The Flow design is trying to mimic our individual workflows, but there is nothing organic about it. Fundamentally you are talking away the world we have built out of clay and trying to put in metal hallways that resemble our existing structures. No matter how much you round off the corners, it's still a metal cage. It's a set of rules and constraints written in code and imposed by a top-down authority. We can't build there, we can't collaborate there, will we be able to survive there? It's the very antithesis of community values: we collaborate as equals in an extremely anti-authoritarian way. You can submit to authority, you can fight authority, but it is impossible to collaborate with authority. Our only authority is community consensus, and it is a noble ideal to submit to community consensus. Can you take away the Wiki-clay world we've built, which is such a central part of who we are and how we work, and expect that the whole world on a generic internet chat board will suddenly start engaging in productive discussions and collaboration? Alsee (talk) 17:03, 10 September 2014 (UTC)

I think that in a lot of ways it's actually "we build stuff out of blank pages". It's absolutely true that people have made extraordinary, civilization-transforming things out of blank pages. But I don't think that means we have to live on blank pages all the time.

There's a world of workarounds, templates, hacks and bots that have to exist in order to support building everything out of blank pages. I don't really see the difference between SineBot and having software that automatically signs and dates your message.

There is a lot left to build before Flow is ready to actually deliver on the dozens of promises that have been made about it :) -- but I think the current state of the product is supporting this interesting, thoughtful and productive conversation that we're having right now.

I saw that you replied because of the notification, which brought me here, and highlighted the new message. Then I had a reply box to post my response. I don't think that the system of "get a watchlist email -- click on the third link in the email to open the diff -- scan down to find the new message -- hit section edit, add signature, save" is superior in any way to the experience that I've just had in the last few mintues. DannyH (WMF) (talk) 18:18, 10 September 2014 (UTC)

I don't really see the difference between SineBot and having software that automatically signs and dates your message.

I was saying SineBot is awful. New people show up, they see a community of people with norms of social behavior, they want to fit in. And along comes SineBot putting a big ugly flag on their head. Default signing would take a BIG stress off of newbies. I've seen many people making the complaint that the WMF is constantly doing big unwanted stuff "because you want to want to make newbies more welcome".... but you won't do the simplest little thing we DO want you to do which actually would help.

The bad SineBot experience is related to what I was saying about people wanting to fit into the community. When people step into a clearly new and different social situation there is a strong natural inclination to want to fit into those social norms. When a newbie comes along they are immediately immersed in world built from the bottom up out of collaboration. The fact that the newbie can edit the entire page - including other people's comments - is a powerful experience of who we are, how we work, and how people are expected to behave in our society. Newbies immediately start behaving surprisingly well. Stepping into Wiki is a very obvious step into a very different world, and people start behaving better. It's what keeps Wikipedia from burning up in one colossal flamewar.

But I don't think that means we have to live on blank pages all the time.

If you want to foster a community of collaborators and builders, you have to give them tools to collaborate and build. We don't have to live on "blank pages", but pages that aren't blank need to be built from clay. Give us better tools and we'll build better stuff. It needs to be bottom-up clay, not top-down metal. It's in our DNA to build and reshape our home. It's the very essence of Wiki.

You discussed how Flow is superior to Wikitext:

I saw that you replied because of the notification

Notification are great, whether it's Flow or Wikitext.

brought me here, and highlighted the new message

I think it would great to use color or something to highlight new Wikitext (keeping a diff button handy).

scan down to find the new message

It would be great if a notification jumped you directly to the new/modified Wiki text.

add signature

Default signature is possibly the #1 easy-to-do thing that people have been asking for.

I realize that a Reply button for Wikitext presents problems, but suspect it would be possible to make something that puts the cursor in the right place with the right indentation most of the time, and which will get it right essentially 100% of the time when virtually all comments start getting made using it. (and when it's wrong, we can just edit.)

You could to everything above to improve the discussion experience without any pushback (or outright revolt) from the community.

There is a lot left to build before Flow is ready

I've very much been taking that into account. I'm trying very hard to be positive and productive and look at what it could become. But everything about it screams "backwards". The idea is that you're building a collaboration system, right? Flow currently has zero support for anything collaborative. The only collaborative aspect is scratchpad. When I asked what scratchpad was, the answer I got was that you guys had no clue. It's top down instead of bottom up. It's metal instead of clay. Pretty metal walls still makes for a cage. And no matter how good the intentions... it feels like WMF is treating the community like common users on some commercial social networking site.

the current state of the product is supporting this interesting, thoughtful and productive conversation that we're having right now

There is an implied existing relationship here (community and WMF), and firmly established community expectations for discussions and collaboration. The community makes heroic efforts to collaborate. I assure you that if the WMF had the general public posting around here with 1/10th the level of concern, your message boards would be lavapits. And this brings the topic full circle. Putting Flow boards on Wikipedia would create lavapits. I don't see how we can work in a lavapits. It's very disconcerting that the WMF seems to be either unconcerned or blindsided by this. Alsee (talk) 11:27, 11 September 2014 (UTC)

Rdicerb, Alsee: You said heated discussions are a problem when it's easy to post. I would like to remind you, again, of the moderation notes I had collected; specifically the +/- button should be of interest. This is how Reddit moderates their posts (where not only heated topics attract audience, but the whole site is built in a way that encourages people posting comments to up their reputation — and this site needs to handle a lot of noise along with the drama). Gryllida 04:03, 11 September 2014 (UTC)

I'm saying people with no interest in productive collaboration are disruptive. I'm saying that we painfully get by when a few disruptive individuals get involved. I'm saying that collaboration will be impossible if collaborators are overrun by warriors. Yes, this is all intimately related to the fact that Talk pages are currently inconvenient to use for people who have zero interest in how to edit articles. I just want to be 100% clear about where my point lies. And all along I was asking if the WMF had considered this in their planning. The answer seems to be no.

I would like to remind you, again, of the moderation notes I had collected; specifically the +/- button should be of interest.

And I remind you that I commented there three days ago. Yes, the +/- button idea was of great interest to me. I replied that it was extremely toxic to collaboration. Maybe I didn't give a sufficient explanation of why it was toxic. It implements a system for a majority vote to silence (or ignore) a minority. It promotes groupthink and win/lose combat. That is utterly fatal to collaboration. Implementing a +/- button will turn Wikipedia into a schizophrenic version of Conservapedia. Articles will be used as free fire spin zones, with the direction of the spin being controlled by whichever side can call in more warriors. Alsee (talk) 12:31, 11 September 2014 (UTC)

Ah. How would you suggest moderating flammable nonsensical comments then? Gryllida 23:49, 11 September 2014 (UTC)

As an alternative, we could introduce comments namespace, and move all unproductive comments to that. There should be means to move them back to a talk page where they are considered collaborative. (Such comments namespace would have to have the +/- to filter out stupidity.) Just a thought. It's a complicated subject. Gryllida 23:52, 11 September 2014 (UTC)

You see, easy feedback is collaborative, but when made really easy, it will inevitably get 80% of noise like most edits do. A mechanism to control the noise while leave it reasonably available and reasonably transparent is something to think about early. Gryllida 23:53, 11 September 2014 (UTC)

BTW, about diminished visibility: I expected to have 3 sorts:

1. freshly added,
2. recently active, and
3. ones that have higher "score".

They'd remain visible in the other two sort things. Gryllida 00:02, 12 September 2014 (UTC)

How would you suggest moderating flammable nonsensical comments then?

Everything about Flow looks wrong and backwards to me. I made a good faith effort trying to to see what Flow was all about, trying to give productive input on some things in case this gets deployed. On this particular point I was asking if the WMF had considered this issue. I was asking if the WMF had some solution planned that I hadn't thought of. When I point out a fatal problem it's not fair to expect me to supply magic beans.

Requirements:

1. Keep the noise and flames to a manageable level.

2. Avoid Conservapedia-style partisan domination.

3. Promote a collaborative atmosphere.

I'm sorry, but I'm not aware of any solution that meets all three criteria without some degree of self-selection. Currently there is effectively zero cost to join Talk pages for people with a genuine interest in contributing. They're learning Wikitext anyway. These people tend to have an above average interest & personal investment in community values. I also believe the Wikitext discussion environment itself promotes collaboration.

Currently, people who are primarily interested in fighting for their pet cause generally find it more convenient to fight elsewhere.

The current system works because there is some degree of self-selection in participation.

I don't see what weapons you can arm the community with to silence a noisy mob, which won't also set those weapons lose to silence and alienate collaborators with annoying viewpoints. And then they cease to be collaborators.

And don't forget, anything that does silence a noisy mob is just going to infuriate them. They're posting on an open discussion board. Any moderation of their posts will be viewed (by them) as some abusive jackass censoring them. Alsee (talk) 04:53, 13 September 2014 (UTC)

Editing other people's comments - a new angle?

I was looking at the archives on this subject. In a nutshell, community members felt it was intensely important that the community have control over this configuration setting, and even to my ears their arguments sounded very fuzzy, supported by minor corner cases at best. The WMF position was that being able to edit other people's posts was an alien concept for most message board users. Both sides seemed open to experimenting with it, the strong conflict was who gets to make the final decision on it. A particular comment struck me, basically saying the WMF intended to make the final decision, and that the final decision apparently was that editing would be locked off unless someone demonstrated a technical workflow blocked by that configuration.

On one side the community comments failed to give any clear reason why they felt it important for the community to have control, on the other side the WMF basically asserted dictator control and disregarded that nontechnical issues could matter.

Thinking about this, I think I have a new insight. By any reasonable standard Wikipedia should have failed. By any reasonable standard, an encyclopedia that Anyone Can Edit should have turned into a scribble board. The reason Wikipedia works has little to do with any technical details. The reason Wikipedia works is primarily sociological. If you look on any other website, people on opposite sides of significant social issues inevitably descend into endless flamewars. On Wikipedia we (mostly) avoid that. You can't achieve that by technical means, that is a purely social phenomena. We have found a way to get people to engage in collaborative work and consensus seeking.

On Wiki it is trivially easy to engage in all sorts of malicious behavior editing other people's comments. However it is extraordinarily rare for this to become a problem. There is a strong social taboo against editing anyone else's comment in any way that might be perceived as deceptive or malicious. A newbie might be shocked to discover that they have the power to edit other people's comments - but that shock is going to come with the realization that maybe it would be a bad idea to do that. It's going to make them stop and think about the power they have, and that they need to exorcize some restraint in their own behavior. It teaches people that they are expected to respect other people's comments, and maybe it helps teach them to apply more respect to the people making those comments. The fact that we can edit other people's comments sends a powerful message that we're here collaborating, that we don't engage in that sort of behavior. In the rare case that someone does abuse the power to edit other people's comments, that person gets a strong social message that that sort of behavior is Not Acceptable. Either that person gets the message and learns to collaborate (a good thing), or that person repeats the behavior and we expel them from the community. The fact that people can so easily abuse editing other's comments makes it a GREAT red flag. It's a cheap easy way to identify and expel those who are unable to collaborate productively (a good thing). Alsee (talk) 07:06, 8 September 2014 (UTC)

I believe the folks (don't speak for the entire community, please) have two simple use-cases -- need to sign a post accidentally submitted as an IP, and need to refactor talk pages. Admittedly an expectation of good faith from whoever edits my comment has to play some role, too.

Partly this anyone-can-edit philosophy cultivates a 'peers' and 'working all together', 'collaborating' culture. Wiki was invented as a fun way to collaborate online in the first place. Having a select group (sysops, say) who can edit others' messages (and do so as a routine) doesn't fit into such peer-to-peer directed philosophy very well. Gryllida 12:07, 8 September 2014 (UTC)

I didn't intend to "speak for the community". When I said "In a nutshell, community members felt.." I was attempting to summarize my impression of the particular arguments I had just been looking at in that archive. I was trying to say that I could see why the WMF involved would be baffled at the intensity of the argument. I just thought my comment above might be an interesting new angle. Note that I didn't argue for anything in that post... or at least it wasn't intended to be presented as an argument. I just thought it was a striking new idea on the subject. (Or at least it was new to me)

Maybe I would have been better off presenting the thought without describing the lead up that inspired it. The archive on the subject was contentious, and I guess any description of it would tend to be provocative. Alsee (talk) 14:48, 8 September 2014 (UTC)

I think that "need to sign a post accidentally submitted as an IP" would impossible under Flow; what would be needed would be to (at least hide, if not delete) the initial built-in "signature" (identifier), and preferably to replace it with the user's "signature" (identifier). Arthur Rubin ^en.Wiki (talk^en.Wiki) 15:42, 8 September 2014 (UTC)

I've been wondering about this recently, because at Wikimania someone mentioned to me, "often my second action at a talkpage, will be to log-in, and sign my accidentally-anonymous post."

But, surely this would be possible, as the software could just match IPs. -- If I understand correctly: the database knows what IP a logged-in user is using, but that info is only revealed to human checkusers on an as-needed basis. But is it available to the software anytime? We could (I believe) have a button on Flow topics/posts, for anyone whose current log-in matches a recently posted chunk of content from an IP.

I.e. If I accidentally make a logged-out post, and then log-in, that post would now have an extra line saying:

"Was this your post? Claim this post (transfer the contribution to your account, a logged-action), or request an Oversight action."

Maybe it could be restricted to a limited time (eg. only 2 minutes after posting).

However, I'm possibly not thinking of some obvious problem with this idea, such as how it could be misused by shared-IPs ? Not sure. Quiddity (WMF) (talk) 20:11, 10 September 2014 (UTC)

Excellent thought. If feasible, the also question remains as to who could see the old "signature". Perhaps Oversighters?

Although I tend to agree with Fram that this system is never going to work properly, it's nice to know that you (WMF) are considering some of the serious problems. Arthur Rubin ^en.Wiki (talk^en.Wiki) 00:25, 14 September 2014 (UTC)

I think that a more general solution would be helpful: if your account has been logged out (at least during the last day or two–this is something that checking cookies ought to be able to identify), then pop up a large, blinking warning saying "Guess what? You got logged out when you weren't paying attention!" and give people a chance to login before saving their contributions. The oversight teams would doubtless be grateful to stop the flow of requests due to people's login sessions expiring while they're typing their messages. WhatamIdoing (talk) 19:15, 16 September 2014 (UTC)

Gryllida, thanks for the second paragraph edited into your post. I find it rather frustrating that the three other people replying here failed to even acknowledge the subject of this thread, and bittersweet consolation that even your reply required an edit to do so.

Edit: This reply system is unusably ambiguous. My reply to Gryllida looks like a reply to WhatamIdoing or maybe to Arthur Rubin. A whopping 8 comments in this thread and already it's gone into total failure mode with no way to tell what is replying to what. Alsee (talk) 15:08, 18 September 2014 (UTC)

Do I get this right? Your answer was to this post by Grydilla?

It definitely looks anything but. Could be WhatamIdoing, Arthur Rubin or Quiditty, or even the former post by Arthur Rubin or your own one, but never the one by Grydilla.

And why was I asked "Do you want to leave this page?" once I hit the "Save" button? I don't want to leave, I just want to save, for fuck sake.

Test to edit this one again. This time everything went smooth, strange. Grüße vom Sänger ♫^(Reden) 15:49, 18 September 2014 (UTC)

Alsee: There will be good news coming soon, regarding Editing other people's comments.

Sänger S.G and Alsee: There will be changes at some point, for this currently-limited-to-3 number of indents. Danny wants to change it, but they can only change/fix/add/update so many elements at a time. :-/

Sänger S.G: I've been trying to reproduce that "do you want to leave" bug (bugzilla:70586), but cannot. Please could you confirm, if you're only seeing it after you follow a link from a notification (i.e. with "&fromnotif=1" in the URL)? Also, what Operating system and browser and skin, are you using? That info should help the developers narrow down the problem. Much thanks, and sorry that it's frustrating to encounter. Quiddity (WMF) (talk) 20:25, 18 September 2014 (UTC)

This is a test for coming here from notifications.

There was no such bug here, and also not after I edited this post.

For info: I'm on a MintMate 17 Live-CD with FF31 Grüße vom Sänger ♫^(Reden) 21:04, 18 September 2014 (UTC)

Replying to: Do I get this right? Your answer was to this post by Grydilla?

Correct, I clicked reply on Grydilla's comment, and the reply system craps out. It simply dumps new posts on the end with max indent.

P.S. It's utterly gross that I needed to type-out what post I am currently replying to. Alsee (talk) 15:09, 19 September 2014 (UTC)

I'm testing the indentation. This reply is to Gryllida's message (beginning with the words, "I believe the folks (don't speak for the entire community, please) have two simple use-cases").

Update: Well, that worked correctly for me. I clicked the 'Reply' immediately under Gryllida's message. WhatamIdoing (talk) 22:40, 22 September 2014 (UTC)

Testing. This reply seems to be getting zero indent. I'm not sure if there has been a bugfix or I somehow botched my earlier reply to Gryllida. This is marginally better, but most places to reply in this thread still leave it ambiguous who the reply is to. Any reply to Arthur Rubin, or any reply to a post in the third column, all look like they land in the same spot. Alsee (talk) 04:40, 26 September 2014 (UTC)

well, implementation

i think one option is to make flow + VE opt-out on mobile & app, so it will be a parallel experience. the community can stay on desktop with their old talk pages

you could also migrate flow functionality onto the notification channel. add a reply button, or discuss button for thank button. (and a pop up for opt-in VE) this would have parallel channels for discussion.

this would encourage "flow" late adopters to opt-in without needing a vote.

you can add thread functionality to notifications allowing sorted threads, work flows

this implementation plan would minimize the chance of AfC drama, since existing experience is unchanged, newcomers are sent to forked mobile site; they get an opt-out better interaction experience.

also new devices get interaction suited to their touch screen, tablet.

so you would have editable talk on talk pages, and non-editable on notification/flow threads

technical overhead is larger, since duplication of functionality. Slowking4 (talk) 00:42, 10 September 2014 (UTC)

Having parallel, disjointed, article discussion on Talk pages and Flow pages would be a problem. You'll get nothing but edit wars if two people (or two groups of people) don't see each other's comments. Trying to automatically copy Flow comments into Talk pages would be crude and fragile to breakage, and trying to automatically copy Talk comments into Flow is even worse. Alsee (talk) 17:52, 10 September 2014 (UTC)

well, you would be noticed in notifications / flow, and could respond on talk page. talk would feed flow. the parallel experience would be people talking on notification / flow, which talk page only users would not see. similar to the IRC experience. less disjointed than current experience. and i don't know about others, but i really don't read my talk anymore, there's nothing collaborative there, merely warning template spam. Slowking4 (talk) 01:02, 25 September 2014 (UTC)

No way to view old topics?

In previous versions of flow, scrolling down loaded one set of older comments, and you could load even more by clicking a link at the end of the page. In this version, there's no link and there's no automatic loading, making more than two previous topics inaccessible without using the history page. Also, I'm pretty sure more than two topics were shown by default at a time before...

I also got this nice error when posting: http://i.imgur.com/IiVdrnd.png 110.148.190.247 (talk) 07:59, 8 September 2014 (UTC)

The posting time said "-14 seconds ago"...

Also, when I went to click on this reply box, it just opened the single topic view instead of opening the reply box, once I reloaded the page it worked correctly. 110.148.190.247 (talk) 08:01, 8 September 2014 (UTC)

Couldn't reproduce any of the bugs reported. Infinite scroll works for me. Gryllida 12:05, 8 September 2014 (UTC)

Infinite scroll only works for me (right at this moment) if I reach the bottom, scroll up a bit, then scroll back down. It might be a bit buggy at the moment. Rdicerb (WMF) (talk) 18:43, 8 September 2014 (UTC)

Infinite scrolling only works if I don't change the sorting, which I have to change every time since it doesn't save.

Also, JS features don't work on additional content from scrolling, new posts and changing sorting. 110.148.190.247 (talk) 08:50, 9 September 2014 (UTC)

Indicate that moar topics are loading

A gif with fallback to "Loading…" probably? Lazowik (talk) 16:27, 8 September 2014 (UTC)

Current status on Flow/Echo changes

We released a new version of Flow/Echo code to enwiki earlier than we should have. There are bugs, and features that aren’t fully cooked. I’m sorry that we pushed this out too fast, and created some irritating distractions that got in the way of people’s editing work.

Having read lots of feedback and seen the reported bugs, we talked as a team about whether to roll back the latest version, or move forward with bug fixes and retuned features. Rolling back would probably cause more problems than it would solve -- some of the reported bugs are already fixed on Mediawiki, so we can get things on enwiki fixed faster if we deploy those, rather than roll back to a week ago.

Our plan is to backport some more fixes to Mediawiki later today, and if those are stable, then we’ll move them to enwiki tomorrow afternoon.

Meanwhile, there are two things that you can do if you’re finding the current system too distracting right now:

• There is and will be a lot of testing done on the test/sandbox boards. If you’re getting bothered by notifications to those boards, it’s probably a good idea to stop watching them for now.
• You can also turn off Echo notifications for Flow in your preferences. (There’s still one bug that shows up even if you’ve turned them off -- it’s in the list below.)

Here’s the current status, as I know it right now.

The following items are planned for Mediawiki later today, and then enwiki tomorrow:

• Make the Alerts tab the default when you open the flyout, unless you’ve only got new Messages notifications and no new Alerts.
• Email notifications bundled per topic, limited to once every four hours.
• Bundling “created a new topic” Echo notifications, so you don’t get multiple notifications for the same board at once.
• “No formatting for notification” errors displayed in the notifications flyout.

Other bugs we’re fixing, but may not be out tomorrow:

• If you’ve never had Flow notifications, don’t make the Alerts link clickable.
• Swap the color of the Messages and Alerts tabs, so the clickable link is blue. The active tab shouldn’t be clickable.
• Monobook: Can’t hide topics, because the modal dialog is grayed out.
• When you create a Flow topic and mention a user in the first post, that user gets two identical notifications.
• With Flow notifications turned off in preferences, a mention on a Flow post still sends a notification.
• Monobook: Messages/Alerts text in flyout is too small.
• Monobook: Page tabs are not clickable on Flow boards.
• Monobook: Watch star on Flow boards is in the wrong place.

There’s a balance between responding to questions and actually getting fixes and features tested and out -- so we might be slower in answering some questions. We’ll keep everybody updated as much as we can, and we really appreciate all of the feedback, ideas, and bug reports. DannyH (WMF) (talk) 20:12, 8 September 2014 (UTC)

Okay, it's the end of the day -- here's the list of fixes that are on Wikimedia.org now. Assuming it still looks stable tomorrow, these will get pushed to enwiki tomorrow afternoon (PST):

• Alerts tab is the default when you open the flyout, unless you’ve only got new Messages notifications and no new Alerts.
• Bundling "created a new topic" Echo notifications, so you don’t get multiple notifications for the same board at once.
• "No formatting for notification" errors are reported, but not displayed in the notifications.
• When Flow notifications are turned off in preferences, user doesn't get notification for Flow mentions.
• Email notifications bundled per topic, limited to once every four hours.

The other items listed above are still being worked on, and the plan is to get those out later this week. Thanks to all of the people who've posted bug reports, and I apologize for the distractions and inconveniences with this release. DannyH (WMF) (talk) 01:40, 9 September 2014 (UTC)

I would really like to see user mentions redesigned. They should not clutter a message contents. Please. :-) Gryllida 01:54, 10 September 2014 (UTC)

Missing styles

Where is the syntax highlight of comments containing a code snippet? Helder 03:08, 9 September 2014 (UTC)

That's bugzilla:57159. I'll give it a nudge. Quiddity (WMF) (talk) 03:11, 9 September 2014 (UTC)

Missing title in the <title>

When I open a topic, the <title> element does not contains the page title. For example, this topic page should have a title containing "Talk:Flow" (e.g. "Flow failure case on Talk:Flow" or "Talk:Flow - Flow failure case", instead of just "Flow failure case") or I'll always have to scroll the page to the top to see what is the page which contains the topic. Helder 15:18, 9 September 2014 (UTC)

This is a good thought, thanks. Would it only make a difference on topics with shorter titles? I'm using Firefox right now, and the "Missing title in the <title>" is almost filling the tab. We could use the format that we're using elsewhere, which is "Missing title in the <title> on Talk:Flow", but it would probably turn into an ellipsis before you get very far. DannyH (WMF) (talk) 17:13, 9 September 2014 (UTC)

I'm using Firefox 32.0 on Linux, and it shows the full title above the tabs, in the title bar (only the title in the tabs is truncated). Helder 19:06, 9 September 2014 (UTC)

Okay, that makes sense. I've filed a ticket to make this change; I think it's a simple change that would make the titles more informative. DannyH (WMF) (talk) 00:16, 10 September 2014 (UTC)

Watchlist and Notifications

Flow pipes itself in both watchlist and notifications. This is annoying. I read watchlist and then see it again in notifications, or vice versa. Thoughts? Gryllida 01:43, 10 September 2014 (UTC)

I would personally rather have it in watchlist btw — as (i) replies a public event and (ii) I turned Echo off as I'd rather receive all things passively without web or email nagging.

However, it also is a private event; were Flow piped only to the watchlist, people who don't use it would remain unaware of replies. Hm. Gryllida 01:45, 10 September 2014 (UTC)

JavaScriptless — ability to view all topics expanded

I'd like to view the entire board with full topics contents. Can we add a button for that please? Gryllida 01:50, 10 September 2014 (UTC)

Flow doesn't have means to link to a topic inside of a board

I would like to link to a topic inside a board — without having folks only look at a single thread. Gryllida 01:51, 10 September 2014 (UTC)

JavaScriptless — no ability to sort or switch to compact mode

Both these buttons are missing. Gryllida 01:52, 10 September 2014 (UTC)

JavaScriptless — (no) ability to edit thread title

The 'edit' button for the title is simply not there. Gryllida 01:53, 10 September 2014 (UTC)

Yes, Flow used to have clunky no-JavaScript implementations of various actions (you were dumped in a form with no context). Now we have good implementations of Reply and Edit post, and adding back the other no-JavaScript actions is on our To Do list. SPage (WMF) (talk) 23:50, 10 September 2014 (UTC)

It is for me... Click on the "..." on the thread title box.

Never mind. I have JS on. Arthur Rubin ^en.Wiki (talk^en.Wiki) 02:41, 10 September 2014 (UTC)

Flow notifications

Some observations on Echo's "messages", in particular in the flyout:

• They're sorted oldest first. That doesn't seem very useful, I'd prefer (at least an option to sort them) newest first like on enwiki.
• For debuggigng/reporting, it would be nice if one could mark and copy text in the flyout.
• Why are the board titles bold and why are they not links?
• Why is "new topic" bold? Why is it greyed out, and why is it only revealing itself as a link on hover?
• Why is the whole notification a link with undecypherable target? Why is this not consistent between the flyout and Special:Notifications?
• Is there/can we have a link to a board that shows all comments/topics that were added/edited since the last visit marked with the green bar?
• Most glyphs in menus, the watchstar etc. are completely wrong here, fine at enwiki.

I'm using FireFox 32.0 and Monobook. — HHHIPPO 21:52, 10 September 2014 (UTC)

• Oldest notifications first is bug 69919, fix is coming but we have to address performance impact first.
• Link to a board that shows all comments/topics: Flow doesn't store a last visited but someone could add "Show everything newer" to the Flow action menu.
• garbled glyphs is bug 70681 and should be fixed by now (by the way it wasn't a Flow issue but a web server configuration bug). SPage (WMF) (talk) 23:44, 10 September 2014 (UTC)

• Oldest first: I see, so it's not mw vs. enwiki but read vs. unread. Then it's maybe not so urgent, I guess it's not normal to have 70 unread messages...
• Last visited time: isn't that / couldn't that be stored in the watchlist table? At least for the board. Or does Flow use it's own system also for that?
• Glyphs are back to normal indeed.
• I'll come back to the other questions some other time.

Thanks — HHHIPPO 07:01, 11 September 2014 (UTC)

Here's another funny detail: When viewing a single Flow topic, clicking on the Echo icon (notification number) doesn't open the flyout, but goes directly to Special:Notifications. This happens in both MonoBook and Vector, but only here, not on enwiki. — HHHIPPO 21:23, 13 September 2014 (UTC)

History

My watchlist and the board history agree that

(cur | prev) 19:28, 11 September 2014 . . 93.144.117.189 (talk) edited the header . . (-40)‎

If I click on the "prev" link, I see a diff claiming "no difference", inconsistent with the (-40) above. The links to the two revisions in the diff view yield an error, while clicking the date in the history works as expected (except for the gray background). I assume the history being truncated is a nown issue.

Edit: 2nd try to "Add topic" 1st one yielded an error. — HHHIPPO 20:20, 11 September 2014 (UTC)

Btw: "Hide topic" doesn't work in MonoBook. The whole page turns gray and unresponsive, including the pop-up box. — HHHIPPO 20:30, 11 September 2014 (UTC)

Hide not working in Monobook is known, and I'm expecting it'll be fixed in next week's release. [1]

I don't recognize the edited header bug. I'll put it in the backlog to work on it. Thanks! [2] DannyH (WMF) (talk) 23:44, 12 September 2014 (UTC)

Hide - updated version spec

I posted a spec for an updated version of the Hide function at Flow/Hide spec. I think this new version will match the current talk page functionality more closely -- hidden topics will actually be removed from the board view.

The spec includes rough wireframes, which are not mockups -- It won't actually look exactly like that, but that's the functionality change that I'd like to build.

I'm interested in hearing what you think -- especially from Gryllida, because I know you have a lot of ideas about the moderation actions. What do you think of the new ideas? DannyH (WMF) (talk) 23:53, 12 September 2014 (UTC)

In my view hiding should have a clear entry point - an "edit" button. It should not have separate entry points. This would make it less confusing.

• I click 'edit' on a topic title and delete button appears there which deletes the whole topic
• I click 'edit' on someone a message and the delete button also appears there

So instead of focusing on a single feature, I would focus on the bigger harder work mentioned here - improve refactoring of talk pages and ability to edit comments of others. This would take a long time to implement and would be praised by many people, including ones who handle massive requests for comment. Gryllida 23:32, 21 September 2014 (UTC)

I really don't think having to first go to "edit" makes sense at all for hiding a topic. Edit and hide are two separate things. Jay8g (talk) 00:30, 22 September 2014 (UTC)

I disagree. This hide implementation removes the topic from the board completely, for one. For two, even if it didn't, touching others' comments falls into "edit" category. Gryllida 21:30, 22 September 2014 (UTC)

DannyH, Quiddity: ping please. Thanks! Gryllida 12:28, 25 September 2014 (UTC)

Late reply: A pointer to the other thread where yourself and Diego Moya discussed a similar idea: Entry points for moving and hiding discussions. Yes, I'm looking forward to refactoring/merging/splitting features. I do Thoroughly appreciate all your comments and suggestions - Sorry I can't reply to them all - I'm rereading many of them often. Quiddity (WMF) (talk) 01:39, 17 October 2014 (UTC)

Quiddity: I replied in that other thread again. Gryllida 10:39, 14 November 2014 (UTC)

Closed (locked)/moderated topics in single-topic view

Closed (now called "locked", apparently) (example) or moderated (example) topics can't be seen in single-topic view, as they are collapsed and can't be uncollapsed. Jay8g (talk) 03:35, 13 September 2014 (UTC)

Yeah, it should be the opposite, sorry. They should always be uncollapsed. We'll fix that right away. DannyH (WMF) (talk) 19:09, 15 September 2014 (UTC)

Exception Caught: Did not load root post S08b3a2z6zb7542s

encountered trying to scroll all the way down Talk:Sandbox Deltahedron (talk) 16:30, 13 September 2014 (UTC)

Preview does not show by default

Is this new? When I clock on Preview, the text does not show up by default untill I then click on the boxed 1. This is not very inutuitive for the newcomer Deltahedron (talk) 16:36, 13 September 2014 (UTC)

That's odd; I'm seeing Preview work as it's supposed to. Can you describe that a little more? I'm not sure what you mean. Also: what skin and browser are you using? DannyH (WMF) (talk) 19:04, 15 September 2014 (UTC)

I'm using FF32.0.2 on OSX 10.9.5, skin whatever is default on MW. If I create a new topic, and write in the text field, and click preview, I get a version of the comment with not text showing, and have to clock on the title bar or the [1] to reveal the text. It seems quite consistent for me Deltahedron (talk) 16:43, 21 September 2014 (UTC)

Inconsistent statistics

My latest contribution to Talk:Sandbox shows as 20:32, 13 September 2014 (diff | hist) . . (+13,512)‎ . . Long on Talk:Sandbox on Special:Contributions/Deltahedron (diff | hist) Long on Talk:Sandbox; 20:32 . . (+12,542)‎ . . Deltahedron (talk | contribs) on Special:Watchlist

Surely these figures should be equal? Deltahedron (talk) 20:38, 13 September 2014 (UTC)

That is interesting; I didn't realize that was happening. Thanks for reporting it. DannyH (WMF) (talk) 19:02, 15 September 2014 (UTC)

Tracked at https://trello.com/c/KlvyQzmz/ Quiddity (WMF) (talk) 02:31, 16 September 2014 (UTC)

Curiously it can also report fewerː changing one character to another just now was reported as (-1) Deltahedron (talk) 19:32, 20 September 2014 (UTC)

Why does my comment appear twice on my watchlist?

My previous posting creates two entries on my watchlist: (diff | hist) Inconsistent statistics on Talk:Flow; 20:38 . . (+23)‎ . . Deltahedron (talk | contribs) (diff | hist) Inconsistent statistics on Talk:Flow; 20:38 . . (+318)‎ . . Deltahedron (talk | contribs) Deltahedron (talk) 20:39, 13 September 2014 (UTC)

There's one line for creating the topic, and the second one for posting the first message. We recently made that the same action, so we need to figure out whether to add an edit summary explaining it, or just combine those into one item. DannyH (WMF) (talk) 19:02, 15 September 2014 (UTC)

Especially since there is no explanation for these in the watchlist, these should be consolidated into 1 "created a topic" entry. Jay8g (talk) 00:10, 16 September 2014 (UTC)

Take a look into how it is done on ptwiki:

https://pt.wikipedia.org/wiki/WP:Esplanada/propostas?action=history&uselang=en

The edit summaries (which appear both in the history and the watchlists) include three information:

1. The fact that a new topic was created
2. The title of the topic (with a link)
3. As much content from that topic as possible

This makes it very easy to decide wheter I want to open the full topic or not from my own watchlist. Helder 16:46, 16 September 2014 (UTC)

I strongly suggest that only a single line appear on the watchlist. As a contributor, my view is that I have done one thing, namely, starting a discussion, not two. And there's only a limited amount of space on my watchlist, especially if I'm using one of these new-fangled mobile devices that seem so popular now-a-days. Deltahedron (talk) 21:03, 19 September 2014 (UTC)

Yeah, I agree. I'm putting a task in the backlog to combine these. Thanks for bringing it up. DannyH (WMF) (talk) 21:04, 19 September 2014 (UTC)

In my watchlist should only be one line per topic put there, currently I've got 5 lines about one single topic here, the \0 by Deltahedron. (NB: Why do we have to use those cryptic goobledigook instead of proper names in wikilinks under flow?)

It should be at most one line per topic, not the whole history of them. If I want to know the history, I go there manually. The current flooding of the watchlist with meaningless blabber is clearly a bug. Grüße vom Sänger ♫^(Reden) 13:44, 20 September 2014 (UTC)

Indeed, that topic now appears five times on my watchlist. Deltahedron (talk) 16:24, 20 September 2014 (UTC)

It seems that every hiding and unhiding operation creates a new line in the watchlist which is not overridden by subsequent comment or editing operations. That is not right. Deltahedron (talk) 19:30, 20 September 2014 (UTC)

On the other hand: I've got the whole page on my watchlist, and only get lines from the single topics, that are explicitly on it, not about new threads or new posts. New Threads are mentioned in my notifications, but new posts to other threads nowhere. Not the expected behavior.

I expect the newest line from here to be included in my watchlist. Grüße vom Sänger ♫^(Reden) 11:26, 21 September 2014 (UTC)

It's still the same. I've got the whole page here on my watchlist, but only get lines in either this or the notifications if a new answer to any of my specifically selected topics is written, or e now topic is created. The expected behaviour is a notification somewhere, I don't really now care whether in notifications or the watchlist, but preferably the second, but no mentioning anywhere is clearly a bug. Grüße vom Sänger ♫^(Reden) 17:21, 3 November 2014 (UTC)

The short answer is: More options are needed, and will eventually be developed, for us highly-active-editors who have hundreds or thousands of pages watchlisted.

Overall, the Flow team are trying out various possibilities, because it's easier to make changes when Flow is only on a few pages and being used by a few editors who are interested in beta-testing, rather than when thousands of editors are relying upon it working and not changing much. It's currently a difficult balance, between "don't change anything", versus "improve everything possible", with different editors having different perspectives on every feature within.

However, yourself and Deltahedron are correct, that there are some frustrating bugs and/or inconsistencies, in the current watchlist output (even more so, with grouped/expanded changes enabled). I believe the team is planning on re-examining all aspects of the watchlist output in the next sprint (2 week work-plan), or the one after.

(Re: your earlier NB - There are a few ideas about how the URLs & wikilinks can be improved. The most recent set of notes, are at https://trello.com/c/7d2CciSA/446-add-extra-human-readable-text-to-topic-page-urls )

Hope that helps. Quiddity (WMF) (talk) 22:25, 3 November 2014 (UTC)

Rollout on other wikis

Is there any plans to deploy flow to other wikis, where it is not deployed? — Revi 03:59, 16 September 2014 (UTC)

Right now, there are test pages on English, French and Hebrew Wikipedia, and we've had some requests for test pages on more languages. Is there a wiki where you're interested in trying it out? DannyH (WMF) (talk) 19:57, 16 September 2014 (UTC)

Yes, I would like to see it tested on Korean Wikipedia (or sisterproject). — Revi 23:06, 16 September 2014 (UTC)

I'm getting feedback on this for Portuguese Wikipedia on w:pt:WP:Esplanada/propostas/Flow? (18set2014) Helder 20:32, 26 September 2014 (UTC)

Requested on bugzilla:71757. Helder 21:07, 7 October 2014 (UTC)

He7d3r. I think we just found a bug. Your link is broken due to the "?" symbol in the page title. Flow seems to not be aware of it and, when the browser receives it, the symbol is used to mark the beginning of the QueryString.

Here is a working link: w:pt:WP:Esplanada/propostas/Flow? (18set2014) (I used %3F instead of "?" to workaround the issue: the produced URL is still wrong, but it works)

Does anyone know if this bug has already been reported? Diego Queiroz (talk) 11:49, 16 January 2015 (UTC)

I fixed the link by copying it again from the Firefox address bar. Helder 13:31, 16 January 2015 (UTC)

Hidden comments aren't hidden

Hidden topics (example) appear fully shown by default. Clicking on the post only hides the "this topic was hidden by [username]" line. I really hope this is not intentional. Jay8g (talk) 01:41, 20 September 2014 (UTC)

The example comment has now been unhidden. Jay8g (talk) 16:54, 20 September 2014 (UTC)

The single character 0 is not a valid comment

Curiously, while most single characters are accepted as a comment, the single character 0 (zero) is not. Deltahedron (talk) 11:05, 20 September 2014 (UTC)

To be more specific. When I tried to reply with just "0", I got this:

• Post has no content. Content is required to save a post.

Helder 20:30, 26 September 2014 (UTC)

Thanks for reporting this, I've submitted a patch to fix this issue. EBernhardson (WMF) (talk) 19:49, 16 October 2014 (UTC)

Changing a title which is 256 characters long

If you create a title of exactly 256 characters, it works fine. Then try editing it to add a sibgle character at the beginning. That seems to work, but actually truncates the title by about 50 characters. See [3] Deltahedron (talk) 08:52, 21 September 2014 (UTC)

Now filed at bugzilla:71584. Thanks :) Quiddity (WMF) (talk) 01:23, 3 October 2014 (UTC)

Title change not reflected in prompt

If you change the title of a thread, then reply to the thread, the prompt in the reply box still prompts for a reply to the old title Deltahedron (talk) 10:51, 21 September 2014 (UTC)

We just got hit by a live example Flow Failure Case

A hyper-partisan website with substantial traffic just LINKED DIRECTLY TO ONE OF OUR TALK PAGES because it wanted its own ATTACK-PIECE inserted into our BIO OF A LIVING PERSON.

The current talk page is currently struggling to sort out what, if anything, should go into the article. The issue here is not about the specific content. I hope I don't have to explain to anyone why this is event is a Very Bad Thing, how this would become common if Talk were ever replaced with Flow, and how the impact would be catastrophic under Flow.

Alsee (talk) 14:23, 21 September 2014 (UTC)

As far as I can tell, this is exactly what the strategy behind Flow is about. If Flow makes it easier for newcomers to edit the talk page, then that is deemed to be a Good Thing, and a success, not a failure for Flow. Of course, it may be that you and I think it a Bad Thing for building an encyclopaedia, but WMF think otherwise. Indeed, the WMB Board chair is on record as saying that

• We want to attract new editors. They don’t have to become heavy editors, they could even contribute once in a while, as long as we get lots of them. We have to make it easy enough for anyone to contribute so that people once again feel that “anyone can edit.” [4]
• If that means changing the dynamic, this might very well be the time that we have to do that. [5] Deltahedron (talk) 16:32, 21 September 2014 (UTC)

As long as a proper talk page is still provided, the troll-space provided by flow could simply be ignored by the proper users and editors of an encyclopedia. If one day this troll-space will become the only talk page, it's no fun any longer. Grüße vom Sänger ♫^(Reden) 16:48, 21 September 2014 (UTC)

Flow pages are proper talk pages. Helder 20:27, 26 September 2014 (UTC)

Flow is just suited for (very short) conversations, not suited for all the other stuff needed in a talk page.

WP is not a forum, and should not be. Grüße vom Sänger ♫^(Reden) 07:16, 27 September 2014 (UTC)

There have been long discussions about what Flow needs to deliver beyond chat. See, for example, many threads at w:en:Wikipedia_talk:Flow, such as w:en:Wikipedia_talk:Flow#Workflow_research Deltahedron (talk) 10:26, 27 September 2014 (UTC)

That is where I personally would like to see means to weed out trolling from talk pages while not removing it entirely. Having +/- buttons for comments was a thought. Some people rejected it as they think that it would make it harder for people to work. But I see it as an additional sorting criterion (in addition to time created and time edited of a topic) and, if the total "score" is hidden enough (i.e. only used for sorting but is not visible), I think it could be a productive feature. Gryllida 23:41, 21 September 2014 (UTC)

In the case under discssion that would give yet another means of disrupting the conversation to visitors who want to argue about the topic rather than discuss collegially how to improve the article. Deltahedron (talk) 06:33, 22 September 2014 (UTC)

Did you ever read my comments on your discussion page why +/- would be bad?

It's particularly ironic that you're raising +/- again on this thread, with a wingnut site like thefederalist linking directly to a talk page. The wingnuts would flood minus-ratings at all of the legitimate editor's comments. My head wants to explode when you call it a "productive feature". Alsee (talk) 09:02, 22 September 2014 (UTC)

Editing a comment after it has been replied to

It seems to be possible to edit a comment after it has been replied to. There does not seem to be any warning that there are replies depending on a previous state of the comment, nor is there any clear indication that the reply is to an old version of the comment. Of course it is possible to do this in raw wikitext, but Flow is going to be so much better as a discussion system.

Could Flow make it clear when editing a comment that there are depedent replies, please?

Could Flow indicate that a reply is to a previous version of the comment, please? Deltahedron (talk) 16:39, 21 September 2014 (UTC)

There is a clear indication. Each message has two timestamps, creation and edit timestamp.

For example for this one:

• 23:36, 21 September 2014 • 23:35, 21 September 2014 Gryllida 23:35, 21 September 2014 (UTC)

You can indeed find this information. My suggestion is that instead of my doing that work, the Flow software should do it. Deltahedron (talk) 06:31, 22 September 2014 (UTC)

Flow topics appear to have their own talk pages

It appears that Flow topics have their own talk pages: I found one by accident, and found that I could create and edit it. Is that desirable? Deltahedron (talk) 17:36, 21 September 2014 (UTC)

Hi, thanks. What is your entry point to a talk page and are you sure it's not just a random page with a name you made up on the spot? I see "Topic", I don't see "Topic talk" tab personally. Gryllida 23:38, 21 September 2014 (UTC)

The talk page is here, deleted twice in the sandbox, but I think it's somehow protected now, for whatever reason. Grüße vom Sänger ♫^(Reden) 04:37, 22 September 2014 (UTC)

The template {{TALKPAGENAME}} on this topic gives the name Talk:Structured Discussions/2014/09. If you enclose in in double brackets, Talk:Structured Discussions/2014/09 creates a link to a page you can edit. It seems reasonable to describe a page linked to by TALKPAGENAME as the talk page.

In the case I reported, the page was created from this page by using the {{draft}} template.

My question, is it intended that that should happen and is it desirable?

By the way, in future please do not suggest that other editors are making things up. Deltahedron (talk) 06:40, 22 September 2014 (UTC)

Well, it's not really a talk page, but just a random page in mainspace, so that's an issue with {{TALKPAGENAME}}. However, if you manually go to Topic talk:S2rkofnrcs9kllj9, you also get a page you can create, which does not seem desirable at first glance, though I guess this is also just a random page in mainspace, since the Topic talk namespace doesn't exist. Jay8g (talk) 13:56, 22 September 2014 (UTC)

I concur that I think there is no "Topic talk:" namespace and TALKPAGENAMEE needs to be fixed. This is interesting.

(If "By the way, in future please do not suggest that other editors are making things up." was directed at me, mind your mindset -- I wasn't suggesting that, I was merely asking for steps to reproduce.) Gryllida 21:33, 22 September 2014 (UTC)

(It was.) Deltahedron (talk) 21:42, 22 September 2014 (UTC)

Flow topics do not appear in categories

I tried to add Topic:S2rjakm9xomtshnq to Category:Testing, but it does not seem to show up there. Is that intentional? Deltahedron (talk) 18:21, 21 September 2014 (UTC)

I hope not. Helder 20:21, 26 September 2014 (UTC)

Categories are not currently supported, but that work is planned. Quiddity (WMF) (talk) 01:27, 27 September 2014 (UTC)

Templates in topic titles can be expanded

I created a topic with title {{draft}}. Quite correctly, that's how it renders on the Flow page. However, there are circumstances under which the template expands, such as here. Presumably that shouldn't happen?

PS: the same with <math>, here.

PPS: {{collapse top}} as a title also creates problems. Deltahedron (talk) 18:25, 21 September 2014 (UTC)

The {{draft}} doesn't seem to expand now. Perhaps someone fixed it? No doubt at some stage we'll be told ... Deltahedron (talk) 18:27, 27 September 2014 (UTC)

This one was partially fixed at https://gerrit.wikimedia.org/r/#/c/162243/

Followup work is tracked at bugzilla:70982 Quiddity (WMF) (talk) 18:45, 28 September 2014 (UTC)

Thanks for that Deltahedron (talk) 18:48, 28 September 2014 (UTC)

In fact, {{collapse top}} appears to actually break the page. Deltahedron (talk) 20:36, 22 September 2014 (UTC)

Internal error at Topic:Rvn1lfzn6r8vn0db

Going to page Topic:Rvn1lfzn6r8vn0db produces

[516969bf] 2014-09-21 19:17:04: Fatal exception of type MWException Deltahedron (talk) 19:18, 21 September 2014 (UTC)

I didn't see any error when I visited that page. Helder 20:20, 26 September 2014 (UTC)

Indeed, it works for me now. Deltahedron (talk) 20:42, 26 September 2014 (UTC)

"Exception Caught: Interwiki to my_wiki not implemented"

I'm using todays Flow Version.
1) New Threads are not saved, they disappear when I leave the site.
2) When I "answer", I get the Exception above.

Other Extensions I use:

• Skin Chameleon
• Mantle
• Parsoid
• Parsoid Service

Flow Config:
$wgFlowParsoidURL = 'http://localhost:63179';
$wgFlowParsoidPrefix = localhost;
$wgFlowParsoidTimeout = 100;

Wiki Version: 1.24wmf22 Tamriel (talk)

How do you get that? Gryllida 23:36, 21 September 2014 (UTC)

I would love to get some additional advice, how I should set up Flow on a fresh wiki. Maybe I missed something. Tamriel (talk) 23:16, 22 September 2014 (UTC)

I found the cause: The name of my database ended with a number. Tamriel (talk) 22:03, 29 September 2014 (UTC)

Search/filter in topic contents and title

Previously (without Flow) you could simply search with browser tools (CTRL+F). As Flow doesn't show all topics with all content there should be some search and/or filtering mechanisms. Content search would be useful on large discussion pages when you are searching for something specific.

As for filtering it would be very useful to show only "topics I contributed to" or "topics I watch". Nux (talk) 06:49, 22 September 2014 (UTC)

+2. Helder 20:19, 26 September 2014 (UTC)

One of the major ongoing tasks is working with the search team, to get some custom and highly-filterable search options.

Hhhippo has some great ideas about Filtering at w:User:Hhhippo/Flow - I'd encourage adding notes/comments there. :)

(The mess of developer notes are listed at https://trello.com/c/nIDJHl8s/821-search-tracking ) Quiddity (WMF) (talk) 03:05, 27 September 2014 (UTC)

Templates in topic titles can be expanded II

It is possible for a template to overflow the space allotted to the title in the reply box: see this example. Deltahedron (talk) 17:17, 22 September 2014 (UTC)

and why cant I (pre)view the hidden topic without unhiding it first? (Maybe the message is shown, but I dont know) Christian75 (talk) 20:28, 22 September 2014 (UTC)

Problem saving new topic

Sometimes when I click on Add topic, the cursor spins and I don't get sent to the new topic: but it has been created. If I click on the Add topic button again, I generate a further copy of the new topic. Deltahedron (talk) 17:24, 22 September 2014 (UTC)

Another problem saving new topic

I randomly get a dialog asking whether I want to stay on or leave the page when I click on Add topic. If I click on leave, the topic is saved anyway. Deltahedron (talk) 17:54, 22 September 2014 (UTC)

Hidden comment text still visible

When I hide a comment, the text is still visible as soon as I open the topic. Deltahedron (talk) 20:10, 22 September 2014 (UTC)

Sorry for the duplication, this appears to be a duplicate of Hidden comments aren't hidden Deltahedron (talk) 20:38, 22 September 2014 (UTC)

Oddities on hidden comment

If I hide a comment, it has a footer saying something like

Edited 3 minutes ago . 4 minutes ago

If I hover over the first part, it changes to

[object Object]]

If I leave the page and return, then the footer looks the same but now when I hover I get a sensible timestamp.

Presumably these should read Hidden and Edited respectively? I object to the object Object object. Deltahedron (talk) 20:26, 22 September 2014 (UTC)

Filed as bugzilla:72170, after much initial confusion. Thanks. Quiddity (WMF) (talk) 01:55, 17 October 2014 (UTC)

Mark message as read

In the Echo flyout, the "x" marking a Flow-related message as read is quite far away from the right edge for me (FF, MonoBook). For truncated topic titles it's actually overlapping with the "...", resulting in an artistically interesting, but not very useful figure.

Btw., my pre-Flow intuition says that clicking an "x" makes something dissapear rather than being marked as read. I don't think a message should dissapear when read, but I'm wondering if "x" is the best choice of glyph here. Thunderbird uses a green bullet and bold text for unread, and a grey bullet and regular text for read, a similar pattern is used on MediaWiki watchlist and history pages. Having a glyph on read messages would also provide an easy route to implementing an option to manually switch a message back to unread. — HHHIPPO 21:12, 23 September 2014 (UTC)

Unable to open individual topics

Something odd: if I go to an individual topic such as this one, for example. by clicking on it from my watch list or the permalink, I seem unable to open it by clicking on the title, or to reply by clocking on "Reply". But if I click on it from this page, then it works as expected. Deltahedron (talk) 21:03, 26 September 2014 (UTC)

I believe this is/was an instance of bugzilla:71593 ("topic page can get stuck in collapsed or small view, can't expand") Quiddity (WMF) (talk) 01:45, 17 October 2014 (UTC)

WIBNI infinite scrolling

It would be nice if on reaching the botton of the page, while waiting for another chunk to load, we could pop up a little messages saying something like You have reached topic number 123 out of 456, now loading numbers 124-156 Deltahedron (talk) 18:23, 27 September 2014 (UTC)

Filed as https://trello.com/c/7eZGggJf/ Thanks! Quiddity (WMF) (talk) 01:33, 8 October 2014 (UTC)

Have bugs been fixed?

I have reported some things which appeared at the time to be bugs, and where the unwanted or unexpected behaviour no longer occurs. While it's nice to see that bugs can be fixed so quickly, it would be nice to have some comment here, for example, adding the bug report number when it's picked up, and a later comment to say that it has been fixed. Deltahedron (talk) 18:29, 27 September 2014 (UTC)

The stream of bug-activity can be seen at here for example (the last 2 weeks of bugzilla "changes" in the Flow component). It's difficult to update prior reports, because they originally come from a large variety of locations (wikis/mailing lists/IRC/direct email/trello). The move to Phabricator should eventually ease some of this, but it'll still be complicated because everyone files bugs in different styles and with different amounts of context.

(I am personally backlogged on filing bugs, and reading/replying to comments, on all wikis. However, I do appreciate the testing and bug-discovery you've been doing in the Sandbox. Thanks again!) Quiddity (WMF) (talk) 18:37, 28 September 2014 (UTC)

Thank you for the pointer -- I had previously not been aware of the existence of that page. Deltahedron (talk) 18:38, 28 September 2014 (UTC)

Nonetheless, for the future, when I report a bug here on this page, and the report is read, and mapped across to Bugzilla, I would appreciate some indication that notice has been taken of my report. In addition, the link you gave is much less useful without knowng the Bugzilla reference number. I do not see that as some kind of optional extra if users' bug reports are considered an integral part of your development effort. Perhaps if your team is too busy to do this, you should ask us to hold off reporting bugs until the team is able to deal with them appropriately? Deltahedron (talk) 18:43, 28 September 2014 (UTC)

Re: the bugzilla link - it's just a basic time-limited search. The columns that appear (in any default search) can be configured for yourself, by clicking "Change Columns" at the bottom of the page. (Strangely, the ID (reference number) column appears for me at the far left, in all my test browsers (including anonymous modes). Does this version work differently for you? (It looks the same to me, but it specifies "id" in the columnlist).)

Re: backlog - Danny is currently working on a documentation/timeline update, which should help us all discuss "a few topics at a time" rather than "everything at once" (which is a core part of the reason we're so backlogged). That is hoped to be ready by next/this week. So, please keep the bug reports coming as you find them, but the faster you find them the longer it will take to process them (logically!) and to respond to everything else. (And yes, I'll try harder to update all 3 places when I file a bug (bugzilla + trello + original reported location). Thanks for your patience.) Quiddity (WMF) (talk) 19:30, 28 September 2014 (UTC)

I meant that if a bug is reported here, and then copied over to Bugzilla by a member of the team without leaving a comment here about what the Bugzilla reference number is, then it is hard to use the listing to correlate the report here with the status of the report on Bugzilla. Deltahedron (talk) 19:52, 28 September 2014 (UTC)

Overlong title bug

Still happening Deltahedron (talk) 18:32, 27 September 2014 (UTC)

Flow edits don't count

I just noticed that edits to Flow pages don't seem to be listed on the edit counter tool [6]. Deltahedron (talk) 16:20, 28 September 2014 (UTC)

That's tracked at bugzilla:61887 Quiddity (WMF) (talk) 18:23, 28 September 2014 (UTC)

Thanks for the pointer: I see that bug report has not been commented on since February. Is it proposed to fix this at some stage? Deltahedron (talk) 18:27, 28 September 2014 (UTC)

I've now added the bug to trello, which gets it one step closer. (All bugs should be fixed, at some stage! However, I will encourage the devs to examine this one sooner.) Quiddity (WMF) (talk) 23:31, 30 September 2014 (UTC)

Leading spaces in titles behave oddly

It seems possible to edit leading spaces inti a title, and they are there when you save. But when you edit the title again, they are no longer there. Deltahedron (talk) 21:40, 29 September 2014 (UTC)

This seems to have been fixed, in one of the other Title-bug-fixes. Quiddity (WMF) (talk) 01:41, 17 October 2014 (UTC)

Clicking title to collapse

In the default-state, all topics are expanded, and I can click a title to collapse a topic.

It's not clear to me why I'd ever want to collapse an individual topic. Is there a real use case for this?

There is a point here about consistency, I guess, since we can switch all topics to being collapsed by default. I'm skeptical that this is useful, and suspect a true TOC of some kind would be more valuable than something I have to use to switch back and forth.

As for clicking the title, I would suggest quicker access to editing titles, perhaps by double-clicking them.

Curious if other people find the current behavior useful as-is. Erik Moeller (WMF) (talk) 07:32, 30 September 2014 (UTC)

Hi Erik, In this case visiting the mobile website might be worthwhile. In it, article sections content visibility is toggled when you click them. To my knowledge, they are trying to save the bandwidth and space. Unfortunately I get rid of this behaviour there (as well as at Flow talk pages) by disabling JavaScript in the browser entirely. This is probably inconsiderate of me given that I'm not advocating proper interface for the rest of the readers and contributors. Gryllida 02:36, 1 October 2014 (UTC)

I agree it's not much useful in its current form, but it could be a way to allow partial access to just some relevant content in the thread.

The collapse/reveal behavior would be useful for a "recent updates/diff" view, where each topic were collapsed except for the few comments posted or changed since your last visit (plus the single comment above each new one of them, shown for context, as we have in the current diff views).

When accessing such "changelog" view, it would be useful to have a click on the header to expand all comments and allowing the user to revise the full thread, after having read just what was new. Diego Moya (talk) 09:05, 30 September 2014 (UTC)

I do find this proposal of having the collapsed mode show just the diffs in a changelog view very interesting (although I still don't like the "click on header" interface, as explained below). Klipe (talk) 09:27, 30 September 2014 (UTC)

I do collapse individual topics from time to time. I do it for long ones in the default "all topics expanded" mode, or for any topics I just read when looking at the board in "all topics collapsed" mode.

However, I don't like the "click on the title to collapse" interface. In particular, I find it very much annoying that topics get collapsed every time I try to select (part of) their title for copy/pasting. I would prefer a small active zone (e.g. a visual indication of the collapsed/expanded state to the left of the title, in the grey title box) on which to click to change the state, while the title itself can be selected normally.

This said, collapsing individual topics may become less useful once we'll have a real ToC...

In case we want a quick access to "edit title", then again (double) clicking on it would interfere with standard text selection functionality (double click typically selects a whole word). More fundamentally, I think that such a quick access would be marginally useful and bring more confusion. To me, "edit title" is a comparatively seldom action and may therefore stay in the "other actions" menu behind the dots triplet icon. If this action becomes accessible with just one (double) click, then new/occasional users may suddenly find themselves in an "edit title" mode without knowing how they went there. They may even not realise what they are doing and just start typing something!

In any case, thanks for having brought this topic forward. I'm curious to read other's opinions on the matter. Klipe (talk) 09:22, 30 September 2014 (UTC)

Thinking more about it I agree that the function has uses. For example on mobile there won't be enough space for a ToC on the side, so it would be useful there to have the whole board collapsed and working as its own index. Article pages on the mobile interface work that way, and it's a reasonable approach.

And I concur that linking the action to a click on the title box seems weird, like it would be having double click to edit; all interactive actions should be tied to a button or link working as an affordance to suggest that the action is possible, and giving a hint as to what is their effect.

Double click in particular is a gesture with accessibility problems, and it can always be replaced by two successive single clicks - one to focus and select the item, and a second click on the focused item to trigger the action. A fast "click to edit" command could work that way. Diego Moya (talk) 11:36, 30 September 2014 (UTC)

I use it once in a while, too, as a way for marking a thread as read, but I agree (and I'm sure I nagged about that before) that clicking something that doesn't look like a link or button is not intuitive. My suggestion would be to implement this ;-) and then apply a similar approach to the topic title: Start the bottom line in the title box with the collapse/expand triangle icon, followed by n comments with the same mouse function. After that come the Reply link and the timestamp.

I also think that editing the title is rare, and can stay in the "..." menu. Assigning a double click on the title to this function would not be very discoverable. What one could maybe consider is showing the "..." menu also for a right-click on the title, if we can (and want to) steal that mouse event from the browser.

Using collapsing to guide the reader to new activity would be a nice feature. I've been meaning to include that in more detail in my suggestions regarding Partial collapsing and monitoring activity. Maybe I find the time... — HHHIPPO 16:55, 30 September 2014 (UTC)

Your proposal around compact nesting is really worth reading. That's a very interesting approach to nesting and collapsing, which would indeed serve various use cases better than the current implementation. There may be drawbacks... but I still haven't found any :-) Klipe (talk) 20:02, 3 October 2014 (UTC)

I got notified about the creation of this topic by Echo, but it didn't show up in my watchlist, even though I'm watching the board. Is that a known bug? — HHHIPPO 16:58, 30 September 2014 (UTC)

They might have been playing with this given that people are complaining that they see things in Echo first and then in Watchlist again. Opening a new topic about this might be worthwhile. Gryllida 02:38, 1 October 2014 (UTC)

Should be fixed when https://gerrit.wikimedia.org/r/#/c/165316/ gets merged. But I've asked for clarity at https://trello.com/c/o6X9S97z/ Quiddity (WMF) (talk) 03:50, 8 October 2014 (UTC)