Wikipedia talk:Flow/Archive 10

This is an archive of past discussions about Wikipedia:Flow. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

←

→

Editing own comments

Is there any particular reason to disallow IP editors from editing their own comments? I could maybe see giving a limited window for doing this in, given the way IPs shift, but completely disabled?

If the entire point of Flow is to attract new editors, and we know that editors start by making those first few edits when they're new (and being surprised that it works), what message are we sending by not allowing them to make corrections in their own comments, making them look less polished in their first interactions with other editors?

Given that, in my experience, a newbie who registers first (and so edits as a redlink) is greeted with even more suspicion and hostility by many of the community than an IP editor, I would generally want to encourage new editors to edit without registering for a little while until they learn the ropes, to improve their initial interactions with other editors. This should involve some interactions on talk pages. 86.129.13.205 (talk) 18:14, 25 June 2014 (UTC)

That's an interesting point. I think so far the team's been operating on the idea that IP addresses change, and therefore you can't tell whether people are actually editing their own posts. I don't know if the idea of having a limited window for it has come up before. We'll definitely think about it; thanks for posting your thoughts. DannyH (WMF) (talk) 19:52, 25 June 2014 (UTC)

Thank you for considering it. I've assumed that a limited-editing-window wouldn't be difficult, given that many other commenting and bulletin board systems use it, but I realise that it may be more involved than I assume. 86.129.13.205 (talk) 11:26, 28 June 2014 (UTC)

My feedback

Cool idea, but there is a lot of cosmetic work to do before this would be usable as a talk page replacement. This is my initial feedback, viewing from Firefox 29 on a 5:4 monitor, 1280x1024 with pretty vanilla settings.

1. The text is much too large.

2. The gray-on-gray text in the "header" boxes does not have enough contrast.

3. The text is, really, much too large.

4. There is about twice as much whitespace on the right hand side as there should be.

5. When I mouseover the "compare post revisions" icon in the header box (and comments) for posts that have been edited, it displays mouseover text saying "Last edited by XX (br) Show changes". This text stays displayed indefinitely and blocks the list of commentors below it. Intuitive behavior would be for the mouseover text to disappear as soon as the mouse moved. Also, how will that button be handled for tablets? VQuakr (talk) 17:45, 8 June 2014 (UTC)

@Quiddity (WMF): I would be curious to hear your thoughts on these observations. VQuakr (talk) 01:31, 13 June 2014 (UTC)

@VQuakr: Sorry for the delay, I'm away from home this week. Thanks for the feedback. :)

1 & 3) The text-size is (over)due to be fixed to the same size as article-text.

2) The color-contrast in the header box and in the text-entry placeholders, are indeed an accessibility concern, and will be fixed soon.

4) This aspect is still under extensive internal discussion (because it is objectively easier to read a fixed width column (less eye-movement and line-length to track, on eg. a very widescreen monitor with maximized window), but many editors (including me) are frustrated by it). There are a few possibilities, including: A) Putting a floating Table of Contents in that area, B) including some other type of useful meta-information or functions in that currently-empty space. Possibly some sort of power-user tool(s), so that the interface is uncluttered for newcomers, but dense-with-tools/info for those who want it. Suggestions would be appreciated! C) moving the function-links (reply/edit/thank/view wikitext/timestamp) over there. D) user-preference.

5) The first part is a new bug, thanks for spotting and describing it; filed as bugzilla:66569. For the second part, they're changing the way the "edited content" information gets displayed, to be embedded right within the timestamp area, so that should solve the touch-screen issue for that feature.

Thanks again. Quiddity (WMF) (talk) 05:51, 13 June 2014 (UTC)

@Quiddity (WMF): re item #4 - I was viewing on a quite mundane, low resolution PC with a 5:4 monitor when I noted the excess whitespace. Yes, the problem will be worse at high resolutions or with a widescreen monitor, but I think it is quite telling that it is noticeably too narrow even in a near "best" (non-tablet) case. The solution is to increase the column width to a more reasonable value, not to add meta content in the whitespace. VQuakr (talk) 00:51, 19 June 2014 (UTC)

6. How about adding a "collapse further" button to each discussion header? Right now, I can only see five collapsed sections at a time. There could be another icon that collapses the header further, reducing the font size and hiding all information except the title, to get the header to take maybe 20% of that vertical dimension. VQuakr (talk) 00:51, 19 June 2014 (UTC)

@VQuakr: Aha! It has that, currently as an experimental feature. (Just icons, hence easily overlooked, amongst all the other newness.) See the 3 icons in a line, just above the top-right corner of the top-most topic, eg Wikipedia talk:Flow/Developer test page.

In the long-term, there are many possibilities further along those lines (but the more we suggest, the better). Personally, I really like Gmail's 3-level density setting ("Comfortable/Cozy/Compact"), and also NYTimes font size selector, and I hope to see something like that (throughout mediawiki) in the next few years. Quiddity (WMF) (talk) 00:32, 1 July 2014 (UTC)

Superimposed text

Looking at the test at Wikipedia talk:WikiProject Hampshire the time-tagging has the "13 June 2014" and "11 days ago" written on top of each other so that neither is readable. Is this a known bug? Or is the preference, or gadget, or whatever it is that gives the (hours/ days/ whatever) ago not going to be available if/ when Flow arrives? --David Biddulph (talk) 12:33, 24 June 2014 (UTC)

Could be a browser specific issue. When I look at it I see the "days ago" view, and when I hover on that I see the actual time and date of the post - but I never see both together. I'm using Google Chrome - what are you using David? WaggersTALK 09:25, 25 June 2014 (UTC)

It seem to be OK on IE11 at home, but the problem occurs using IE8 (under Windows 7) at work. - David Biddulph (talk) 11:06, 26 June 2014 (UTC)

@David Biddulph: That's a known bug, tracked at bugzilla:60849. (/me grumbles about IE browser quirks, from 6-11...) Sorry for the delayed response, and thanks for the bugreport. :) Quiddity (WMF) (talk) 00:42, 1 July 2014 (UTC)

July 10 Flow Update

We've got a major update coming later today. This release is an architectural re-write for the front-end, so Flow will be easier to keep updating in the future. Many of the changes aren't visible for the user, but there are several notable improvements.

The new feature in this release is the ability to sort topics on a Flow board. There are now two options for the order that topics appear on the board -- you can see the most recently created threads at the top (the default), or the most recently updated threads. This new sorting option makes it easier to find the active conversations on the board.

We've also made a few changes to make Flow discussions easier to read, including:

The font size is consistent with other pages
Dropdown menus are easier to read
Now using the new button style, and the WikiFont webfont

As with any big release, I'm sure there will be some new bugs for us to identify and fix. Hopefully, we've fixed more things than we broke, but you never know. Let us know if you spot something broken!

It's been a while since we've released visible changes to Flow. We're planning to ship faster from now on -- smaller releases, but much more often.

Our plans for the rest of the summer include changes that will help people track the conversations that you're involved in, and filter out the ones that you're not interested in.

If you've got ideas, questions or bug reports, let us know!

Note: There's a fairly thorough list of recently identified bugs at Front end refresh feedback - those and other bugs, will be a primary focus this week.

[p.s. I'm copying most of DannyH (WMF)'s previous message, hence the mixed pronouns.] Quiddity (WMF) (talk) 18:39, 10 July 2014 (UTC)

The best way to fill the space on the right

I already posted this at the discussion test page, but the best use for that big blank space on the right half would be the page being discussed. So, if you're posting at Talk:Fish, the article Fish would be right there on the other half of the screen. No more switching tabs back and forth to remind yourself exactly what you're commenting on. Eventually, you could create an animation of the talk page sliding out from the left and shoving the article over to the side (long-term to-do list). Also, this might be a technical challenge, but the ideal way to deal with width is to have a width slider that users can adjust on the fly however they want. For logged-in users, it would remember it and use the same width on the next talk page, but there would be a restore default button always available. Ego White Tray (talk) 03:43, 10 July 2014 (UTC)

No, the best way to fill that space on the right would be (at least as a user preference) using the whole width for the discussion, instead of half of it. Your suggestion may be a secondary option, but the space shouldn't be there to begin with. Fram (talk) 06:43, 10 July 2014 (UTC)

We're actually looking right now at putting a dynamic Table of Contents on the right side, so you can navigate between topics without scrolling. We're still working on the design. DannyH (WMF) (talk) 22:27, 10 July 2014 (UTC)

Gah, no to both of these suggestions. They'll look horrible on mobile, to start with. I do NOT want the article there beside it, because it will be terribly confusing to keep track of what I'm supposed to be editing. And no dynamic table of contents, please - at the best of times, they're intended for pages where the content is static, not for ones that are being actively edited. They're visually distracting even on pages where one just is scrolling down (they jump and quiver and move at a different pace than the scrolling), and I can only imagine how much it would be bouncing around as people edited the main column. It's almost as though you've become so married to the width of the flow field that you're scrambling to find anything else you can think of to fill the gigantic whitespace left behind. Really, the discussion should be there. I'm good with having a nice wide margin on either side (i.e., actually centering the discussion) - a two-inch whitespace margin on either side should make everyone happy - but after having been hammered for over a year about how incredibly necessary it is to decrease clutter and have lots of whitespace on the page, please don't now say that it's okay to have article content (of all things!) and flashy moving TOCs competing visually with the discussions that were so important nothing should distract from them. Risker (talk) 05:37, 11 July 2014 (UTC)

I agree. Please use it for to widen the space for the discussion. Don't add something else on the right. And no dynamic toc. Dougweller (talk) 08:14, 11 July 2014 (UTC)

+1 Just using the space for discussion content is far and away the best option. — Scott • talk 11:01, 11 July 2014 (UTC)

The current decision about the width of the page is based on what's most readable on computer screens -- there's a limit to how long a text line can be before it gets uncomfortable. I know that Wikipedia doesn't have a fixed width now, but lots of websites do, and we want to try it out on Flow pages.

So we didn't create the right column so we could put something there, and we're not going to put something there in order to justify the right column. :) They're separate decisions. When we've talked about elements that we want to try -- including a ToC and a link to archives -- then it's natural to think about the right column as a place to put them.

Regarding the dynamic stuff -- we're just working on the ToC design right now. It's actually been going a little slower than we first thought, because I'm super sensitive about distracting movement while I'm trying to read. I totally 100% agree that we don't something that flickers and jumps around. Right now, I'm thinking a list of topic titles, with (maybe) a color for the one that's on the screen at the moment. As you scroll down to a new discussion, the color switches to the next title. But we're still working with the designers to see how that looks; we haven't prototyped it yet. It may turn out to be annoying and unnecessary, or it may turn out to be incredibly helpful. We need to mess with it a bit to figure it out. DannyH (WMF) (talk) 17:14, 11 July 2014 (UTC)

Feedback 2: Flow got better.

I've taken a quick glimpse of the updated Flow design since my last post here. And it's better.

Whitespace was, at least, reduced.
Smaller font, better reading.
I believe the scroll bars on long comments were removed. Nice move.
It's nice that wikilinks have been technically allowed in comments.
Image support was also added. But way too large.

Comments:

Reverse chronological order of discussions sorted by title. Is there any benefit coming from this style?
Can there be a user preference for viewing older threads first?
How do we view archives?
What will happen to posts that are contiguous from the old style to the new Flow design? Will they be archived before the change takes place, or will the software automatically fuse them into the new design?
The time zone always appears in the comments, even if the user had set this in his/her preferences.
Is ISO 8601 a better alternative to the date and time format?
What if we place the timestamp to the right of the username?
Threads become a mess for the eye if there is a limit for the number of subcomments for a thread, like what some threads at WT:WikiProject Breakfast have. Is there a way to adapt the Outdent template?

That's all. But then Flow has improved. Users will miss the old design. Japanese Rail Fan 10:38, 14 July 2014 (UTC)

Good, I'm glad you like some of the changes! I'll try to address each of your questions...

Reverse chronological order of discussions -- The benefit is that new/active discussions are at the top of the page. This is pretty much standard for the internet when you're showing a list of discrete items. The key comparisons here are to forums and inboxes, where new / newly updated goes to the top.
User preference for older threads first -- It's certainly possible. We want to see if there's demand for it once people get used to the current options.
Archives -- We're still figuring out some things about how users will navigate to the discussion they're looking for. Right now, Flow boards use an "infinite scroll" -- older threads aren't archived, they're just below the fold, and you can scroll down to find them. This isn't the ideal solution for a number of reasons. We're currently working out a few different features to help users find older threads, including a table of contents and a search feature. They need some more design/UX work before we can start building them.
The transition between standard wiki talk page and Flow board is probably going to involve a one-time inconvenience of restarting an existing conversation on Flow. Importing talk page conversations to Flow would create more problems than it solves. However -- at the point when a Flow board replaces an active talk page -- we'll have a special archive space for that talk page, and a clear link from the new Flow board to the archive of the old talk page. (We don't have that yet, but it's a requirement before we enable it on an active talk page.)
The time zone appears -- where are you seeing that? I'm not seeing the time zone mentioned...
Placing the time zone next to the user name -- what's the benefit that you see for that?
Replies and outdent -- What do you see as messy with a limited number of reply levels?

DannyH (WMF) (talk) 20:56, 14 July 2014 (UTC)

DannyH (WMF), re "Reverse chronological order of discussions -- The benefit is that new/active discussions are at the top of the page". Why is having the discussion in the wrong place an advantage? We spend enough time trying to cure newbies from top-posting on talk pages. Why would you give them the confusing experience of having some places on Wikipedia where top-posting is correct when it is wrong everywhere else?—Kww(talk) 21:19, 14 July 2014 (UTC)

I think we have a different understanding of what's the wrong place. But one of the goals for Flow is to free everyone from the chore of curing newbies from doing newbie things. Newbies should be able to post in a place that makes sense for them. Then the software can give users the ability to see the board the way that they want to. Does that make sense? DannyH (WMF) (talk) 21:22, 14 July 2014 (UTC)

No, because it implies that there will be one day that Flow will suddenly flash-cut into place and top-posting will be the new "correct". It's unlikely that Flow will ever become ubiquitous. If it does, there will still be a prolonged interval getting there where many discussions are on talk pages and some are on Flow. Since there's no actual need to use top-posting, all this is accomplishing is making that prolonged interval more painful that it needs to be. I've noted this tendency to attempt to retrain newcomers to not fit into Wikipedia structures on places like the Teahouse, and can't help but wonder exactly why WMF-sponsored pages force the use of top-posting.—Kww(talk) 21:32, 14 July 2014 (UTC)

Because Facebook. In any case, bottom posting will never be practical until they get round to implementing a TOC. And I agree with Kww that the overlap period, which will likely be indefinite, will be more painful for newbies, confusing them – "do I need to post on the top or the bottom?". I don't see a lot of evidence of top posting newbies anyway – it's never happened that I can remember on my talk page, for example. BethNaught (talk) 21:40, 14 July 2014 (UTC)

Probably about 5% of newbie posts on my talk page wind up on the top. Admins probably get a few more messages from completely raw editors than most because they come scream at us for deleting pages about their garage bands and pet dogs.—Kww(talk) 21:47, 14 July 2014 (UTC)

@DannyH (WMF): Re to my post:

Timestamp location -- Check out your social media sites, e.g. Facebook, Twitter, YouTube, and other Blogger sites. Almost all of them place a relative or exact timestamp directly next to the username of the one who posted a message. Not where we see it as of this post.
Timezone -- I've seen it in Safari on an iPad 3 running iOS 5.1.1. But on a regular desktop or laptop that's no problem.
ISO 8601 -- Despite setting user preferences to see talk page timestamps in their preferred date and time format, a Flow board has all thread marked with a M/D/YYYY timestamp. I set my preferences to DD MMMM YYYY but on Flow, there's no effect.
Reply levels and outdenting -- On WT:WikiProject Breakfast there were Flow-related threads that lined up on merely three indentation levels. Not on our current talk pages where every response comes under with one indentation more than the previous. Per WP:TPG, indentation is needed to identify who replies to whom. But on Flow, the third indentation level became too crowded. [1] is one example where the third indentation level all seems to reply to the last second level indented post. Starting a new topic on the first level is not an alternative to outdentation, but is this really a problem? Japanese Rail Fan 08:10, 15 July 2014 (UTC)

Thanks for the explanation about the timestamps -- I'll check that out, and file a bug ticket. You're right, it should follow the user preferences. I'll also look into the timestamp and timezone suggestions; thank you.

We're still experimenting with the indent/reply format on Flow discussions. Some elements of WP:TPG may not apply to Flow discussions, because they're based on properties that are specific to MediaWiki talk pages. For example, you don't have to add four tildes for a signature on Flow, because signatures are automatic. Similarly, Flow doesn't need to use indentation to mark the difference between one post and another, because the design is accomplishing that in a different way. So we're also looking at solutions to indicating who you're replying to directly, and possibly not using indentation for that. But we'll do more work on that in a little while; there are other pieces that we're building right now.

Sorry, I know that I'm giving vague answers to some of these questions, but we're using an agile development model, which involves a lot of fast iterative changes. We're also starting to work with a brand-new Design Research team, which will help us set up a lot more user testing than we've done before, with both experienced and new wiki users. So there are several areas where we know we still have questions to figure out, and replying/indenting is one of them. DannyH (WMF) (talk) 18:34, 15 July 2014 (UTC)

Re: Timestamps, I've reopened bugzilla:59919 for those 2 issues. Quiddity (WMF) (talk) 00:32, 16 July 2014 (UTC)

Cultural norms, and WP:TPG

I don't know if this has been dealt with, but:

Users are surprised by the cultural norms of the community

is not always properly dealt with by Flow. There are "cultural norms" which are not (significantly) influenced by the "current" talk page structure, but are incompatible with Flow as originally described (I have seen no evidence that the description has changed, but I could be wrong).

The example you give, that anyone can edit others' comments, is an (at least) en.Wikipedia cultural norm; although the present talk page structure makes it impossible to restrict, some editing is specifically allowed by WP:TPG, and many of the allowed changes could not be handled by any reasonable algorithm without allowing anyone to edit anyone's comments. Specific (current) allowed edits, and status:

If you have their permission.
Still reasonable, although not essential, as you could ask the other editor to make the change.
Personal talk page cleanup
I don't know if the "Hide" button has been implemented in Flow, and if users would automatically be given access to it on their own personal talk pages. If so, it would serve most of the purpose, provided that the hiding shows up on the watchlist-equivalent.
Removing prohibited material
Still relevant, and almost impossible for automated privileges, without allowing an editor to removing anything.
Removing harmful posts.
Ditto
Off-topic posts
Could be handled by a Split button, but, again, as noted, determining whether a post is off-topic is subjective. In any case, the split needs to be revertable.
Attributing unsigned comments
Unnecessary under Flow
Signature cleanup
Probably unnecessary under Flow. I still think that a user should be able to note in a quasi-signature that his/her home Wiki is elsewhere, at least until cross-Wiki notification is properly implemented.
Fixing format errors
Some of the reasons are inappropriate under Flow, but there could still be format errors that need fixing.
Fixing layout errors:
Most of the reasons are inappropriate or unnecessary under Flow, but there are still possible problems which could be fixed.
Sectioning:
Probably "split", with additional caveat that the that a pointer to the new thread should be placed at the appropriate place in the original thread, and a pointer to that same point be placed in the "header" (or fixed area) of the new thread.
IDs:
Is deep-linking possible under Flow? Even if {{anchor}} is an allowed function in Flow posts, it might still not be possible to link to it.
Section headings
This could be allowed separate from anyone editing the actual posts, but would it interfere with links to the threads? (As my recollection, possibly mistaken, is that links to threads wasn't working properly, this would need to be asked at a later time.)
Disambiguating or fixing links
Still relevant.
Hiding or resizing images
Possibly relevant
Deactivating templates, categories, and interlanguage links:
Interlanguage links, and possibly categories, are irrelevant under Flow, but templates may still be a problem.
Hiding old code samples:
May be unnecessary, if the thread with the code sample is easily collapsed in Flow, but there is no real objection to it, and it should not be restricted to the person who originally posted the code sample.

— Arthur Rubin (talk) 22:52, 14 July 2014 (UTC)

@Arthur Rubin: Thanks for the thorough thoughts. The short answer, is that the restriction on editing each other's posts (for non-admins) is still an experimental feature (cf Wikipedia:Flow/FAQ#Components of the discussion system, in the "Comment editing" row), and could be changed to give other usergroups that option (eg anyone, or autoconfirmed, or rollbackers, or etc), and different levels at different wikis (if wanted/warranted). The issues you point out are exactly why it's still 'experimental'.

See also the page that Okeyes put together last October, at mw:Flow/Editing comments, which covers much of the same ground.

To comment on a couple of points

Personal talkpage archiving - this, and re-examining how Flow handles archiving in general, has been suggested/requested a few times. They're examining/learning about the wide variety of existing archiving methods and tools (eg User:Equazcion/OneClickArchiver, de:Vorlage:Autoarchiv-Erledigt, etc).
Deeplinking: Yes, we can link to posts within a topic, using the "permalink" button in the ActionMenu (click the "..." at top right of each topic/post). E.g. a post link - They're currently working on a better style of both internal wikilink, and URL. More details on that, soon.
Section headings - Anyone can currently edit these. Click "Edit topic" in the actionmenu. The name of the topic (thread) does (and will) not affect the permalink, so it can be changed without problem.
Hide - they're planning on re-examining this experimental feature too, as it definitely needs to be tweaked or replaced. I believe a more basic (undo|rollback) is coming, but I need to reconfirm that with the devs/PM.

HTH. Quiddity (WMF) (talk) 02:50, 16 July 2014 (UTC)

Indentation levels

I concur with User:Japanese Rail Fan in the thread above (#Feedback 2: Flow got better): the third indentation level provides little benefit in its current usage-nested comments require unlimited nesting to make sense.

If you're going to a "trailing, almost-flat" style of comments it should be made as simple as possible, avoiding the third level for as long as possible; "base" comments for the topic should be at the first level, all replies should be placed at the second level in order, and the third level should be kept just for out-of-order replies to a comment in the second level. For example suppose a thread with 8 comments, where posts 6 and 7 are replies to the third comment, and number 8 is a direct reply to the topic. It would show this way:

.Topic title

.1-Alice

2-Bob
3-Charlie

6-Dave
7-Eve (Reply to Charlie)

4-Bob
5-Eve (Reply to Alice)

.8-Charlie

Some other problems I've seen:

-Outdenting one level (from third to second, ~~or second to first~~ level) requires scrolling all the way up to find the intermediate post and clicking "Reply" on that. An "outdent" command would make things more complicated, but it's not needed if you follow the above approach:

By default, all replies made in order to a post at either the first or second levels should be placed at the second level, last comment in the thread. A reply to an intermediate post in the second level would be placed at the third level, cutting the thread in two (see posts 6, 7 in the example above).
Outdenting from the third level to the second would not be possible; all replies to the third level should also be at the third level (post 7 as a reply to posts 3 or 6).
Outdenting from the second to the first doesn't require an outdent command - it's done with the current "Reply to topic" box that exists now.

-The "by" and "reply-to" user names at the beginning of each post are hard to distinguish, as the have a similar style (same color and font family) and they're placed side by side. In the current talk pages, starting a reply with Re:User is not a problem because the signature is at the end. But if the signature is placed at the top, showing always who you are replying to is problematic because then all comments have two user names at the beginning. Either the "reply-to" should be placed at a different color, or it should not be created by default - only when the user is replying to a comment which is not the one immediately above it.

Diego (talk) 15:36, 15 July 2014 (UTC)

I agree. This may be a clarification, but correct me if I am wrong: Outdenting refers to starting the next reply at the leftmost margin, but is still a reply to the last reply above it. On the other hand, a reply made at the first level without the outdent template shows that the editor who made the comment is starting a new discussion regarding the same topic. Perhaps I would also agree to the last bulletpoint about the signature location. Perhaps we should place it at the bottom, flush right before the timestamp? Japanese Rail Fan 10:30, 17 July 2014 (UTC)

Interesting proposal, Diego; personally I quite like it.

<tangent>(I'm so used to the (practically-infinite, effectively 8-15 level) threading of reddit/email/slashdot/wikitalkpages, that I'm still wrapping my head around the options, and trying out new sites to see the alternatives in action. Whilst searching around, I was amused to see this 2012 angry discussion at theguardian.com when they changed from a flat-system to a 1-level nested system (it's still in use).)</>

Also, good point about the confusion of the author/@reply-to names being so close together. I believe they're still considering various alternate placement options for the author-metadata (either at bottom with the timestamp (per current signatures), or in the right-edge (possibly along with the "reply/thank/etc" links). I'll ask if there are any mockups available. Quiddity (WMF) (talk) 02:30, 19 July 2014 (UTC)

Deleting, then others

How do you delete a topic on Wikipedia_talk:Flow/Developer_test_page when you shouldn't have created one? :( I'll paste what I put there: I'm not sure if someone already asked this (part 2), which brought me to part 1, searchable? I wanted to know if anyone mentioned archive pages for these or if the page will continue on. Also, does this module remove my ~~~~? I'm very used to signing all comments.

I didn't want to click Close Topic because I'm not sure what will happen. Will WP crash?? Really though, will topics be closeable only by admins? Topic creators? Would a creator then prematurely close a topic to end discussion?

It looks like Wiki markup won't work, will it ever? cliffsteinman -- Discuss 21:01, 23 July 2014 (UTC)

There are a few different moderation features you could use. You can Hide a topic or Close a topic -- neither one will make WP crash. :) All the actions are reversible if somebody makes a mistake.

Searching on a Flow board will happen -- it's something we're planning to work on this fall.

There won't be an archive page for Flow boards, because the page essentially auto-archives -- older conversations fall down below the fold. Right now, we're using "infinite scroll", so you can keep scrolling down the page to see all of the conversations. We're also thinking about pagination -- that's not completely decided yet.

Wikitext will absolutely be supported. There are a few things that don't work properly now, but those are bugs that we'll fix. The only exception is the signature, because we want to break people of the habit of ending everything with ~~~~. Flow posts already have your name and the date on them; you don't need an extra signature. :) You'll get used to it. DannyH (WMF) (talk) 23:18, 23 July 2014 (UTC)

Awesome, just awesome. Talk pages are the engine, the articles are just the face. This is big for the project as a whole, I'll keep my eye on it. Good luck! I'll try and jump in your early test articles to see how it works out. cliffsteinman -- Discuss 03:48, 24 July 2014 (UTC)

Great, thanks! I'm glad to hear that you're excited by the possibilities. :) DannyH (WMF) (talk) 17:16, 24 July 2014 (UTC)

Full Wikitext? Including CSS hacks and ugly misappropriation of templates? Or just parsoid? --h-stt !? 11:04, 25 July 2014 (UTC)

It'll be as full as we can manage without being foolish about it. Ideally, we'd like to be able to say "you can do anything in wikitext that you can do on a talk page", but we have to watch out for stuff that might break the page. DannyH (WMF) (talk) 17:17, 25 July 2014 (UTC)

Update changes

When I look at [2], I get three dots extremely close to "Feedback" in the sentence "Feedback there is appreciated". They are placed between (not above) the vertical lines in the "b" and the "k" of "feedback", making it look like some diacritics instead of the menu button I know it is. I get the same kind of "wrong" placement on all pages in Flow now.

Oh, and when I scroll to the bottom of the main developer test page, I seem to get into an infinite loop of more pages, always the same pages appearing again and again. You need to expand it until the ones with the very large images appear, and then things are screwed. Things start repeating from the topic "top posting" on for me.

The history of the page only goes back to 10 May now, so we are still losing more and more old history.

The header of the page has "(Note: The Board header diff history is now accessible (from the main history). It's not smooth yet (multiple clicks are required), but that is one of many things being worked on. Thanks.)" The link in that line to "main history" returns [3] with text "no such action": "Wikipedia does not recognize the action specified by the URL. Return to Main Page."

Which were enough problems for me to stop testing even before I had posted anything with Flow. 07:11, 31 July 2014 (UTC)

@Fram: In order:

The misaligned actionmenu is bugzilla:68262, which has been patched. (Live on mediawiki.org in a few hours)

I've filed the looping bug as bugzilla:68932.

The history-pages needing pagination is bugzilla:65088.

The link to history is now just the standard URL ("action=history" rather than the previous "action=board-history"). I'll update that, when the bug preventing me from doing so gets solved (bugzilla:68526).

Thanks as always. Quiddity (WMF) (talk) 18:34, 31 July 2014 (UTC)

Accidentally creating a topic?

Something very strange just happened. I was looking at flow on Wikipedia talk:WikiProject Breakfast to see how it works. Then I clicked in the field for "Start a new topic" to see what will happen. However, I didn't type anything and I didn't save it or do anything else, before navigating away from the page. Still, when I checked my contributions, there was an entry for me creating a new topic at Topic:Rrtki2fpqy5qpiep. When I looked in the history of the target page, there was no entry logged created by me. I'd assume this is a bug? 2Flows (talk) 21:44, 24 July 2014 (UTC)

That is very odd. I'm not sure how that happened, especially because that particular conversation started in March, and you didn't participate in it. But yeah, there it is in your contributions. We shouldn't have Topic:ID links like that in Contributions anyway -- that's a bug that we're going to fix -- but I'll have to see if I can figure out why that ended up assigned to you. Thanks for flagging it; sorry about the bug! DannyH (WMF) (talk) 23:00, 24 July 2014 (UTC)

Alright, I hope you find out why that happened. Indeed it's quite a strange bug, so probably it will be hard to recreate it. 2Flows (talk) 23:31, 24 July 2014 (UTC)

Contribution not made by me is attributed to me

Copied from [4], per suggestion of I JethroBT

My contributions list has a mystery item on it, apparently related to the new Flow extension. Although I did view that page, this question is the only edit I have made today, yet this item appears in my contributions list: "17:54, 29 July 2014 (diff | hist) . . (+1)‎ . . N Topic:Rojlc5xnvwolwrkg ‎ (→‎Taken over by Flow) (current)". I would like to know if this is a bug, if there is a Bugzilla report, and whether the edit can be removed from my contributions list. This item makes it look like I have inserted nonsense or vandalism, so it would be great if it could be removed or at least properly attributed to whomever made it. Thanks! Eddymason (talk) 01:15, 31 July 2014 (UTC)

@Eddymason: That's a bug (the same one mentioned in the thread above hence I'm going to make this a subsection) and it should be fixed with this code change, which will be live at mediawiki.org tomorrow, and here 2 weeks after that. (Normally it would be live here next week, but the deployment schedule is on hold during the week of Wikimania). I'm not sure whether the old entries will be removed, or whether the fix will simply prevent new instances of the bug from being created, but I shall ask the devs what options there are. Thanks for the (double) report, and sorry for the trouble. Quiddity (WMF) (talk) 03:46, 31 July 2014 (UTC)

Okay thanks. I'm not sure quite what Wikimania is but I hope I don't catch it. :) Eddymason (talk) 20:25, 31 July 2014 (UTC)

@Eddymason: I asked a dev, who says, "those will disappear in about a month as the recent changes table gets truncated. If its really a problem to have them in contributions i can probably write up a maintenance script to change the owner, but generally its not considered a great idea to go back in time and change existing revisions."

Wikimania is the annual conference, where hundreds of people gather together for a few days of presentations and discussion. This year's is in London, from August 6-10. Many of the developers are there, so the usual weekly software deployment (updates) are put on hold for the week. HTH. Quiddity (WMF) (talk) 22:19, 31 July 2014 (UTC)

Flow & Pings

Has anything been done to address this: Topic:Ronsz8yhsrhq3890? - tucoxn\^talk 12:53, 10 August 2014 (UTC)

I'm sorry -- I hadn't seen that, and I didn't realize it was still going unanswered. I just replied on that thread. Thanks for the nudge. DannyH (WMF) (talk) 18:44, 12 August 2014 (UTC)

Separate notifications for flow updates and user events?

I see a problem in the way the new notification system conflates the functions of Echo and the Watchlist. The previous system issued alerts only for rare events that directly affect the user (direct mentions, comments at your talk page, reverts, links to pages created by you, etc), so I knew that I should review any warning appearing in it. The use case for watching threads is different; I'll have a huge number of watched threads, and I'm not really interested in reviewing everything that appears in it, all the time, only in skimming through it to find something to work on.

Unfortunately, as H-stt explains above, the system doesn't scale to high volume "follow lists": the important warnings risk getting buried among the long list of trivial thread updates.

Now, I can see the benefit of having a single stream for both types of notifications. Is it possible to have it without losing the benefit of the current Echo notifications? What I want is a way to tell apart when there are updates from separate channels, so that I can know when there are new important warnings. Maybe alerts should be highlighted with different colors for warnings (red) and updates to watched topics (green or blue?). Diego (talk) 13:47, 27 August 2014 (UTC)

There are a few ideas along those lines:

mockup from #1

At mw:Compact Personal Bar#Design V2 there are ideas (and 2 Mockup images) around having separate flyouts for each of the 3 main standard workflows - 1) Watchlist 2) "Talk messages" 3) Alerts.
So #2 would cover all of the "discussion" types of notification (replies, mentions, usertalkpage posts). This option has been partially discussed amongst the Flow dev team, and the current "2 tabs in 1 flyout" (as seen on mediawiki, if you have Flow contributions there) is just a temporary setup until a better long-term solution is determined.
At Wikipedia talk:Notifications/Archive 5#Granularity, there was an idea to separate each of the Notification-Types into a separate icon, and only have the icon appear if there was a fresh Notification of that specific type.
For a really active editor, it could look something like: 1 3 15 2
And then if I had 0 new notifications, it would be the default single number/icon on grey.
At Wikipedia talk:Notifications/Archive 5#Color-coding the dot, there was a related idea to just color-code the badge/number background, but that's complicated by cultural-nuances of colors, and color-blindness, etc.

(Personally: I really like #1, although I want words in addition to icons. I really like some aspects of #2 but I also worry about the variable-width and the potential number of icons if I had many types of new alerts. In the end, I suspect we'll need a combination of #1 and/or #2, plus another option for levels of "watching" a Flow board, which I'll explain in the "too many Echo notifications" thread.)

Of the 3 ideas above, what do you think are the best/worst aspects? And what other options are there? Quiddity (WMF) (talk) 01:53, 28 August 2014 (UTC)

The best idea is no drastic change; flow updates come in the watchlist, just like every other kind of update. There is no need to invent the wheel again here. Give me an echo if I get pinged on Flow, of perhaps when a topic I started gets deleted or hidden or whatever; but that's it. Color-coding the dot is definitely the worst idea of them all (having multiple dots would at least be better than that). Fram (talk) 07:12, 28 August 2014 (UTC)

All the notifications will slow down work, even if you can turn it off. At least I will not turn it off (I am too curious) and I will check every time... As it is now - if its really important it is posted on the user talk page (or somebody ping you, or thank for an half year old edit)... Christian75 (talk) 11:25, 28 August 2014 (UTC)

Rights

A. Who has the rights now to put an enwiki page in or out of Flow-mode?

B. Who will have the rights to put an enwiki page in or out of Flow mode in the future? Fram (talk) 11:51, 28 August 2014 (UTC)

Special:ListGroupRights and Special:GlobalGroupPermissions (for stewards, sysadmins and staff) mention Flow, but not about activating flow mode, as it were. I suspect this is currently at database level? BethNaught (talk) 12:05, 28 August 2014 (UTC)

Right now, only the Flow team can enable/disable Flow pages, which is not sustainable in anything but the shortest of short-terms. The next step is for us to have a special page to enable and disable Flow on pages, which will be tied to a user right. We've done some planning work on this, and we're looking into some ongoing WMF database work that might be blocking this development. DannyH (WMF) (talk) 19:19, 28 August 2014 (UTC)

Deletion

A flow talk page can't be deleted directly. Why?
When deleting the non-talk page part, e.g. Wikipedia:Flow/Developer test page, one gets the option to delete the talk page anyway: this is not consistent with point 1 above
After deletion, one gets an error: [589656fd] 2014-08-26 13:54:07: Fatal exception of type MWException
It is impossible at that time to create the talk page (even though talk pages without non-talk page should be possible, e.g. for user pages or some subpages)
After restoring the main page, the talk page automatically reappears
The page then had 22 "deleted revisions" at [5], but after restoring them, they seem to have simply gone from the logs (they can't be found in the history, which is of course still deficient).

All this is rather counterintuitive and not really internally consistent. It still looks suspiciously as if Flow pages can be used as large balck holes to get rid for things once and for all... Fram (talk) 14:03, 26 August 2014 (UTC)

This is an element that we don't need right now -- it's not important for the next set of use cases. We're focusing on the features that we need to build for the next stage, and then move on. So what you're seeing in your test isn't an indication of how this will work later on. This is a huge project that's going to take a little while, so we're being deliberate about what elements we need to build for each iteration. DannyH (WMF) (talk) 19:27, 28 August 2014 (UTC)

Just like with "move" below, you are going at this backwards. If you can't get basic existing functionalities to work, it's hardly useful to add new ones already. get move, delete, history (!!!) to work, and then start thinking about more fancy stuff. Fram (talk) 06:59, 29 August 2014 (UTC)

Updated information

I've just updated the WP talk:Flow page with a lot of new information, including the rough plan of our quarterly goals for the next year.

I have to apologize -- this is a page that we updated on Mediawiki earlier this month, with the intention that we'd mirror the new version here, and I forgot to actually do that, because apparently I am a genius. So I was very confused yesterday, when Risker said that the page here didn't have information about what we're working on. I thought I'd already copied over the updated version.

So -- I'm very sorry about the confusion there. Totally my fault, and I feel vaguely foolish about it. On the plus side -- lots of updates on the page! If you're interested, please take a look, and I'm happy to hear what you think and answer questions. Thanks! DannyH (WMF) (talk) 17:22, 29 August 2014 (UTC)

"Done Subscribing to Flow board = notifications for new topics on that board" Doesn't work

"Done Roll-up notifications for activity, one notification item per topic" Not wanted (next ones all related, so...)
"Done Log item improvements for Watchlist and Contributions" Doesn't work, never did

Simply showing all changes to a board since last visis is still impossible. Simply getting the watchlist to display whether a Flow board has changed since the last visit is impossible. These aren't planned for the next year apparently. Are people at the WMF even aware that these are a problem?

A rollout to articles on enwiki in Q4 is a completely absurd idea but a very good way to create the next WMF-community clash. The WMF devs still seem to live in cloud-cuckoo land, or they have to meet some unrealistic deadlines to keep their jobs, or some other unsavoury reason lies behind all this, whatever, but this is just the same old nonsense. Has any destructive testing been done yet? I know I have done it once and broke the watchlist of a serious number of people here, with an act that any vandal could have done very easily. Is it really that kind of untested software that you want to release to talk pages or a brand new moderation project? Please no. Fram (talk) 20:15, 29 August 2014 (UTC)

Move doesn't work

Why can't a Flow page be moved? This will need to be corrected before this can be used (if ever). Fram (talk) 07:20, 28 August 2014 (UTC)

You're right; this is a piece that we have to build. It's not at the top of the list right now, because we won't need it until we move on to a later deployment stage. DannyH (WMF) (talk) 19:22, 28 August 2014 (UTC)

Let's reverse that, shall we? You should not move to a next deployment stage (however small) unless this is in place (and a few other things, like the rights setup, and some finished idea of how the watchlists and notifications should work, oh, and perhaps finally a history that is working, and ...). Thinking about further deployments should be the last of your worries now. Fram (talk) 06:58, 29 August 2014 (UTC)

Need or no need, the point is that if you want to convince the community Flow is useful then it will need to actually be functional (as Fram says) before being deployed to a high volume area, as people will notice the missing functionality. BethNaught (talk) 07:10, 29 August 2014 (UTC)

That is absolutely true, and that's why it's not going to a high volume area yet. Right now, the two use cases we're focusing on are the French WP Forum des nouveaux (their version of the Teahouse), and a new mentorship project on enwiki that just got grant funding. Those are going to be the next stage of Flow deployment, possibly with a third mentorship space that we're talking to. For those projects, there are features that they absolutely need (table of contents, searching on a Flow board, a way to generate new Flow boards on subpages, an update to the hide topic feature), so that's what we're prioritizing for the next month or so. Those projects don't need to move Flow boards, so we're putting that off until the next stage.

But I totally understand the confusion. I just updated the project page here, I'll start a new thread to explain... DannyH (WMF) (talk) 17:16, 29 August 2014 (UTC)

"It is absolutely true", but we'll deploy it further anyway. Please, don't agree with me when I say that "you should not move to a next deployment stage (however small)" and go on to tell me that you'll do just that anyway. Testing new software on a new mentoring project is about the worst idea I'v heard here. What they need is a stable environment, where the focus can be on the mentoring. Using such a project as the testing ground for software (which doesn't need a testing grond as there are plenty of show-stopping bugs noted already anyway) is a recipe for disaster. Fram (talk) 19:59, 29 August 2014 (UTC)

I trust the developers that there will eventually be a "move" function, and that Flow will probably not be rolled out on a wide basis until it's there (although not necessarily working correctly, as some edge cases probably won't be tested). However, the ability to copy between Flow messages and _WikiText_ (not just VE) is a minimum requirement, with most WikiText, including complicated templates, working correctly. I see no indication that that's in the plan. I see they claim it works. I need a test page on en.Wiki to verify. — Arthur Rubin (talk) 01:50, 30 August 2014 (UTC)

Deployment venues

I think this warrants more attention: test-deploying Flow on pages heavily used by new editors is really not a good idea. I realize why you're doing it, but it's not worth it at this point. It would be a bad idea if Flow were less buggy, because it would essentially be forcing new editors to learn two interfaces at the same time - not just technically, but also culturally. This is confusing to them, not to mention contrary to nearly every help or guideline page relating to discussion they're likely to be pointed to, and is likely to create extensive extra work for all editors. Editors who actually work with newbies will need to be explaining and troubleshooting an interface that they themselves have little experience with. Other editors will be needing to clean up after newbies who, becoming accustomed to Flow, attempt to follow the same customs on non-Flow pages. I was training new editors around the time that VE first rolled out, and let me tell you, it was twice as hard than normal training, even though the interface was supposed to be so much easier.

Given all that, deploying the current version of Flow, with its identified bugs (particularly those that separate it even further from how the rest of the wiki works, like history and watchlist issues), is not really something I would see as justifiable. Costs far outweigh the benefits, really. Nikkimaria (talk) 02:49, 30 August 2014 (UTC)

History and watchlist

At the moment, neither the history nor the watchlist really work for Flow. Any indication when this rather basic functionality will work? Without it, any work on developing Flow is useless, as it is impossible to follow discussions in an easy way. Flow has been prematurely deployed in, what, February, so half a year later one would expect that these most basic of things would be working most of the time. But at the moment, I don't get changes to Flow pages in my watchlist at enwiki, and I do get them in mediawiki, but when I try to see the history from my watchlist, I get a "Fatal exception of type Flow\Exception\FlowException" error.

Problems with these things have been raised from day one, and while the actual problems have changed of the months, they have never really improved, never mind been fixed. This seems to indicate basic flaws with either the concept or the development of Flow. The current "Echo" bombardment problems are only the umpteenth example of the struggle you all seem to have with this. Could you please get back to your drawing board and get this really fixed (I note at Trello that this was opened before Flow was enabled at enwiki, and supposedly solved in April already; I can't remember any time when this truly worked though, you have just replaced one set of bugs with another set... Fram (talk) 07:30, 29 August 2014 (UTC)

Thanks for reporting the bug about the history link in the watchlist. I just checked it out -- it's actually only happening for hidden topics (as far as I could tell). Other history links in the watchlist work correctly. I filed a bug ticket for this, and it'll be fixed soon.

However -- I am seeing topics that I'm subscribed to on my enwiki watchlist. They're now in the form "Topic title on Talk:Board name" -- maybe you're looking for the old-style items? Let me know what you see -- it might be a bug that isn't happening to me, for whatever reason.

In more general terms, bugs are always a part of software development. It's absolutely impossible to build software that doesn't get at least occasional bugs, especially during a stage when there's fast-moving, active development. They're not good, obviously, and they need to get tracked down and fixed, but they're also not a harbinger of disaster. :) I appreciate that you're helping us identify bugs when you see them. DannyH (WMF) (talk) 17:07, 29 August 2014 (UTC)

I note that you are copying the style of testing that the VE people from the WMF also use. Not a good development. Generally, you are rapidly losing the trust that the earlier WMF people discussing Flow had slowly built.

The bug about the history link is not only happening for hidden topics (which would be bad enough), it happens for e.g. this topic when I click "hist" in my watchlist. Note also that in general, there is no possibility to see the state of a topic (never mind a complete talk page) at a certain moment in time anymore. Not good... But on the plus side, we get countless "topic" links, one on every line of this page, which are utterly useless since you are already at that topic. Good UI!

"I am seeing topics that I'm subscribed to on my enwiki watchlist". Good for you. I'm watching Wikipedia talk:Flow/Developer test page, the whole page, like I have done since the start, and I don't see anything on my watchlist except for my own attempts to delete it. Ah, and now my edit to the header as well. Anything else? Nope, no new topics, nothing. Isn't the purpose of adding a page to your watchlist that you see when e.g. a new topic or section is added?

In more general terms, I have to agree, major bugs are alwayzs a part of WMF software development. "Fast-moving, active development"? Well, I don't see much "fast-moving development", and "active" development is rather superfluous, passive development would be a novelty.

VE had the same "thanks for noting the bugs, don't expect us to draw any conclusions or change or plans accordingly though" attitude. Hasn't the WMF learned anything from VE, MV, and so on? Fram (talk) 19:54, 29 August 2014 (UTC)

So, for the sake of clarity: I have Wikipedia talk:Flow/Developer test page on my watchlist. I don't get any update when anyone edits the page, apart from my own edits there (which I am aware of, thank you). Not when someone replies, not when someone creates a new topic (which I can't yet have watchlisted anyway), ... So no, as far as I am concerned, Flow doesn't work with the watchlist, and so is not acceptable for further rollouts. Fram (talk) 09:36, 30 August 2014 (UTC)

Note that Flow also corrupts the watchlist counter. My watchlist on mediawiki claims "Below are the last 7 changes in the last 12 hours, as of 4 September 2014, 07:32.", but it only shows four. Looking at the histories, I note that this comes down to 6 changes to Flow pages (of which 3 are shown in the watchlist), and a non-Flow page. Apparently the watchlist is hiding some Flow changs (luckily, even though it is very far from perfect yet) but counts them anyway.

I still get an error when trying to access one of them (not a deleted or hidden page) from the watchlist. Flow pages don't get the "bold" when not yet visited indication. There is no indication whether something is a new topic or a comment. And so on, and so on...

You really haven't thought this through, have you?

Apart from all the other problems mentioned above and in the archives, there seems to be a rather major flaw in the choice of pages for the proposed further rollout ("Right now, the two use cases we're focusing on are the French WP Forum des nouveaux (their version of the Teahouse), and a new mentorship project on enwiki that just got grant funding. Those are going to be the next stage of Flow deployment, possibly with a third mentorship space that we're talking to.")

Now, go to e.g. our tea house, and take a good look. One of the main things one needs to be able to do easily is display wikicode, so people can show what they do, or be shown what they have to do. See e.g. Wikipedia:Teahouse/Questions#Citing the same reference twice.. But without an easy way to show wikicode, and without an easy way of looking at the code that someone else uses, you are making such pages a lot less user-friendly for newbies. The exact opposite of what Flow was supposed to do... Fram (talk) 07:24, 30 August 2014 (UTC)

@Fram: Have you tested this? The <nowiki> and <code> tags work in Flow, which is what I've generally used in the Teahouse to show wiki markup, so I don't think this is a problem. I, JethroBT ^{drop me a line} 07:32, 30 August 2014 (UTC)

More interestingly, when VE becomes viable and is rolled out again (which, hopefully, shan't be too far off) all the newbies will ask how to do stuff in VE which we old fashioned wikitext editors won't be able to help with. But that's a side topic. BethNaught (talk) 07:39, 30 August 2014 (UTC)

JethroBT, and how are newbies supposed to know this? Oh, they can find them in "advanced", and then the icon of "W" in a "forbidden" circle. Or at least, that's the explanation you can give them in wikitext. In Flow? "You can type nowiki" and so on? Yeah, that's user-friendly... As for VE, I have used it a lot for testing. Loads of things inside VE still require wikitext knowledge (so people now have to learn two or three editing environments, quite an improvement). VE and Flow? Two negatives make a positive? Nice to see that at least in this regard, the WMF supports the mathematics editors ;-) Fram (talk) 08:10, 30 August 2014 (UTC)

Why would newbies need to know how to use nowiki tags? We must be talking about different things. I'm talking about how mentors show other editors how to do markup like in the Teahouse because that's what you brought up. Either way, as a host, you'd use things like nowiki and code tags regardless of whether it's Flow or standard talk pages. I, JethroBT ^{drop me a line} 08:26, 30 August 2014 (UTC)

"Hi, I tried to do X, but when I try to save it I get an error". "Can you show us what code you used?" Um, no, not in Flow, I wouldn't know how... And obviously, as mentor as well, having to type nowiki and so on is rather old-fashioned and unfriendly of course. There is absolutely nothing in Flow that helps you as an editor, no matter if you are a new one or an old hand, and newbies need it the most of course. So yes, you would still use "nowiki", but it would be in a rather unwelcome way. What I would actually do is invite the other editor to another, non-Flow page. Oops, that wasn't the purpose probably... Fram (talk) 08:48, 30 August 2014 (UTC)

Perhaps I was wrong. If one can copy/paste between Flow and WikiText editing, there's little problem, although even VB experts can probably not reproduce the keystroke sequences that resolve problems. I was lead to believe that that functionality was implemented. If not, I agree with Fram. Flow is not even ready for beta in regard talk pages which might require detailed WikiText (or VB) descriptions of what is wrong with a page or how to fix it. That would include the Teahouse on en.Wikipedia, but I don't know how fr.Wikipedia operates. — Arthur Rubin (talk) 16:43, 30 August 2014 (UTC)

Arthur Rubin: After testing it and looking at what others have been doing over at mw:Talk:Sandbox, Flow and Wikitext editing can be copied/pasted with very few issues at this point (one thing they're working on fixing is math formulae). Fram, if a new editor encounters an error like that, any host worth their salt would actually go and check out their contributions to see what happened and address it accordingly. We don't demand a new editor to write everything out again. This just doesn't seem like a realistic scenario. I, JethroBT ^{drop me a line} 22:01, 30 August 2014 (UTC)

If, as described above, the person got an error, then no, it won't be visible in their contributions. And what is the deal with copying between Flow and Wikitext? How does that help? Fram (talk) 08:20, 31 August 2014 (UTC)

The use case which was discussed a year ago [6], in the special context of mathematics, but of course it applies more generally, is the need to be able to collaborate on a chunk of text on an article talk page. For example, to copy-paste wikitext from the article onto the talk page, work on it there, and then copy-paste it back into the article without loss of fidelity. In the case of mathematics, that was crucial since discussion were likely to be about presentation and layout as well as content. But the need exists in complete generality of course. A related and simpler case is when a user finds a problem with a piece of wikitext, or asks on the talk page how to do something in wikitext, other editors can craft a response which can be copy-pasted into the article. Presumably there's some page or document where all these cases are captured, assessed, prioritised, resolved and desgined for, but I don;t know where that would be. No doubt the Flow developers can point you to the list of use cases that they built up as part of their "pretty good idea". Deltahedron (talk) 11:21, 31 August 2014 (UTC)

We were assured a year ago that the Flow team "have a pretty good idea of what our existing users need" [7]. Deltahedron (talk) 18:02, 30 August 2014 (UTC)

How to inform about new topics

According to User:DannyH (WMF) at mw:Flow, there are only two possibilities how to handle new topics for people subscribed to a board.

"Yeah, we're going to have to retune the way subscribing to a board works. There were two possible definitions of what "subscribing to a Flow board" would mean -- a) You get an Echo notification that a new topic has been created, or b) You get automatically subscribed to every new topic created on the board. "[8]

Really? Why not simply put a line on the watchlist every time a new topic is created? No automatic subscription, but no Echo either, which should be kept for more important things. It seems as if the Flow developers are hell-bent on getting rid of the watchlist, or for some other reason refuse to use it. Why? You can, as far as I am concerned, keep the user-defined option of "subscribe me to every new topic", but why not go for the simplest and least intrusive solution as the default? Why, especially, not even consider it as a third option? None of the three certainly is even worse, but that is what happens at enwiki now; watching a flow-enabled page does absolutely nothing apart from showing changes to the header... Fram (talk) 08:07, 1 September 2014 (UTC)

Strangely, at the above mw-discussion, this is exactly what Helder (from the portuguese Wikipedia) proposed ("see the edit which creates new topics appear in their watchlist, but edits to the subpages of those topics will not appear in their watchlist"), but DannyH seems to not understand the concept of watchlists or the difference between a watchlist and Echo, "We're going to make a change within a couple of weeks that makes subscribing to a Flow board work the way that you described -- you'll get a notification when new topics are created." No, DannyH, not a notification (which is Echo, your A option), but a line on the watchlist. Please make it clear in your responses what it is you really mean, and please make the distinction between watchlist and Echo clear in them. And read what people are actuallu suggesting, and not what you want to hear. Above, in another discussion on this page, you made the same kind of "yes you are right" statement followed by one that contradicts or ignores it. That is not helpful. Fram (talk) 08:15, 1 September 2014 (UTC)

Seeing changes since the last visit

What is the method in Flow to see all changes to a board (not to a topic) since the last time you visited it / from a certain point in time? You can see the changes to a topic since you last visited it, or you can see the whole board, with recent active topics at the top, but seeing (by diff, or colour indication, or whatever) what is actually new or changed on a board seems to be impossible. This is standard functionality on current pages (you know, all the green "updated since last visit" indications on a page history), but has been completely abandoned here AFAICT. On e.g. WP:AN, after the weekend, you easily have changes to 5 topics and 10 new topics. Having to open these one by one is tedious (and having 15 notifications for that page alone is madness). Why isn't Flow integrated in the current mechanisms for history and watchlists, with where needed additional options and features? Fram (talk) 16:01, 1 September 2014 (UTC)

I asked that same question at the beginning of Flow development, as it's one of the essential features why the Watchlist and History pages exist - to review recent changes of conversations related to a given article. IIRC the answer was that they'd have to develop it from scratch because of the way they have structured the Flow data model on top of the Mediawiki software, with a separate wiki page for each ~~[topic]~~ comment - not one for each board. Last time I checked it didn't seem to be very high in their list of priorities. Diego (talk) 16:45, 1 September 2014 (UTC)

I know, most major problems and flaws in Flow were there from the start. That's why I don't get their intention to deploy it to more pages, confronting especially new editors with it. Probably they have to meet some deadline to get their bonus (or keep their job), but that's not really a good reason to continue on this path. Or they genuinely believe that they are doing great, which is something that has lead to previous WMF deployment disasters. Just look at e.g. Wikipedia talk:Flow/Archive 7#Please disable Flow from enwiki, the list of missing things I got there from a very first test after they went live. I can copy that complete list here, verbatim, but we are more than 6 months later and according to the WMF, everything goes great and we can roll this out further! Fram (talk) 17:05, 1 September 2014 (UTC)

I need to be able to go into the history and compare 2 times, just as I do now. Dougweller (talk) 17:12, 1 September 2014 (UTC)

Why roll this out to other pages at enwiki?

The question (like many other rather important ones) has been asked a few times above, but hasn't goten a real answer AFAIK.

There are many, many remaining problems, bugs, design choices to be made, fundamental issues to solve, ... with Flow. Many of those have been raised from day one, more have been added since. Very few have been solved. So what is the purpose and what the benefit of rolling out Flow to more pages on enwiki? Will it help the people (mainly inexperienced editors needing mentoring or having questions about editing) at these pages? Will it make the development of Flow any faster or easier (and if so, how?). Will it solve any of the open problems (at the moment, at Bugzilla, 338 open Flow bugs)? Will it do anything that rolling it out to more pages at e.g. mediawiki won't solve? Fram (talk) 07:33, 4 September 2014 (UTC)

The Law of Unintended Consequences

When you look at someone's contributions, you can select a namespace, and check the "associated namespace". So you can e.g. see all changes someone made to articles and their talk pages.

With Flow, this no longer works, since talk page messages now get their own namespace, Topic. Which, as an aside, makes me wonder how the talk page of WP:AN would look once WP:AN is Flow-enabled.

The good news is that you can of course check all contribs to the "topic" namespace. But (hey, it's Flow, there is always a but, and usually a dozen of them), they have been made the most uninformative possible. [9] shows

All posts as new (N)
All sizes as "+1"
All edit summaries as "‎(→‎Taken over by Flow)"
All statuses as "Current"
All descriptions as " Topic:Rzi5r14uxfclgfdw", " Topic:Rzi5e3sjta2n7h8r " or " Topic:Rzi5dgyw1s0v58p9 "
No entry when a post is edited
No diff

So, what do we see on the roadmap?

Done Log item improvements for Watchlist and Contributions

Yes, let's roll this out to more pages, it is so ready! Or, alternatively, first do your homework, remove all offensive "done" checks from your roadmap, rewrite the roadmap, drop all plans to roll this out to other pages, and come back once you have a system where the basic functionality, front- and backoffice, works. Fram (talk) 07:57, 4 September 2014 (UTC)

Agreed! It's a wonderful idea to roll this out to newbie pages, that way we can replay the VE and MediaViewer rollouts, or the (much cursed) abolition of the toolserver (may he rest in well-deserved peace), which resulted in useful tools like Citationbot to slow down to almost being unusable and Reflinks to disappear altogether. Man, are we having fun here! WMF, this is another disaster in the making, can't you learn from previous experiences and please slow down? Fram, I much appreciate your engagement on behalf of the community here! --Randykitty (talk) 10:53, 4 September 2014 (UTC)

Deployment

On the roadmap, I see for this month: "The Co-op mentoring project (w Jethro, Jake, Siko & Aaron)" According to Jethro, the deployment there wil be for December at the earliest, so no idea why it is listed for Q3.

For Q4, I see a possible deployment to "User talk on Product-friendly projects". What are product-friendly projects? Then, the third line, is "Possible opt-in user talk test?" What's the difference with the "user talk" of the first line? It's still a bad idea (and unacceptable without the necessary admin tools for it).

The fourth and final lines again are duplicates, "Expand rollout of WikiProjects/article pages" and "More WikiProjects on Wikipedia, possible rollout to articles in those areas". You are aware that Projects don't own articles, and that many articles are in the scope of multiple projects, which may not all support Flow (yet). So please don't go to e.g. Wikiproject Hampshire and ask them whether you may set their articles to "Flow", as they don't get to decide that (their input is welcome of course). You'll need community consensus to deploy Flow to more things, like articles or user talk (as an opt-in for other people). If you really need to deploy it further, use it on WMF pages on enwiki (the talk pages of the WMF people, the talk pages of WMF pet projects), before rolling it out to other pages. Of course, first fix the many major bugs and deficiencies. That will probably make the Q3 and Q4 dates impossible though. Fram (talk) 08:09, 3 September 2014 (UTC)

Yup, that's how it works. That's why it says, at the top of each section: "Possible deployment: All deployment ideas are preliminary; actual rollout depends on conversations with staff and community stakeholders. These can be unlocked when we meet our goals for the quarter."

You can't actually predict in June 2014 what the product will be like in June 2015, at least not with any specificity. For planning, you have a good idea of what you're going to do in the first quarter, and a general notion of where you'd like to go in the second quarter. Third quarter is entirely guesswork, and fourth quarter is just a direction you'd like to travel. We're actually doing pretty well on meeting our first quarter goals, and we've learned a lot. We'll do a more realistic update on Q2 goals at the end of this month. DannyH (WMF) (talk) 14:39, 3 September 2014 (UTC)

I am not discussing what you are planning for June 2015. I am discussing what you are planning for July to September 2014, i.e. at the last this month. A planning you posted here on 29 August 2014. Are you seriously saying that you didn't really know what you would be doing in September 2014 at the very end of August 2014? Could you, in the future, just respond to the question instead of going on complete strawman tangents? It's a very annoying habit. And perhaps WMF can use the standard quarters, i.e. Q1 for Jan-Mar, Q2 for Apr-Jun, and so on, instead of what you used now? Then you would have noticed that I was discussing the standard Q3, Q4, and so on (which you could easily have seen by seeing my references to actual months, or by comparing my quotes with the roadmap), not the uber-user-friendly WMF quarters (let's start Q1 in July!). Fram (talk) 17:04, 3 September 2014 (UTC)

Uhm, Q1 does start in July. We're on a business year, not a calendar year. --Jorm (WMF) (talk) 17:25, 3 September 2014 (UTC)

"We"? Again, as usual, keep your in-company stuff in-company and out of Wikipedia, and discuss things here (and present them on the Flow page) in a standard manner. And like I said, everything in my post made it clear what I was talking about, certainly for the product manager who had posted the very roadmap. But of course, it is easier to focus on the Q1 vs Q3 discussion than on the many relevant points made here (scroll up, and up, and up, and you'll see tons of remarks, questions, problems, ... no one has replied to). Fram (talk) 17:48, 3 September 2014 (UTC)

I'm not sure if there's anything anyone can say to you, Fram, that isn't going to be rejected immediately. The fact of the matter is that we operate on a Fiscal year and thus our planning documents are built around that. It's a very common practice. I'm sorry that you didn't understand that, but yelling at me isn't going to change that.--Jorm (WMF) (talk) 18:09, 3 September 2014 (UTC)

If you want to try saying something that has an improved chance of acceptance, perhaps you could try addressing the original posting, which was about planning for certain specific items in July to September 2014? Deltahedron (talk) 18:17, 3 September 2014 (UTC)

I'm sorry, I was actually confused by Fram's original post. Now that that's cleared up -- conversations with the Co-op are happening this month, and we're going to put up a test page soon so that the people who will join the Co-op program over the next month will have a place to try out Flow and give us specific feedback based on what that project will need. That decision was made in a meeting at the end of last week; I haven't updated that Goals page yet.

The questions about October to December are spot on -- I believe I wrote those items in June, and a lot has happened since June.

But -- the big question that's coming up in a bunch of threads here over the last week is: Why aren't you updating this information more? And my answer is: You're right, I should be, and I'm going to work on getting better about that. Honestly, there's been a big uptick in people's interest in the project in the last couple weeks, since we did our last release and also started sending out more information on the Wikimedia EE mailing list. For the last few months, it didn't seem like very many people actually cared enough to pay attention to the Goals section. It looks like that's changed, which is great. That means Nick and I need to be updating that documentation more often. You'll see more of that soon, and I'm sorry that it took me this long to recognize that as a problem. DannyH (WMF) (talk) 18:32, 3 September 2014 (UTC)

Thanks. You haven't indicated why you feel the need to roll this out to inexperienced people already having some trouble with editing; it won't help them, and it isn't necessary for Flow development at the moment, there are more than enough problems, open questions, bugs, ... to keep you busy for months to come. That to me is a much more important question than why the info isn't updated more regularly, although that would be good as well (certainly better than posting information at the end of August which is already outdated at the time). As for people not caring: no, people noticed that nothing wsa happening, and probably assumed that the team was working on the issues raised in (mainly) February. Now people notice that this isn't really the case, and that the WMF is again on a self-supporting path of wishful thinking, with goals reached, improvements done, progress for the future, but only on paper, not in reality. People don't care, people are worried. Fram (talk) 07:22, 4 September 2014 (UTC)

Fram puts it well. People don't care (though they should, the community needs to come up with a clear policy and response on Flow usage); people saw the rollout of MediaViewer and came here in an effort to raise problems in order to prevent another software rollout disaster, one which will have a much greater effect that any software change for a long time. Given the lukewarm response to certain critical issues raised (deletion, moving, and the whole Watchlist/notification confusion) my concern has not abated. BethNaught (talk) 07:32, 4 September 2014 (UTC)

(ec, reply to Jorm) What Deltahedron said (most importantly), and please just think about it: what does it matter to anyone at enwiki who is interested in Flow that you (the WMF devs) work according to a Fiscal Year (never mind why you plan your releases around a fiscal year)? Can't you see that using Q1 for the period July-September in your communication with users (editors) is just slightly confusing, as evidenced here? That it in reality has no advantages to use that here, but all kinds of disadvantages? But if you prefer, just ignore this side-discussion, and focus on the actual questions. Fram (talk) 18:33, 3 September 2014 (UTC)

Nevertheless, thanks to DannyH for his commitment for better communication. Deltahedron (talk) 18:35, 3 September 2014 (UTC)

DannyH (WMF), quite a few people who have been following this topic were aware of the change in leadership for the product, ad then were told that there was a lot of redevelopment of both the front and back ends of the code, which we (reasonably, I think) assumed would accommodate a lot of the issues that had been surfaced over the past year. In other words, people gave some time and space for you to get acclimatized and for the redevelopment to take place. Now that you've been here a while, and the deployments have happened, we're back... Risker (talk) 13:45, 4 September 2014 (UTC)
Just for the record, I was opposed to the deployment of FLOW in principle, and I remain opposed. My main point has never been addressed - this is the first important deployment without the opt-out option, and I believe the idea of FLOW is flawed, to the point I will probably stop editing talk pages if FLOW gets installed. I believe I am not the only user who feels like this. I feel that we are moving towards a revolt and possibly towards a serious instability within the movement. I am pretty much disappointed that WMF consistently fails to address this point, trying to solicit reaction to cosmetic improvements instead.--Ymblanter (talk) 16:10, 4 September 2014 (UTC)
I agree. The WMF has failed to establish that there is agreement for this nuclear change. The back/forth conversion functionality which is being developed could well end up in a wheel war being site admins and WMF staff beyond anything of the likes of VE and MV. Naturally, this is why Möller jumped at the excuse to add superprotection to the software. BethNaught (talk) 16:16, 4 September 2014 (UTC)

Lacks an experienced, non-sticky persona

All the personas listed are sticky. In my present guise, I'm not. Over the years, from time to time, I became involved with a page and made substantial contributions. I know the basic markup inside out, and I've gradually become familiar with the most important editorial templates and the policies these enforce. I actually use Wikipedia to survey subject areas I'm learning about for my personal and professional purposes. If I'm being thorough in my research, this often takes me into the darker reaches of unloved articles, where I'm quick to spot various kinds of breakage. I'm usually happy to invest five minutes to bump an article in the right direction. It can be anything from fixing broken markup, copy editing, adjusting balance, splitting an overgrown lead, or plumping up an insufficient lead (the lead is the most frequent problem area I find myself fixing in the musty article space). I believe the majority of my edits serve Wikipedia editorial policy, but I don't hang around to polish my surgeries; I'm hoping others will come along with more investment in that subject area for the smoothing out (always leave a nickel for the next guy). Though my attentions are brief I strongly believe in leaving explanatory tracks. If the template reason field or the edit comment don't suffice, I generally leave a paragraph on the talk page; sometimes all three. In the rare case where my edits are reverted, I don't return to the scene of my crime to contest the issue: I'm okay if 90–95% of my edits make it through infancy unscathed. It's more efficient to be a little on the edge than to second guess myself. Generally I'm an experienced seagull editor who drops a note into a conversation and then bubbles off. I'm not antisocial. If someone challenged one of my edits on my talk page, I would surely respond. I find in software development projects it's always good to model at least one persona who doesn't love what you're building as much as you do. A non-sticky persona might be a good add. Also, I've often added comments to talk pages where I suspect the talk page won't be viewed again for weeks or months or years. I'm quicker to make edits on the pages where editorial velocity and conflict are inherently low. That's another aspect you might wish to model: semi-retired editors who mainly stick to infrequently traveled back roads, where topics created are more like messages in a bottle to record intent than to solicit active engagement (attached to pages where I might not have much of an interest or opinion on its future evolution). I've been around long enough to hold an opinion about the kinds of edits a less experienced editor (say 300 edits) might be afraid to take on, for fear of ruffling some previous contributor's feathers. It's my intent, anyway, that some of my more savage edits lower the permission barrier for such a person (in fly-by-night mode, I rarely delete existing text unless it's extremely out of line, as this strikes me as rude). I would wish to monitor my topics to make myself available to provide clarification about my original motivation. But generally I don't wish to monitor these topics for forward developments. I sure hope the new discussion system doesn't end up conveying the implication that whenever someone opens a new topic that they plan to stick around and set up a tent. I'm a batcher, who edits mainly in passing, usually with external agendas in tow. The last thing I wish to bring into my life for my efforts is a rolling notification feed, though I do believe in showing up to account for my past actions, if I wasn't clear enough in my original note. Those are a few dimensions people might consider if you decide to enlarge your persona roster.— MaxEnt 08:13, 19 August 2014 (UTC)

That's a great perspective to add, and well-explained. Thank you. (and with my volunteer hat: "I like how you roll", as the kids say. ;-) ) Quiddity (WMF) (talk) 00:08, 23 August 2014 (UTC)

I don't think I understand this. I think you're talking about a watchlist trimmed with time. But, perhaps, one of the features of WP:FLOW was to be an enhanced WP:NOTIFY whenever one of your comments was replied to, in which case, yes, you need to be able to turn that off. — Arthur Rubin (talk) 16:20, 23 August 2014 (UTC)

Are we talking about the personas at Wikipedia:Flow/MVP and if so, what does sticky mean in practice? Dougweller (talk) 18:45, 23 August 2014 (UTC)

@Dougweller: I'd imagine it refers to how often an editor looks at a talk page. Some editors read an article's talk page every day while others may glance at it once and then never read it again. @Quiddity (WMF): Pardon my cynicism but one point in the personas really stuck out for me as making things easier for the developers rather than accurately describing roles. No, Watchers don't want to hide inappropriate comments, they want to delete them, like you have Admins listed as doing. I'd wager the good majority of talk page deletions now are done by non-admins. --NeilN ^{talk to me} 20:07, 29 August 2014 (UTC)

@NeilN: Agreed, and they're now planning on making "Hide" work more like "undo" does (as well as being accessible from the History pages), by not leaving the comment extant and expandable on the page anymore, but instead just leaving it in the history. Quiddity (WMF) (talk) 02:04, 5 September 2014 (UTC)

I believe MaxEnt is using "sticky" to describe someone that wants to keep close track of everything that goes on, when they leave a comment or make an edit - For example using the "Add pages and files I edit to my watchlist" user-preference (or manually ticking the "Watch this page" box, abundantly). MaxEnt is asking that we take the opposite persona more clearly into account - someone who doesn't want to spend more time collaborating and discussing articles and other aspects of the site, unless strongly needed.

The main way someone would do that on a standard talkpage, is to simply not watchlist when posting, and to rely upon Mentions or Talkback templates or direct Usertalk threads when their attention is needed. In Flow, we currently automatically watchlist the individual topics we start/reply on, and can additionally choose to: A) unwatchlist the topic afterwards, or B) watchlist the entire Board. There are ideas (discussed further below and elsewhere) about splitting (B) in two, so that users could either: just watch new-topic additions, or watch every edit/action on a page. I'm not sure how we could further assist a non-sticky persona? What other in-page-options, or special:preferences options, would be helpful? (particularly for non-sticky personas, as the needs and frustrations of the more standard sticky persona are being discussed in threads below.) Quiddity (WMF) (talk) 02:04, 5 September 2014 (UTC)

New topic notifications change

Okay, a change in Flow notifications went out with today's release. As of now on Mediawiki.org, subscribing to a Flow board will only give you a notification that a new topic has been created; you won't be automatically subscribed to new discussions on that board. This will help to cut down on the repetitive notifications that people were getting.

We're also going to try out bundling "created a new topic" notifications, when there are multiple new topics created on a board that you're watching. Rather than going directly to the topic page, the bundled "new topic" notifications will take you to the board, sorted by newly-created topics. The plus, obviously, is that you get fewer notifications; the minus is that you may need to scroll down on the board to make sure you don't miss something.

We're also working on bundling email notifications, and giving the emails a more helpful subject line. So that's also a thing. DannyH (WMF) (talk) 00:05, 5 September 2014 (UTC)

So, if you are not automatically subscribed to new topics, do you still get watchlist entries for posts etc on all topics on watchlisted pages? If not, this change is not helpful:Jay8g [V•T•E] 00:42, 5 September 2014 (UTC)

Yeah, I know. We have to figure out something else for watchlist-only people. The saga continues. DannyH (WMF) (talk) 01:48, 5 September 2014 (UTC)

So, the feature that was live on mediawiki and most people complained about (was anyone happy with it?) is now being rolled out to here as well. Are you (plural) being deliberately obnoxious or what? Why don't you use the watchlist for this, and keep echo for the important stuff? Echo = this may need your attention first, Watchlist = you may want to check this out in your own time. A new topic on any of the thousands of talk pages I am watching is not something I want an echo about, but something I may want to see on my watchlist. You have provided the exact opposite. Great! Fram (talk) 07:13, 5 September 2014 (UTC)

@DannyH (WMF): Just revert this as quickly as possible. Really. Right now, basically. It just makes my life worse, not better. Apart from the things already mentioned, couldn't you perhaps have realised (after, you know, testing this as a real editor) that "messages" are less important than "alerts" to everyone but Flow developers? Now, if I get an alert, I open Echo, and I don't see them. Oh, I get the unimportant "messages" by default, and have to go to "alerts" to see the things that are of most interest. I have to do this even when the messages are all read and the message counter is zero, so not even that excuse (weak as it is) can be used. You are trying to force-feed Flow with disregard for any negative community feedback (i.e. 95% of the community feedback you get). The only result is that Flow will be loathed from the very start, with no chance to recover from that position, and that the people who try to push it through anyway may be facing the Erik Möller treatment (not how he acts, we wouldn't do anything as bad as that, but how he has been treated here and at the German Wikipedia). I can't imagine that being in your planning for this Fiscal Year. Fram (talk) 09:57, 5 September 2014 (UTC)

@DannyH (WMF): Indeed: just take it back to mediawiki wiki and make it work properly before you try to make us use it. You worked at Wikia: you should have noticed that the skin changes there drove away communities. Indeed, your determination to push this through makes it look as if driving away inconvenient old-timers would be a pleasant side effect for you. BethNaught (talk) 10:13, 5 September 2014 (UTC)

So funny it hurts

So, after fully protecting Wikipedia:Teahouse/Questions/Flow test, I switched to my non-admin alter ego User:EngFram t osee whether protection actually works with Flow. Well, not really.

The good news: you can't create a new topic anymore.

The bad news:

if you try to create a new topic, you first can edit as much as you like, but on saving, you get a smallish pink box with the message "Blocked". Blocked? Oh, I'm not really blocked, I just can't save my new topic.
If you want to reply to existing topics, no problem! You can reply to topics on fully protected pages. Which means that protecting a Flow-enabled page has very little effect and won't do a lot to stop vandals and the like. Yes, this is completely ready to be rolled out to more pages. Fram (talk) 08:17, 5 September 2014 (UTC)

Is it still blocked? I've been able to create a new topic right now. Diego (talk) 10:58, 5 September 2014 (UTC)

Apparently, after it was "deleted" (which didn't work), the protection was lost. Which was not logged in the page log... The more you test this, the worse it gets. I've reportected it, normally (hopefully) you won't be able to create a new topic on that page any more. Fram (talk) 11:10, 5 September 2014 (UTC)

Right, now it is like you reported. I can't create new posts (shows Blocked when I try to Add topic), but I can reply to the existing one. Diego (talk) 11:49, 5 September 2014 (UTC)

There's a patch for that, written yesterday. It was a fresh bug. Quiddity (WMF) (talk) 16:28, 5 September 2014 (UTC)

Perhaps (probably) this has already been discussed, but I just had a look at Wikipedia talk:Flow/Developer test page and noted that there is not table of contents at the top of the page. So if I want to see whether a certain subject has been discussed, I need to scroll through the whole page? --Randykitty (talk) 08:41, 5 September 2014 (UTC)

Flow is a memory hole: there's no TOC, no archive functionality, no search feature. This is just one reason why deployment to high volume pages, like, umm, the Teahouse, is a crap idea. BethNaught (talk) 08:51, 5 September 2014 (UTC)

And that would also apply to my own talk page? OMG!! That would lead to a huge talk page (look at the archives I have) and make it impossible to revisit older discussions... Nononononono! --Randykitty (talk) 09:18, 5 September 2014 (UTC)

But you can always check the history! Well, at least the 200 or so most recent edits, all the older ones are at the moment irretrievably gone. See e.g. [10] and try to get at any history from before 10 June (the page went live in February). You can find it topic by topic (if the topic doesn't have too much history of course), but not as a whole... This has been noted months ago, but hasn't improved yet. Fram (talk) 09:24, 5 September 2014 (UTC)

That alone makes busy talk pages almost useless. Dougweller (talk) 09:40, 5 September 2014 (UTC)

Only started to look into this yesterday, I'm here to edit, not to bicker about software. Seems like that was a mistake. Based on what little I have seen, I don't see any improvement to our current system. If it ain't broke, don't fix it! --Randykitty (talk) 09:43, 5 September 2014 (UTC)

@Randykitty, BethNaught, Dougweller, and Fram: There is a ToC coming. There are 2 current designs for that: the slightly older floating ToC on the siderail, and the newer a ToC at the top of sections (This semi-interactive draft version mixes 2 ideas: a ToC at the top of the sections, and a ToC in a fixed header ala Winter. It's likely that we'll see the simpler version soon, which will be basically the same as the existing ToCs. I'm advocating for it to be uncollapsed by default, but that would require some design reconfiguring.

Search is also coming, they're working on that with the 2 search developers right now,[11][12]

The historypage needing pagination is also being worked on.

Quiddity (WMF) (talk) 16:20, 5 September 2014 (UTC)

Good to hear. Thanks. Dougweller (talk) 16:37, 5 September 2014 (UTC)

Notifications galore, and editing "deleted" topics

Apparently everyone who is mentioned on this deleted topic gets an echo (with the wrong date?) every time someone replies to that discussion, even if they have not been named in the reply, and they haven't watchlisted this page, board or topic. This is clearly unwanted behaviour.

Furthermore, it is way too easy for administrators to edit deleted topics, this is clearly unwanted (not their specific posts there, we are only testing, but the option in general). Something that is deleted should remain unchanged until it is restored, otherwise you create admin-only discussion areas and a greater rift between admins and non-admins than we already have. Fram (talk) 07:22, 5 September 2014 (UTC)

I got two echo notifications this morning that someone mentioned me here 7 months ago, and have now twice (I think) been notified that someone created a new topic on that page 13 hours ago ... Andreas JN 466 13:00, 5 September 2014 (UTC)

I am getting the notifications too, although I'm not sure who mentioned me and where. BTW, I have never participated in Flow discussions. Δρ.Κ. ^{λόγοςπράξις} 15:14, 5 September 2014 (UTC)

@Fram: I've filed bugzilla:70449 for locking deleted content. Thanks.

Regarding the notifications for old topics, that must be a bug. @Jayen466:, what was the other notification that you got this morning? (so that I/we can try to diagnose/reproduce the error). Thanks.

It seems what happens is that when you click on the red number, you're always shown the "notifications", even if what you got was an "alert". (I linked the page in question above. All three notifications refer to the same page.) Just make it so that if there are zero new notifications, but 1 or more new alerts, you are shown the alerts, and not the notifications people have seen already. Andreas JN 466 18:42, 5 September 2014 (UTC)

@Dr.K.: If you have any of the pages watchlisted, you'll currently be getting "New topic created" notifications. The idea is that we can then watchlist the individual topics, if we want to follow them. If we are watching the individual topic, then we get notified when there are updates to it. This configuration is just a first pass, and will definitely need A) some ongoing tweaking, and B) probably some additional userpreferences. What additional changes or features, might be helpful? Quiddity (WMF) (talk) 18:38, 5 September 2014 (UTC)

Thank you very much Quiddity. I have unwatched the pages involved and it seems to be working, since no new notifications have come up. As far as other features, I haven't given this much thought so I cannot comment on this issue. Take care. Δρ.Κ. ^{λόγοςπράξις} 21:41, 5 September 2014 (UTC)

Wiki misconceptions

There are some important issues in the current design of Flow related to talk page mechanics which I would like to bring to people's attention:

Maximum level three indent. Almost every discussion in Wikipedia goes past that level and if it bottoms out at three then separate threads in a conversation become lost and hard to work through. The assumption that such threads should be split off is often not true.
No custom sigs. There is no evidence I've seen that they are causing a problem. Personally I'm ambivalent, but they are a popular and longstanding feature and any attempt to remove them will cause a massive stink.
No refactoring of posts except by admins. This could cause serious problems – what if a serious issue arises in a post and it needs to be redacted (legally dangerous libel, highly offensive and upsetting personal attacks) but there's no admin around? How can individual comments by a banned editor or a troll be removed? I am aware there is a hide function, but that is not total removal and that doesn't account for editing. In the words of Jimmy Wales (with whom I do agree on this matter) it "is a bad idea for a lot of very deep wiki reasons".

I think the community needs to discuss the reality of wiki discussion mechanisms here more to help the WMF develop a more effective model for Flow, and the WMF needs to be less keen on major talk page dynamic changes without community approval – since it is the community who will be doing discussion with it. BethNaught (talk) 21:57, 29 August 2014 (UTC)

Commenting on BethNaught's issues above:

I agree completely. Indentation in discussions is incredibly useful to knowing who is responding to what, and reducing the threading level to three may not be helpful, even when it's just a small number of people talking. Even back-and-forth between two just two editors can go beyond three levels.
I did see that the team brought up some arguments here about HTML causing display and formatting issues. Have signatures ever been enabled on Flow and if so, what problems did you find? I acknowledge from usability standpoint, the fact that links to user/talk page/contributions can appear in different places in one's sig is a bit strange, but all a new editor has to do is click on it to see where it takes them. There is also a very human element to signature customization that would be an unfortunate loss from a community standpoint.
I think the question of who can refactor things is still somewhat open, and I don't think any permanent decisions have been made about that just now. In fact, here under Post moderation, they write:

"Hide", "Delete" and "Suppress" - analogous to revert, revision-deletion and oversight - are current features for Flow, and will be present before the first deployment on Wikipedia. Users will also have the ability to delete/suppress entire threads.

with the addition comments of:

Flow currently includes a version of these features (as of August 2014). However, we're not completely satisifed with how "hidden" and "deleted" discussions are displayed on the Flow board; we'll come back for another revision before the end of the year.

So, it seems there is a plan to make sure comments can be deleted by editors, not just admins. It looks like they tried to implement this in an earlier stage, but it wasn't working so well, so they are probably back at the drawing board for the time being. I, JethroBT ^{drop me a line} 22:56, 29 August 2014 (UTC)

Hi, Beth -- I think I can answer some of those concerns.

First, just to clarify why we're prioritizing some pieces ahead of others -- There is a big list of features and requirements for Flow, if it's going to do all of the things that we'd like it to do. You can see some of that on the Wikipedia:Flow page under the quarterly goals -- but even that is a condensed list. We have lots of ideas. So for this next stage, we've chosen specific places where we're talking to the community about trying out Flow. The two places where we'll (almost) definitely roll out are the French WP Forum des nouveaux (the French version of enwiki's Teahouse) and a new mentorship project called the Co-Op, an enwiki community project that just got grant funding. There are a couple similar mentorship spaces around the wikiverse where we're talking to the folks who work on them. So with those use cases in mind, we're working on features that they need (search, table of contents, a better version of the moderation actions, the ability to create Flow boards as sub-pages), and we're putting off building features for other use cases.

So, for example -- people have pointed out that Flow isn't good enough to be on a Village pump right now, or an RfC-style structured discussion, or other high-volume areas. That is correct, and that's why we're not planning to go there until we've passed through several of these use case stages. RfCs is actually one of the most complex use cases, so it'll be a while before we tackle some of the features that we would need. Basically -- we're building Flow to handle the simple conversations first, and once we nail those, we move on to more challenging areas.

Here's where we are with the three items you mentioned...

Indented replies: There are two big reasons why we use indenting on wiki talk pages. One is a workaround for a deficiency in wiki talk pages -- most discussion systems automatically display people's posts in a way that makes it clear visually where one person's message ends and the next one begins. Using colons to indent is a workaround that has become the culturally accepted default. In Flow, we don't need to use indenting in order to separate people's posts visually -- the board does that automatically.

The other use for indenting is, as you said, to allow for branching discussions on big, complicated conversations, especially RfC-style consensus/voting conversations. That is a very important part of those kinds of complex discussions, and we won't be able to use Flow for those kinds of use cases until we have a way to handle those branching discussions better. The level of indenting that we have right now is appropriate for the simpler one-on-one and group conversations that we're focusing on in this stage. We have some big-picture ideas for how to handle the more structured branching discussions, but it's a ways off.

Custom signatures: Custom sigs are another beloved workaround that grew because the system doesn't sign your posts for you. The basic system that you see on Flow right now automatically signs and dates a message, which at least means we don't have to deal with the headache of unsigned templates and teaching newbies to add four tildes.

But one of the good things about custom signatures is that you get to change the name that you sign -- for example, my personal account is User:Toughpigs, but my custom signature is [[User:Toughpigs|Danny]]. We are definitely talking about building a "preferred name" into Flow signatures, possibly something like Danny (Toughpigs) in my case, where Danny comes from a preferred name field that I fill out somewhere. The only reason why we haven't planned for that yet is that a preferred name would be useful for a few different Wikimedia projects, and we have to discuss it with some other product teams to make sure it works for all of us.

The other stuff that people use in their custom sigs -- colors, sparkles, catchphrases, etc -- that's a very controversial subject among the Flow team. Those elements can add a lot of personality and fun. They can also get really annoying if they're not done right. So we're punting on those until we get a clear mandate from the people. :)

Hiding/refactoring: There's a few different elements here. The basic functionality that we absolutely need to provide (and we don't quite do it correctly yet) is the ability of any user to take obvious spam and vandalism off the page. That stuff happens, and the best way to deal with it is the way that wikis always have -- if you see something bad on a page, then you hit the edit button and clean it up, without having to go and report it to someone else. The bad thing is still accessible in the history, and people have the ability to undo your edit if it wasn't actually that bad after all.

So we've got a Hide function right now, and any user can hide a bad topic, or a single bad message within a conversation. The problem is that the first version that we built doesn't actually hide things enough -- it leaves a big clickable button on the page that basically shouts "come look at the bad thing!" The next version, which you'll probably see in a few weeks or so, will actually take the hidden thing off the page, so that it's still accessible in the history but not on the page anymore. We're also going to add undo and rollback functionality on the thread and board history pages.

The other piece is the ability to edit other people's messages. Flow doesn't allow this right now, but I know it's something that we have to address. The most basic use case is that somebody includes a link that doesn't work, and it's nice if someone else can fix it. We're talking about a few different ways that we can address that, but we haven't found the perfect idea yet. It would be great to talk to you more about it, if you're passionate on that subject. I'd love to have another person to bounce some of these ideas off.

Anyway -- I hope that was a helpful look behind the scenes a little bit. As we get into the next stage of development, I'm going to be doing a lot more of this kind of thing -- getting ideas, answering questions, bringing interested people into the process more. If you're really interested in the ins and outs, we're using the public EE mailing list for a lot of discussions about what we're working on. You should feel free to join that list, or let me know what you think here on the wiki. Thanks! DannyH (WMF) (talk) 23:19, 29 August 2014 (UTC)

Thanks for the detailed reply, I will keep looking at the test pages to see the new functions. BethNaught (talk) 07:20, 30 August 2014 (UTC)

DannyH (WMF), what's so difficult about indenting to more than three levels? That's really, really, really basic functionality others have solved long ago. Look at Reddit. My advice would be don't even think about bringing anything to the community until you have replicated that functionality. You'll be a laughing stock or worse, and rightly so. Andreas JN 466 00:40, 30 August 2014 (UTC)

Jayen466: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --Jorm (WMF) (talk) 00:47, 30 August 2014 (UTC)

Is "more than three" synonymous with "infinite"? Deltahedron (talk) 09:32, 2 September 2014 (UTC)

In computing, typically yes :-) It's the limit at which the programmer decides that the behavior should be implemented as a procedure that can handle arbitrary size. Diego (talk) 09:56, 2 September 2014 (UTC)

Odd that we spent all that time discussing numbers between 3 and infinity then. But the point is whether Flow has been designed to work the way people want, or the other way round. The casual assumption that the programmer decides that is revealing. It may be implemented as being capable in principle of indefinite indentation internally but nonetheless restricted to some specific limit (possibly depending on workflow, application or platform) in the code. I suppose the question is, what is the design goal here, and where can we go to read the explanation of why it was chosen that way? We know for a fact that alternatives such as 8-12 and 30+ were being discussed at one stage. Is there documentation that explains why they were rejected? Exposing that now would save having to have that discussion all over again, or alternatively annoying people with a flat those are the design goals. Deltahedron (talk) 10:16, 2 September 2014 (UTC)

Please don't infer too much from my tongue-in-cheek comment. I meant to convey the idea that, once you create generic code to allow for arbitrary nesting all levels will therefore be shown in the same way, whereas if there's a custom-made limit, different levels could be made to look and behave differently.

This doesn't imply anything about the state of the design process, of which I'm not aware. AFAIK, designers were still open to experimentation and haven't discarded any possibility, yet they are testing the possibilities of limited nesting. IIRC they promised a new design for the next version using user feedback gathered from the working prototype. Diego (talk) 12:15, 2 September 2014 (UTC)

This discussion is quite interesting, especially the part under the heading 8-12 levels of nesting. There are three comments from WMF staff saying that it wouldn't work for mobiles, and one user saying OK. That's not quite such a compelling consensus against indenting beyond 3 as one might have wished. But still, the design goal is fixed now. Deltahedron (talk) 18:08, 2 September 2014 (UTC)

So Flow is designed for mobile use? Do you expect people to do encyclopedic work while standing in the subway with their mobile phone? Fair enough, occasionally one might want to fire off a talk page reply in such a situation, but then I think it would be rather better to cater for that situation by having mobiles display the talk page indents differently, perhaps with micro indents. Does anyone know what Reddit threads look like on a mobile? Andreas JN 466 01:46, 30 August 2014 (UTC)

Having borrowed a mobile, I find that Reddit looks much the same there as it does on a desktop computer. And it's perfectly usable, infinite indentation and all. (By the way, one thing I really like about Reddit is that when two people go on and on replying to each other ad infinitum, eventually, after 10 indents or so, Reddit will just put an arrow link to a new subpage.) I honestly don't see the problem. Andreas JN 466 02:05, 30 August 2014 (UTC)

@Jayen466: At Reddit, just replace the "www" with "i" to get their mobile version. Interestingly, they don't display as many levels in their mobile site: see desktop and mobile comparison of the same thread - 10 levels are shown on desktop, and only 5 in mobile, despite the indent-width also being reduced. Quiddity (WMF) (talk) 23:37, 2 September 2014 (UTC)

Thanks, Quiddity (WMF). I found both the mobile version and the desktop version of Reddit usable on a mobile. So yes, smaller indents might work on a mobile, and it would surely be possible for Flow to host five or more, and then use a similar system to Reddit on mobiles to follow longer subthreads. It's a problem they've solved, so why shouldn't WMF be able to? Even if this is solved (and it should) there are of course further problems, such as how to allow communal editing of a chunk of Wikitext, using tables etc. You have your work cut out, guys. If I were you, I'd look at keeping the underlying structure of talk pages the same, but bolt an optional interface on top that allows people to reply without having to insert colons, asterisks and signatures manually. Andreas JN 466 16:45, 3 September 2014 (UTC)

Do we not have a separate interface for article pages on mobile devices? Why was that option was rejected for talk pages? Incidentally, could somebody link to the design goals and, if possible, please point to the design documents that explained the reasoning behind the design decisions? Thanks. Deltahedron (talk) 17:06, 3 September 2014 (UTC)

Seconded. Andreas JN 466 13:03, 5 September 2014 (UTC)

@Quiddity (WMF): I think you have just acknowledged that there needs to be different functionality for desktop users and mobile users. It's common practice, at least with database driven sites, to use a combination of responsive design and logic to present different content arrangement and interface elements for desktop and mobile users. One only has to look at this very talk page to see why multiple indents is so important. The design FAQ suggests that reducing the number of indents is conducive to "healthy discussion", and that flat is better than nested. I'm skeptical, but here's an experiment you can do: Edit this page to replace all of the sequences of four or more colons with three colons, and then see how healthy the discussion is.- Mr X 17:20, 3 September 2014 (UTC)

Jorm, Flow needs to work best for the vast majority that edits talk pages from non-mobile, not for the tiny minority that wants to edit talk pages from a mobile device. If you want to provide options that make talk pages look or behave different when opened on mobile devices, fine; but making your editing environment suck for the majority of editors, for the benefit of the few, is not designing for the future.

Then again, in it very telling that you equate "being successful" with "meeting the design goals", and not with "being the best possible solution for as many editors as possible", no matter what the original design goals were. WMF seems very bad at responding flexibly to changing circumstances, to reality checks, to problems that arise from earlier goals and choices; it just sticks to what was decided years ago, no matter if that is the best thing to do or not. VE, MV, Flow, the list is getting quite long. All the words about community input, working together, listening to the users, and so on, seem to be just as hollow now as they were a few years ago. Then again, most of the people uttering them are the same, so why should we except any improvements? Fram (talk) 14:02, 1 September 2014 (UTC)

DannyH (WMF), I have a hard time thinking of a clearer "mandate from the people" that WMF has received than that this limit of three levels of indentation is unacceptable. I can't recall a positive comment from a user about it, although I can remember Maryam saying that she doesn't like infinite indentation and Jorm complaining that he doesn't want to implement it. It's not a particularly special function: I hit over that on my user talk page frequently, and it happens on nearly any contentious discussion. Why would you wait for a mandate from the people about signatures? WMF has proven itself perfectly content to proceed without it when it comes to software development, and shows little compunction about intentionally and purposefully contravening such user mandates. What makes signatures special?—Kww(talk) 23:03, 31 August 2014 (UTC)

@DannyH (WMF): Replying to some things: Indenting: You say that your revision of Flow as it stands is built for small conversations, for small talkpages. Herein lies a fundamental problem in the way that the WMF perceives Flow and the community. Sure, most talk pages will only be confined to little discussions, but on all pages, no matter how big or small, someday there will be an edit war, there will be an RfC, and the software must be ready for that. Consider a dam. Dams are not built to hold what the engineers think will be the minimum capacity, but rather the maximum. I think that it is a testament, not a design problem, to the way that Wikipedia discussions draw so many people and opinions.Also consider this talk page. Mostly discussions fall within the "three indent limit". But this discussion is a monster. How will Flow handle it? Not very well.Custom Signatures: As mentioned above and below, people with names with non-latin characters will have problems. You mention that it has been much a subject of debate among the Flow devs. Not so among the community. It illustrates once again the fundamental divide between devs and the community. I see also the problems that hiding, refactoring, and editing other people's comments have given you. While I am sympathetic, these are things that text editors should be built around, not added later. Fram also mentions in another section issues with deleting talk pages. This can be put off as not an essential function, but going back to the dam allegory, the time and capacity will come to use it. Also, deletiononly hats the posts. How will RevDel work? This could have implications for BLP should an editor decide to post libelous materialFinally, I think the project has turned into a skycraper with no foundation. They are so worried about indents and sigs that they forgot to add editing and removing posts, a fundamental feature. --KonveyorBelt 17:34, 3 September 2014 (UTC)

On the point of signatures there is the case of people who have non english usernames especially those in non-latin scripts. For example User:烈之斩 User:सर्वेश मिश्रा, User:ליאור. These are becoming increasingly popular since the introduction of single user login. Often these use a latin name to sign themselves for example User:ליאור signs himself as Lior and User:ברוקולי signs as Broccolo. Without the ability to sign using a recognisable script it becomes hard to distinguish these users.--Salix alba (talk): 06:21, 30 August 2014 (UTC)

My signature on other Wikis points to my user and user talk pages here; until we have interwiki Notification, if someone wants to contact me, they have to leave a message on my talk page here, not meta, WikiSource, Wiktionary, de.Wiki, es.Wiki. — Arthur Rubin (talk) 06:32, 30 August 2014 (UTC)

There seems to be a lot emphasis on accommodating mobile users, while making design compromises that might adversely affect non-mobile users. This obviously supports the notion that there is an uptrend in mobile browsing, but has anyone done an analysis of user's talk page participation from mobile devices? Jayen466 makes good points about indentation and Reddit as model for such, although I don't advocate unlimited indents. I find Reddit very usable using Android with Dolphin browser.- Mr X 17:34, 30 August 2014 (UTC)

LOL, thanks for mentioning me (User:烈之斩). I just changed my name to English, Chinese Character is really annoying TBH.--fireattack (talk) 22:22, 31 August 2014 (UTC)

@DannyH (WMF): "the ability of any user to take obvious spam and vandalism off the page. That stuff happens, and the best way to deal with it is the way that wikis always have -- if you see something bad on a page, then you hit the edit button and clean it up, without having to go and report it to someone else. The bad thing is still accessible in the history, and people have the ability to undo your edit if it wasn't actually that bad after all. " No, the most common occurrence when you see something bad on a page is to hit the "undo" or "rollback" button. Oops, these no longer exist in Flow. Why? No one knows. Now, if someone makes multiple bad posts in Flow, you'll have to hide them one by one, instead of simply doing rollback. Or instead of doing "undo" on many edits in someone's contributions, you'll have to open every discussion, find the right post.... While the hide option is good, and it is nice that it is somewhat easier to get rid of one bad post when reading a board or topic, it is abosuletly bad that you have made it a lot harder to get rid of problematic posts across multiple pages (spam and the like). Fram (talk) 08:28, 1 September 2014 (UTC)

Misconception: Mobile editing is the future for talk pages

According to Jorm from the WMF (above): "Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past."

Reality? Of the last 500 edits to the talk namespace (i.e. Article talk), 1 (yes, one was made from a mobile device, according to the tags): [13] Of the last 500 edits to the Wikipedia Talk namespace, none (nada, nil, not a single one) got a "mobile edit" tag: [14].

You can compare this with the article namespace, where 26 out of the last 500 edits got a "mobile" tag[15].

So, why are "we" (the WMF, that is) building a tool "for the future" that is aimed at a non-existant market, with smaller screen size, less indentation, and so on? Who has made these decisions, based on what research? And who will revert these decisions and inform their devs that the future of talk page editing is not "editing from mobile devices" and that mobile editing considerations should be given much less weight from now on? Fram (talk) 16:50, 1 September 2014 (UTC)

I will add here that on the few occasions where I have participated in lengthy discussions on Facebook, not being able to tell which post anyone is replying to is an absolute pain. And the discussions we have here are different in nature from the typical Facebook discussion: they concern sometimes intricate points of detail and argument, comparisons of source wordings and so on, where you need to be able to see the logical thread bright and clear in order to be able to follow what people are saying at all. Unquestionably, Wikipedians sometimes argue too much and too interminably. But if you make it physically impossible to engage in a sustained conversation, you're chucking out the baby with the bathwater. Andreas JN 466 19:41, 1 September 2014 (UTC)

Both during Wikimania and just now I tried browsing a selection of articles on a mobile device, and found that I can't actually work out how to get to the talk page without going through search or similar. That might explain the imbalance. Beyond that, I agree with Andreas. Nikkimaria (talk) 01:11, 2 September 2014 (UTC)

Strange enough, nothing in Flow (so far) helps any editor in finding the talk page, everything that has been developed is about what happens after you found that page. This seems to be another major oversight. Fram (talk) 06:36, 2 September 2014 (UTC)

Agreed: I tried it today on an Iphone 4S in Safari on the mobile website and couldn't find the talk page either -- and I knew it was there, and was looking for it. Deltahedron (talk) 19:27, 3 September 2014 (UTC)

@Jorm (WMF): "Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past." - There may be a fundamental problem in this approach which maybe isn't immediately visible to those who focus on software development: As Wikipedia has grown, the focus of encyclopedic work has shifted away from quick, rough content additions and towards creating an encyclopedic resource that can be taken seriously and where the content is thoroughly verifiable through references. Many people have great trust in Wikipedia (often too great, they should question us more) and this creates great responsibility. In-depth working at such a resource simply doesn't happen on mobile devices: When I work on a complex article (I'm active mainly in German Wikipedia), it may involve switching between a dozen of tabs with literature, and it may also involve complicated discussions with others. I don't want to do this on a mobile device, and the basic reason for this is very physical - screen size and handling, so I doubt that this will change with more advanced mobile devices in the future. Mobile editing is great for correcting typos and doing simple things that don't require discussion, but have you ever written a fully referenced article like de:Tynset (Roman) (an example of my newer work) on a mobile device? I think - this goes also to @Erik Moeller (WMF): - that it's very good to optimize Wikipedia for mobile reading, as well as to add options for easy mobile editing, but this should never unnecessarily obstruct more in-depth editing that isn't possible with mobile devices limitations. And, by the way - we're living (and editing) neither in the future nor in the past, but in the present :) Gestumblindi (talk) 20:41, 5 September 2014 (UTC)

This is an excellent post, and I think Gestumblindi has hit the nail on the head. The question, beyond all the user specs and requirements, which need to be determined, is whether Flow is being developed so that people can just simply dip into a talk page when they have nothing better to do and are waiting for a train, mobile device in hand? If so, then talk pages will quickly become forums. But Wikipedia is first and foremost project where content editors write (for the most part without pay) content for others to read. Often this is done alone and there's little talk page work. Other times it's done in collaboration and quite a lot happens on a talk page. So I'd want to know from the developers (i.,e Jorm (WMF)) whether Flow will be able to support the kind of work that that's been going on at a page such as Talk:Beaune Altarpiece? Thanks in advance for answering. Victoria (tk) 21:45, 5 September 2014 (UTC)

View deleted

I was wondering whether "view hidden" (for [autocofirmed?] users), "view deleted" (for admins), and "view suppressed" (for Oversighters) will be implemented. It seems a minimal effort to ensure transparency among those who could see the material, to allow them to do it without making it visible to all. — Arthur Rubin (talk) 00:22, 6 September 2014 (UTC)

Well, you should definitely be able to access anything through history or contributions, if you have the user right to see it. We're going to be doing some more work on all the hide / close / delete stuff. We need to at least match the functionality on wiki talk pages, which it doesn't yet. DannyH (WMF) (talk) 01:25, 6 September 2014 (UTC)

Please be so kind as to respond to some questions

I asked some questions of general interest to the community at large. So far they have not been answered, or even acknowledged, by WMF staff. If you are not going to answer them, it would be polite to at least say so explicitly. For reference, they were:

(In the context of an exchange about three levels of indentation versus infinite indentation) Is "more than three" synonymous with "infinite"?
Is there documentation that explains why [alternative indentation choices] were rejected?
Do we not have a separate interface for article pages on mobile devices? Why was that option was rejected for talk pages?
Incidentally, could somebody link to the design goals and, if possible, please point to the design documents that explained the reasoning behind the design decisions?
Perhaps the relevant design documents, with the decisions and the reasoning behind them, which will have been generated during the design and planning process, could be posted, or pointed to?
(When Brandon said "In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future,..." was he referring to a set of specific agreed goals in existence today that you can point to or publish, or should we read that as a statement about what the goals would be like when they are agreed at some point in the future?

Thanks in advance. Deltahedron (talk) 19:55, 5 September 2014 (UTC)

Re: Threading/indenting: There have not been any recent decisions on indenting, and it is one of the major issues to be re-examined in the near future. Nothing has been rejected. There are a lot of pros and cons to each of the various options, and Danny wants to compile those details so that we can discuss it anew. I'm hoping for some test pages/instances so that we can demonstrate the pros and cons in-action, and compare side-by-side, but at worst we can create demo's with :::indents. (Personally, I like the roughly ~10 levels that wikitalkpages and reddit use, so that's my bias, and are why I originally put together that listing used in the old major discussion. But I understand the benefits of flat&chronological discussions with selective "quoting" as gmail/forums/bugzilla uses, and I'm looking forward to discussing it again.)

Re: design decisions and documents: so far, the wireframes and mockups generally get attached to the trello cards, or discussed in meetings (and in person and in IRC and in the various mailing lists and CC-threads). However, per Wikipedia:Flow/FAQ#Components of the discussion system, most of the ideas are still experimental, and they've been working to get them into a functional state precisely so they can be tested and extrapolated upon, and (in the near future) discussed with all of us (and the communities at the other wikis) using real working examples rather than just textual-descriptions or static wireframes/mockups.

The abstract design goals are the 3 bullet points at the top of the main project page; I believe that is what Brandon was referring to. Danny did a large overhaul of the primary documentation page at the beginning of August, and there'll be a bunch more work on that and the other pages, next week. Quiddity (WMF) (talk) 23:58, 5 September 2014 (UTC)

Thank you for that. Before commenting further, perhaps someone could enlighten me, please — what on earth is a "trello card", and where on earth would I find it? Deltahedron (talk) 06:36, 6 September 2014 (UTC)

It's a project management tool used by the team; you can see the current sprint here, for example. The presentation can take some getting used to but is a pretty standard way to manage software projects.--Erik Moeller (WMF) (talk) 06:38, 6 September 2014 (UTC)

Thank you. I now realise that I don't know what "wireframes" and "mockups" refer to in this context, and perhaps I am not the only person in that lamentable state of ignorance. Could you enlighten us further please? Deltahedron (talk) 08:08, 6 September 2014 (UTC)

A mock-up is a higher fidelity representation of a user interface, whereas a wireframe is used to primarily describe the interaction logic and rough layout in a design and lacks visual detail. Here's an example card where the team discusses a simple design change, using mock-ups to illustrate it. You can look at the previous sprints board, as well, to see many examples of both design and functionality changes.--Erik Moeller (WMF) (talk) 08:26, 6 September 2014 (UTC)

Once again, thank you. Deltahedron (talk) 10:07, 6 September 2014 (UTC)

Reference does not support contention

So I just watched this video File:WMFUsability_highlights_explain.ogv which is listed as a reference purporting to support the need for flow. If there's anything about talk pages in it, I missed it. NE Ent 12:04, 6 September 2014 (UTC)

Effort justification

I see the following problem. Until (and unless) Flow is almost satisfactory for all processes used on talk pages, we (or at least I) will be unable to speculate as to whether it will ever be a satisfactory replacement. (The fact that templates are now substituted, as a gloss on the Parsoid modality, suggests that templates will always be substituted, which is completely inappropriate for any page which may need to be used to discuss tests of use of templates. There are other problems for which I cannot see viable solutions, which would prevent it being appropriate as a replacement for article, user, or template talk pages. There may be other problems I haven't thought of which would make it essentially unusable for most other types of discussion pages.)

As an aside, it appears that some WMF people have misinterpreted what I said was part of a MVI; that most templates be usable as templates (and copy/paste as templates) which displays more-or-less as they would in article-space. "Substitution" is not satisfactory.

That being said, the WMF teams will have to put a lot of effort into Flow before (I, at least) could support its rollout, except on some specialized discussion pages. Then effort justification steps in. The teams (and possibly WMF management) will be reluctant to admit that they have spend a lot of time and effort on something which cannot work, so they may force it into use.

Is there any process in place at WMF to counter this tendency? If not, I would vote for the immediate termination of the project, as, even if it cannot work, it's likely to be put into effect. — Arthur Rubin (talk) 11:47, 6 September 2014 (UTC)

Indeed, this reboot would be the appropriate time to have considered terminating the project. I wonder whether that was ever explicitly discussed? If not, then that would be strong evidence for AR's analysis. If it was, then it would be interesting to know which stakeholders were involved in the discussion and to see some documentation of the outcome. Deltahedron (talk) 12:33, 6 September 2014 (UTC)