Talk:Structured Discussions/2014/02

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

Readability and skimming

Background on own username seems a recent addition. It looks a bit ugly to me (name more difficult to read). I would start with making the threads display more compact (there is a lot of padding and white space at the sides) and only then think how to make own messages easier to spot. Gryllida 01:58, 1 February 2014 (UTC)

Gryllida: I like the background for my own username, but anything that highlights my posts would be fine with me. I agree about making it more compact. Skalman (talk) 19:39, 1 February 2014 (UTC)

I like the idea of the functionality, but I think it would be better to use something like the colored left-bar that's used throughout the design of Flow (For an example, try replying to this comment, to the left of the text input box is a line similar to what I'm suggesting). I definitely do agree that it looks pretty bad right now. Nicereddy (talk) 03:18, 4 February 2014 (UTC)

Nicereddy: Good idea! :-) Gryllida 20:38, 4 February 2014 (UTC)

If you don't like flow's highlighting I think you can create custom highlighting by adding an entry to your common.css file, e.g.

#bodyContent a[title="User:Gryllida"] { background-color: #ffa500; color: #ffffff; font-weight: bold; }

This code (should be all on one line, btw) will highlight your user name when it appears as the title of a link, e.g. Gryllida. Pointillist (talk) 11:06, 4 February 2014 (UTC)

Pointillist: Thanks. I have issues with this, such as average contributor not being aware how CSS works, and such as any background being ugly. Gryllida 20:36, 4 February 2014 (UTC)

Gryllida: Oh yes, I agree with your original points about whitespace too. It would be interesting to try an alternative stylesheet for Flow (and maybe VE) that uses a more compact and contrast-y layout. Pointillist (talk) 21:33, 4 February 2014 (UTC)

Pointillist and Gryllida: Personally, I use the Highlight your username script, which colors my name (i chose green) everywhere (including watchlists, history pages, etc) and does not require a userpage-wikilink (plaintext gets highlighted). See screenshot. [That's just one of the reasons, that I don't use a custom signature! ;) ]

The general topic of "how do we style a visual highlight" is definitely complicated, as aesthetics are so subjective. As always, we have to aim for a default that suits everyone, and investigate potential customization options from there (bearing in mind that adding any "preferences" introduces great code complexity and upkeep problems). Quiddity (WMF) (talk) 23:17, 7 February 2014 (UTC)

Let's also put this thread to VE's talk page. Seriously, can we have shared threads yet? :-) Gryllida 00:22, 5 February 2014 (UTC)

Layout

I think that the username should be moved to the right bottom, before the date, as otherwise it occupies its own almost empty line.

<message>

Reply - Edit - <stretched space> - Gryllida (4 days ago)

Mouse over

<message>

Reply - Edit - <stretched space> - (talk contribs) Gryllida (4 days ago) Gryllida 05:21, 1 February 2014 (UTC)

I think it's preferable where it is, as that's the way the majority of readers would scan through the content. Left to right and top to bottom. Having the username at the bottom is pretty unique and likely not what most users would be used to, causing unnecessary friction in finding content which has a pretty much standardized location on most of the rest of the internet. Nicereddy (talk) 03:20, 4 February 2014 (UTC)

Nicereddy and Gryllida: One difficulty is that usernames can be up to 40 characters long. eg:

Lorem ipsum dolor sit amet orci aliquams

So allowances have to be made for that.

Additionally, there's the current mouseover behaviour of the timestamp. (Which some editors are requesting a preference for, to change their default from elapsed to exact (which is a lot longer string)).

Lastly, here's the latest mockup-image, for upcoming design tweaks. As you can see there, it will remove the current "edited post" pencil icon, and replace it with a text string (both subject to timestamp mouseover). A lot to consider! Quiddity (WMF) (talk) 23:10, 7 February 2014 (UTC)

Excesively narrow scope: Flow 'n' article things

I feel that the Flow work should be more integrated with how articles are edited, and less locked down. We all would make use of an edit box for each section, both source editor and visual editor. Watching an individual section. History per-section.

Flow locks things down excessively; subsections and simply refactoring a talk page discussion appears to be difficult (moving someone's thread around, changing its heading level).

Apart from creating new objects for talk pages, there appears to be a need to dive more into MediaWiki's way of storing pages, adding objects there, as well as interface. Gryllida 22:29, 2 February 2014 (UTC)

Topic bar: potential lack of need in nick and time

Previously people just used a section title. From all the time I talked to contributors, I never saw them confused about who started a thread or when; this information is readily available in its first message, and is not essential where we want to focus on the message content. Gryllida 22:50, 2 February 2014 (UTC)

Gryllida: The meta-information in the second row of the titlebar is

• On the left: "$OriginalPoster, $MostRecentPoster, $SecondMostRecent, and X others"
• On the right: timestamp of most-recent-activity

If only a single person has posted to the topic, it currently reads "$OriginalPoster started this topic" - I believe this is the aspect you're concerned about.

Keep in mind that it is possible to start a topic without an accompanying post. That's the equivalent to just leaving an empty ==header== on a page. Hence clear attribution is useful for that situation.

Also, the hypothetical situation where User:A starts a new topic and posts in it. Then User:B makes a top-level post in the topic. Then User:C deletes/suppresses User:A's 1st post. We'd still want attribution for User:A having started the topic, even though their post is no longer visible (to most editors).

It gets complicated. :/

Suggestions welcome! (For wording changes, or other options to consider). Quiddity (WMF) (talk) 22:30, 5 February 2014 (UTC)

Quiddity (WMF): I like the current way of displaying the posters. In my opinion, this bit of Flow is well thought !

Off topic... I had [[User:Gryllida|Gryllida]] mentioned automatically instead of [[User:Quiddity (WMF)|Quiddity (WMF)]] in this comment, although I clicked Reply just below Quiddity's comment. I was better before, with a mention of the poster of the comment being replied to instead of the poster of the top-level comment in which I'm participating. With just one level of indent, not even mentioning the right poster means totally loosing any sense of discussion... flow. Klipe (talk) 12:15, 6 February 2014 (UTC)

Klipe: Re: off topic. It was no conscious choice to change this: it is still supposed to prefix the username of the exact post you clicked to reply too, but a bug slipped in. Just submitted a fix, so it shouldn't be broken for too long anymore. Mmullie (WMF) (talk) 16:24, 6 February 2014 (UTC)

I would show the topic author name only if the topic has no text, then. It's obnoxious, people don't need the name, there has been no single case when people need it.

The focus should be on content of the threads, not on who participates, and I see no benefit from mentioning the list of people who participated in the topic bar. Gryllida 19:45, 6 February 2014 (UTC)

Topic bar font

...should be serif. It's too ugly otherwise. Gryllida 23:27, 2 February 2014 (UTC)

Gryllida: bug 59636 is that Flow should not override the h1 and h2 fonts. But May Galloway recommended there that the h2 title in the topic titlebar should continue to override to keep its current appearance (sans-serif and no ruled line on the bottom). I'll pass on your input. SPage (WMF) (talk) 06:21, 13 February 2014 (UTC)

You mean sans-serif? I believe the current font is a serif, which I personally find to be ugly in its current iteration. Nicereddy (talk) 03:15, 4 February 2014 (UTC)

Nicereddy: No, right now it's something sans serif, a bit Arial-like. Like the comment text. "I" is one line, no horizontal lines. Gryllida 03:29, 4 February 2014 (UTC)

Nicereddy: Interesting, mine has horizontal lines. Maybe it's a difference between having the Typography Refresh on/off? Nicereddy (talk) 02:21, 5 February 2014 (UTC)

Tested and confirmed - the headers only display in serif if we have Typography refresh enabled, and Vector skin. Quiddity (WMF) (talk) 22:07, 5 February 2014 (UTC)

I have it off, because I'm not using Vector skin. PLEASE, support it on all skins. It's not that hard. :[ Gryllida 03:13, 5 February 2014 (UTC)

Gryllida: I don't know what the community support for serif-headers is like, either overall, or specifically amongst Vector users, or among Monobook users, or among other skin users. It's quite a divisive and subjective issue! In the short-term, I'd recommend experimenting with your personal.css. Quiddity (WMF) (talk) 22:17, 5 February 2014 (UTC)

I think it would make sense to have the refresh feature available for all skins, and let people choose... Gryllida 22:20, 5 February 2014 (UTC)

Gryllida: See the last comment (from Steven) at Talk:Typography_refresh#In_summary... (and make any requests/comments about it there ;) Quiddity (WMF) (talk) 22:53, 7 February 2014 (UTC)

Two feedback channels

This one, and on Labs wiki instance.

Suspect it could be less confusing to have one, here, so people don't have to sign up over again. Gryllida 06:02, 3 February 2014 (UTC)

Gryllida: Are you suggesting removing the link to ee-flow, from the header message on this page? Or something else?

I agree that fragmented multi-location discussions are hard to keep track of, but we do need to preserve the links to prior discussions, and also to retain easy access to the ee-flow instance which has the bleeding-edge code.

Suggestions welcome. :) Quiddity (WMF) (talk) 21:50, 5 February 2014 (UTC)

Quiddity, I'm suggesting to put a big fat disclaimer at the top of 2 places, saying that feedback should go elsewhere (to the third place). I think discussing things in 1 place would help to get more people participate, and you would have to pick up feedback from 1 place mostly. Gryllida 22:19, 5 February 2014 (UTC)

Gryllida: I've updated the headers at ee-flow to recommend posting feedback at Enwiki.

Changing anything else runs into the problem of m:not my wiki though. Some editors will be unhappy about being asked to use Enwiki (or mediawiki) to provide their feedback (and will be less likely to participate regularly, as it won't be on their daily watchlists, etc). I think we're stuck using both Enwiki and Mediawiki. I'd encourage you to use Enwiki, but am hesitant about putting that request in the page header... :/ Quiddity (WMF) (talk) 22:40, 7 February 2014 (UTC)

They should be more than happy with being asked to provide feedback at Meta or here. These two are for discussions relevant for all projects after all. Gryllida 05:10, 8 February 2014 (UTC)

"Custom workflows"

Extension_talk:Scribunto#Framework_for_interactive_applications_on-wiki_38855

Of interest. Please share detail as to what the plans are. It would be interesting to know. Gryllida 01:04, 4 February 2014 (UTC)

Why is this being rolled out to enwiki?

Flow doesn't work. Most of the basic requirements aren't met. Whose ida was it to roll it out to enwiki (and elsewhere?) without having e.g. a decent "history" and "watchlist" system? Archiving? Search? Anything? Fram (talk) 13:43, 4 February 2014 (UTC)

Its only been rolled out to two WikiProjects who consented to their involvement, as far as I know that's the only part of enwiki which has been effected thus far. It's still a beta by all means, but it's not being added to enwiki in any large way as of yet. Nicereddy (talk) 02:20, 5 February 2014 (UTC)

So? Promises were made about minimum viable product requirements and the like. These are now totally disregarded. No admin or bureaucrat actions are possible on these pages. The history, watchlist, and so on are one big mess. I have 30,000 pages on my watchlist, but the three Flow-enabled pages suddenly take up half my watchlist.

There were plenty of major bugs identified on MediaWiki to keep the developers busy for quite a while, so there was no need to roll it out to enwiki, apart from not going over the self-imposed deadline too much.

If wanted on enwiki for some reason, it could have been done to Talk:Flow only, instead of ruining the talk pages of live projects (nearly all posts there are now about Flow, not about the project, so...) Fram (talk) 08:07, 5 February 2014 (UTC)

No, comments can be edited and deleted, and pages protected/unprotected, much like a normal talk page. No comment on the rest of your comment. Jasper Deng (talk) 08:11, 5 February 2014 (UTC)

Jasper Deng: Really? Have you tried this at enwiki before responding here? Pages can't be deleted nor protected there. If you can, then the normal admin settings don't apply to Flow pages. If you can't, then you perhaps should have checked before replying here... Fram (talk) 08:19, 5 February 2014 (UTC)

I can't try there because I'm not an admin there. It isn't immediately obvious, but if you scroll down to the bottom left of the topic or the top right of a comment, and click the "...", you will see a few options.

I know admin actions are possible because I've had to do so myself here to clean up a massive round of spam. They might not all work out but you can do indeed do things like protect the talk page like this one. See the history of Talk:Sandbox. Jasper Deng (talk) 08:23, 5 February 2014 (UTC)

Jasper Deng: Just shut your big mouth please. You can not see whether it works at enwiki or not, but then you proceed to tell me that it works nevertheless, and add some ifno I have long been aware of and am not discussing here at all?

If you can't try it, then you shouldn't respond as if you know the answer. You could have said "strange, these things work here, can you check to make sure?" or something similar. Now you are just making an arrogant fool of yourself.

On [1], all I see is "view history" (yeah, that's useful), the "watch this page" star, and Twinkle options because I have installed Twinkle. The normal admin dropdown with "delete - move - protect" IS NOT THERE. Fram (talk) 08:28, 5 February 2014 (UTC)

Fram: can you please take it down a few notches? I think you're making this more personal than it needs to be. Rschen7754 08:35, 5 February 2014 (UTC)

Ah, you again. Nice to see some familiar faces. Please tell Jasper Deng to have a bit more trust in people. Like I said, I wouldn't have minded if he had genuinely questioned me, and said that it was possible here, at MediaWiki. But to make the same mistake twice, i.e. to think that he knows better even if he can't check it and I can, is no longer slightly stupid, it is plainly arrogant (and stupid, but arrogance usually is).

I would not dare to tell him that it is not possible here, at MediaWiki, since he is an admin here, and I no longer am (thanks to, among others, you two). But he clearly has no such scruples. But feel free to block me again for "trolling" if that makes you feel better. Easier than confronting the real problems here of course.

Now, can we get back to the actual issue, i.e. the implementation of Flow on enwiki? Fram (talk) 08:43, 5 February 2014 (UTC)

By the way, when I use "reply" underneath rschen7754s post, I get "Jasper Deng: " at the front of my post. But you don't have to trust me on this, please check for yourself first! Fram (talk) 08:44, 5 February 2014 (UTC)

What does my not being an admin on enwiki have to do with this, when the sysop tools I mentioned already exist in its release?

Let me just remind you that if you want answers, you should be civil. Don't let the events of November repeat themselves. Jasper Deng (talk) 08:45, 5 February 2014 (UTC)

(however I will say that deletion of a Flow talk page is not currently possible by design) Jasper Deng (talk) 08:29, 5 February 2014 (UTC)

Jasper Deng: Why? Fram (talk) 08:44, 5 February 2014 (UTC)

For similar reasons as why archiving is a redundant concept for Flow pages.

I do not know all the details. If it causes too many problems, it will be changed. Jasper Deng (talk) 08:48, 5 February 2014 (UTC)

I'm interested in this. There will still be a way to permanently hide something from public view (and possibly, from the history), right? Elitre (talk) 21:36, 10 February 2014 (UTC)

If you have objections to Flow being deployed in a community, ask the community whether it wants it. If it decides not to, I gather Flow will be disabled for it. Thanks. Gryllida 05:17, 8 February 2014 (UTC)

Where on enwiki is this deployed? πr² (t • c) 18:15, 10 February 2014 (UTC)

en:Wikipedia talk:WikiProject Hampshire and en:Wikipedia talk:WikiProject Breakfast, at the request of those two small groups of editors.

There's also a general testing page at en:Wikipedia talk:Flow/Developer test page, which apparently exists in the hope that people will do random/sandbox testing there, rather than cluttering up the WikiProject's work pages with information completely unrelated to the WikiProject's work. Whatamidoing (WMF) (talk) 20:07, 10 February 2014 (UTC)

"Show" perhaps should be "unhide"

The use of "show" for hidden comments/topics implies a temporary action, akin to showing collapsed topics on normal pages. I feel that "unhide" would be more appropriate for this, as it implies that it removes the hidden status.

A slightly related idea: maybe there should be a "show" button on all moderated posts (if you have the permissions) to temporarily show the content. Jay8g (talk) 01:32, 5 February 2014 (UTC)

Jay8g: That's exactly the plan! See image-mockup here.

There is already a "show" button on all moderated posts (if you have the appropriate permissions) to temporarily show the content - see this post for example. Quiddity (WMF) (talk) 21:46, 5 February 2014 (UTC)

Quiddity (WMF): Great! For some reason I thought that "show" was permanent and was too afraid to test that. Jay8g (talk) 02:39, 6 February 2014 (UTC)

Weird word wrapping

In the heading, the word "server" is broken in the middle. There doesn't seem to be a wikitext issue. See screenshot.

Also, the word "See" is broken in this post. Jay8g (talk) 00:51, 8 February 2014 (UTC)

Jay8g: Yup, there's a strange word-wrapping bug in the newest version. They tried a (temporary) hyphenation fix yesterday, and I'm not sure what they've settled on. (I have so much bugzilla email it's not funny). Follow the fun at bugzilla:61002. ;) Quiddity (WMF) (talk) 01:35, 8 February 2014 (UTC)

Thanks, I had also noticed the same issue in one of my messages. Gryllida 05:11, 8 February 2014 (UTC)

Not just in headers, by the way. Klipe (talk) 10:56, 10 February 2014 (UTC)

Title edit preview issues

When clicking "preview" when editing a topic title, at first nothing seems to happen, but after scrolling down (even after title save), one can see that the "reply" window has been opened, the title is previewed above that box, and extra "preview" (that do nothing) buttons below the reply box. See screenshot (after pressing "preview" twice). Jay8g (talk) 01:00, 8 February 2014 (UTC)

Jay8g: You're breeding preview-buttons and title-edits? I think a license is needed for that... (depending on what country you live in).

More seriously: What Browser/OS are you using? I'm seeing drastically different (equally odd) results in my own tests. I've filed as bugzilla:61079 for now. (and extra thanks for providing the screenshot. 'tis much appreciated.) Quiddity (WMF) (talk) 01:54, 8 February 2014 (UTC)

Quiddity (WMF): Oops, I forgot to say Vector/Firefox 26/Windows 7. Jay8g (talk) 04:45, 8 February 2014 (UTC)

Thumbnails are too small by default

Image thumbnails, by default, show up tiny. They are much smaller than in normal pages. The default size should be increased. Jay8g (talk) 01:02, 8 February 2014 (UTC)

Hmm, I'm seeing normal 220px thumbnails...

Oh, I see what you mean: I've tested changing my default-thumbnail-size preferences, and thumbnails don't change accordingly. I've filed bugzilla:61081 for this. Thanks again! Quiddity (WMF) (talk) 02:07, 8 February 2014 (UTC)

Quiddity (WMF): I should probably have mentioned that this was on preview, if that matters. Jay8g (talk) 04:49, 8 February 2014 (UTC)

Jay8g: Are Previews smaller than 220px? If so, could you take a screenshot of that, please? [Ack, wrong account] –Quiddity (talk) 22:08, 8 February 2014 (UTC)

Quiddity (WMF): Never mind, I guess I must have changed my preferences and didn't remember it. Jay8g (talk) 20:15, 9 February 2014 (UTC)

Diffs broken

On any diff page (such as this one from this post), I get
"Error
Diff operation can only be done for two revisions belonging to the same post.
Return to MediaWiki."
Firefox 26, Windows 7 Jay8g (talk) 17:37, 9 February 2014 (UTC)

Jay8g: Being tracked as bugzilla:60947. Quiddity (WMF) (talk) 19:27, 11 February 2014 (UTC)

and I think it's fixed. SPage (WMF) (talk) 01:07, 12 February 2014 (UTC)

Hard to get to permalinks of individual posts

There is no easy way to get to permalinks of individual posts. The only way I could find was to go to the topic history and click on the "comment" link of the post you want (with no easy way to differentiate between posts by the same user). There should be a link directly from the post. Jay8g (talk) 17:46, 9 February 2014 (UTC)

There is. It's in the "..." menu on the top right corner of every post (which is probably too light to be easily spotted). wctaiwan (talk) 07:58, 10 February 2014 (UTC)

Wctaiwan: OK, then, now we have a new problem. I never would have found that on my own, and still can't easily find it even though I now know it's there... somewhere. It needs to be made darker and much bigger, more similar to the topic "..." icon. Jay8g (talk) 15:04, 10 February 2014 (UTC)

A darker version of the "action menu.svg" is coming soon, as well as soon better ordering and coloring of the contents within; see mockups here. I'm not sure if it will be any bigger, I'll leave a note. Thanks. :) Quiddity (WMF) (talk) 02:28, 11 February 2014 (UTC)

Maybe the arrow in wikipedia next to the search box would be a better icon Goldzahn (talk) 03:40, 26 February 2014 (UTC)

No infinite scrolling anymore :-) But aslo no mean to access older topics anymore :-(

I cannot access any topic older than "Topic bar: potential lack of need in nick and time" (3 days ago) on this flow page: arriving at the end of this page, nothing happens and there is no link or button to make it happen either. Klipe (talk) 11:01, 10 February 2014 (UTC)

Klipe: Tracked as bugzilla:61066. Quiddity (WMF) (talk) 02:25, 11 February 2014 (UTC)

Klipe: And fixed, sorry about that! SPage (WMF) (talk) 19:59, 14 February 2014 (UTC)

Should be fixed now. MPinchuk (WMF) (usurped) (talk) 20:01, 13 February 2014 (UTC)

Maryana (WMF): Indeed, thanks. ==> This topic is a candidate for closure.

Is the announced functionality "topic closure (with summary)" already on the agenda ? Klipe (talk) 13:25, 14 February 2014 (UTC)

Klipe: More and more people are asking for it! :) Yes, I think it should be the next big-ticket item we tackle, but I'd like to check in with the WikiProjects on enwiki that are testing Flow to make sure that it should be our next priority. MPinchuk (WMF) (usurped) (talk) 18:29, 14 February 2014 (UTC)

Editing subsections

Like in this section in Talk:Sandbox, I appear to be unable to edit subsections of my message. Where I leave a long message, it may be desirable to be able to do so. Gryllida 08:24, 13 February 2014 (UTC)

Signing subsections

I may desire to create a new topic with an intro and two subsections discussed separately and sign them all — all 3 parts — separately, like so:

== Maps ==
Maps are used throughout the article but they appear to be out of date.
=== Green Park ===
The Gren Park suffered a fire and is now moved to Y. ~~~~
=== Huff Lake ===
The lake is now twice as large — since January 24 .... ~~~~

You notice that these are two distinct points which will inevitably be broken up in two and I am unable to sign them twice, with Flow. Gryllida 08:29, 13 February 2014 (UTC)

Gryllida: From the looks of it, what you want to do is achieved by making three posts in a row, and adding a ===Subsection heading=== at the top of each. WhatamIdoing (talk) 16:50, 19 February 2014 (UTC)

=== Green Park ===

The Green Park suffered a fire and is now moved to Y.

Subthread Discussion #1 Quiddity (WMF) (talk) 01:16, 14 February 2014 (UTC)

Thanks for letting us know about the fire. Quiddity (WMF) (talk) 01:18, 14 February 2014 (UTC)

=== Huff Lake ===

The lake is now twice as large — since January 24 ....

Subthread discussion #2 Quiddity (WMF) (talk) 01:16, 14 February 2014 (UTC)

I think this subthread method, could work. Quiddity (WMF) (talk) 01:19, 14 February 2014 (UTC)

=== North ===

While updating the map... May someone also think about indicating the North?

This is subthread discussion #3 Klipe (talk) 13:13, 14 February 2014 (UTC)

I also think that this subthreading method is adequate. Klipe (talk) 13:15, 14 February 2014 (UTC)

pre word wrap...

...is missing, like so:

foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar foo bar

Gryllida 08:30, 13 February 2014 (UTC)

Gryllida: <syntaxhighlight lang='text'> tags don't wordwrap by default, and so it would be inconsistent for Flow to make them do so.

If you want word-wrapping without formatting, you need to use {{Pre2 }} (T:Pre2 at Enwiki) or Extension:SyntaxHighlight GeSHi or similar. Quiddity (WMF) (talk) 01:15, 14 February 2014 (UTC)

Layout

Often I used a "Subject ..." topic for a section, and a "...rest of the sentence" content. This appears to be hardly readable, with the current layout. Gryllida 08:31, 13 February 2014 (UTC)

Gryllida: The way the current Flow is organized bothers me a lot. The first comment, aka the topic of the thread, should have the gray background and be included with the header text. The way it's currently laid out sort of makes sense for the purpose of Talk pages, but it's still incredibly confusing. The comment box that is shown by default is used for top-level discussions, not replies.

The "Reply" button is used for secondary replies underneath the first comment. It confuses the user (as exemplified throughout Talk:Flow) and can ruin the layout of discussions incredibly quickly. Most people immediately respond to the layout by using the text entry box opened by-default, regardless of the fact that they're attempting to reply to the first top-level comment.

Oftentimes I see comment threads which move around in layers frequently (e.g. top-level, secondary-level, top-level again, secondary-level), rather than being organized as a singular thread of comments which has an easily understood order. Nicereddy (talk) 01:35, 17 February 2014 (UTC)

Nicereddy: you are meditating about bug 59230, here. Vote for it. Draw a mockup of layout, which would be compact and intuitive, and attach it to the bug. Gryllida 03:22, 17 February 2014 (UTC)

comment

It seems that it is possible to add a new flow at the bottom and at the top of a discussion page. Why not at the front page too, i.e. at the bottom of an article? Maybe this would be positiv for using flow with a smartphone. (as an subtitute for the Article Feedback Tool).

My second question: We use bots to archive discussions. Will that still be possible with flow? And If flow would archive the discussion page on its own, than it could be possible that someone replies to an archived flow witch than will get out of the archive on its own.

It seems, that without a topic header it is not possible to save a new flow. I had to search some time until I recognized that.

Could you make it possible that one flow is living on more than one discussion page? For example at the user page of the person who gets the message and at the user page of the person who writes the message. Goldzahn (talk) 10:41, 13 February 2014 (UTC)

Goldzahn: I like the way GitHub does this, in that they have a "User X Mentioned this issue in another thread" which links the threads together without confusing the user and making them the same exact thread. Commenting on a single post and having the comment duplicated onto multiple pages would likely be very odd, but having a Flow header which links to wherever the original post was (e.g. a redirect link from my Talk Page to yours if I were to comment on your Talk Page) would probably make sense to most users. Nicereddy (talk) 01:29, 17 February 2014 (UTC)

Goldzahn: 1) Better linking between Articles and Discussions, has many possibilities. Anything from your suggestion of appending/embedding the two in a single window, to more selective possibilities such as having a single Topic attached to a single template (eg. imagine a {clarification needed} that when clicked would open an overlay of the related discussion, so we could see the article and discussion in the same tab. Sort of like googledoc annotations.).

Also, note that AFTv5 was disabled everywhere last week (details).

2) Re: Bots - There's an API being developed, so bots will be able to interact with Flow in various ways, once that is further along.

Re: Archives - Flow is designed to not need 'archiving' as we're used to it; instead discussions will simply age off the top of the page - As for someone replying to an old discussion, there are two features which will partially solve that - they're working on a "close & summarize" feature (like the {archive top} template-group); and also on "sorting/filtering methods" so that we can personally reorganize the displayed topics at the top of the Board, eg most active, or most recently created. It should also be possible to make an automated topic-age-based warning, eg "Are you sure you want to reply to this 2 year old topic? It might be best to start a new thread."

Re: Title as required field, thanks! Submitted at bugzilla:62404

Re: Topics appearing in more than one location - that's part of the plan :) - So eg. A discussion about deleting an article, could appear on the talkpage of the article, and at the central AfD hub, and at the talkpage of the original author, and anywhere else wanted. But also, with code hooks so that the AfD-topic could be automatically pointed at anywhere too/instead, eg at the related WikiProject(s) (Ie. more like Notifications than Transclusion).

HTH. (And sorry for the late reply.) Quiddity (WMF) (talk) 21:02, 7 March 2014 (UTC)

3 more problems about Flow

1. en:Template:Edit protected and en:Template:Unblock will not work.
2. It's impossible to categorize pages using Flow.
3. Pages using Flow can't be transcluded like en:Wikipedia:Village pump (all). GZWDer (talk) 18:42, 14 February 2014 (UTC)

GZWDer: Thanks for your comments. A page that has Flow enabled (a "Flow board") is no longer a single block of wiki text, it's more a view into a collection of individually-revisioned posts organized into topics. Some behavior of regular pages can/should/will apply, but not all.

1. I'm not sure about page protection, but eventually we will build a Flow/Block Module workflow.
2. It seems to me [[Category:Foo]] in the header of a Flow board should work, but if you've categorize an old post that now only shows up when you scroll down several times, should that categorize the Flow board?
3. How would transclusion work when a Flow board has hundreds of topics and we don't paginate them all in? Instead, some day you'll set up a "Flow feed", see some early thoughts at Flow/Basic information

• Search is coming SPage (WMF) (talk) 19:56, 14 February 2014 (UTC)

S Page (WMF): en:Template:Edit protected and en:Template:Unblock are used in talk pages, and the template will categorize talk pages to en:Category:Wikipedia protected edit requests and en:Category:Requests for unblock. is it possible using Flow?

Other unanwsered problem:

1. if moving the existing content of a talk page to an /Archive subpage without leaving a redirect, does the page probably no longer exist in MediaWiki database? Probably we can't link them in Wikidata.
2. Flow edits does not count as "number of edits".

new questions:

1. Can we read Flow content in Module (using Lua)?
2. if I type [[:en:XXX]] in a flow board, It will turns to [[en:XXX]] when modifying the submitted post, and [[https://en.wikipedia.org/wiki/XXX]] when the next time. (to reproduce the bug, write [[:en:XXX]] and trying to modify it and save it twice) [[https://en.wikipedia.org/wiki/XXX]] will not be shown correctly.
3. We can't use WikiEditor or VisualEdieor when using Flow.
4. We can't set edit summary when using Flow. GZWDer (talk) 05:09, 15 February 2014 (UTC)

Quiddity (WMF): Any answer? GZWDer (talk) 10:02, 19 February 2014 (UTC)

WhatamIdoing: Any answer about 7 questions above? GZWDer (talk) 10:28, 21 February 2014 (UTC)

GZWDer: Sure: "Not my job." I'm only here as part of the community, because I (like you) expect that I'll be using this someday, and I want Flow to work in a way that works for me, and I know that the best way to do that is to keep telling the people working on Flow what I want it to do.

But on your actual questions, for the most part, you can't do exactly what you've done in the past in exactly the same way, but you can do the equivalent. For example, you can't use the existing unblock template (usefully), but you can create a far simpler, more intuitive method of getting an admin's attention if you want to be unblocked. You can't "transclude" Flow pages, but you will be able to "associate" them with another page, and associating all the Village Pump pages with WP:VPALL will have the same effect.

Do you really need to put Flow pages in a category? What's the point of putting a discussion in a category? We've (ab)used categories as a means of getting admin attention (e.g., for unblocks), but do we normally want individual discussions to be permanently placed in categories?

Do you normally need an edit summary for posting a new message or for replying to someone's post? If you go look at page histories, most people's edit summaries are some pointless variation on "comment", "reply", "support", or similar. WhatamIdoing (talk) 20:48, 22 February 2014 (UTC)

GZWDer: Sorry for the late reply. Last week was busier than usual.

Re: Page-moves: Flow Boards, are just containers, hence they don't ever need to be 'moved'. However, the Topics within them, will be movable, once that feature is implemented.

Re: Categories: They're investigating using either categories, or some new form of #tag system, to be able to add things like which "workflow-step" a Board or Topic needs. tbd.

Re: Edit-counts, thanks! I forgot to enter that a while ago. Now submitted as bugzilla:61887.

Re: New questions:

1. One of the devs is working on documenting the API, at the moment (the initial work is at Flow/Architecture/API). I'm not sure specifically, but I'll ask.
2. Tracked as bugzilla:61725
3. WikiEditor should be added somewhat soon. VisualEditor will follow later on.
4. There was an interesting discussions about this at w:Wikipedia talk:Flow/Archive 7#Edit summaries. The outcome is: this as a next step (they're going to auto-excerpt the first 140 characters. That's what Enwiki's w:Help:Edit_summary recommends: "When editing talk pages, consider copying your comment to the edit summary, if it is brief; this allows users to check Recent changes, Page history and User contributions (see below) very efficiently." although editors rarely do. We mostly just write "reply" or even worse offer subtext that most people will never see. Further suggestions/feedback welcome! Quiddity (WMF) (talk) 02:40, 25 February 2014 (UTC)

And how to search topics? GZWDer (talk) 18:46, 14 February 2014 (UTC)

GZWDer: Search is being investigated at the moment. They were holding off until the new CirrusSearch was deployed (it's currently a Beta Feature on many wikis). Quiddity (WMF) (talk) 20:47, 18 February 2014 (UTC)

Quiddity (WMF): Will it search hidden elements as well as visible ones?

And holy cow, the font in this window is so faint I can barely read it. Risker (talk) 03:20, 20 February 2014 (UTC)

And:

1. if moving the existing content of a talk page to an /Archive subpage without leaving a redirect, the page probably no longer exist in MediaWiki database. Probably we can't link them in Wikidata.
2. Flow edits does not count as "number of edits". GZWDer (talk) 18:50, 14 February 2014 (UTC)

if moving the existing content of a talk page to an /Archive subpage without leaving a redirect, the page probably no longer exist in MediaWiki database. Probably we can't link them in Wikidata.

That doesn't make any sense at all. Talk:Example/Archive 1 can exist, even if there has never been a redirect to it. In fact, 99% of archive pages do not have redirects pointing at them. And why couldn't you link those pages in Wikidata? There's nothing special about an old-style archive page. It's just the same as any other subpage in the talk namespace. WhatamIdoing (talk) 16:40, 19 February 2014 (UTC)

WhatamIdoing: You probably misunderstood my question. For example:

1. Use en:Special:MovePage/Wikipedia talk:Flow/Developer test page to move en:Wikipedia talk:Flow/Developer test page to other page without leaving a redirect;
2. Try to link en:Wikipedia talk:Flow/Developer test page to a Wikidata item.

Can it really be linked? GZWDer (talk) 10:28, 21 February 2014 (UTC)

GZWDer: The page move is a red herring. If Wikidata refuses to link to non-existent pages, then Wikidata refuses to link to non-existent pages. Does Wikidata ever link to anything in any talk namespace anyway? It would make more sense for Wikidata to link to the article/project/content page. WhatamIdoing (talk) 20:51, 22 February 2014 (UTC)

Reply buttons and Design that prioritizes individuals over content.

I like the improvements, but the instances of the word 'reply' seem to dominate the pages.

I wanted to see if anyone else had commented on this, but a quick page search turned up 71 instances of 'reply' so I couldn't sift through it. :)

Reply

  Reply
  Reply
  Reply  

Reply

  Reply

... okay I made my point. ;)

I still feel like the option to reply should be a right side of the screen option. Not left. Gmail's reply button is an image (arrow arcing to the left), located on the right hand side. Go with something like that. I keep confusing the text 'reply' as meaningful text I should be reading. It makes scanning clumsy to my eyes.

Also, there is still too much white space vertically. :(

I think part of the problem might be that this design gives too much prominence to 'who' is replying, vs. 'what' they are saying. So far, in wiki conversations, I care more about the content of the reply, and 'who' is replying is secondary. Wiki's are about the creation of content, other discussion forums (social media) are more about 'look at me' posting. I think if the design slid the author's names back to the end of posts, and didn't give them a separate line, everything would be more readable.

That and I keep wanting to reduce the font size by 5%. Too big! I'm not 80. :) MarkJurgens (talk) 03:51, 18 February 2014 (UTC)

MarkJurgens: Thanks for this input. :)

Re: "reply" and "usernames" in the sidebar: The designers recently had a meeting about "things to potentially put at the righthand side" (to collate all our and their ideas, so far), so hopefully we'll get a synopsis of that, soon. Changes to the ongoing experimentation with UI layout are definitely possible/probable, and suggestions encouraged.

Re: fontsize: There's been a mention of both preferences, and in-page toggles (like NYTimes has in the top-right corner dropdown menu). Also with the ongoing Typography refresh, I assume they'll want to match the text sizing in that (Technically: currently the betafeature is using 0.875em, instead of the old/current 0.8em, which works out to 14px instead of 12.8px. Flow is currently using 16px). So, we shall see. :) Quiddity (WMF) (talk) 19:59, 18 February 2014 (UTC)

Quiddity (WMF): Just remember to prioritize content over interaction elements, and everything should work itself out. Reading is the primary action performed on talk pages - way above clicking on reply buttons.

This is not a newspaper article that must work for drive-by users, we expect editors to come back regularly to talk pages. For drive-by commentators, we already have the feedback box on articles themselves. Diego Moya (talk) 17:52, 19 February 2014 (UTC)

(I'm starting to become concerned with how frequently people from the WMF point out to newspapers and Q&A sites as their inspiration for the Flow design. Those sites are not designed at all to support a sustained conversation, so they're a terrible example to follow - their purpose is entirely different. Where are all the examples and comparisons with discussion forums such as phpBB, Discourse, the Slashdot beta -ok that one is not a good example-, etc?). Diego Moya (talk) 18:20, 19 February 2014 (UTC)

Diego Moya: I purely meant, for non-logged-in users, NYT has great typography options: http://i.imgur.com/7U3yAoF.png (I've seen this dropdown-for-text-sizing idea elsewhere, too, But NYT is the one I remember.) It was mentioned in regards to implementing it in Winter. Nothing to do with Flow - I was just wanting to indicate "preferences/options" regarding the large text, might solve it for everyone, because some people like it. :)

Also, Ha! at the Slashdot reference. Yeah...

Re: The feedback box on the articles: Nope, that's being disabled at the end of the month. See w:Wikipedia talk:Article Feedback Tool/Version 5#Article Feedback: Next Steps Quiddity (WMF) (talk) 02:57, 22 February 2014 (UTC)

Why is the color of usernames different to the color of normal Wikilinks?

I just noticed that the usernames of Flow posts have slightly different colors than normal Wikilinks.

E.g. User:Patrick87 has a color of #0645AD and User:Unknown User has color #BA0000.

However the usernames used in the headers of Flow posts have colors of #3C68B1 #A55858.

Why this inconsistency? Please change the code to use the same Link colors as are used everywhere else. Otherwise it's not only inconsistent but can be easily mistaken as an already visited link. Patrick87 (talk) 21:07, 18 February 2014 (UTC)

Patrick87 & Nicereddy The colors are from design mockups but I'm not sure the color variation is intended, or worth it. I filed bug 61890. SPage (WMF) (talk) 05:32, 25 February 2014 (UTC)

S Page (WMF): Thanks, much appreciated! Patrick87 (talk) 09:53, 25 February 2014 (UTC)

I also noticed this and it bothers me quite a bit. #A55858 looks washed out and ugly to me, hopefully it's just a minor oversight or bug. Nicereddy (talk) 02:42, 19 February 2014 (UTC)

I don't think it will be confused with an already-visited link, because those are purple, not light blue. It might be confused with an interwiki link (like the link on your userpage to the German WIkipedia). And since it's possible that a discussion could happen cross-wiki, then this may not be entirely inappropriate. WhatamIdoing (talk) 16:35, 19 February 2014 (UTC)

WhatamIdoing: I already mistook a redlinked Flow-username with a visited Wiki-redlink (visited Wiki-redlinks have color #A55858 which is exactly the same color as redlinked Flow-usernames!). Therefore it is a serious problem for redlinks. Blue links are better, but I see no reason to introduce inconsistencies on purpose. Using different colors only makes the UI less clear for no real reason.

Besides that the chosen colors look somehow washed out (they're lacking color saturation). Therefore it even looks bad from a design perspective.

P.S. I didn't get what you were trying to say with the second/third sentence in your reply above?

P.P.S Why did you (and also User:Nicereddy) reply to the topic instead of my post? You posted answers to my post so you should have replied to it, right? Are you already "playing the system" to compensate for the limited nesting depth of Flow? If you are, this is a design fault in Flow and should be accounted for. Patrick87 (talk) 17:48, 19 February 2014 (UTC)

Patrick87: I've done this somewhat consistently and always accidentally. As WhatamIdoing said, we used the box that is opened by-default at the bottom of each thread. In my rush to comment, I forgot about the reply button. This is my own mistake, and something I've commented on previously.

I think Flow could do very well to improve its structure. The first comment should be part of the header-title, not a comment itself. This causes the exact problem we're currently discussing, that being that the first reply is at the same depth-level as the main post itself. Obviously, this kills any attempt at proper organization of content, as Flow is and should be trying to do.

I should also note that, because I'm posting this comment now, the thread will be even less organized because it will go between your post and WhatamIdoing's reply. Hardly her fault, simply a mistake caused by the current iteration of Flow. Nicereddy (talk) 04:46, 20 February 2014 (UTC)

We are using the very convenient box at the bottom of the thread, rather than clicking on the little "Reply" button.

For the rest, compare the colors Special:Random vs w:cs:Special:Random (on a regular wiki page; I don't think that Flow distinguishes between them). These are not the same on a non-Flow wiki page. But the second is at least similar to the color that Flow is using for usernames. WhatamIdoing (talk) 19:35, 19 February 2014 (UTC)

Sorry, but this totally does not make sense. You're actually giving up the point of threaded discussions (which Flow is supposed to offer) and are using Flow as an ordinary forum works (without any nesting). I'm a little scared, that even WMF employees "misuse" Flow like that so early in it's development. How is Flow ever supposed to work efficiently if it's not used as it's supposed to?

Edit: I'm not blaming you for it, don't understand me wrong. But if you "use the very convenient box at the bottom" (which is meant to be used to reply to the topic) when you're actually replying to a post of me (for which we specifically have the "Reply" button), then we have a design problem regarding Flow!

Regarding "the rest" (the actual topic, I assume I'm going to create a new topic for the above): You're right, actually Wikilinks and Interwikilinks have different colors (#0645AD for Wikilinks compared to #3366BB for Interwikilinks). This difference is so slight at normal text sizes that I was never able to spot the difference at my display. Actually a useful feature (font colors might have to be tuned though)!

This however makes it even more important to change the color of Flow-usernames. Since they are leading to the local userpage, they are Wikilinks and should therefore never be given the same color as Interwikilinks! Patrick87 (talk) 20:04, 19 February 2014 (UTC)

Quick update, that bugzilla:61890 is resolved. Quiddity (WMF) (talk) 23:02, 4 March 2014 (UTC)

Patrick87: I agree 100% with your point about threaded discussions: Replying to a certain post should be the usual interaction on an existing topic.

Regarding the actual topic, I agree with you as well, except about the point to make the colour fixed like you seem to consider in the end. I think that the same set of colours should be used on usernames as on any other links, with the same meaning for each colour. In the future, when we'll have topics possibly on multiple Flow boards on multiple wikis, it would make sense to have the same link appear in "local blue" on a board and in "remote blue" on another board. And the same would apply to usernames if the target transwiki implementation of Flow would make use of something like a "home wiki" preference associated with the SUL account. Klipe (talk) 20:15, 19 February 2014 (UTC)

Patrick87:

Who says that they'll always be local wikilinks? Flow is supposed to handle cross-wiki discussions (e.g., people at a Wikipedia can comment on a deletion discussion at Commons without leaving their home wiki), so the userpage might actually be an interwikilink from the perspective of a person reading from Commons.

Also, there's an interesting bug open about having centralized user pages (hosted at Meta), in which case some people's "normal" user page would almost always be an interwikilink. WhatamIdoing (talk) 20:33, 22 February 2014 (UTC)

Klipe: Why exactly should people be pushed into replying only to one person's comments instead of to the whole thread and/or multiple posts in the thread?

Also, if you have a discussion involving people from multiple projects, do you think that it's a good idea to visually distinguish "locals" from "tourists"? It seems to me that this might have the unfortunate effect of some people's comments being unfairly disregarded because they're "not part of the community". WhatamIdoing (talk) 20:38, 22 February 2014 (UTC)

WhatamIdoing: Nobody says that. The moment the username links to another project we can use the Interwikilink colors for that username as far as I'm concerned. Currently however all usernames are linking to local userpages. Therefore they are clearly normal Wikilinks and therefore should use Wikilink colors.
Anyway this still does not explain how we suddenly got different colors for redlinked usernames which look like visited redlinks (when they are not). Since there never was (and maybe never will be) an Interwiki-redlink it's inconsistent at this point for sure. Patrick87 (talk) 21:44, 22 February 2014 (UTC)

WhatamIdoing:

==== About replies ====

See the dedicated topic Klipe (talk) 22:20, 22 February 2014 (UTC)

WhatamIdoing:

==== About username colours ====

In trans/cross-wiki discussions, I would just consider it normal to have the username colours follow the same conventions as any other wiki links, i.e. distinguishing between local and remote wiki, knowing that these notions depend on the perspective since the same topic may be viewed as part of boards on multiple wikis. Honestly, I didn't even think of a risk to consider some users as "not part of the community"... An interesting point, indeed.

If that's the reason to make all usernames appear the same, then maybe the colour dedicated to usernames should be significantly more different from other wiki links. Not because it's useful to usernames themselves but rather to avoid breaking the convention established for other wiki links. But does it even make any sense to point to a certain user page? Which one to choose?

I think that Flow should be built for a target situation where each user would have just one global user page instead of one user page per wiki. Probably these would then be stored in a dedicated wiki. Keeping the established wikilink convention, the username colour would then be "remote blue" anywhere, except on user talk pages (stored on the dedicated wiki for user pages) where it would be "local blue" for all usernames. Alternatively, a dedicated username colour could still be picked as in "another approach" above. In both cases, the risk to view some users as "not part of the community", vanishes. Klipe (talk) 22:41, 22 February 2014 (UTC)

User:WhatamIdoing & User:Klipe on a side note:

If being afraid to make people unequal by differentiating link colors is an issue, making everybody a "stranger" by exclusively using Interwikilink colors is not really an improvement I assume.

If you want to express equality and unity then making all links colored like internal Wikilinks would be the way to go.

Anyway I think we got to a point were the discussion is rather academic (I'd never have come up with the idea that the link color is expressing the relation of a user to the project he's posting to). My initial idea of the topic was purely technical in that the very first priority should be to make link colors distinguishable and unambiguous. A fundamental web-design paradigm which we're badly violating right now. Patrick87 (talk) 23:16, 22 February 2014 (UTC)

Patrick87: I agree. The main point is that different colours should mean different things while the same colour should mean the same thing, plus the fact that different colours should actually be significantly different from each others.

About the community, well... I also don't think of colours in that way, and in general I wouldn't consider anyone -- including IPs -- participating in a discussion as not being part of the community (except in most cases of vandalism). I may however conceive that some people could react in another way. WhatamIdoing, did you see such situations happening? Or do you know of any study on that matter? Klipe (talk) 09:42, 23 February 2014 (UTC)

Klipe: It happens with IPs all the time, but you'll find it in AFDs (on, say, BLPs about people who are not famous in English-speaking sources, some "single-purpose accounts" are actually people with hundreds of edits at non-English projects). You'll also find it happen at Commons, usually as a claim that a person's view is completely invalid because they think Commons works like the English Wikipedia.

Additionally, there are a number of Wikipedias who have specific requirements for voting (most non-en.wp projects actually use straight out voting for many purposes). I believe that it would be "illegal" for you to vote in RFCs at both es.wp and de.wp, despite having made 3600+ edits so far, because only edits at their specific projects "count". But don't feel too bad: I believe that it's nl.wp that would not only refuse to count my view, but actually bans people like me, because only 28% of my en.wp edits are in the mainspace, and all "good" editors maintain at least 33%. Your contributions at fr.wp would be considered much more respectable by their standards. WhatamIdoing (talk) 06:21, 25 February 2014 (UTC)

WhatamIdoing: OK, I understand better. I know about such cases as well, but I don't recognise them as being considered "not part of the community", except indeed the case you mention about Commons. For instance, I find it normal not to have a right to vote in a project where I almost never contribute, while probably I have the right to participate in the discussion and bring arguments to the attention of those who have the right to vote. This is just a certain member status, as autopatrolled or sysop: the community decides on the rules to apply to itself, including granting some of its (would be) members some advanced tools or the right to vote. And those rules and rights have not much to do with colors! Especially now with SUL and later on with trans-wiki Flow boards... Klipe (talk) 19:57, 4 March 2014 (UTC)

Klipe: I find it normal to participate in any decision that affects me, even if I'm new to the group. I find it silly to exclude the voice of a subject-matter expert, merely because the expert is new to the group. People make bad decisions when only "the right kind of people" are allowed to participate. WhatamIdoing (talk) 17:43, 7 March 2014 (UTC)

Legal requirements

In the add comment view:

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

is so vague and small (GRAY TEXT AAAAAAAAAAAAAAAAA when are designers gonna FFFF'ing learn), we might as well remove it. —TheDJ (Not WMF) (talk • contribs) 10:08, 19 February 2014 (UTC)

I concur - this is not something we want our new users to miss. It should be placed in high contrast and near the Reply button so it's impossible to miss, at least for unregistered users and not-autoconfirmed accounts. Diego Moya (talk) 17:42, 19 February 2014 (UTC)

Diego Moya and TheDJ: Hmm, Firefox style inspector says it's using black text. I'll ask what's going on [wrong link removed]. [Edit: Ah, it's got an 0.6 opacity applied. Ok, I'll follow this up.] Quiddity (WMF) (talk) 22:09, 27 February 2014 (UTC)

"When are designers going to learn"

The answer appears to be "when all designers have reading glasses and cataracts".  ;-)

It's a challenge in the overall industry right now. Last year, my bank redesigned its website, and most of the data ended up about six pixels tall in the initial release—even smaller than this text. And light gray is so trendy: I complained about it in a newsletter, and the young woman said, "Oh, no, we don't use 50% gray, it's 80%". I had to show her the source, where it said 50%, before she would believe that I was actually having trouble reading it. (They changed to 100% black, which made me very happy.)

It looks like this particular text is <div class="flow-terms-of-use plainlinks">, so presumably it could be adjusted locally in CSS. WhatamIdoing (talk) 16:24, 19 February 2014 (UTC)

WhatamIdoing: How was that saying? "Youth is a disease that heals through the years." :-) Diego Moya (talk) 17:45, 19 February 2014 (UTC)

It looks like there's some confusion about the problem this text string is solving for: there's the community perspective (deterrence of inappropriate contributions, e.g. copyvio) and the legal perspective (e.g., requirements the WMF has to follow in order to not get slapped with a lawsuit).

While I'm sympathetic to the community perspective, the truth is that no amount of black/bold/blinking warnings and disclaimers are going to deter copyvio; they're much more likely to distract and possibly scare away potential good-faith contributors. If you look at some of the edit forms we have out there on our projects (ukwiki is a good example of one I contribute to), they're pretty terrifying, and so cluttered with warnings and disclaimers that it's hard to even find the save button. Until about a year ago, when WMF designers drastically cut the cruft out of the enwiki edit form, enwiki was just as bad. This kind of visual clutter and lack of information hierarchy is something we're actively fighting.

From the legal requirements side, this text is really a nice-to-have, and mostly a courtesy to our legal team – we already have this information in our Terms of Use (linked to on every page), but there's a lawsuit a few times a year from someone who wants to reclaim their ownership over some piece of content, and it's just easier to present a screenshot with legal text next to the submit button than to go through the trouble of fighting it. It's important to remember, though, that this use-case is less of an issue on talk pages; they're frequented by a much smaller and more experienced population, and (especially if they don't look exactly like an article, as Flow pages don't) it's less likely that someone will submit some long piece of text that they claim copyright ownership over and then get mad enough to sue when it's no longer "theirs."

So, this text should not have the same level of prominence as the rest of the reply form. I do agree that it's looking a little too washed out now, but I don't think it's a huge deal given its secondary importance to the main actions in the UI. MPinchuk (WMF) (usurped) (talk) 20:19, 6 March 2014 (UTC)

So, we are going to NOT care about the fact that our community wants people to actively think about the actions and their consequences that the actions have in terms of licensing ? About the fact that our community when confronted with the question: "Would you please revoke my permission to share this text for ever and ever", with the statement: "You can't, it said so right next to your save button" ?

I find that a very worrisome statement. There is a big difference between plastering something all over the place, and having a notice as far as I'm concerned.

How about instead we actively track giving permission, by way of a dialog, with a permission that is saved in the database for all registered users? Then we can have a readable statement for unregistered users, and remove it for users who are registered.

If terms change, present the dialog again, and update the permission statement. Very simple. Perhaps a yearly reminder ? Just some thoughts. —TheDJ (Not WMF) (talk • contribs) 21:03, 6 March 2014 (UTC)

TheDJ: "How about instead we actively track giving permission, by way of a dialog, with a permission that is saved in the database for all registered users? Then we can have a readable statement for unregistered users, and remove it for users who are registered." That's precisely the long-term plan :) It's a much, much better UI pattern to ask explicitly up-front on registration, instead of relying on disclaimers that most people tend to ignore due to banner blindness. It's just going to take some time and leg-work to implement. It's unlikely that Flow will be deployed widely before that work happens (Flow's not going global until at least 1-2 years from now), so this is a stopgap in the meantime. MPinchuk (WMF) (usurped) (talk) 00:58, 7 March 2014 (UTC)

prefer current ("old") system

Sorry, I don't like this new format. Recent experience: some days ago I came to this wiki (media) wanting to say how I enjoyed my VisualEditor experience at pt.wikipedia, and ask if/when it was going to be available on en.wikiquote, but decided not to post anything because "Flow" was enabled ([edit: LiquidThreads was enabled, not Flow]), which made discussions look too official and intimidating. It was off-putting to me, and I don't like the thought that this will soon be forced on all wikis, though that may be just because I'm used to the "old" system. Anyway, I hope you guys know what you're doing (if this actually does make people more willing to participate in talk page discussions, and easier for them to ask questions and get help, then great); good luck. DanielTom (talk) 23:13, 19 February 2014 (UTC)

Flow is only enabled on a couple of pages. I think you mean LQT, but I may be wrong. VE#Timeline only shows times for Wikipedias, which is the sister project the WMF mainly cares about (as it is by far the best known) πr² (t • c) 23:19, 19 February 2014 (UTC)

Quote: "VisualEditor may be offered to users at non-Wikipedia projects, such as Commons or Wiktionary, after deployment to the Wikipedias has completed. No timeline has been set for this." πr² (t • c) 23:20, 19 February 2014 (UTC)

Ah, sorry, you're right. I was thinking of this format, which looked like Flow to me, but seems I was wrong. I'll do some experiments with Flow on the sandbox, and give it a chance, before commenting again. DanielTom (talk) 23:25, 19 February 2014 (UTC)

Q: Why does the caption for a picture not show at the first comment (start of topic), but then show in the comment to it? (here) (never mind, solved) DanielTom (talk) 23:33, 19 February 2014 (UTC)

never mind, I figured it out (am I flooding this thread with comments? Is there a way to delete comments with Flow?) (and if ~~~~ doesn't work, will people who like to personalize their signature be disappointed?) DanielTom (talk) 23:35, 19 February 2014 (UTC)

DanielTom: There's a way to delete comments (or hide them). Click on the little "..." in the corner of a post and you'll get the menu.

And don't worry about spamming the thread. We're testing; everyone is patient. Jorm (WMF) (talk) 23:43, 19 February 2014 (UTC)

Jorm (WMF): thanks. I edited my comment: do you worry about people who want to personalize their signature? DanielTom (talk) 23:45, 19 February 2014 (UTC)

DanielTom: I have thoughts on signatures, but it's highly unlikely we'll allow anywhere near the degree of customization that exists now. We're thinking a "Display Name" field will be the best solution (so I could appear as "Brandon Harris" and link to "Jorm (WMF)", but it wouldn't allow me to make my name bright green or have images or anything). Jorm (WMF) (talk) 01:30, 20 February 2014 (UTC)

Jorm (WMF): any reason to not allow sigs like we have them now? πr² (t • c) 13:00, 21 February 2014 (UTC)

PiRSquared17: There's the short and logical list of problems at w:WP:DEFAULTSIG (<-- my personal stance, and probably the clearest explanation), and the highly-divisive showcase of the issue at w:User:Athaenara/Gallery and w:User:Athaenara/Gallery/Beyond, and also the FAQ answer.

There's also a recent discussion that touches on this, and another archived discussion (but they both cover multiple other topics).

HTH. Quiddity (WMF) (talk) 22:10, 21 February 2014 (UTC)

I think you can hide your own comments, but you may need to be an admin to do so. πr² (t • c) 23:42, 19 February 2014 (UTC)

PiRSquared17: Yup, any user with an account can hide posts ("flow-hide" in Special:ListGroupRights) (configurable, and to be discussed further soon, as I mentioned on IRC). –Quiddity (talk) 01:40, 20 February 2014 (UTC)

Only admins can edit other users' posts. πr² (t • c) 23:43, 19 February 2014 (UTC)

PiRSquared17: Hmm, interesting. I don't understand the rationale. I think either everyone should be capable of editing other's comments (as in the current system), or no one should be allowed (—why only admins?) [For example, even in wikis where there are many admins, it is usually regular editors who revert/delete insulting comments--apparently, in this system we would have to wait for an admin to do it.] DanielTom (talk) 23:49, 19 February 2014 (UTC)

DanielTom: I'm not a fan of admin-only by default either. Apparently each wiki will be able to change their settings, but I'd rather just let anyone edit any comment on Wikimedia wikis (provided they aren't blocked) πr² (t • c) 23:53, 19 February 2014 (UTC)

PiRSquared17: Another comment: there doesn't seem to be any quick access menu in this system, for example for special characters, or dashes (—), I guess because they are trying to make the interface cleaner and simpler? DanielTom (talk) 23:58, 19 February 2014 (UTC)

DanielTom: sorry for replying in the wrong place, see below πr² (t • c) 00:01, 20 February 2014 (UTC)

You don't see the keyboard icon when you're typing? The "input tools" thing (as it calls itself) seems to only support typing in different keyboards like Cyrillic script ones, and has no special characters list. Maybe Jorm (WMF) can comment on the design. πr² (t • c) 00:00, 20 February 2014 (UTC)

PiRSquared17: You mean the small one at the bottom right, that appears in all other wikis? It doesn't look like a quick access menu to me, it only shows language options, and says I am using "native keyboard" (whatever that means) DanielTom (talk) 00:04, 20 February 2014 (UTC)

DanielTom: yeah, it doesn't support adding symbols (but it should IMHO, file a bug?) πr² (t • c) 00:06, 20 February 2014 (UTC)

PiRSquared17: It's not a bug, just a questionable option. :-) DanielTom (talk) 00:08, 20 February 2014 (UTC)

DanielTom: seems like you figured out how to hide comments πr² (t • c) 00:14, 20 February 2014 (UTC)

PiRSquared17: anyone can still see them though. So it can actually be deceiving, say if I post something really stupid (e.g., my home address) and then hide it, without realizing others can still see it. I don't see the value of this feature. DanielTom (talk) 00:19, 20 February 2014 (UTC)

DanielTom: it's supposed to be the replacement for rollback, at least for now. This is not even its final form. πr² (t • c) 00:20, 20 February 2014 (UTC)

PiRSquared17: hide, a replacement for rollback? How? I can only hide my own posts, I can't hide yours, or vandals'. DanielTom (talk) 00:21, 20 February 2014 (UTC)

DanielTom: Not a dev, but I agree that limiting access to what used to be basic features like editing and undoing to admins will not help in the long run. πr² (t • c) 00:33, 20 February 2014 (UTC)

PiRSquared17: also, a good thing about this system seems to be that there are no diffs. At least I can't find them in the edit history. So if I say something bad, it will be harder for admins to provide the diff, thus delaying possible blocks. :-) DanielTom (talk) 00:37, 20 February 2014 (UTC)

DanielTom: You mean like this? ;) They're harder to find (you have to know where to hover over), but they're there. πr² (t • c) 00:41, 20 February 2014 (UTC)

PiRSquared17: ah, very good. what about the "Thank" function? Was it all for nothing? DanielTom (talk) 00:42, 20 February 2014 (UTC)

DanielTom: I don't think it's available in Flow (yet). πr² (t • c) 00:45, 20 February 2014 (UTC)

PiRSquared17: it looks like an easily implementable feature, so it will probably be added soon. One final observation: in this system we don't type edit summaries. I guess they are not considered important in discussions? DanielTom (talk) 00:55, 20 February 2014 (UTC)

DanielTom: ask Jorm πr² (t • c) 01:13, 20 February 2014 (UTC)

PiRSquared17 and DanielTom: The keyboard icon is nothing to do with Flow. You must have enabled ULS in your preferences, after it got disabled, because that's where it comes from ;)

Flow/Thanks is being worked on by two Facebook Open Academy students.

Edit-summaries: There was an interesting discussions about this at w:Wikipedia talk:Flow/Archive 7#Edit summaries. The outcome is: this as a next step (they're going to auto-excerpt the first 140 characters. That's what Enwiki's w:Help:Edit_summary recommends: "When editing talk pages, consider copying your comment to the edit summary, if it is brief; this allows users to check Recent changes, Page history and User contributions (see below) very efficiently." although editors rarely do. We mostly just write "reply" or even worse offer subtext that most people will never see. Further suggestions/feedback welcome!

[Edit:] Anyone with an account should be able to hide anyone's post. However, this is definitely one of the more confusing new-features, and I'll be starting a discussion about it in the next few days.

[Ack, wrong account. This should be User:Quiddity (WMF). Sorry, long day. :] –Quiddity (talk) 01:50, 20 February 2014 (UTC)

Quiddity: I agree most edit summaries in discussions are useless (e.g., "cmt"). The exception to this is when someone is only correcting typos, or doing some other minor edit, like formatting—then edit summaries are useful. I don't know if that will be necessary in this system. At first sight, including an edit summary section would actually seem to be counter to what this system pretends to achieve, a less complicated interface. Maybe there should be a possibility to mark edits as "minor", though, so that people don't get repeated notifications just because others are correcting a typo. DanielTom (talk) 15:46, 20 February 2014 (UTC)

Quiddity: in other wikis, in the notifications, a quote appears of what the editor said. Here the same is implemented, but it doesn't seem to be working properly, the quotes should be extended. At least in my notifications, the quotes are always the same, and just: "Dan...", which is close to useless. DanielTom (talk) 15:55, 20 February 2014 (UTC)

DanielTom: There are some definite inconsistencies and quirks with Notifications. Sometimes I get an excerpt, but usually just a name of the topic-title. I suspect this needs a complete overhaul of the messaging (as do all aspects of Echo's messaging. It's got some different outputs for the flyout vs special:notifications vs email, which need to be worked on.) So much to do! (the developers start twitching beyond typing-ability, if we feed them more caffeine, so that's out..) Quiddity (WMF) (talk) 23:20, 21 February 2014 (UTC)

PiRSquared17: While the biggest Wikipedias allow anyone to change any comment (within pretty narrow limits), I believe that there are other projects where that's a blockable policy violation.

But as you've noted, it need not be admin-only; that just happens to be how it's configured at the moment. You could set it to anyone, to autoconfirmed, to reviewers, to a new setting—anything.

I haven't so far seen anyone in these test discussions mention that they have actually needed to change other people's comments, so perhaps that's not an unreasonable setting for the moment. WhatamIdoing (talk) 20:28, 22 February 2014 (UTC)

WhatamIdoing: blockable policy violation^{[citation needed]} ;) I would consider that somewhat anti-wiki if it also disallowed fixing MediaWiki syntax or links. Anyway, I'm not here to debate policy. I just find this an odd default. πr² (t • c) 00:56, 23 February 2014 (UTC)

WhatamIdoing: Beside a need to change other people's comments as you might not think of, there is also the willingness

• to help (e.g. correct wiki-syntax, typography or even natural language grammar/orthography for those many non-native speakers that we all are somewhere)
• to make discussion pages more accessible (e.g. adding {{lang}} around foreign language text, alt descriptions to images, clear col/row scopes in tables...). Klipe (talk) 09:30, 23 February 2014 (UTC)

Sure, one could do useful things when changing other people's comments. One could also vandalize them, remove "personal attacks" that aren't actually personal attacks, blank them, and make other inappropriate changes.

Rather than allowing IPs to do this at all 800+ projects, it might make more sense to limit it to a subset of the community. Exactly what the subset is, is something that can and should be decided by each community.

The people working on Flow have said that this is not set in stone. They have actively designed this to be configurable. I believe they'd be happy to change it... as soon as someone has a practical need to edit another person's comments, which hasn't happened yet. Perhaps it is good for us to be reminded how rare this kind of action is. WhatamIdoing (talk) 15:17, 25 February 2014 (UTC)

If I am seeing this correctly, the good side of this system is that it is much faster, and more intuitive, ==> easier for newcomers. On the down side, editors seem to lose some liberty/creativity in editing discussions: it's all standardized now. (Apparently even signatures will be standardized?) [I don't know if they plan on adding a quick access menu for common symbols, characters, and formatting, as is available in all wikis, but it's something worth considering.] DanielTom (talk) 00:30, 20 February 2014 (UTC)

DanielTom: Adding the Extension:WikiEditor is on the to-do list. Similarly, VisualEditor will eventually become an optional choice, for those who prefer it. –Quiddity (talk) 02:00, 20 February 2014 (UTC)

(Quiddity: I don't know how the VisualEditor will be compatible with this system; or will there be two [three?] different systems for TP discussions [source, VE, Flow], which the editors will be able to choose for themselves?) DanielTom (talk) 16:00, 20 February 2014 (UTC)

DanielTom: Subject to per-wiki configuration, users would be able to choose how they want to enter and edit posts. Their choice wouldn't affect how other users see the Flow board and its topics. SPage (WMF) (talk) 21:43, 21 February 2014 (UTC)

DanielTom: Indeed, as S says, there will eventually be 2 systems, for both Flow and EverythingElse: Source, or VE.

Currently, the devs are only concentrating on Source-mode editing (which Extension:Wikieditor is the edittoolbar component of). VE will (supposedly! because Flow is running on Parsoid) be a somewhat-easy drop-in addition, in the future. Getting it to work with Source-mode editing, for us old/powerusers, is hence the focus to begin. Quiddity (WMF) (talk) 22:17, 21 February 2014 (UTC)

"View source" action needed

I don't know if this was discussed before, but as one is not able to edit other users posts without admin rights, one is also not able to view the Wikitext of those posts. This is bad in my opinion since it makes it impossible to copy code from others. If people do not explicitly use <code> and <nowiki> tags it's not possible to discuss specific Wikitext snippets.

Therefore I think a "view source" action would be badly needed. Other thoughts? Patrick87 (talk) 10:46, 20 February 2014 (UTC)

Patrick87: I would like this as well. I've learnt a lot of wikitext from viewing the source of other users' posts. Hiding it behind the "three-dot" menu would work for me without complicating the interface for less advanced users. Nicereddy (talk) 00:53, 21 February 2014 (UTC)

Nicereddy & Patrick87: I mentioned this need several weeks ago, with "learn by example" as a major argument in favor of it, and it was then added to WMF's long to-do list.

Unfortunately, with Flow-related design ideas and discussions now spread over so many regular talk pages and non-searchable Flow boards on at least 3 different wikis (WP:en, MW and wmflabs), and WMF having just switched from one to another project management tool, I just don't find back any traces of this suggestion anymore. :-( Hopefully those at WMF still remember? Klipe (talk) 15:41, 21 February 2014 (UTC)

Patrick87, Klipe: I filed this request as bug 60465. If something isn't filed as a bug, assume people won't remember :)

As a poor workaround you can Inspect element or View selection source of a post and see Parsoid's representation of the original wikitext in data-parsoid HTML attributes, but that's mid-level computer science. SPage (WMF) (talk) 21:34, 21 February 2014 (UTC)

S Page (WMF): One can only do it wrong: If one reports an issue to bugzilla which may have the potential for further discussion the "Bugwranglers" (I'm not referring to André Klapper specifically but I don't know a better word right now) blame one for not bringing it up on Wikipedia discussion pages or on the mailing lists first. If one writes it to the appropriate talk page (as in this case) one is told that it will be forgotten anyway if it is not reported to bugzilla.

Somehow contradicting hints... Especially in this case as Talk:Flow is often recommended as the "right place for feedback regarding Flow". Might be an issue to bring up in some WMF meeting and discuss better ways to efficiently direct feedback into the correct channels?

Regarding your workaround: I don't find any Wikitext in the data-parsoid attributes. I assume this is at most Parsoid's internal representation of Wikitext in contrast to the Wikitext we know? Anyway I hope this issue will be fixed eventually, so this shouldn't be a problem anymore then... Patrick87 (talk) 22:15, 21 February 2014 (UTC)

Thread structure of Flow needs improvement

I noticed in multiple topics on this page (e.g. here), that threaded discussion is not really taking place.

The problem is that people reply to a specific post by using the "Comment on {topic title}" box. Therefore they're replying to the topic on the lowest nesting level when they actually wanted to reply to a specific post and the answer should thus have been on a higher nesting level.

I see two problems here:

1. The design is tempting people to just use the most obvious way to reply (which is currently "the reply to topic" box). I assume that the "reply to post" button is much to inconspicuous.
2. The intended structure (initial comment by topic starter is created as first post of a topic) is not optimal. People consider the content of the first post of the topic to be the content of the topic. Therefore if they reply to a topic they think this is equivalent to replying to the first post (which it is not in Flows current design)

In my personal opinion number 2 should be reconsidered as this might solve number 1 at the same time. I'm open for other thoughts though! Patrick87 (talk) 11:01, 20 February 2014 (UTC)

How should i interpret the silence? I hope my post did not sound rude but I'm seeing a real (and fundamental!) issue here which should not be taken lightly. Patrick87 (talk) 22:18, 21 February 2014 (UTC)

Silence usually means that people are busy with other things.

For most discussions, I don't think that "proper" threading is important. My reply here is to both our your posts; I'm not even sure what "proper" threading would look like. That's common for discussions: I'm replying to everything that went before, not specifically to your first or second message. WhatamIdoing (talk) 20:20, 22 February 2014 (UTC)

WhatamIdoing: So your reply is on both on my posts and you replied to the topic (therefore to none of them). Congratulations!

I don't know what is actually considered important about Flow (and what people might be "busy" with) but if proper threading and therefore a reasonable discussion structure is not considered important then I'm afraid I'm at a loss with Flow.

Why do we even design a "modern discussion and collaboration system for all Wikimedia projects" if we then come up with something each and every forum software has offered years ago? Patrick87 (talk) 20:34, 22 February 2014 (UTC)

Patrick87: Is this not a "reasonable discussion structure"? Are you honestly confused about what I say, how my comments relate to the discussion, or whom I'm talking to? WhatamIdoing (talk) 22:02, 22 February 2014 (UTC)

WhatamIdoing: Yes I am!

What if people post replies to my second post in this thread? Nobody will ever get why you wrote something about "silcence" somewhere down the topic at that point (even if it currently is the third post and therefore next to my second post – that might change and then your post doesn't refer anymore to what I said).

Right now the discussion is between you and me and doesn't contain many posts (therefore I can calm you that I still can figure out what we're talking about). But if the system already shows weaknesses when two or three people are having a conversation with only few posts – how is it supposed to be fit for full grown cross-project discussions with hundreds of participants and countless posts?

In the other thread you're writing that you want to be able to reply to multiple people: That's something Flow actually does not really support at this point. By replying on a higher level you're not replying to everything that was before but you're starting a new branch of the conversation, maybe with a new argument to talk about. By exploiting this to "reply to multiple posts" you're destroying the bit of threading that is possible in Flow currently and force an unthreaded forum-like discussion structure. This however gets disturbed as soon as people use the system "correctly" and therefore "squeeze in" comments before your post destroying the chronological sequence of arguments. Patrick87 (talk) 23:00, 22 February 2014 (UTC)

WhatamIdoing: Currently I'm replying to your post that's at the top level, despite my comment being placed below all of Patrick87's comments.

Preferably, the discussion would be threaded in a similar way to how reddit is. Imagine if you tried to have that same conversation with people jumping around in the "levels" which their comments are placed. It'd be impossible to read.

Currently, this is more like Facebook or YouTube's comment system. The threaded discussions go one level deep and that's it. On Talk pages currently I've seen and been involved with threads which went 7-levels deep. If everyone in a conversation like that started using the top-level instead of threading it, or even threading it to a single level, it'd be unreadable and a complete mess. Potentially moreso than the clusterfuck that is Talk pages presently.

While it's not your fault for replying in the most convenient way, it does cause large problems in how the conversation is structured.

Again, I see reddit as the way we should go for this (albeit, without the upvote system). Already, people use the indentation provided by colons in Wikitext to make threaded conversations which are incredibly similar to that of reddit, but nothing like Flow. If we want Flow to be accepted by the community, and god do I hope it is, it should have the capability of handling multi-level threaded conversation which allows for the conversation to branch off between different replies to the same comment, rather than having them all listed in a single row. Nicereddy (talk) 06:50, 23 February 2014 (UTC)

Nobody will ever get why you wrote something about "silcence" somewhere down the topic at that point

And if I'm the second person to reply to you, and we have a long sub-thread based on the first person's reply to you, then we have exactly the same "problem", even though everything was don't "properly", according to your definition of "proper". WhatamIdoing (talk) 06:06, 25 February 2014 (UTC)

=== Flat vs current vs improved vs "branching and merging" ===

It's already very much difficult to follow a discussion that makes use of the full capability of the current paradigm (i.e. either comment at topic top-level or reply to individual post with only one-level depth visual indent complemented with "being replied to" username).

The current paradigm with just one level indent could be made a bit more efficient by identifying the post being replied to instead just a user. See my proposal of 1^st Jan.

Of course, a variant with more indent levels has been proposed many times already, which I would prefer as well.

Some people seem to try out another discussion paradigm, completely flat. OK, why not. For me, if even the one level indent and the "being replied to" usernames are gone, then it's not a discussion anymore and following the thread becomes nearly impossible. I rate this attempt as worse than the already poor current model. Maybe other people like it, after all, but so far we've barely heard their voices and arguments.

Now, if anyone is willing to code this... I'd be happy to try out a really different paradigm, also supporting replies to multiple posts: what about threads that could both branch and merge, as implemented for code in Git? Klipe (talk) 09:58, 23 February 2014 (UTC)

Klipe: I like this idea, but I'm not sure exactly how it would look?

If you want this changed, please consider voting on the relevant bug on Bugzilla, as that will get it noticed by more Wikimedia developers. Nicereddy (talk) 00:18, 24 February 2014 (UTC)

For the sake of visibility by those interested in the topic at hand, please consider voting on the relevant bug on Bugzilla, as that will get it noticed by more Wikimedia developers.

@Patrick87 Nicereddy (talk) 00:20, 24 February 2014 (UTC)

Nicereddy: Please be aware that voting on a bug is effectively meaningless, as the number of votes does not determine the whether or not a bug gets fixed or addressed. Jorm (WMF) (talk) 03:16, 24 February 2014 (UTC)

Jorm (WMF): Can you turn off voting for Flow, without needing to turn it off for all MW extensions? WhatamIdoing (talk) 06:08, 25 February 2014 (UTC)

WhatamIdoing: That's up to Andre Klapper, I suppose. I have no idea if it's possible to do on a submodule level. Jorm (WMF) (talk) 20:08, 25 February 2014 (UTC)

Patrick87, WhatamIdoing, Nicereddy, and Klipe: Sorry about my delays in replies, I'm a bit behind at the moment with multitasking and email backlog.

Re: indents: You'll be somewhat pleased to see https://gerrit.wikimedia.org/r/#/c/115110/1/Flow.php (a third level of nesting). It needs to get some testing to make sure none of the UI needs additional tweaking to encompass it, then hopefully that'll be riding the deployment train to here and Enwiki within the next couple of weeks. Once it's here and we've used it, they'll then ask us for more feedback regarding how to progress from there. With options including:

• leaving it there (to enable tangents, but discourage long rambling tangents),
• or increasing it further,
• or adding a toggle to enable/disable autocollapsing any nesting deeper than that (Eg. similar to how Reddit separates any replies deeper than level 10)
• or other (ideas welcome :)

HTH. Quiddity (WMF) (talk) 00:04, 26 February 2014 (UTC)

Quiddity (WMF): That is good news. It'll definitely improve the current situation a lot by making it actually possible to bring some structure into a discussion. How much of an improvement it will be we'll have to test though (as you wrote yourself).

On a general note (since you're asking for ideas):
I still think (as has been brought up a few times already) that the first post to a topic should be on nesting "level 0" (that means the same level as the topic title).

The rationale is simple:
A topic title is just too short to be enough to define a topic. Therefore you have to include the first post as part of the title instead of making it a first comment on the same level as later comments will be put on. At the same time this will "magically" add a virtual level of threading depth (as people can actually reply to the first post without already replying on the currently deepest (with the update second deepest) level. Patrick87 (talk) 00:34, 26 February 2014 (UTC)

Patrick87: Ah, yes, I meant to also reply to your top-post in this thread, agreeing that this is an interesting idea.

(There was even a design-draft at one point, that placed the first person's post within the gray topic-titlebar, but they dropped that because some first-posts are very long.)

Are there any use-cases that would conflict with this, or reasons that we should hesitate in contemplating it? (Ie. this would be equivalent to forcing everyone to use at least one : (colon) in talkpages, when replying to someone else. No more "reply at root" possibility) Quiddity (WMF) (talk) 00:48, 26 February 2014 (UTC)

Quiddity (WMF): I like the idea of a post "at the same level as the topic header".

I would not like the idea of limiting the current top-level post level to just 1 post, as this would remove one level of nesting! And the current top-level post level is typically where is makes sense to possibly introduce sub headings, e.g. to organise a discussion around a few possible options.

Unlike the topic header itself, however, the "post at the same level as the topic header" should be "signed", and editable only by its author if that rule is set for all other posts as is the case now. Klipe (talk) 06:29, 5 March 2014 (UTC)

Quiddity (WMF): The only I can think of would be in the case of someone suggesting a feature/idea/concept, etc. as the first "level 0" topic and then others being unable to respond to it at the same level.

However, this is easily remedied by having a "Request for suggestions" or similar as the level 0 post, with all others being level 1 or deeper.

The potential issues it can cause are, in my opinion, vastly outweighed by the benefits of usage and readability of the thread structure. I would definitely be interested in discussing this idea further, as I feel it could be greatly beneficial to Flow. Nicereddy (talk) 00:58, 26 February 2014 (UTC)

Topics

I believe that there should be a way to create Flow threads not attached to any talk page. Flow should support setting special 'tags' or 'topics' for threads, e.g. if I am watching all threads tagged with 'WikiProject baseball' and someone makes a bot request involving baseball-related articles, that request should be tagged with 'WikiProject baseball', and I should receive some sort of notifications (as Special:NewMessages) even if I am not watching the bot requests Flow board. Ricordisamoa 19:45, 21 February 2014 (UTC)

Ricordisamoa: This is in the Plan. In the future, Topics will be able to be attached to multiple boards - or even removed from them (but still be visible via search). At least, that's the plan. Reality tends to come crashing down. Jorm (WMF) (talk) 20:59, 21 February 2014 (UTC)

Flow on usertalk

No one will ever be forced to use flow on their own usertalk page, right? Just checking. ~ Jakec (talk) 13:39, 22 February 2014 (UTC)

Jakec: Eventually, Flow will be used on all talk pages. This moment is a long, long way out, however. Jorm (WMF) (talk) 18:09, 22 February 2014 (UTC)

Jorm (WMF): If you ever want testers, I would be first in line to donate my Talk page :D Nicereddy (talk) 06:29, 23 February 2014 (UTC)

Nicereddy: We'll keep that in mind :) Thanks for all your feedback & ideas here and on enwiki! MPinchuk (WMF) (usurped) (talk) 22:31, 27 February 2014 (UTC)

Maryana (WMF): you're more than welcome! Please feel free to leave a note on my Talk page if you want feedback on any large changes to Flow or VisualEditor in the future :) Nicereddy (talk) 22:57, 27 February 2014 (UTC)

Nicereddy: I've already Flow-enabled mine, but I get so little traffic it doesn't mean anything. Jorm (WMF) (talk) 08:39, 23 February 2014 (UTC)

"Subscribing to/Following" a Flow thread?

I was wondering if there were any previous suggestions to follow a specific thread to get notifications for it? I can follow an entire Talk page, but only using the Watchlist. I would like to be able to Follow/Subscribe to a topic (or thread? I suppose they're interchangeable in this case) and receive Echo notifications whenever a comment is added.

Preferably, regardless of how many comments there would only be one Echo Notification for each thread I'm subscribed to. Opening the Echo dialog would tell me how many responses there are, who wrote the most recent response, and/or how many new responses there are since I last viewed the topic.

e.g. "Subscribing to/Following" a Flow thread? on Talk:Flow has 4 new responses and 13 responses total.

This could undoubtedly be improved and changed to suit the most common needs of users, but I'd like to at least discuss the feature, as I feel that it's unfortunately lacking. Nicereddy (talk) 00:08, 24 February 2014 (UTC)

Thanks Nicereddy. It's been mentioned a few times, and is on the to-do list, but this is a good description of a desired feature-set.

"Bundling" is how Echo defines its "many related changes merged into a single message", so I'll use that term.

Bundling Flow changes by-topic is a good idea, and something that they've already started to implement in our watchlist entries (not live on mediawiki.org yet. Work ongoing). It's not perfect yet, but it should demonstrate how we can get things that are better than the status quo.

How Flow changes get integrated with both our Echo notifications and our Watchlist entries, are something that will need ongoing tweaking and experimentation, as the scope/scale increases, and the possibilities-via-new-features expand. More suggestions appreciated. :) Quiddity (WMF) (talk) 23:08, 25 February 2014 (UTC)

Require users' attention on a specific thread

Flow users (or maybe sysops only) should be able to set a 'priority' on each thread, so other users would focus their attention on important discussions first, even if they are not the newest on their board. Ricordisamoa 17:53, 25 February 2014 (UTC)

Ricordisamoa: So "Sticky posts", essentially? I'd support this feature, but I'm not sure how priority should be given. If anything, the post should be colored differently (or have some other differentiator) and collapsed by default as not to break the flow (heh) of the rest of the page. Especially if there's more than one. Nicereddy (talk) 00:28, 26 February 2014 (UTC)

Ricordisamoa: They're planning on adding some "sorting methods" to the ordering of topics, so that we can reorder by "recent activity" vs "chronological".

They're also contemplating various ways meta-data could be applied to topics or posts (such as through the category system, or via a new #tag type system).

Adding these 2 features together, plus any other "sorting methods" that we can suggest and-are-possible, should result in us each being able to focus on different topics/threads, in the ways that we need. :) Quiddity (WMF) (talk) 01:07, 26 February 2014 (UTC)

Yeah, I hadn't thought about an actively user-specified sorting option (just the more programmatic ones: newest, most replied-to, etc.), but I like the idea. Will add to our backlog :) MPinchuk (WMF) (usurped) (talk) 22:29, 27 February 2014 (UTC)

Multiple threading levels

Why not to allow 3rd, 4th, etc. level for messages, as in LiquidThreads?

If user A creates a post, B replies to A, A replies to B and C replies to A's first post, C's reply could be misinterpreted as a reply to A's second post. This is undesirable. Ricordisamoa 03:12, 26 February 2014 (UTC)

Ricordisamoa: We want whatever we build to work across all the different kinds of devices that people use to access Wikipedia now and 5-10 years from now: desktop, laptop, tablet, phone (mobile phones currently represent ~20-30% of Wikipedia pageview traffic, and this number is steadily growing). Infinite levels of threading display very badly on smaller screens. We're testing 3 levels currently (reply to topic, reply to user, reply to user's reply) to see if this suffices for more complex back-and-forth discussions. MPinchuk (WMF) (usurped) (talk) 22:25, 27 February 2014 (UTC)

Maryana (WMF): anyway, Common Sense should forbid users creating more-than-5-level threads. Ricordisamoa 22:57, 27 February 2014 (UTC)

Maryana (WMF): Can't you increase the width of the comment threads a bit? It's somewhat weird: Articles are much more dense in terms of the information contained yet they extend over the entire width of your screen, but discussion threads (here) only get roughly 60% of the normal width of a Wikipedia page. Pajz (talk) 21:00, 1 March 2014 (UTC)

Pajz: Full width looks very strange with short comments and is difficult to read. Following 1 line of text across an entire screen is tough on the eye. There's some more info on this at the Flow design FAQ if you're interested. MPinchuk (WMF) (usurped) (talk) 21:24, 5 March 2014 (UTC)

Maryana (WMF): While I agree with using an optimal reading width; with further nesting levels you run into the issue of the comment being less than the optimal width. I assume the reason for the first nesting level having a smaller font size was to solve this, however you won't be able to just keep lowering the font-size for additional nesting levels.

The easiest solution would be to allow nested comments to extend out further, however this would look pretty messy. So perhaps the solution is to meet it half way and extend the width to a bit greater than optimal, so nested comments are a bit closer to optimal? 137.147.205.98 (talk) 04:48, 7 March 2014 (UTC)

137.147.205.98: I mostly agree with your comment right there. Additionally, longer replies get more compressed in such a narrow width.

Since Maryana said it's at approximately 60% width right now, I'd just take a guess that 70%-80% would still look good, and meet half-way with the two opinions on the width. GeorgeBarnick (talk) 05:00, 7 March 2014 (UTC)

Why not just do like Reddit does and have the ability to enter into deeper thread layers? AslanFrench (talk) 00:50, 16 October 2018 (UTC)

We were already discussing this as part of Thread structure of Flow needs improvement.

At least a third level of threading will be available soon. If this will suffice we'll see... Patrick87 (talk) 10:53, 26 February 2014 (UTC)

Shouldn't it be configurable? Ricordisamoa 16:48, 26 February 2014 (UTC)

nesting broken test BobaFett9 (talk) 11:52, 18 September 2017 (UTC)

nesting only work in source edit BobaFett9 (talk) 11:52, 18 September 2017 (UTC)

Patrick87: A third level is, indeed, now available :) MPinchuk (WMF) (usurped) (talk) 22:15, 27 February 2014 (UTC)

Maryana (WMF): yeah, it is! Ricordisamoa 22:53, 27 February 2014 (UTC)

Can I make a fourth available? AslanFrench (talk) 01:48, 16 October 2018 (UTC)

now its working BobaFett9 (talk) 11:53, 18 September 2017 (UTC)

nesting seems broken BobaFett9 (talk) 11:52, 18 September 2017 (UTC)

Given that the acceptance of Flow/Structured Discussions by the Wikimedia community is already hard, why make it harder by not allowing the administrators of wherever it gets installed to decide on the level of nesting? ChristianKl (talk) 13:38, 13 November 2017 (UTC)

Yes, agreed, this seems like something that admins should be able to decide. It makes sense to have an opinionated default but to make this difficult to change is just silly.

Plus there ARE solutions to making deeply threaded conversations mobile friendly. Reddit does it after all. AslanFrench (talk) 01:49, 16 October 2018 (UTC)