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.
I experimented with transcluding another page to the Flow test page, [1].
One thing I didn't expect was that such a move would trigger Echo notifications for people listed on that page. But I'm glad it did, since it looks like the notification they got doesn't work... Here an editor describes how this notification gave a Could not find the requested workflow error. Fram (talk) 12:57, 5 February 2014 (UTC)
The editor has added more problems with this, [2], with Echo refusing to un-echo the edit I made. No idea whether the problem is Echo, Flow, or interaction, but it certainly is a problem! Fram (talk) 13:00, 5 February 2014 (UTC)
Clarification: The page Special:Notifications is completely broken. This is what the page looks like for me. I can't read any notifications on that page (but I have switched on e-mail notifications and still get the e-mails correctly) and I can't change the number 5 into 0. --Stefan2 (talk) 14:22, 5 February 2014 (UTC)
I'm missing what is special abut the transclusion in Flow. Wouldn't this have happened is Fram had transcluded the page anywhere? I occasional get some odd Echo notes, but usually realize it was due to a transclusions. What makes this one different? (I gather than some are unable to clear the notification, but not sure why)--S Philbrick(Talk)18:14, 5 February 2014 (UTC)
The only difference is that Flow revisions are larger than most wikitext revisions. So, for a full explanation of the bug; when you mention someone, Echo stores the text revision they were mentioned in (for use in, for example, the little quotes from the revision that you get in notifications). The problem is that Flow revisions are pretty large, and this one with all the transcluded content was larger than the database field we store them in, which led to it getting truncated and excluding essential information - hence the bug. As you say, this would've happened with or without Flow eventually; the breakpoint is "a revision > [certain size]", and it's definitely possible to get that just with a normal wikitext page. We've got a deployment later today to fix the issue. Okeyes (WMF) (talk) 18:49, 5 February 2014 (UTC)
I don't think Okeyes explanation is correct (or complete). The difference, as far as I see it, is that normal talk pages allow transclusion of a page: Flow automatically substitutes the page though (and all subpages), so that people get notifications and so on. Not something that would have happened on other pages. Yes, you can do that with a normal Wikitext page, if you deliberately substitute the page: but you get it in Flow even without susbstitution... Fram (talk) 20:21, 5 February 2014 (UTC)
So, I did some tests (would be nice if WMF people did the same before replying sometimes). Transcluding a page onto another page does not (I repeat: not) trigger notifications. Unless you do it in Flow, of course, since that can't handle transclusion and changes it into some strange form of substitution, which means that
Everyone on that page, and on every page transcluded on that page, and so on, gets notifications
The page size gets a lot bigger
The code gets a lot uglier
Changes to the transcluded page do not transfer to the Flow page (defeating the main purpose of transclusion)
I will not test whether substituting the page I tried to transclude somewhere else will cause the same errors as we had on Flow (though that test will need to be done as well some day), but what was claimed, that transclusion of this anywhere would have caused the same problems, is completely false. Transclusion only causes these problems in Flow, so my original complaint remains. EngFram (talk) 20:55, 5 February 2014 (UTC) (EngFram is my testaccount for non-admin actions, getting confused here with constant logging in and out from one to the other to test notifications to myself :-) I normally restrict myself to the Fram account!)
Ah, if changes are being made after the transclusion is done? Yes, that may be true, I haven't tested that. Not what happened here (and it shouldn't trigger the bug that had to do with diff size according to WMF, FWIW), but still nice to know. Fram (talk) 21:08, 5 February 2014 (UTC)
Again, it's nothing to do with substitution or transclusion, although that is the trigger. So, I guess we're talking about two bugs here: one is notifications through transclusions and substitutions. That is partly a Flow problem, insofar as Flow substitutes by default, although as Legoktm says it can happen outside of Flow as well. The second is mentions breaking Echo. That's not Flow-specific, it's revision size specific. Okeyes (WMF) (talk) 21:56, 5 February 2014 (UTC)
Will we get a developer to fix that? I now have three notifications that I cannot read, and it's a becoming more problematic as the time goes by. I came to rely on ECHO a lot, so it would be nice if we could get confirmation that someone will look into this, I've seen some bugs here go untackled for days if not months. Ok, I see it's being looked into, thanks. --Piotr Konieczny aka Prokonsul Piotrus| reply here21:56, 5 February 2014 (UTC)
Further testing. This test has broken the notification system for a number of editors, and mine remains partially broken. The red box with numbers at the top of the page allows me to see see the last 5 notifications, but Special:Notifications still returns an error. This impedes my work :( Please may I ask Fram and anyone else considering a test like this to discuss it first? The choice of transcluded page is important, and care will be be needed to ensure that an errors don't have adverse effects on uninvolved editors. --BrownHairedGirl(talk) • (contribs) 22:19, 5 February 2014 (UTC)
We deployed fixes for this, those who encountered notification problems can you see whether Special:Notifications works for you? The problematic notification from the large Flow post is still there, we just don't show it. So your Echo notification counter may stick at 1. We're working on that too. If you want your Flow notifications to drop to zero (if you're not involved with Flow on the two project pages, why not?) then disable Flow notifications in Special:Preferences > Notifications. -- S Page (WMF) (talk) 00:54, 6 February 2014 (UTC)
Additional fix options:
To fix it, you can either: 1) Temporarily uncheck the Flow notifications (web) in Special:Preferences#mw-prefsection-echo; or 2) Ignore the [1] for 9 days (a week from Thursday) when we'll get the next version of mediawiki code deployed to Enwiki;
press 'save', and a dialog will pop-up asking if you want to mark all Notifications as read. Accept that, and it will be fixed. You can then remove the line of code from your common.js again.
Since we are talking about changing the way that talk pages work I have a suggestion. Currently when someone is blocked, its impossible for them to edit at all, even in discussions where their comments are needed or appropriate (such as ANI about them). Currently though they can only comment on their talk pages. If we are making changes to the talk page commenting ability anyway, the ability for an admin to grant a blocked user the ability to edit a page or a group of pages would be a beneficial improvement. Currently its all or none. 108.45.104.158 (talk) 13:09, 7 February 2014 (UTC)
Whitespace
There's too much.
Yes, I've read Wikipedia:Flow/Design FAQ#Why is there so much whitespace/padding?. I don't agree with it at all. Not only is it poorly-phrased ("decreases user unsatisfaction"), it's patronizing, defensive, makes all sorts of dubious assertions (whitespace could prevent harassment? Give me a break) and cites sources that either do not directly support any of the specific implementation of whitespace in this design, or, worse yet, actively contradict it - like the reader expends energy in the wrong place and tires more easily [when] lines... are too widely spaced. Well, I can tell you that the lines are too widely spaced. I've been online for almost 20 years, and in that time I've read vast quantities of text with formatting that would make any competent designer turn to drink - everything from single-spaced error-strewn OCR'ed text in UNIX terminal windows to multi-colored full-browser-width colored Comic Sans-on-wallpaper-GIF GeoCities extravaganzas. You know what? They were ugly as sin, but they were tolerable. This? This makes my eyes hurt. I can actually feel them straining as they jump around between tiny islands of text in a sea of white. The figure is completely lost in the ground.
That FAQ even links to this post on UX Myths. Look at the ratio of whitespace to text size on that page. Then look at mw:Talk:Sandbox. Flip between them a few times. Can you see the difference? Compare the current appearance of Flow to pages on Svbtle or Medium.
If you're unwilling to reduce the font size in this new interface, your options are basically two: either increase it to fix the figure-ground balance - thus making it completely out of scale with the rest of MediaWiki - or reduce the whitespace. You can't leave it like it is. — Scott•talk18:14, 5 February 2014 (UTC)
Hadn't run into that before. How patronizing. I find it very hard to read. Maybe if I were a very slow reader I might appreciate it, but I'm not. And it's going to make pages very very long or have a much smaller amount of content on them. I want to be able to scan down a page quickly. Dougweller (talk) 18:54, 5 February 2014 (UTC)
I'd note here that we are discussing having a more expanded view as a preference, which personally I strongly support (it's too narrow for me, too). I'm going to poke the designers to address the problems with the whitespace argument in the DFAQ. Okeyes (WMF) (talk) 18:56, 5 February 2014 (UTC)
I think it might be too extreme in the opposite direction… A bit of padding in a few places would help readability. And yet I like it more than what the Flow developers came up with. And I completely agree with User:Scott Martin. Keφr22:25, 5 February 2014 (UTC)
Probably; I was fairly indiscriminate in the whitespace I cut. Any suggestions for places that could use some more spacing? Writ Keeper⚇♔22:48, 5 February 2014 (UTC)
I'd suggest using some longer posts (multiple full paragraphs) as well as 1-liners, to more clearly demonstrate (in the screenshots) how it would look during realworld usage. Quiddity (WMF) (talk) 00:37, 6 February 2014 (UTC)
Working – the newest code we pushed on Thursday has tighter spacing between posts. We'll be doing a larger frontend UI refactor over the next few weeks. When finished, it should, among other things, widen the board/reduce the right margin and create a more responsive interface that scales for larger/smaller screens. It's all experimental and changing rapidly based on your feedback, folks – if we were "unwilling" to change anything, we wouldn't have put it out there so early for you to test :) Maryana (WMF) (talk) 22:13, 7 February 2014 (UTC)
Preference request
I noticed that new topics go to the top of the page by default. This is a personal preference, but I absolutely despise that order of order of arrangement. It would be most appreciated a user option to have new topics fall to the bottom of the page were available when this ultimately rolls out. Thanks! Resolute21:19, 5 February 2014 (UTC)
Perhaps it's the infinite scrolling that needs to be rethought. I've yet to see a good argument in favour of it, to be honest; it just seems to be a "choice" that nobody actually asked for. Risker (talk) 23:05, 5 February 2014 (UTC)
Agreed. I find infinite scrolling to be equally annoying. If forced, I would adapt, but I find the combination of the top-down approach with scrolling makes it remarkably difficult to move through histories. Resolute01:17, 6 February 2014 (UTC)
This seems to be a case where developers are forcing a particular modus operandi that is contrary to typical Wikipedia norms (i.e. new topics go at the bottom). Be prepared for more forced changes. Killiondude (talk) 22:51, 5 February 2014 (UTC)
Developers, and designers, and product managers, yes, in line with how pretty much every other piece of discussion software on the internet works. Can you tell me how asking people to opt-in and not deploying it if they said no is a forced change? Okeyes (WMF) (talk) 23:05, 5 February 2014 (UTC)
Can you point me at an example of a threaded discussion system that runs upside down? I've certainly seen them with the topics being displayed with newest on top, but anything I've used maintains an oldest-on-top model for each individual thread.—Kww(talk) 04:43, 6 February 2014 (UTC)
In terms of typical discussions, yes. But we do have areas that operate in this top-down format already. Namely, AfD, DYK, etc. It's not unheard of on Wikipedia. Resolute01:17, 6 February 2014 (UTC)
Like the FAQ says, that and other aspects, are experimental, and feedback is appreciated. The options (for all those many aspects) are A) What us regulars are used to (with known pros and cons), B) What's been suggested so far (with new pros and cons), and C) New ideas. I'd personally love to learn about more in category C - we're not stuck between "keep it as it always was", and "this new design is the only alternative" - we're only limited by what is possible. Quiddity (WMF) (talk) 23:37, 5 February 2014 (UTC)
I think one of the problems here is that Wikipedia discussion pages aren't intended to work "in line with how pretty much every other piece of discussion software on the internet works". Our discussion pages are different because they're actually intended to be discussions; most of those other sites aren't. Most of them are "comment and move on" sites, as opposed to pages where people are working. Making a Wikipedia discussion page look like those sites will encourage that kind of behaviour, instead of teaching the very different processes that are required here.
I think it would have been extremely simple to come up with the top-5 ways to improve Wikipedia discussion pages (making indents easier would be at the top of almost everyone's list), but the core design principles being illustrated with this are not well-suited to the fundamental purpose of discussion pages. One of Wikipedia's strengths is the willingness to be different, to be focused on function rather than form. I think perhaps some of the core values and principles of the project are being overlooked here. Risker (talk) 05:06, 6 February 2014 (UTC)
Thank you Risker. I agree entirely. I wish that developers would do surveys before starting work. Unless there are major changes I can't see this as anything but detrimental. I certainly would not want to try and have a serious discussion on a page that looks like and works like Wikipedia talk:WikiProject Breakfast. On the other hand, I'd love it if someone would make indenting easier. Dougweller (talk) 12:22, 6 February 2014 (UTC)
Yes, and Risker's point, about how discussions here are not intended to work like "comment and move on", and about how the wrong kind of interface will send the wrong message to new users finding their way around here, is very, very important. It bears repeating and reinforcement. --Tryptofish (talk) 14:19, 6 February 2014 (UTC)
Breakfast page
The density of information is significantly lower than the existing style. It's like turning The NY Times or Wall Street Journal into USA Today (colors! bad graphics! lots whitespace!). In other words, to review the content I have to do way more scrolling to get the same amount of information.
I think the permalink option is intended to be the diff capability, but that is obviously grossly limited given it can only link one post rather than a range of them. Oddly, I can still permalink to a post that I deleted: [3]. Can anyone else see it? Resolute15:38, 5 February 2014 (UTC)
I'm not an admin. I can't see that a post has been deleted. Either it's shown there as "not deleted", or it's comletely missing without any log message or other information. --Stefan2 (talk) 15:48, 5 February 2014 (UTC)
Oh, cool. So as a bonus, admins can potentially see a flood of deleted junk. There are definitely some (minor) stylistic issues to be worked out still - though I think this and NE Ent's concerns can be addressed fairly simply if the Flow team is willing. Thanks for checking! Resolute16:24, 5 February 2014 (UTC)
I don't whether the permalink isn't working for me or it's just I don't understand the interface. I'm not finding a way to see anything that looks like a diff. NE Ent16:39, 5 February 2014 (UTC)
Permalinks don't show diff changes - the popup for the pencil icon of an edited post has an option "show changes" that opens the diff page. Diego (talk) 22:49, 7 February 2014 (UTC)
Needs a UX person to redesign it
I've had a look through Flow and it's nice to see an attempt at improving talk pages. This product is obviously a very long way off, but it's got some good features that will be interesting to see deployed. However, I think you need someone to properly spec the project in advance because it seems... a little mish-mash. Some examples of problems...
Infinite Scrolling
That's going to get incredibly confusing on very long pages.
Infinite scrolling in discussion/topic is a very infrequently used format, for very valid reasons! I recommend bringing a UX expert onboard to spec a really good discussion/topic-list UI
I recommend implementing a usable and robust archiving system (so, say, editors can configure archive strategies per page). I'd consider an archive system a blocker to any release.
Top Posting
This is going to confuse and put off regulars. Although it's a common pattern it's not the *only* way to do things. Is there a firm use case for changing the status quo? Whoever the produce manager is (??) they should be able to justify design choices like this in detail - so I'd be interested to hear that justification.
Layout
On mobile the buttons are massive, mostly all I see is ErrantX everywhere and then the big blue buttons. Then some other smaller text links. Actually reading anything is cumbersome
On browser view the layout doesn't scale. The vast majority of the screen estate that you do use is also taken up with interface - which for a system intended to facilitate discussion is somewhate counter-intuitive
In summary, I think the whole UI needs speccing properly, by a UX person, with plenty of user testing (UAT). I'm guessing that the current interface was put together by the developers, which for such a massive change is not the best solution and unfair to place on their plate :) --Errant(chat!)11:56, 6 February 2014 (UTC)
I see that the whitespace and fixed-width are intentional choices. This is a bad decision; what you say about whitespace is somewhat true. However this problem is actually introduced by the amount of user chrome added with Flow. You should focus on reducing that chrome as much as possible (because it is a distraction). Fixed-width is not a good choice as it forces a particular choice on the user. Instead the recommended approach is to have a simple and obvious way to increase font-size, which achieves a similar affect but with more versatility. Also, your default font-size is not the Wikipedia standard font-size. It's basic UX 101 not to do that :S --Errant(chat!)12:09, 6 February 2014 (UTC)
So, just to reply; this was put together by UX people. FWIW, I share your concerns about fixed-width (we're going to be working on that - it's far too narrow, and it shouldn't be fixed anyway, imo), and several other points; I'm poking Maryana to reply to those I don't have an opinion on ;). Okeyes (WMF) (talk) 17:07, 6 February 2014 (UTC)
I put this up on the screen this afternoon and our creative team had a play around with some improvements/suggestions - so if you want some detailed feedback and perhaps a rough mockup I could jot something down. --Errant(chat!)21:33, 6 February 2014 (UTC)
Comment from that elusive Product Manager :)
ErrantX, it sounds like you're One of Us,tm in the sense that you work in software design and development. As such, you probably know that design is not an exact science – there are some quantitative measurements and data you can get to inform design decisions, of course, and they're extremely important. But at the end of the day, there's a large portion of qualitative data/subjectivity/art. Who can objectively, neutrally say why one icon is better than another icon? Or why one website's navigation feels intuitive and another's feels weird/clunky? That element of subjectivity is why you can take two extremely talented designers, ask them to work on the same problem, and come out with two completely different results. Or why designers are so fond of redesigning each others' redesigns all the time ;)
So, to your point that the decisions around whitespace, top-posting, and infinite scrolling that our designers made are things you don't agree with or personally don't like... fair enough. We're putting it all out there early for people to play around with as a whole (and, yes, doing lots and lots of user testing; remote and in-person, there have been 3 rounds so far, comprising around 20-30 users). If there are aspects that are confusing or make discussion more difficult for end-users, obviously they'll need to change. But the key here is end-users, and it bears remembering that the intended users of Flow are not just the few hundred extremely active English Wikipedia users currently editing today – who, we all know, overwhelmingly tend to skew to the young, white, male, US and EU demographic that also tends to be the average reader/user of Reddit, StackOverflow, and, yes, Hacker News ;) There are millions of other great, smart people in the world who find all those aforementioned discussion systems – not to mention Wikipedia talk pages – scary, confusing, and alienating. If we build something that works perfectly for you and me and other Wikipedians, but that 99% of other humans simply can't use, we've failed.
That's the stretch we all have to make with this project, and why it's not quite so simple as "well, just get an expert UX person to design it" or "just let me tell you what I (and by proxy) all Wikipedia users need!" No matter who we are (designers, experienced Wikipedians, newbies), we have to think about the people outside our homogeneous circle who are also going to be using this software. I'm not saying what we've got now is perfect – I'm saying all of us have a lot of testing and talking to do to get there. Luckily, I think the tension between different people's ideas of a good discussion system is actually quite a productive one that will ultimately help us find the right ways to solve these extremely complex UI/UX problems. I'd much rather have a thousand strong opinions and redesigns than design by fiat/user complacency and silence (but that's probably why I work for Wikimedia and not, say Google) :) Maryana (WMF) (talk) 01:05, 8 February 2014 (UTC)
We certainly do care :) In the next couple of weeks, we're going to start reaching out to bot operators and writers of vandal-fighting scripts to help us test and build out our API so that it integrates with community-developed tools. This is something we're hoping to do a dedicated sprint on during the Wikimedia hackathon next month. Maryana (WMF) (talk) 01:11, 8 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.
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).)
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. — HHHIPPO07: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.
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.
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?). — HHHIPPO07:37, 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. — HHHIPPO22:42, 4 February 2014 (UTC)
[off-topic] 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"). Helder11:17, 5 February 2014 (UTC)
Helder.wiki: I'm not sure what use case you're thinking of here. I wanted to say something about the enhanced watchlist, but I wasn't (and am still not) sure if that feature really is called 'enhanced watchlist'. The qqx trick reveals that the switch to turn it on is called 'tog-usenewrc', but I doubt anybody would understand a sentence like "You can avoid overFlowing of your watchlist by using tog-usenewrc". So I guess the best option still is to quote the whole label of the checkbox. Your method for doing that is interesting, but copy & paste seems simpler. Anyway, we're getting really off topic here. But thanks for your input. — HHHIPPO19:19, 5 February 2014 (UTC)
The point is that the description you copy is the current text from MediaWiki:tog-usenewrc, while using {{int:...}} it will always be up to date and will be shown in the user language (so it is easier to identify if someone is not using English, or even if he is using en-GB). Helder13:44, 6 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)
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)
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)
This is a real regression from the easy linking that exists through most of MediaWiki, as well as LiquidThreads. Can we at least replace the superlong hexadecimal strings (like 050fe6b801fd6f3747a890b11c28d448) with normal demical ones (like 8310294)? -- Ypnypn (talk) 14:34, 6 February 2014 (UTC)
Not really; Flow threads exist independent of boards, which means that the easy linking in mediawiki isn't really possible. We could just use decimal strings, but at that point we'd hit the limit on the number of available topics....pretty quickly. Okeyes (WMF) (talk) 17:05, 6 February 2014 (UTC)
Notes: the current superlong hex strings are soon being shortened to use base36 alphadecimal strings (ie. 0rnfikwkyoc1shvx6 instead of 050fe6b801fd6f3747a890b11c28d448). There's some discussion and documentation about this at bugzilla:57154 and at mw:Flow/Functional Specifications/Boards and Topics#Permalink. TLDR: the ability to have links not break when a topic-title is changed (as they do in current talkpages) or when a topic is archived (except the few pages where on Enwiki anomiebot and cluebotIII fix them) means that using a UUID is necessary. See the last 3 points in bugzilla:57154#c5 for some technical explanations and possibilities (with their pros and cons) for the future. Quiddity (WMF) (talk) 21:19, 6 February 2014 (UTC)
Will there be any option for custom signatures in flow? For example, my tree-colour signature? (I don't read MediaWiki discussions) Tito☸Dutta09: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☸Dutta11: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.
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)
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):
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)
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)
Custom signatures help the reader distinguish contributions by different participants in a large discussion. As they will no longer be possible in Flow, strong consideration should be given to allowing user avatars instead. — Scott•talk17:43, 5 February 2014 (UTC)
Scott Martin: Avatars and the usage of them is being investigated but not for Flow; they are part of a different project (currently named Global Profile). Introducing avatars has a lot of nuance problems even without people saying "I don't like it"; there are issues about cross-project use, fair use, moderation, etc. All of this is outside of the scope of Flow. However, when/if avatars are introduced, then I'm certain Flow will make use of them.--Jorm (WMF) (talk) 19:31, 5 February 2014 (UTC)
Oh, please no! No avatars! Back in the archives of this talk, I expressed concern that we not turn Wikipedia into something like Facebook, etc. With avatars, we would be well on our way to turning into 4chan, Something Awful, or perhaps Wikipediocracy (smile). This is still supposed to be an encyclopedia, folks. If we have to resort to avatars, we'd be better off never implementing Flow. --Tryptofish (talk) 19:25, 5 February 2014 (UTC)
Tryptofish: The presence or absence of avatars does not make a site into Facebook or 4Chan. Those are social constructs. User identification is known to aid in usability. Just because our software modernizes does not change the Mission; far from it.--Jorm (WMF) (talk) 19:31, 5 February 2014 (UTC)
Moronic avatar, thanks to PointillistEncyclopedias are social constructs too. New editors form their opinions of how to interact on Wikipedia based on what they see when they get here, and the last thing we need is for them to figure this is something other than what it is. Bad construction of discussion formats can unquestionably dumb down any website. And now I'm going to insert some sort of moronic image of someone with their head exploding, next to my signature here. --Tryptofish (talk) 19:38, 5 February 2014 (UTC)
Many common forum engines provide the user with an option not to display avatars. I'm sure MediaWiki will do so too as and when it's necessary. — Scott•talk19:44, 5 February 2014 (UTC)
That might not be enough. I can choose not to use an avatar, and I can choose not to see other users' avatars, but if some new editor shows up and sees the wrong kinds of avatars, we are going to have some horrid deterioration of talk pages pretty quickly. --Tryptofish (talk) 19:48, 5 February 2014 (UTC)
Well, if we are going to discuss my prejudices, I'll add that the drawing on your userpage looks like Justin Bieber. But no, it's not just conjecture. I can point to other websites (in fact, I did) where there are avatars like the one that Pointilist gave me here, and the quality of discourse is awful. --Tryptofish (talk) 23:06, 5 February 2014 (UTC)
There are plenty of other websites that allow avatars in which the quality of discourse is just fine. And in years upon years reading this website, I've encountered some of the worst discourse I've ever seen - and we don't even support avatars. Fancy that. — Scott•talk23:43, 5 February 2014 (UTC)
Yes, I agree with you about there sometimes being low quality discourse right here on Wikipedia. You've just proven the point. --Tryptofish (talk) 14:22, 6 February 2014 (UTC)
And right there is the potential problem with avatars, as well as, more broadly, any interface change that misleads users into thinking Wikipedia discussions resemble discussions at many other websites. I'm an experienced user here, so what I said, I said on purpose (my apologies, Scott, but you were just too good as a straight man) – but what I'm really concerned about is new users, who could be misled into thinking Wikipedia is something other than what it really is. --Tryptofish (talk) 01:42, 9 February 2014 (UTC)
Yes, no Avatar please. And what is global profile? Is it going to be an alternative of userpage? Or will it be hosted somewhere at Wikimedia Labs or Meta (like edit count page)?Copied to #Avatars section below by author. About custom signatures, why not allow editors to sign their posts in Flow? Currently ~~~~ is disabled. I sign my name Tito Dutta (full and correct name, when I registered account at Wikipedia I did not know the site allows space in username, so I signed up titodutta, which became Titodutta). If someone wants to sign, let him to so. Tito☸Dutta 19:50, 5 February 2014 (UTC) Tito☸Dutta19:53, 5 February 2014 (UTC)
If you click in the Reply text area, it expands (as it should). To close it again, you need to click Cancel, which can be annoying (it was for me). I think that if (and only if) nothing was entered into the text area, clicking outside it should automatically close it. -- Ypnypn (talk) 00:22, 7 February 2014 (UTC)
Thanks for the suggestion.
Anyone else have input?
As a potentially conflicting use-case, I have occasionally: clicked Reply, but then wanted to copy & paste content from further up the page, so that I could quote it. I might get annoyed if the reply area had collapsed again, when I didn't want it to. Thoughts? Quiddity (WMF) (talk) 21:04, 11 February 2014 (UTC)
Nesting
See [4]. 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.
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... — HHHIPPO20:50, 4 February 2014 (UTC)
@Hhhippo: The current design, with a "reply" link for each comment, is intended to (A) trigger a Mention Notification for the intended target, and (B) by auto-filling the username, it should more clearly indicate who the reply is for (which as many people have commented, is not working perfectly in the current indent system). Hence, replacing all the "reply" links with a single one per tangent, wouldn't really work. However, all feedback is good! Please keep it coming. The few brilliant and workable ideas make up for all the ones that don't. :) Quiddity (WMF) (talk) 21:47, 10 February 2014 (UTC)
@Quiddity (WMF): Good point, but I still don't think the current solution is optimal. More specifically:
(A) I don't think Flow should be designed around the current configuration of Echo, rather the other way around. The use case of being notified of replies to one's comments calls for (1) a way to watchlist individual topics, and (2) a notification that is triggered not only by direct replies but also by replies to those replies, anything down the subtree that's rooted in my comment, no matter whether or not an explicit mention was used.
(B) Auto-filling the user name indicates who's the target of a reply, but not which comment, which can be important so it would be nice if we can come up with something to reduce the need for quoting. The auto-mention is a step in the right direction, but we have higher expectations for Flow :-) Plus, it's not optimal to mix two ways to display the structure of the discussion, indentation and target user names.
I'm not sure I want to suggest going back to pure indentation, I agree that can get too much in long reply chains, so I'm just throwing some ideas in the air:
Increase the maximum nesting level. Hitting the limit should be the exception, not the rule.
To save screen space, decrease the width of the indentation with each additional level.
Scale these widths down if the total window width is small.
Quick note, that there has been a complication with the database update today, so the expected downtime (~15min) is taking longer than that. Apologies for the mis-estimation and any confusion. Quiddity (WMF) (talk) 22:58, 11 February 2014 (UTC)
Update: Ok, deployment complete, with complete (?) success! The UUIDs are now shorter (from 128-bit base16 to 88-bit base36 (alphadecimal)), and all old permalinks links still work.
If you find any new problems (particularly with Board/Topic history) please let us know. (Anything found is expected to be related to bugzilla:61244)
On Thursday February 13, Enwiki will automatically get the following patches (now live on MediaWiki.org):
reply field has wrong name
some fixes for the removal of squarebrackets in urls (fixes revision-compare)
unhide the 'watch' tab/star
content breaks out of its box
a scrolling bug
a word-wrap bug and it's temporary imperfect hyphenation-fix.
Hi Maryana and the rest of the Flow team, I just watched your presentation live on Youtube while I was on the bus back home (how very 21st century of me), and I loved it! (To be honest, the "Yo dawg" quote won me over.) But I like what it looks like and I think the "small steps" rollout is not such a bad idea either. Keep up the great work, --Gnom (talk) 21:17, 6 February 2014 (UTC) (There is a lot of white space, though. And where is the "reply to a reply of a reply" feature that we are currently doing with multiple indentions?)
Thanks for the feedback! The whitespace is being discussed in a handful of other threads on this page, but suffice to say it is being continuously thought about and refined (there's another small reduction-tweak coming soon). Regarding "reply to a reply of a reply" - it is possible to reply infinitely, it's just that the indent currently stops at level 2 - However that too is being discussed, and there'll be new on it soon. HTH. Quiddity (WMF) (talk) 00:41, 12 February 2014 (UTC)
Summary: known problems and discussion points
Let's try to provide a list of all known problems and discussion points. The initial list is made by Fram (talk) 15:33, 6 February 2014 (UTC) , but everyone is invited to add or correct things:
History
History works poorly, with loads of info missing
Yep; we're refactoring the histories so you'll just have one page history with all the information. That's in our workload for this and next week. Okeyes (WMF) (talk) 17:04, 6 February 2014 (UTC)
Watchlist works poorly, with way too many entries but with too little information
I meant oversight, now added below. Sorry for the confusion. Glad to know that renaming works though ;-) Fram (talk) 09:27, 7 February 2014 (UTC)
Oversight
Does it work (on a per-edit basis)?
Pages
Deletion of pages is not enabled
Can you explain a situation in which you'd want to delete the WikiProject Breakfast talkpage? Yes, it's needed functionality for any wide-scale rollout, but if you've read any of our planning documentation on enwiki or elsewhere you'll know that isn't on the table for quite a while. Okeyes (WMF) (talk) 17:02, 6 February 2014 (UTC)
Well, you asked us to test for functionality; ability to delete a page is a core functionality. Any page can be subject to deletion. Risker (talk) 17:36, 6 February 2014 (UTC)
I am listing what is missing, I don't really care what is planned or not, as these things are subject to changes at the whim of the WMF. Fram (talk) 08:17, 7 February 2014 (UTC)
"if you've read any of our planning documentation on enwiki or elsewhere you'll know that isn't on the table for quite a while." Well, Wikipedia:Flow#Roadmap says that further deployment is planned for "Long-term (2014-2015)", but we are well into 2014 already, so that actually doesn't tell me that "this isn't on the table for quite a while". So did you mean a different page? Wikipedia:Flow/Community engagement discusses the "Release plan", starting with "For the remainder of 2013,...". Not much there either. (Note, that page claims that WT:Flow would also be converted to use Flow as part of that first release, so it clearly isn't up-to-date).
"Current medium-term (January through March 2014) plans include some or all of the following: [...]creating a new beta feature option to Flow-enable a user talk page" So User:Okeyes (WMF), are you going to copy the manners of many MediaWiki admins and VisualEditor team members? Making uninformed statements, brushing away criticism, acting as if you know better and we should e.g. just have read the documentation, and so on? The current, official documentation on enwiki states that the plan is to enable Flow for user talk pages as a Beta-feature (and more projects, and some articles as well) somewhere in January-March 2014, which I wouldn't describe a "not quite a while". You would know this "if you've read any of our planning documentation on enwiki" before responding here. Fram (talk) 09:46, 7 February 2014 (UTC)
Urgh, my apologies; we keep getting a disconnect between enwiki/mediawiki documentation and internal/external documentation. Hopefully we'll be able to work on that if/when the talkpage isn't as jam-packed. So, fwiw, I consider deletion and/ some way of completely removing threads a necessary prerequisite for, eg, article namespace rollouts; I don't think it's a necessary prerequisite for more wikiprojects, or for user talk opt-ins. The article namespace rollout will be dependent on this feature and won't be happening for quite a while, although I don't have a precise timeline (Maryana is probably more likely to be helpful on that than myself). Okeyes (WMF) (talk) 23:35, 7 February 2014 (UTC)
"That said, our stretch goal for this quarter (Jan-March) is to package Flow as a beta feature that anyone can opt into on their user talk page, try out a Flow experience, and opt back out if it's not working. So hopefully soon... Maryana (WMF) (talk) 18:26, 10 February 2014 (UTC)" (on User talk:Jimbo Wales). Very bad idea with the current state of Flow, and the major flaws in it. Perhaps first correct all the major bugs in it before considering a wider rollout? There is a list as long as the Chinese Wall by now of things that need to be done before this can be considered for further rollout. Enable it on MediaWiki if you must, and test it for a month, not only as if you were an admin or regular editor, but also as a clueless newbie and especially as a vandal. Should be standard practice for all such releases, but experience makes it obvious that this need to be said again and again here. Fram (talk) 11:12, 11 February 2014 (UTC)
Yep, this is deployed now. Strange that my first unprotection doesn't show in the protection log[5], but that's not really that important (assuming that from now on, unprotects will appear in the log). Fram (talk) 15:05, 7 February 2014 (UTC)
However, it looks as if the same update that added the "protect" dropdown, also removed the "watch" star. Maintaining the balance of Good and Evil here? Fram (talk) 15:09, 7 February 2014 (UTC)
Page protection is not visible to editors, they only get a warning when trying to save
Flow replaces the need for archiving - essentially it auto-archives. The feature of "Close and Summarize" (being worked on here soon) is still needed - and with our help, will be an improvement on the current {{hat}} et al systems. Among other things, this will solve the problem of broken links to threads that were archived. Quiddity (WMF) (talk) 18:35, 6 February 2014 (UTC)
So you'll get pages with 500 "older topics", taking minutes to get to them eventually (if at all, at the moment I get an "older topics" on the test page which doesn nothing at all)? Not a good solution for high-traffic pages. Fram (talk) 08:17, 7 February 2014 (UTC)
Sections / topics
Archiving sections is not enabled
See above.
Hatting / closing down sections is not enabled ("hiding" is not the same)
Administrators still see the hidden sections, but they don't seem to appear in the page history. This is non-transparent. The reason for the creation of revision-deletion was to improve the transparency of removal of individual edits from the page while keeping them visible in the page history. Risker (talk) 17:36, 6 February 2014 (UTC)
I think this refers to the currently confusing design where the Board-History is separate from the Topic-History - this is being worked on in the current sprint (notes here), and will combine the two histories on the Board-History view, to fix this. (as well as a general overhaul of the Histories output, to give them all the details we're used to). Quiddity (WMF) (talk) 18:43, 6 February 2014 (UTC)
Not just that though. When I look at [postId=05102e83bba542ce2f4390b11c278234&action=post-history], I see at the moment two entries, "Fram added a comment" and "Fram hid a comment". I don't see who created the topic (and when), and in reality 3 posts were added (1 initial and 2 comments), and 2 were hidden, not one of each. Furthermore, one comment was edited, which is also missing from the history. So yes, section history is not complete at all. The topic creation is at the general page history (confusing, but this will seemingly be corrected), but the other events are simply missing. Fram (talk) 11:18, 7 February 2014 (UTC)
No, "Hide" is a very different function. The information is still on the page itself. Undo and rollback remove the information from the page. Risker (talk) 17:36, 6 February 2014 (UTC)
What you're suggesting is a bug, not a feature. Why should any talk page continue to be polluted with trolling? Why should it have to retain sections that were placed there in error? This is particularly important with the "infinite scrolling" that will retain all this nonsense as an akashic record. The tools were created for a purpose, and a software change doesn't eliminate the purpose. Risker (talk) 18:12, 6 February 2014 (UTC)
Sections placed in error can be deleted by those who placed them (or, will be), and last time I checked VPT or AN/I were rarely if ever rolled back. In terms of trolling, yes, individual posts will continue to exist inside a thread, but that's nothing new - people trying to look at the history of a page, or where it stood at [point in time] (to use your example above) would still have a chance of catching trollish comments. In terms of trollish threads, threads are going to be detachable from pages anywhere; if the people maintaining that page decide it's a thread they want rid of, they can do that. Okeyes (WMF) (talk) 18:21, 6 February 2014 (UTC)
No, people just remove the offending edits, blanking them out or undoing them, so that it is no longer associated with a page except in the history. Where in the documentation does it say that anything can be removed from pages? As best I can tell, it's there forever, whether left viewable, hidden, deleted or suppressed. There does not seem to be a way to get unwanted edits off a page. Risker (talk) 18:33, 6 February 2014 (UTC)
Indeed, "hide" is a very different funtion. If someone messes with a post or a header, we need undo or rollback. And if someone maks a lot of bad posts in a row, we need rollback, not "hide", "hide", "hide", "hide", ... Fram (talk) 08:17, 7 February 2014 (UTC)
Revdel? A post can be deleted, but can a change or a number of changes to a post be deleted only?
Section linking, like is done now on discussion pages, no longer possible with the short and human-readable wiki-syntax
See the #Links topic above for details on these 2 points. (And I recognize the irony of this short wikitext link, but also remind us that it will break once either section is archived. ;) Quiddity (WMF) (talk) 21:53, 6 February 2014 (UTC)
Look and Feel
Much disagreement about what is needed, much more discussion needed about e.g. (in no particular order)
Whitespace
Font
Color
Buttons (color, size, position, inconsistency in look)
For VisualEditor, the aim is to "disable" all wikitext, editors may not use wikitext when editing. For Flow, editors need to know more wikitext than they need for standard wikitext editing (with the exception of signing and indentation). It would be nice if the WMF could decide what it will be, whather they want their editors to know and use wikitext or not, and why not one editing philosophy has been chosen.
I think this refers to the currently missing edittoolbar. Adding that in, is on the to-do list (see my notes here). (If that's a correct understanding, please clarify this section's title! :) Quiddity (WMF) (talk) 19:02, 6 February 2014 (UTC)
The missing edit toolbar is a problem, but that's a symptom more than the problem. The problem is that you have two major developments, one wanting to eliminate all wikitext editing (VisualEditor), and one embracing all wikitext editing (Flow). This is rather bizarre. Fram (talk) 08:17, 7 February 2014 (UTC)
As the docs say, VE will become an optional interface method, in the future. The devs are creating Flow with just wikitext support at the beginning, because adding VE as a choice later will be fairly easy (since it all runs on parsoid), and because us power-users would raise all kinds of hell if they did it the other way around. Quiddity (WMF) (talk) 01:09, 12 February 2014 (UTC)
Discussion
Which of these, if any, are sufficient to stop the current test and move this exclusively back to MediaWiki?
Which of these, if any, are sufficient to delay any further rollout to more pages on Enwiki?
We're not currently planning to roll out to further pages on enwiki for quite a while. When we do, it'll be opt-in in the same way that this deployment was. Okeyes (WMF) (talk) 16:57, 6 February 2014 (UTC)
That's a point that all of you at WMF would do very well to shout loudly from the rooftops at every opportunity, because it's exactly the kind of information that soothes the savage editor. --Tryptofish (talk) 00:00, 7 February 2014 (UTC)
In-line responses
Okeyes, you've replied inline with most of these points. This will not be possible in Flow. At best, the respondent would have to copy-paste the original post and then respond inline, and that's not reader- or user-friendly. Risker (talk) 17:36, 6 February 2014 (UTC)
That's reinventing the wheel again. I have yet to hear a good explanation of why we're using modified web forum software on Wikipedia. Risker (talk) 18:05, 6 February 2014 (UTC)
Yep. That's precisely what it looks like. A web forum circa 2003. It may have lots of fancy coding, but the end of the day, it's just a web forum. Its current design actively discourages discussion but encourages drive-by commentary. Oh, I know there are great theories about all the things people are supposed to be able to do with it. But it seems rather odd that something that's supposed to open the doors to new users to *edit* Wikipedia (after all, that's really the entire purpose of this website) will be using software and editing processes divorced from either of the editing interfaces. Hope you guys are having lots of fun! Risker (talk) 01:06, 7 February 2014 (UTC)
Uh-oh, here I am at an indentation level I won't be permitted with Flow, responding to Okeyes's comment. Why do you think that "sandbox mode" is inappropriate for nearly all discussions? Of all the various decisions I've seen on this, choking off threaded discussion is the strangest one. Will sandbox mode permit full discussions? Or will it also have a depth limit that prohibits replying to replies?—Kww(talk) 02:18, 7 February 2014 (UTC)
Choking off threaded discussion? We're not discussing that, to my knowledge. The team are going to be talking about increasing indentation levels, which I'm personally supportive of (one level of indentation is not sufficient by quite a way) Okeyes (WMF) (talk) 23:36, 7 February 2014 (UTC)
This page obviously is neither GAN nor FAC. I've argued before that the interleaving of comments is something that should be encouraged, not restricted. It should be possible now (or at least soon-ish) with all Flow-posts not some extra feature to be added much later for a select few. And I think the current solution for this (as used on this page) is far from perfect. E. g. it's not immediately obvious who contributed which lines, you can only guess and for doing that successfully you need to know the social conventions for the use of talk-pages or you will have to check the history. --HHill (talk) 08:31, 7 February 2014 (UTC)
Links to sections of discussion
Right now it is possible to link to an individual comment, and to a topic, but nothing in between (e.g. to how a page looked on a particular date). Risker (talk) 17:36, 6 February 2014 (UTC)
Oliver, I've been concerned about some of the things people have said about archives. Someone said Flow will effectively abolish the concept of an archive.
A Wikipedia talk page is essentially a collaborative document. It's not like Twitter, Facebook or IRC. People suggest texts and sources on talk pages, there are RfCs, formal and informal peer reviews, and so on. (And posts have to be moved around, RfCs restructured.) I've many times relied on archives when rewriting an article by going back to see what people were complaining about and suggesting. Archives are invaluable.
We need to be able to organize them chronologically, and sometimes by subject matter; the latter means we have to be able to continue to copy material over to them. To what extent (if any) can this be done with Flow? That is, to what extent will it allow us to create a "January–June 2014" archive and a "Sources for the first section" archive (which might span several years)? SlimVirgin(talk)16:45, 7 February 2014 (UTC)
Well said. Our requirements are many and varied and will not allow a one-size-fits-all solution. Anything that supports fewer ways to collate and archive discussions is an enormous step backwards in terms of functionality. If it hasn't been done already, this project needs to assemble a list of as many kinds of archive - with real examples - as it can, and consider how Flow will support each of them.
To put it bluntly, if the WMF's developers try to force this single automatic archive mode on people, the result will be little short of a user uprising. I for one will not allow it as a talk page mechanism for myself; I will simply direct users to an area of my user space to continue in wikitext as before. The results around the project in other namespaces and among various different wikiprojects and sub-communities will be a mess on an unprecedented scale. — Scott•talk20:00, 7 February 2014 (UTC)
I agree as well, and this is something I was alluding to above when I expressed my concern about the top-down, infinite scrolling set up for Flow. I think the system has potential, but it still needs quite a bit of customization to fit our practical needs. Resolute20:12, 7 February 2014 (UTC)
I too agree. Infinite scrolling with talk pages with archives will be problematic. (eg. Talk:Jesus, this talk page will give you examples of the requirements User:SlimVirgin has mentioned, archive page by subject matter, peer review, important discussions etc etc) Tito☸Dutta20:17, 7 February 2014 (UTC)
Count me too as agreeing with everyone here. Perhaps there could be a way to have some sort of very functional search function, that could help with some of this. --Tryptofish (talk) 21:43, 7 February 2014 (UTC)
Okay, so, in order:
Flow will not have "archives" in the conventional sense; you'll be able to scroll or, more realistically (as Tryptofish mentions) search to particular threads. This could include date filtering - I don't think search has been entirely specified yet, because we're waiting on a new search engine that Platform/Operations are building.
You will be able to 'archive' threads, removing them from view, and this will be something you can explicitly call for a thread or set to happen automatically. The time period or inactivity level or...whatever restriction for automatic archiving will hopefully be settable with some granularity (when threads are archived for AfD is different from when threads are archived for, say, the Village Pump). It's worth noting that this current purely-date-based display mode is not expected to be the be-all and end-all of how we show content: I imagine we'll have some kind of algorithm to mix up new things, heavily-responded-to things, things that haven't been responded to at all, so on and so forth, so marking a discussion as archived and closed will make a difference. Okeyes (WMF) (talk) 23:40, 7 February 2014 (UTC)
@Okeyes (WMF), if I understand you correctly, "archived" will be a thread state rather than a location. This state can be used to filter the threads shown in subscriptions and searches. Because archiving a thread won't change its location, any permalinks into the thread will continue to function however many times it changes state. The precise ways that searches will work – and for that matter who/how can mark a thread as archived – are still t.b.d., but (except for oversighted items) it will always be possible to search Flow's historical corpus of threads. Have I got that right? - Pointillist (talk) 00:09, 8 February 2014 (UTC)
You are absolutely correct (ish) though the states a topic can be in are probably going to be more fine-grained than simply "archived". It's probably more like "close", "closed and locked", "stale", etc. --Jorm (WMF) (talk) 00:12, 8 February 2014 (UTC)
I was trying to stay net (ish). Yes, and states like Oliver's "new", "heavily-responded-to" &c are dynamic, or at least frequently re-computed. There are cultural issues to consider too, e.g. who owns a thread?, when can threads be closed and re-opened?, can off-topic discussions be collapsed or forked into a new thread?, and so on. Interesting times ahead.... Pointillist (talk) 00:48, 8 February 2014 (UTC)
Flow may not have archives per se, but as long as we can move threads to other pages, then we would still have the ability to put certain page types into subpages and keep effectively the same concept. That would be useful for pages like the aforementioned Talk:Jesus. The current style of Flow with a solid search feature would, IMO, be a very good replacement for having to archive my user talk page. Though I'd still like the option of removing entirely topics such as issues of the Signpost once I've read them. Resolute01:36, 8 February 2014 (UTC)
Thanks, Okeyes. Clearly, searching functionality is going to be important. As I thought about this some more, I was thinking about how, under Flow, we will be able to watch/subscribe individual discussion threads within a discussion page, and that led me to another point worth considering here. Let's say there is a page with discussion threads 1, 2, 3, 4, 5, 6, 7, 8, and 9, created in that numerical order. Then let's say that, on that rather busy page, an important discussion issue arises that draws upon earlier discussions in threads 2 and 4. But threads 1, 3, 5, 6, 7, 8, and 9 are unrelated to that important discussion. In the current talk system, we might create a subpage of the talk page to pursue the new specialized discussion. But in Flow, we might open thread 10. What I'm raising is that there should be a good way to associate/link/connect threads 2 and 4 to thread 10. --Tryptofish (talk) 20:39, 8 February 2014 (UTC)
What is the "preview" supposed to do when you change the title of a topic? It doesn't seem to do anything at the moment, apart from removing the cursor from the title edit area...
Oh wait, now I see, it adds a preview of the new title at the "bottom" of the topic, which is not logical at all (and since the page doesn't automatically scroll to the preview, not visible either in many cases), and it adds all previews beneath one another (type - preview - type - preview -type - preview results in three "preview" lines at the bottom)! I don't know whether we even need a preview for this, but the current one is absolutely useless. Fram (talk) 08:13, 12 February 2014 (UTC)
"Older topics", which was working badly already before the latest update, seems now to be completely broken? At the moment, on Wikipedia talk:Flow/Developer test page, it doesn't do anything, even after many repeated attempts, no matter if I look at it collapsed or uncollapsed. Not good... Fram (talk) 08:18, 12 February 2014 (UTC)
It is interesting and perhaps quite relevant to make note of the backlash Slashdot is currently experiencing over its comment redesign proposals, particularly since many things they are doing are issues that we've already identified with Flow. Namely, the vast reduction in content density and the loss of features that their community had come to find invaluable. For myself, I am happy that the Flow team appears to be taking this slowly and is engaging the community. While it is inevitable that there will be a good many complaints when this is finally launched site-wide, I am hopeful that lessons learned by Slashdot can be applied here to minimize disruption and user discontent. Resolute21:04, 12 February 2014 (UTC)
Yup, the team has been discussing that ongoing story via email for a few days. [And I've been a /. reader for more than a decade, so am following it personally, too!] Thanks for the pointer though, and for the long&wide-view perspective. Quiddity (WMF) (talk) 21:21, 12 February 2014 (UTC)
Flow notifications broken
Please patch this rather urgently: I receive email notifications each time someone (even myself!) replies to my post or edits my post. I have checked my preferences, where I had disabled these immediately after Flow was activated on enwiki, and my preferences indicate "Flow: Web yes, Email no". So why do I get notifications? Very, very annoying (not being able to add or remove these pages from my watchlist may also be corrected by the way). Note that these edits, for which I got an email, did not produce an Echo! Fram (talk) 09:31, 12 February 2014 (UTC)
Sidenote: You can unwatchlist any page, even with the missing-till-tomorrow watchlist-icon/tab, simply by going to the partner project page and clicking the star/tab there. Eg. Wikipedia:Flow/Developer test page.
I cannot reproduce this bug, either here or on mediawiki.org. I've tried all 4 combinations of [on/off] for the web/email notifications, and they all seem to work as expected, for basic replies, or edits to posts.
As I understand it, the bug you are experiencing is: "Your preference for Flow-Notifications are currently saved as web-on/email-off. When someone replies to your Flow post, you do get an email-notif and do not get a web-notif." Is that accurate?
I've not received any further emails from the system, I will let you know (here) if it happens, but meanwhile we can probably ignore it as a one-off glitch or something. Fram (talk) 08:01, 13 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? KonveyorBelt04: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)
And remember: new topics go at the top, but topics with new comments stay where they were. So if you reply to the 20th topic on a Flow board, it doesn't rise to the top but stays way down. Fram (talk) 12:07, 5 February 2014 (UTC)
Search functionality was on hold, but is now near the top of the to-do list, since the new cirrus-search integration is everywhere. (See the "New Search" Beta Feature, which was not automatically enabled per bugzilla:60748)
What about an integrated flow archiv? An archived flow will get out of the archive on its own, if someone replied to it. --Goldzahn (talk) 11:41, 13 February 2014 (UTC)
Topic jumping
I love it that when you click on the "4 comments", "1 comment", "3 comments"... in the topic header, you automatically jump to the next topic. Totally useless and cuonterintuitive, but works perfectly. Anyone has an idea what the purpose of this "feature" is?
The purpose seems to be to bring you to the "comment" field at the bottom, but...
The cursor isn't automatically put there, so the box remains small and things like the buttons aren't visible
Having a small white box at the very top, and a large grey one directly underneath in full view, puts all the emphasis on the next topic, not on the comment box
Usually, when you want to comment, you want to see the thing you are commenting on. By moving the comment box to the top, you can't see anything from the topic yuo are commenting on.
When the thread is collapsed, the underlined "4 comments" does absolutely nothing
Agree, this is weird behavior. Intuitively, I would expect these links to collapse/expand the comments. I know most of the grey box has that function, but that doesn't look clickable. A function to add a new comment I would more expect when clicking an "add" link to the right of "n comments", and in any case not with this kind of scrolling. Btw: we talked about this earlier and, Quiddity (WMF), no, this is not bugzilla:58372. — HHHIPPO19:52, 13 February 2014 (UTC)
Thanks both of you. I've entered these as bugzilla:61345 ("Clicking "Comment (n)" in Collapsed View doesn't expand the topic") and bugzilla:61344 ("Clicking "Comment(n)" scrolls to the wrong spot and doesn't expand text area"). There are a few other aspects of this that are being examined closely already, including the potential confusion of clickable links within the clickable total-area. The "scroll-to" code is also in the process of being improved, so that might fix some of the second bug. Quiddity (WMF) (talk) 23:02, 13 February 2014 (UTC)
Wikipedia talk:Flow/Developer test page alone made my watchlist virtually useless. Had to unwatch it through the project page, but is there any plan to bring the unwatch button back to the talk pages themselves?
Also, MzMcBride's flood of images/topics shows rather clearly that the current implementation is not good for high-traffic boards. Potentially active topics drop off the page far too quickly. Resolute14:52, 7 February 2014 (UTC)
I was thinking what MZMcBride was trying to do with so many large large images. I have never seen any article discussion page with so many large images. Loading such a page is very problematic for slow internet users like me Tito☸Dutta21:51, 7 February 2014 (UTC)
I'm not sure if MZMcBride has explained what that was about (I may have missed their explanation), but indeed, those are two concerns that the posts help identify. Though the slow connection problem exists now if someone were to post a dozen large images in the current talk pages. I wonder if admins would still be screwed though since deleted posts aren't really deleted? Resolute01:28, 8 February 2014 (UTC)
That's referring to the fact that "delete" acts the same way for sysops as "hide" does for the rest of us - it simply collapses the content for everyone with sysop permissions. Quiddity (WMF) (talk) 23:46, 10 February 2014 (UTC)
Edits to Flow showing up logged as edits to user talk pages
I had reason to look at my contributions to user talk pages, and was quite shocked to find that all of my edits to Flow test pages (all of which are in Wikipedia talk space) turned up in my log of edits to user talk pages. It's been a couple of days since I did any Flow test edits (so some interim changes may have occurred) but I don't see anyone else noting this, so I want to make sure it is addressed. Risker (talk) 17:25, 13 February 2014 (UTC)
History view is already available (can you not see it?)
Moving should be coming at some point, but we need to scope it out.
What do you mean by revdel? You can already delete individual posts and threads, which will largely achieve the same thing; the one thing we don't have at the moment is the ability to delete individual revisions of posts, but that's definitely coming.
When I click on history the page just reloads. I want a menu for things such as strikethrough, I really don't editors to have to know markup. By 'delete' do you mean delete so only Admins can see it? I assume that sometime new topics will appear at the bottom of the page and not the top? And we will have a table of contents? Dougweller (talk) 18:11, 5 February 2014 (UTC)
Okay, that's weird; what OS/Browser are you using? Yes, the delete functionality deletes stuff so only admins can see it. And no, new topics appear at the top rather than the bottom. At the moment the argument is being made for infinite scrolling and no TOC, and compensation for this to come via other means (a time-period selector, for example, and an efficient search system), but the plans are very much inchoate at the moment because it's a hard problem. Any and all thoughts are welcome (assuming they're civil). Okeyes (WMF) (talk) 18:59, 5 February 2014 (UTC)
OK, here's some thoughts on TOCs: When I load WT:Flow/Developer test page, I can see no more than two comments without scrolling, containing 25 words in total. This calls for a rethinking of font size and whitespace, but it also calls for a TOC. To the right, about 30% of my browser window are whitespace. This calls for something to fill it with. Why not put a TOC there? It could be of similar style and font size as our usual TOCs, contain the topic titles, number of comments and, if any, number of new comments since my last visit. It could fill the entire available space horizontally, wrapping the topic titles inside if needed. If there's not enough space, hide it, maybe with a button to expand. Vertically, it could show the same topics that are currently loaded on the page, updating when that changes. It could be floating as long as it fits in the window vertically and doesn't need scrolling, otherwise we keep it at the top of the page or invent a more sophisticated scrolling method for it. (This is just brainstorming, not a thought through proposal, hope it helps.) — HHHIPPO20:04, 5 February 2014 (UTC)
@Dougweller: 1) Currently the Board-history is separate from the Topic-history. Ie. topic vs board. This is indeed confusing, and is being changed in the code at the moment. That, along with a number of History-page improvements, should be live within the next few weeks. Specifically: They're merging the Topic-history into the Board-history (whilst keeping the separate Topic-history view also available). They're also fixing some of the ordering issues (bugzilla:61046), and changing the layout and elements contained in the history pages so that it is closer to what we're used to.
There has been some discussion about making &action=history redirect to &action=board-history, but I'll have to check where that's at. (I'm guessing you went to &action=history via navpopups?)
4) Adding in the "WikiEditor/Reftoolbar" (aka edittoolbar) for wikitext mode, is on the to-do list. However it doesn't have strikethrough... The MediaWiki:Edittools tool is in a more complicated situation, and there are frequent requests (totally unrelated to Flow) over the years to kill it off entirely, because two systems that do the same job, is confusing and distracting. I'm not sure how that's going to turn out (I would guess that WikiEditor will be worked on, to add the currently missing features). Quiddity (WMF) (talk) 01:11, 11 February 2014 (UTC)
A few more things currently missing, for whole Flow pages:
Move
Delete
Categories
And for individual topics:
Archive templates (hat, archive, ...): these work within one post, but not for a topic, I think. Doesn't need to be through templates, but a way to close a discussion without hiding or deleting it is necessary on many pages. Fram (talk) 11:12, 6 February 2014 (UTC)
Move and Delete - This process will be different from "talkpages", because the Board is just a container for Topics. Yes, you'll be able to Move Topics (and can already Delete them). I'm not sure how the page-move UI will tie in to the associated Flow Board, but will ask.
And it would be nice if the plus-minus calculation of changes in Flow (as seen in "contributions") would be correct for edits. It is way off base now (seems to be correct for new comments). Fram (talk) 11:18, 6 February 2014 (UTC)
Undo and Rollback - this needs a separate thread (It's also currently discussed at #Edits below). I'll round-up everything I can find, get some input from Maryana, and start a thread (probably Monday).
When multiple comments are posted to a Flow talk page they all appear in my watchlist. Formerly, only the latest comment appeared. I only want to see the latest comment, and not all the comments. Blue Rasberry (talk)16:16, 5 February 2014 (UTC)
What happens if you click on the word 'comment'? It sends me to your comments on the test page. Of course there should be more info directly on the contibutions page, and also on watchlists, they're working on it. — HHHIPPO21:52, 5 February 2014 (UTC)
Yes, that works. The problem is, I cannot tell at a glance what pages I have posted on, on what comment threads or if my comment remains the most recent on the page. Resolute21:59, 5 February 2014 (UTC)
Working – in the next sprint, we'll work on reducing the watchlist volume by showing only the most recent new topics/comments, not all activity. Maryana (WMF) (talk) 22:05, 7 February 2014 (UTC)
Maryana (WMF), just " showing only the most recent new topics/comments" is far from enough, and what I could grasp from some Trello cards didn't reassure me about the target you intend to achieve. Could we get some feedback on the proposals made by Skalman and myself here? Klipe (talk) 22:54, 7 February 2014 (UTC)
I need to be able to rapidly view things by hovering over the relevant text. If I look at contributors' contributions to Flow enabled pages, I can't do that, I actually have to click on Comment and go to that page. This seems a step backwards and slows me down. Dougweller (talk) 12:27, 6 February 2014 (UTC)
When I hover over a diff I can normally see several lines of the edit. That makes it much easier to check to see if it is vandalism, worth reading, etc. Dougweller (talk) 17:25, 6 February 2014 (UTC)
I'm...pretty sure that's a gadget. Can you check your preferences for NavigationPopups or something similar? If it's not a gadget, it's not mediawiki functionality I've seen in my years on the site (which is always possible). Okeyes (WMF) (talk) 17:33, 6 February 2014 (UTC)
Something like this, apparently. Partial archiving of discussions doesn't seem to be in scope (closing down tangents, subsections, ...). Fram (talk) 12:57, 11 February 2014 (UTC)
That doesn't seem enough. We need to be able to easily read through a closed discussion (at the moment we can't easily read through any discussions - are there no speed readers on the design team?). And we need it to look more like closed discussions look on normal pages. Dougweller (talk) 17:21, 11 February 2014 (UTC)
Also, sometimes discussions are wrongly closed and someone rightfully reopens them. This needs to be a use case that is supported. — Scott•talk18:06, 11 February 2014 (UTC)
@Dougweller: Which aspect(s) is insufficient in the spec, in particular? The "collapsing" ideas (this would act like the click-to-expand Topic Titlebars do), or something else?
Secondly, which of the visual elements of the current 'archive top' system do we find most useful? (So that we can think about how to apply them to the Flow design). Sidenote: There was some discussion about this yesterday in a meeting, and I believe there are newer design mockups coming soon (with clear attribution of the user/time of closing, and other tweaks). Quiddity (WMF) (talk) 21:20, 11 February 2014 (UTC)
No I'm not. That was not actually a 'discussion', ie not a thread. We need to be able to close long threads, will we be able to do that? We do it all the time with RfCs for instance. Dougweller (talk) 16:26, 16 February 2014 (UTC)
@Quiddity (WMF): I'll need to see an example, but the criteria look good. However it is important that collapsing is just an option, and with for instance an RfC would rarely want to collapse a discussion. I like the way 'archive top' shows the summary/decision and visually makes it clear that the discussion is closed. Dougweller (talk) 09:56, 19 February 2014 (UTC)
I would like the following two acceptance criteria to be added:
"I can see the content of the closed discussion (i.e. expand it) without re-opening it."
"I can undo both close(+summary) and re-open actions and go back to previous state." So that we can go back to any previous summary if the topic was re-opened (and possibly closed again) either by mistake or by a vandal.
Working – the newest code we pushed on Thursday has tighter spacing between posts. We'll be doing a larger frontend UI refactor over the next few weeks. When finished, it should, among other things, widen the board/reduce the right margin and create a more responsive interface that scales for larger/smaller screens. It's all experimental and changing rapidly based on your feedback, folks – if we were "unwilling" to change anything, we wouldn't have put it out there so early for you to test :) Maryana (WMF) (talk) 22:13, 7 February 2014 (UTC)
Tito☸Dutta 11:30, 4 February 2014 (UTC)
