Wikipedia talk:Flow

Report on Infinite scrolling

Yesterday's Alertbox column from the Nielsen Norman Group publishes an analysis of the usability of infinite scrolling. Some highlights:

• Continuous scrolling is advantageous for content that streams constantly and has a relatively flat structure, where each unit of content belongs at the same level of hierarchy and has similar chances of being interesting to users.

• Infinite scrolling has advantages, but should be applied with caution. Endless scrolling is not recommended for goal-oriented finding tasks, such as those requiring people to locate specific content. Finding [information] by feature might be difficult to accomplish quickly if all of the [topics] are presented linearly on a never-ending page, without sorting or other filtering or navigation techniques to help isolate the intended item.

• Locating a previously found item on an extremely long page is inefficient, especially if that item is placed many scrolling segments down. It’s much easier for people to remember that the item is on page 3 than it is to gauge where the item is positioned on an extremely long page.

• Endless scrolling can hurt the user experience as well. For task-driven activities, infinite scrolling can feel like drowning in an information abyss with no end in sight.

• With pagination, there is a beginning and an end. There is a happy sense of completion when a page is reviewed. Pagination gives people control to decide whether or not to continue to the next page.

• Infinite scrolling breaks the scroll bar by causing it to display the page length inaccurately.

Other analysis I've found for the usability of infinite-scrolling pages are this Smashing Magazine article, and this research paper providing a framework to study their usability. While results are still inconclusive, it seems to me that the infinite scroll metaphor is suitable for content consumption, but it's a bad choice for directed tasks such as collaboration and retrieval of archived content (two central goals of Wikipedia talk pages). As the focus of design in FLow is to use previous research for inspiration, I'd want to ask which research was evaluated when the choice to use an infinite scrolling interface was made, and whether you will ponder some alternative designs on the light of these findings. Diego (talk) 13:00, 3 February 2014 (UTC)

That's fantastic research, Diego; thank you for undertaking it and for providing us with the results :). User:Maryana (WMF), read! ;p. Okeyes (WMF) (talk) 19:27, 3 February 2014 (UTC)

Diego, yes, thank you again for gathering this info you're points are well taken for flow its interesting because some users will be mostly consuming and others consuming and contributing (task based interface) while we'd love for everyone to be part of the conversation (a major product and design goal for flow) we do want the information to be easily understandable very quickly for someone who isn't already part of the community or a specific discussion. We're working on search, we have multiple view formats for a board and the ability to deep link into a specific conversation or share a marker to a specific comment or tangent. We're investigating ways to display the right content at the right time, e.g. initially hide or show tangent replies? what level of default expansion do we show to new users, etc.

to you specific question about how are things findable in infinite scrolling interfaces? we have to work within the framework of the browser, e.g. you can browser find on page, something that isn't technically on the page at that point. How do you handle the state change when someone leaves a page and comes back via browser history buttons, to me these are mostly technical hurdles and I'm confident we can solve them. Check out http://developers.soundcloud.com/docs to see an interesting way they've delt with location in a long document, both via the TOC and a url hash. I think something like this plus some basic browser history manipulation could make the experience great for users with infinite scrolling.

I think only with some real world testing after the launch to the initial participating wikiprojects will we be able to answer some of the questions this poses. Jared Zimmerman (talk) 21:24, 3 February 2014 (UTC)

We do? Exactly who do we think will be simply reading the talkpage without any intent of contributing to it? Okeyes (WMF) (talk) 22:07, 3 February 2014 (UTC)

@Jared Zimmerman: Any answer on Okeyes (WMF)'s question above? I can't imagine anyone coming on a board (discussion page) only to read everything that's already there, indefinitely until he reaches the end of the board, without being somehow involved in a task. That task could be the intention to contribute to some of those discussion topics, the intention to start a new discussion topic if there isn't already one about the matter he has in mind, the hope to find some conclusions on a previous discussion that could guide his current work on an article or help him understand the background of some decision, the need to assess a user's behaviour (in contexts such as anti-vandal fight and ArbCom)... whatever except just reading because he has nothing else to do ! In my opinion, discussions are not the type of content that people would just consume without being involved in any kind of task. Klipe (talk) 11:41, 5 February 2014 (UTC)

Thanks. When you can search (more like filter) a Flow board to only show matching topics, I hope we'll get the best of both worlds. If you're collaborating on a particular topic, I think you would start with its permalink. With existing talk pages, following a link like Talk:SomeArticle#Section_heading when the section has been renamed or archived is very frustrating; permalinks are better in that you'll always get to see the topic, and we're working on making the UUID of the post a little shorter (but still opaque). -- S Page (WMF) (talk) 22:00, 3 February 2014 (UTC)

Yes, true permalinks would be an improvement for archiving. But I'd rather have permalinks and search results work as an entry point to the infinite stream, not only to see the linked topic isolated. I.e. following the link should show that topic at the top of the screen, but it should still be possible to navigate down and load the other earlier topics as "more content" (and probably there should be a link at the top to load "newer content" too). That truly would achieve the best of both worlds. Diego (talk) 23:15, 3 February 2014 (UTC)

Flow live on Enwiki

Testing can be done at Wikipedia talk:Flow/Developer test page. Thanks!

Newer code (arriving here soon) can always be seen at mw:Talk:Sandbox, or even newer code at http://ee-flow.wmflabs.org/wiki/Sandbox.

Hi folks. I'm pleased to announce that, with the permission of the users involved, we've deployed Flow to Wikipedia talk:WikiProject Breakfast and Wikipedia talk:WikiProject Hampshire. Obviously, the intent is for editors to use the Flow boards as they would a normal talk page, so please don't use it for testing (unless you're a wikiproject member, of course!) - just use the test space at mw:Talk:Sandbox. If you've got feedback, please feel free, as always, to leave it either here or on the MediaWiki.org Flow talkpage. We'll be asking them directly in 2/4 weeks whether they're happy to continue testing, but will greatly appreciate all the feedback you all can give in the meantime. Once the first set of WikiProject members have had a chance to try out the software, we will be seeking other WikiProjects to volunteer for participation in this working-environment testing. Quiddity (WMF) (talk) 22:15, 3 February 2014 (UTC)

Basically as predicted: I tried to watch Wikipedia talk:WikiProject Hampshire, which made my watchlist unusable: About half of the top screen are taken by the activity of the Wikiproject talk. Unwatching now until smth gets modified.--Ymblanter (talk) 22:37, 3 February 2014 (UTC)

My experience from the Flow talk page on mediawiki.org is much the same. The truth is, it will require a slight shift in behavior. Unless you really want see all discussion activity, I would just unwatch a Flow board and instead wait for notifications that are built in when someone replies to a thread you're participating in or mentions you. Steven Walling (WMF) • talk 22:55, 3 February 2014 (UTC)

Well, no, because then you never get to actually see what's going on unless you've already participated. User:Ymblanter, this is a bug, not a feature; we'll be fixing and limiting it in the next 2 weeks. Okeyes (WMF) (talk) 22:58, 3 February 2014 (UTC)

@Okeyes (WMF): really? It would be nice but doesn't seem to correspond to what Quiddity (WMF) replied to Fram on [postId=050f6c3fc6c92a1965be90b11c2d7b68&workflow=050f60e47753c65f22ff842b2b7829bb#flow-post-050f6c3fc6c92a1965be90b11c2d7b68 mw] just 7 days ago. Could we get new feedback there, also on the proposals made by Skalman and myself (here)? Klipe (talk) 11:58, 5 February 2014 (UTC)

So if you're hiding this, will normal users get to see a topic has been replied to, as normally shows up on a watchlist or will you have to go to a talk page to discover what discussions have been going on? Also, why is the font so big? Finally, the Flow project has (I assume temporarily) wiped the history from WikiProject Hampshire and only replaced it with the Flow discussion history. Simply south...... disorganising disorganisation for just 7 years 00:02, 4 February 2014 (UTC)

@Simply south: Re: watchlist contents - there's definitely some tweaking needed, both immediately, and over the long-term as new features (such as per-topic watchlisting) get added. In the short-term, I believe they'll be aiming to get it to display as we expect (ie. only showing the last/most-recent change to the Board). But ideas for how it could be even better than the-standard-watchlists-we-have-now, are warmly appreciated. (Some ideas have already been put forward, but not compiled yet. Plus I'm hoping that we'll get some new/unique ideas if editors aren't presented with a list of options, but rather are given a blank slate to dream upon..)

Re: Font size in Flow Boards - there's an FAQ entry that briefly touches upon this issue (linking to a single ref). I'll ask the design team for additional info.

Re: History - I did a page-move archive so that the page history was easily accessible. :) Quiddity (WMF) (talk) 00:26, 4 February 2014 (UTC)

First impression

I'm not involved in the participating WikiProjects, so I didn't do any testing, just had a look. Here's my very first impression:

• The fonts are huge. My first reflex was to zoom out with the browser, but then the rest of the interface gets tiny. Are there plans to allow for custom settings or even skins? Maybe via custom css? It's hard to get an overview of what's going on if you can see only very few posts at a time.
• Clicking on the undelined '6 comments' (the only item that actually looks like a link) in collapsed view does nothing. In full view it scrolls down to the end of the comments. I don't see why, would have expected the link to toggle the collapsing of that thread.
• The little pencil and flag icons have no tooltips and don't seem very intuitive by themselves.

I know it's not done, I'm not meaning to complain, just some feedback from fresh eyes. Hope it helps. — HHHIPPO 22:43, 3 February 2014 (UTC)

• Re: font sizes - I'll ask the design team to weigh in.
• Re: the underlined '6 comments' link not functioning as expected - I think this is covered by bugzilla:58372 (patch-to-review) but I'll check with the devs.
• Re: The pencil and flag icons - they're being moved entirely. You can see/test the upcoming design at mw:talk:sandbox. ('edit' links will be permanently visible next to the permanent 'reply' links, if one has permission to edit the post. the flag-moderation icon is being moved into the "action menu" (3-dots icon).)

Much thanks for the feedback, 'tis appreciated. :) Quiddity (WMF) (talk) 01:10, 4 February 2014 (UTC)

Thanks for the reply, I'll see what happens. As a general note, I have to say I don't like the look & feel yet, but I find all the new features that might eventually become possible exciting. So I'm glad you're working on this and I think this mini-deployment was a good idea. — HHHIPPO 07:37, 4 February 2014 (UTC)

Now that it's here, and I also have a few minutes to really look, there are some key points I'd not paid attention to on Mediawikiwik (where I was trying to figure out hiding and stuff):

• Agree with Hhhippo, the fonts are way too big. Please revert to the normal font.
• More importantly, the smaller size of font in the replies psychologically suggests that responses are less important than initial statements.
• Unless one is actively mousing over the initial post, it's not obvious that there's a "reply" space; the word "reply" isn't visible. It should always be visible, unless you want everyone to just add comments. While I'm not discounting that possibility, it's hardly conducive to discussion.
• Find a way to make this compatible with existing archive processes; nobody wants to lose access to their past archives, nor to have to hunt around for them.
• The page history has to be accurate, and to include all posts made to the page. This by itself should be considered a critical issue that must be addressed, and I'm not convinced even the test should have proceeded without this.
• Way too many entries on my watchlist; just like current pages, it should default to include only the most recent change. I'm fine with an option to expand to all changes, but the default should be most recent change.

More will follow. Risker (talk) 00:51, 4 February 2014 (UTC)

• Re: Font sizes - I'll ask the design team to weigh in.
• The "reply" links will become static (always visible) very soon (I believe on Thursday). (See the upcoming design at mw:talk:sandbox)
• I know you know, but for anyone else: The Board-history and Topic-history are currently separated. iirc, there are plans to merge their display, but I'll have to check how far along that is. If it will be long, I'll see if we can get a note added to the page-history header.
• Re: Watchlist entry abundance - that will be a priority over the next sprint.

Quiddity (WMF) (talk) 01:02, 4 February 2014 (UTC)

About the watchlist integration: I agree it's basically not working yet, but the particular issue of cluttering is not too bad when using the enhanced watchlist ("Group changes by page in recent changes and watchlist", why don't such preferences have an easy to find name?). — HHHIPPO 07:37, 4 February 2014 (UTC)

Hhhippo, is that bugzilla:35768? Helder 22:02, 4 February 2014 (UTC)

Helder.wiki, no. I didn't have any problem finding the preference itself, I just wasn't sure by which name to refer to it, so I quoted the description instead. It would be nice to have easy-to-quote and easy-to-find names for preferences, like here. — HHHIPPO 22:42, 4 February 2014 (UTC)

Hhhippo, you can add "?uselang=qqx" to the URL to get the key of the message from MediaWiki namespace which is used for each part of the interface (in the example, "tog-usenewrc"). Then, you can use {{int: <key> }} to get its text in the user language ("{{int: tog-usenewrc }}" = "Group changes by page in recent changes and watchlist"). Helder 11:17, 5 February 2014 (UTC)

• I just noticed now that when I was typing on a Flow page, the entire screen output starting from the "reply" window on down was quivering. It was particularly noticeable for the cancel/preview/reply buttons (in fact the vibrating green button was what made it obvious) but it applied to everything below the "blue link" to my name, including the editing box. For the record, it's a nice stable monitor, and I've never seen anything quiver on the screen before, but the quivering was directly instigated by each keystroke. Risker (talk) 03:33, 4 February 2014 (UTC)

  @Risker: That's bugzilla:58657, which is fixed in the code-base, and that version should be live on Enwiki soon (either this Thursday, or next, if I understand correctly). Quiddity (WMF) (talk) 20:57, 4 February 2014 (UTC)

Glad to hear it, Quiddity. I don't usually look at the screen when I'm writing, and the quivering was pointed out to me by a family member walking past me about two meters away from the screen, so it's quite noticeable. Risker (talk) 21:00, 4 February 2014 (UTC)

Oh hold on. I just read the bug, and that's not what I'm talking about at all. Think about the bottom of the screen being a little chihuahua out in the cold. *That's* the kind of quivering I mean. That bug seems to report jumping of the screen when the entire post isn't visible. Risker (talk) 21:03, 4 February 2014 (UTC)

It's not just you. I often get the same shivering chihuahua effect on the screen while typing in Flow. Andreas JN466 23:01, 4 February 2014 (UTC)

Risker, what browser/operating system are you using? I'm pretty sure I know what is happening but I want to confirm it. (This would be a conflict between two css rules). --Jorm (WMF) (talk) 00:19, 5 February 2014 (UTC)

Win7 and FF26.0, Jorm. Risker (talk) 02:44, 5 February 2014 (UTC)

Large image when logged in

Not sure if this is intentional but when logged in I see File:Winter in New Hampshire.JPG as an embedded 3 megabyte image at the end, but not when not logged in. Tested with Opera (logged in and not, but I need to upgrade Opera) and Firefox (logged in only) and with Cologne Blue skin (also seen in Monobook but I use a lot of CSS and JS in that skin). I do have a lot of gadgets enabled but none that should expand images. -84user (talk) 23:08, 3 February 2014 (UTC)

Yeah, this is a bug in the software exploited by a user who chose to use an actual, used talk page for testing. The underlying bug will be fixed; the thread is deliberately now hidden. Okeyes (WMF) (talk) 23:11, 3 February 2014 (UTC)

Ah, I see. I thought it was part of the testing. How would an editor such as myself fix such problems, for example by changing the image to a [[:File:name.ext]] link as I would do normally? -84user (talk) 23:22, 3 February 2014 (UTC)

Currently the "hide" button is in the flag-icon, which is hidden under the image. >.<

Once the next release is deployed, (coming this Thursday), we would just click "hide" in the action menu, which will be in the grey topic-titlebar area (See the 3-dots action menu icon, in topics/posts at mw:talk:sandbox).

Re: Changing the wikitext: Flow is currently configured to only allow the original author (if signed-in) to edit a post, plus admins can edit the posts of other editors. This is explained (as an experimental config) at Wikipedia:Flow/FAQ#Components of the discussion system in the "Comment editing" row. HTH. Quiddity (WMF) (talk) 00:03, 4 February 2014 (UTC)

About archiving and staggered loading

How will Flow handle archiving? Flow has an infinite scrolling process, but there is sometime that you need to let those things go. If Flow isn't going to have a table of contents then that scares away users to have 500+ discussions and no way to navigate them. There will be a search box but nobody wants to have to manually look for a needle in a haystack.

Another problem with not archiving is that infinite or "lazy" scrolling only loads part of the page when you go to it. How will that be supported by, say, text only browsers, or people with slow internet connections? I can tell you that from someone who edits on a phone, lazy loading is unusable for the mobile interface.

With no table of contents, how are we supposed to go to the bottom? With each part taking time to load, getting to the bottom of 500+ discussions will take forever. This is rather unintuitive, not to mention a huge problem. How will we ever respond to new threads when you can't get to them? KonveyorBelt 04:10, 4 February 2014 (UTC)

I believe new topics go at the top, so there is no scrolling down to see the most recent. I just had a quick look, and cannot see any docs on that. What I'm wondering is how do I search a talk page—using the browser's "find" function, and using a tool to search archives. Johnuniq (talk) 11:50, 4 February 2014 (UTC)

Which is of no help if you want to scroll down to something that is not the most recent topic. Many times, "search it" is the wrong answer, and you still need a way to access some specific section through navigation. Diego (talk) 12:25, 4 February 2014 (UTC)

Custom signature

Will there be any option for custom signatures in flow? For example, my tree-colour signature? (I don't read MediaWiki discussions) Tito☸Dutta 09:45, 4 February 2014 (UTC)

No, see WP:Flow/FAQ#What happens to my custom signature?. Some of us think that is Flow's best feature. Johnuniq (talk) 10:45, 4 February 2014 (UTC)

• This is "forced point". A point is being created just to support another point. No one said anything against custom signature till now. WP:SIGN mentions some limitation but allows custom signature. And suddenly these signatures are becoming "disruptive". Tito☸Dutta 11:30, 4 February 2014 (UTC)

If you would like to highlight your signature in Flow I think the technique of adding an entry to your common.css file will still work, e.g.

#bodyContent a[title="User:Titodutta"] { background-color: #57C738; border:green ridge; font-weight: bold; color: #000; }

This code (should be all on one line, btw) will highlight your user name when it appears as the title of a link, e.g. Titodutta. You'll be the only person who see the highlight, so you can be as dramatic as you want. - Pointillist (talk) 11:17, 4 February 2014 (UTC)

• Thank you, But my signature resembles Indian flag Tito☸Dutta 11:30, 4 February 2014 (UTC)

You can't reliably use CSS to add characters like ☸ to your username, but you can use it to create multicolor backgrounds in modern browsers, like this: Titodutta. The customization in your common.css would look something like this (all on one line):

#bodyContent a[title="User:Titodutta"] { background: -webkit-repeating-linear-gradient(top,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); background: repeating-linear-gradient(to bottom,rgb(255, 153, 51) 0%,rgb(255, 153, 51) 33%,rgba(0, 0, 0, 0) 34%,rgba(0, 0, 0, 0) 66%,rgb(18, 136, 7) 67%,rgb(18, 136, 7) 100%); padding: 2px; font-weight: 400; color: #000; }

Apparently Flow will provide some mechanism for displaying a nickname, so perhaps you could display Tito☸Dutta. However, if you want your name to be read as Tito☸Dutta by others, why not permanently change it to User:Tito☸Dutta or at least register your nickname as a doppelgänger account? Otherwise anyone who registers your nickname as their username will be able to stop you from using your nickname, because of the policy about impersonating another account. - Pointillist (talk) 13:24, 4 February 2014 (UTC)

• Bad feature Custom signatures should be encouraged. Blue Rasberry (talk) 19:35, 4 February 2014 (UTC)

Actually, @Bluerasberry, I wasn't trying to take sides in that debate. But I know some people have been concerned about not being able to see their own contributions when scrolling down a Flow subscription, and I'm just pointing out that you can already use common.css to customize how your username appears to you when you are logged in. No-one else will see it, so you can be as outrageous as you wish, and it has the rather useful side-effect of highlighting your name on history pages and wherever other people link to your username. - Pointillist (talk) 21:47, 4 February 2014 (UTC)

Ahh, please excuse me Pointillist, as I was not trying to call you or anyone else out. I was just throwing an unattached opinion into the forum. If I were to respond to your points, I would say that I want to see everyone else's custom signatures more than I want to see my own. Blue Rasberry (talk) 21:54, 4 February 2014 (UTC)

Ironically, I was thinking just the opposite. :-) There are so many custom signatures where the "official" username and the one that shows up in the signature are unrelated that sometimes it's hard to tell who is who. And some of the add-ons become absurd; a fair number of the ones with lots of code in them make them hard to read. I suppose it's a good example of something that some users consider a feature and others consider a bug! Risker (talk) 22:02, 4 February 2014 (UTC)

Well, if you prefer not to see other people's custom signatures, there are a couple of techniques at Wikipedia:SIG#Over-riding_custom_signatures. - Pointillist (talk) 22:14, 4 February 2014 (UTC)

Not speaking for the team, just my long held personal opinion: WP:DEFAULTSIG. Legoktm (talk) 03:38, 5 February 2014 (UTC)

Please disable Flow from enwiki

Why has Flow been enabled on enwiki, when the discussions and tests on Mediawiki have shown enough major, major problems to keep you busy for quite a while?

We have:

• No decent history
• No decent watchlist entries
• No archiving
• No good search options
• No indication of how we can enable and disable Flow (locally, not by asking)
• No categories (the old talk page was on what, four categories?)

And so on. Some of these were part of the minimal requirements and promised to be implemented before going live with it.

If you desperately needed to test Flow here, why not use this page instead of a live environment? Fram (talk) 14:00, 4 February 2014 (UTC)

Honestly, as had been said at the tests at MediaWiki, this is not ready for enwiki. But why have we even bothered giving feedback as it obviously isn't taken into account... When you go to someone's history, you see

13:55, 4 February 2014 (topic) . . (+1,340)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:10, 4 February 2014 (topic) . . (+468)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:06, 4 February 2014 (topic) . . (+359)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:03, 4 February 2014 (topic) . . (+295)‎ . . Jayen466 (talk | contribs | block) added a comment. 05:02, 4 February 2014 (topic | post) . . (+13)‎ . . Jayen466 (talk | contribs | block) edited a comment. 05:01, 4 February 2014 (topic) . . (+361)‎ . . Jayen466 (talk | contribs | block) added a comment. 04:59, 4 February 2014 (topic) . . (+276)‎ . . Jayen466 (talk | contribs | block) added a comment. 04:57, 4 February 2014 (topic) . . (+858)‎ . . Jayen466 (talk | contribs | block) added a comment.

No obvious display of where it happened, no edit summaries, no undo(!!!) or rollback(!!!). (Note: Jayen486's edits don't need undo or rollback, it's an example). Fram (talk) 14:38, 4 February 2014 (UTC)

• I agree with Fram. Tito☸Dutta 14:40, 4 February 2014 (UTC)

Another funny problem; you can't see from your watchlist whether you have checked an edit yet or not; the "Pages that have been changed since you last visited them are shown with a green bullet." doesn't work, once you have been to a Flow page, all later comments will be stuck with a "blue" bullet as well. Apparently, when you've seen one, you've seen them all... So, like I said, history, watchlist, ... are all totally useless with Flow, and no alternatives are ready. Fram (talk) 14:49, 4 February 2014 (UTC)

All the issues you mention affect only people who use these two WikiProject talk pages. It was the decision of those two communities to give Flow a try, even though it's not done, and it's up to them if and when they want to go back to a standard talk page. I agree that Flow is not ready for a broad deployment, but I don't see any reason here to diable FLow from enwiki as long as the people actually affected by it are happy to test it.

The issues mentioned below, CU and RevDel not working, are a bit more worrying. However, what's the damage if we have no CU on two low-traffic pages for a while? How often is it usually used there? And is it really not working at all? I would guess all the needed data are somewhere in the database, it's just that the usual interface to retrieve them doesn't work here yet. But that doesn't mean CU is impossible, it might be one just has to wait until the interface works, and then retrieve the data, or it might be possible for the devs to retrieve the data manually if necessary.

For RevDel I guess we have to rely on the devs for the time being. I'm sure they have a close eye on these pages and they have the ability to RevDel by backend-magic if needed, so they can take on that role of administrators/oversighters until the feature is implemented. Maybe one of them can confirm this here to smooth the waters? — HHHIPPO 20:06, 4 February 2014 (UTC)

• I don't mind this tool's implementation in the mentioned two pages. But in current condition I'll not like to see an announcement like "The initial Flow test was successful. But we realised not all editors (specially the new editors) don't follow these announcement discussions and have not got opportunity yo test this feature it. So we are extending flow to more/all talk pages." Flow is a powerful tool, it needs improvement Tito☸Dutta 21:08, 4 February 2014 (UTC)

No, the issus affect all admins, bureaucrats and so on. You have implemented new software, albeit on a very limited basis, that is totally unsuitable for any admin actions. Apart from the things listed by Risker below, and the things listed by me above (like the lack of undo, rollback, ...), there is also e.g. no option to protect or semi-protect Flow pages. And of course, when you have them on your watchlist, they literally flood your watchlist with totally unusable entries, instead of following the standard watchlist options. Absolutely useless, as said (but ignored) at MediaWiki. What's the point of having a test environment if you don't bother to fix the most basic errors before going live? Fram (talk) 07:53, 5 February 2014 (UTC)

So....protection works on MediaWiki.org, but apparently it hasn't be deployed to enwiki yet. Legoktm (talk) 08:05, 5 February 2014 (UTC)

Nono, we must be mistaken the MediaWiki admins in their wisdom have declared that protection and so on is available and works on Flow pages at enwiki; [1] (corrected link, there seslf-generated permalinks don't work in wikitext, as I had posted there a while ago...). I have seen many problematic replies from MediaWiki, but this one must be the icing on the cake, telling us without checking and without being able to check that we are wrong, and that protection is available to enwiki admins for flow pages. I thought ivory towers were a pre-1968 concept, but apparently this hasn't reached every institution yet. Still, they have now eliminated the one major problem (me) with a speed one normally never sees at MediaWiki when actual problems are reported. The wonders of IRC probably. Like Joe Jackson said, "If my eyes don't deceive me, there's something going wrong around here". Fram (talk) 09:47, 5 February 2014 (UTC)

Additional issues

• There are problems with both Checkuser and suppression which have been reported directly to the team and through Bugzilla. (As an aside, the enwiki functionaries were of the impression after running into serious issues with AFT5 that the WMF wouldn't release new extensions that permitted editing, even as tests, until it was certain that both CU and OS were properly integrated and functional. We were apparently incorrect in our understanding.)
• Somehow the software is incorrectly determining which comment a user is responding to, and is sending notifications to the wrong person. I have received emails telling me that a user has responded to me, only to find that they were responding to someone else's comment entirely. I am assuming that the editor to whom the response was directed did not receive an email notice, either. This is repeated in the Echo notifications here onwiki.
• I was unable to post a reply comment today when coming from the emailed link. I could type it, but it would not save. (I'm working on a different computer, WinXP on IE7.)

These are fairly significant issues, I think. Risker (talk) 14:18, 4 February 2014 (UTC)

I got a notification that I was "mentioned". I think you got a notification that someone had replied to you because you had posted the parent post. Assuming I am right, this means that if you have the temerity to start a discussion (equivalent to starting a talk page section) that will draw many commenters, your notifications will be inundated for days. You'll get a message that "someone replied to you" every time someone posts to the topic or subtopic you started. Andreas JN466 16:27, 4 February 2014 (UTC)

Perhaps partially correct, although I've not started any topics, so not entirely bang on. In my early posts, I assumed that the space at the bottom of my screen was where I typed replies, and that resulted in outdented messages, but they weren't new topics. As far as I can tell, though, some of the emails I'm getting trace back to comments that don't start with me at all. Risker (talk) 16:30, 4 February 2014 (UTC)

The team should also be aware ofthis. I do hope you'll let the user know when the test is over so they will feel comfortable in returning. Risker (talk) 17:01, 4 February 2014 (UTC)

Unreadable title under Modern

Tracked in Phabricator
Task T62857

Oww, my eyes. Can you make out the title at all in this thumbnail?

I use the Modern skin, and on all flow-enabled pages the title is black-coloured which makes it unreadable on the blue title background. To be clear, I'm generally fond of flow, modulo this and some of the other, more show-stopper bugs mentioned by Risker (talk · contribs) in the above section. LFaraone 16:02, 4 February 2014 (UTC)

@LFaraone: thanks, I've filed bugzilla:60857 to track this and have submitted a patch to fix it. Legoktm (talk) 03:00, 5 February 2014 (UTC)

Diffs and deletions

In future implementation, will it be possible to see the diffs in the comments instead of trying to work them out from the full comments? As you know, seeing diffs is one of the most fundamental things on Wikipedia in vandal fighting, error correction etc.

Secondly, how do you delete comments? I've tried deleting the title and the comments and some bugs come up where it will not let you implement the changes once you've blanked them. Simply south...... disorganising disorganisation for just 7 years 17:29, 4 February 2014 (UTC)

Re: Diffs: The latest diff to a post or title is currently accessible from the pencil icon at the end of the post content, eg this post. The Board-history and Topic-history are in the process of being overhauled, to more closely match what we are all used to (ie. standard elements and ordering); see the product-management card, and detailed criteria for details. I'm not sure what the ETA is for that, or whether they'll be working on it piece-by-piece or all-at-once. (I believe piece-by-piece, to get the most needed functionality in place, a.s.a.p.). Quiddity (WMF) (talk) 21:37, 4 February 2014 (UTC)

Re: Deletion: For non-admins, the equivalent of "reverting" an edit is to use the "Hide" function. This current configuration is explained in the "Post moderation" section of Wikipedia:Flow/FAQ#Components of the discussion system. The idea is to make things less confusing for someone reading a discussion - Ie. in the current talkpage system, if posts are entirely deleted without trace, it's very hard to understand what happened without going through the page-history.

(Side-note - I've seen forums decimated of useful content, by a contributor "retiring" and deleting all of their submitted posts before doing so. :/ )

An idea that has been suggested, is to allow editors to delete their own posts within x seconds of submitting them, but this has complications to do with Notifications (see notes).

So that's the current situation. HTH. Quiddity (WMF) (talk) 21:37, 4 February 2014 (UTC)

Nesting

See [2]. The discussion rapidly becomes confusing and unreadable after just one reply. Why isn't the more then one level of nesting? I am especially concerned about large noticeboards here.

Also, how will parent and child sections work? ie. ==parent thread== and ===child thread===. KonveyorBelt 20:08, 4 February 2014 (UTC)

I am an opponent of FLOW, but nesting levels have been discussed (basically with the promise that they will be enabled in the bright future).--Ymblanter (talk) 20:16, 4 February 2014 (UTC)

How many nesting levels should be allowed on which board is a complicated design issue, and I don't want to comment on that now. However, there is an additional technical issue here: on boards with limited nesting, like the ones we have now, I think there should be no reply links below each comment on the last level. Any reply to a last-level comment will not be displayed as such, but just as an additional comment on that same last level, that is, an additional reply to a second-last level comment. For consistency, this should be make clear already when posting such a comment. For example, one could remove the Reply links below the individual comments on the last level, and instead have a single Add reply link some distance below the last comment, just where the next one would appear, and still to the right of the dotted line. I hope this makes sense to somebody... — HHHIPPO 20:50, 4 February 2014 (UTC)

Feedback on timestamp bug

Hi @Pocket calculator operator, EBernhardson (WMF), and Dougweller: Re: the comments about File:Date tangling.png at WikiProject_Breakfast - I believe those issues are fixed in the latest code - could you check whether the timestamp displays correctly (both with and without mouseover, in the browser(s) that you are seeing problems in) at http://ee-flow.wmflabs.org/wiki/Sandbox ? Let us know if that has fixed it. Thanks.

Generally, if we could discuss bugs here, and do any needed testing at Wikipedia talk:Flow/Developer test page, instead of in the WikiProject pages, that'd be much appreciated! :) Quiddity (WMF) (talk) 21:07, 4 February 2014 (UTC)

The problem is still present for me; in fact, it looks exactly like the screenshot I emailed to Maryana earlier today (which includes my browser detail). Risker (talk) 21:13, 4 February 2014 (UTC)

((ec)):I don't see any timestamps at all on that page, only n days or n months ago. Risker, what am I missing that you can see timestamps and I can't? Or are we talking about a different page? Dougweller (talk) 21:20, 4 February 2014 (UTC)

Hi @Dougweller:. The File:Date tangling.png illustrates the problem - look at the lower right corner of the posts in the screenshot. When I go to http://ee-flow.wmflabs.org/wiki/Sandbox which is supposed to be the "fix", I see the same problem. Risker (talk) 21:43, 4 February 2014 (UTC)

It does look very much the same, Quiddity. The reply button worked without incident this time. That detail may have been lost when I was figuring out how to post using Flow, and edited my comment several times. In any event, that is the extent of the input I can give. Good luck. :) Pocket calculator operator (talk) 21:31, 4 February 2014 (UTC)

@Dougweller: The timestamps should switch between "elapsed" (x ago) and "exact" (x o'clock) on mouseover.

Thanks all, for the added feedback. I'll file a bug for this now (bugzilla:60849). (I thought it might be fixed, because another user seeing the same bug, with a different browser, had reported that the code at ee-flow fixed it). Quiddity (WMF) (talk) 21:51, 4 February 2014 (UTC)

Thought I'd replied last night, sandbox looks fine to me now I know to hover! Dougweller (talk) 06:31, 5 February 2014 (UTC)

Note on username display

@R'n'B: Hi, Re: your comment here ("Having my user name appear at the end of each section is confusing, when I haven't yet commented on the page. Also, the "Article collaboration" topic appears to be embedded in the middle of the "Welcome to Flow" topic, and the latter topic resumes after the end of the former one.") - the username at the end of each topic has been removed in the latest code (visible at mw:talk:sandbox) and should be live on Enwiki on Thursday. Regarding the "embedded topic" issue, I think you might be referring to this post, which has a screenshot as the main content! If you're seeing something else, further up, let us know. Hope that helps. Quiddity (WMF) (talk) 23:43, 4 February 2014 (UTC)

Doh! I didn't realize it was a screenshot. --R'n'B (call me Russ) 00:46, 5 February 2014 (UTC)

Through The Looking Glass

"There's an old story about the person who wished his computer were as easy to use as his telephone. That wish has come true, since I no longer know how to use my telephone." --Bjarne Stroustrup

Background: (You can skip this section if you want.)

A while back I looked at something (exactly what is not important) that Wikipedia:Flow said would definitely be a feature of Flow. Alas, it was not theoretically possible. Not just hard. Impossible. Perpetual motion impossible. Turning lead into gold impossible. Despite the fact that nobody at the WMF (or anywhere else for that manner) could describe the steps that they hoped would get us to the impossible result (because no such sequence of steps exists or can exist) when asked about this someone from the WMF claimed that they do know how to do this impossible thing. (Who said what is not important. I am trying to fix the problem, not fix the blame). Later the claim was quietly deleted from the page. Not the ideal situation, but such things happen when it takes specialized technical knowledge to realize that something isn't just hard but is actually theoretically impossible.

The problem is not that error, but the reaction when I identified it. Rather than simply changing the page, I was first told that the impossible is possible, then told that Flow is completely undefined in all aspects and that no design decisions have been made, followed by further unpleasantness that isn't relevant here. Of course we all know that Flow is not undefined, and design decisions have been made. For example, it has been decided that Flow will sign your comments instead of asking you to add four tildes ("~~~~") at the end. That is not going to change, nor does anyone want it to.

There is a page at http://blogs.atlassian.com/2013/07/agile-requirements-documentation-a-guide/ and another at http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm that describe Agile Requirements Documentation.

The Agreement

Because of the above, we worked out a solution that everyone agreed to. We agreed that the WMF would pick a page on the English Wikipedia (Wikipedia:Flow would be a good choice) that documents, in broad strokes, WMF's current understanding about what Flow is.

This document was to contain selected "we haven't decided yet" items and selected "we don't know yet" items, but it was also to document everything that we know we are going to do (autosigning posts, for example). This document was to be kept short with broad strokes, not TL:DR detailed documentation. It would also document those things that we have agreed not to do, along with selected items that are desirable but might not or probably won't get done.

We agreed that, when we decide something here on this talk page and everyone agrees that it will be (not might be) done, someone at the WMF would update the page to reflect that decision. That edit would then be considered to be a promise and a commitment.

Of course even the best-laid plans sometimes need to be modified, so if the plans change, someone at the WMF would update the page and post a message on the talk page. Something like "Remember that autosigning thing we all agreed on? I had to move it into the 'we don't know yet' section because of...".

We also agreed that, every so often, key members of the Flow team would look the page over and make sure we don't have something in there that they will object to later.

That is what we agreed to do, and I set a reminder on my computer to fire in three months so I can whether it was done.

It has been three months. Nobody has notified me that it is done. Wikipedia:Flow mentions few things in the lead and in the "expectations" table, but it falls short of what I expected and what I thought we agreed to do.

I was especially disappointed when I checked https://wikimedia.mingle.thoughtworks.com/projects/flow/cards/288 and saw that it had been marked "done" without the slightest indication that anyone has actually done anything to implement my suggestion. --Guy Macon (talk) 04:07, 5 February 2014 (UTC)

Have you checked the various pages on MediaWiki.org, linked to from the sidebar of mw:Flow? — This, that and the other (talk) 05:33, 5 February 2014 (UTC)