Arthur Rubin (talk | contribs) →Move doesn't work: not necessarily a serious problem. Yet. |
→Wiki misconceptions: Reddit on a mobile |
||
Line 247: | Line 247: | ||
::::::[[User:Jayen466|Jayen466]]: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --[[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:47, 30 August 2014 (UTC) |
::::::[[User:Jayen466|Jayen466]]: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --[[User:Jorm (WMF)|Jorm (WMF)]] ([[User talk:Jorm (WMF)|talk]]) 00:47, 30 August 2014 (UTC) |
||
:::::::So Flow is designed for mobile use? Do you expect people to do encyclopedic work while standing in the subway with their mobile phone? Fair enough, occasionally one might want to fire off a talk page reply in such a situation, but then I think it would be rather better to cater for that situation by having mobiles display the talk page indents differently, perhaps with micro indents[[User:Jorm (WMF)|.]] Does anyone know what Reddit threads look like on a mobile? [[User:Jayen466|Andreas]] <small><font color=" #FFBF00">[[User_Talk:Jayen466|JN]]</font>[[Special:Contributions/Jayen466|466]]</small> 01:46, 30 August 2014 (UTC) |
:::::::So Flow is designed for mobile use? Do you expect people to do encyclopedic work while standing in the subway with their mobile phone? Fair enough, occasionally one might want to fire off a talk page reply in such a situation, but then I think it would be rather better to cater for that situation by having mobiles display the talk page indents differently, perhaps with micro indents[[User:Jorm (WMF)|.]] Does anyone know what Reddit threads look like on a mobile? [[User:Jayen466|Andreas]] <small><font color=" #FFBF00">[[User_Talk:Jayen466|JN]]</font>[[Special:Contributions/Jayen466|466]]</small> 01:46, 30 August 2014 (UTC) |
||
:::::::Having borrowed a mobile, I find that Reddit looks much the same there as it does on a desktop computer. And it's perfectly usable, infinite indentation and all. (By the way, one thing I really like about Reddit is that when two people go on and on replying to each other ad infinitum, eventually, after 10 indents or so, Reddit will just put an arrow link to a new subpage.) I honestly don't see the problem. [[User:Jayen466|Andreas]] <small><font color=" #FFBF00">[[User_Talk:Jayen466|JN]]</font>[[Special:Contributions/Jayen466|466]]</small> 02:05, 30 August 2014 (UTC) |
Revision as of 02:05, 30 August 2014
This page has archives. Sections older than 15 days may be automatically archived by Lowercase sigmabot III. |
Flow & Pings
Has anything been done to address this: Topic:Ronsz8yhsrhq3890? - tucoxn\talk 12:53, 10 August 2014 (UTC)
- I'm sorry -- I hadn't seen that, and I didn't realize it was still going unanswered. I just replied on that thread. Thanks for the nudge. DannyH (WMF) (talk) 18:44, 12 August 2014 (UTC)
Categories
Can flow-enabled talk pages be categorised? For example, the header of Wikipedia talk:WikiProject Breakfast contains a category link to Category:WikiProject Breakfast articles, but does not appear to be listed in that category. Just pointing out that if flow is rolled out without fixing this the article assessment system will be broken. BethNaught (talk) 20:48, 18 August 2014 (UTC)
- Thanks for the reminder on that issue BethNaught, I've updated https://trello.com/c/YmFl7PrT/ . Generally, yes, they do need/plan to get categories working, because almost all of our existing workflows depend on templates+categories(+bots) to function. Quiddity (WMF) (talk) 22:59, 18 August 2014 (UTC)
- Ideally, that particular banner would place the page itself, rather than the talk page, in the cat. But (specifically for that one) it would be adequate to place only the header in the cat. WhatamIdoing (talk) 17:52, 23 August 2014 (UTC)
Lacks an experienced, non-sticky persona
All the personas listed are sticky. In my present guise, I'm not. Over the years, from time to time, I became involved with a page and made substantial contributions. I know the basic markup inside out, and I've gradually become familiar with the most important editorial templates and the policies these enforce. I actually use Wikipedia to survey subject areas I'm learning about for my personal and professional purposes. If I'm being thorough in my research, this often takes me into the darker reaches of unloved articles, where I'm quick to spot various kinds of breakage. I'm usually happy to invest five minutes to bump an article in the right direction. It can be anything from fixing broken markup, copy editing, adjusting balance, splitting an overgrown lead, or plumping up an insufficient lead (the lead is the most frequent problem area I find myself fixing in the musty article space). I believe the majority of my edits serve Wikipedia editorial policy, but I don't hang around to polish my surgeries; I'm hoping others will come along with more investment in that subject area for the smoothing out (always leave a nickel for the next guy). Though my attentions are brief I strongly believe in leaving explanatory tracks. If the template reason field or the edit comment don't suffice, I generally leave a paragraph on the talk page; sometimes all three. In the rare case where my edits are reverted, I don't return to the scene of my crime to contest the issue: I'm okay if 90–95% of my edits make it through infancy unscathed. It's more efficient to be a little on the edge than to second guess myself. Generally I'm an experienced seagull editor who drops a note into a conversation and then bubbles off. I'm not antisocial. If someone challenged one of my edits on my talk page, I would surely respond. I find in software development projects it's always good to model at least one persona who doesn't love what you're building as much as you do. A non-sticky persona might be a good add. Also, I've often added comments to talk pages where I suspect the talk page won't be viewed again for weeks or months or years. I'm quicker to make edits on the pages where editorial velocity and conflict are inherently low. That's another aspect you might wish to model: semi-retired editors who mainly stick to infrequently traveled back roads, where topics created are more like messages in a bottle to record intent than to solicit active engagement (attached to pages where I might not have much of an interest or opinion on its future evolution). I've been around long enough to hold an opinion about the kinds of edits a less experienced editor (say 300 edits) might be afraid to take on, for fear of ruffling some previous contributor's feathers. It's my intent, anyway, that some of my more savage edits lower the permission barrier for such a person (in fly-by-night mode, I rarely delete existing text unless it's extremely out of line, as this strikes me as rude). I would wish to monitor my topics to make myself available to provide clarification about my original motivation. But generally I don't wish to monitor these topics for forward developments. I sure hope the new discussion system doesn't end up conveying the implication that whenever someone opens a new topic that they plan to stick around and set up a tent. I'm a batcher, who edits mainly in passing, usually with external agendas in tow. The last thing I wish to bring into my life for my efforts is a rolling notification feed, though I do believe in showing up to account for my past actions, if I wasn't clear enough in my original note. Those are a few dimensions people might consider if you decide to enlarge your persona roster.— MaxEnt 08:13, 19 August 2014 (UTC)
- That's a great perspective to add, and well-explained. Thank you. (and with my volunteer hat: "I like how you roll", as the kids say. ;-) ) Quiddity (WMF) (talk) 00:08, 23 August 2014 (UTC)
- I don't think I understand this. I think you're talking about a watchlist trimmed with time. But, perhaps, one of the features of WP:FLOW was to be an enhanced WP:NOTIFY whenever one of your comments was replied to, in which case, yes, you need to be able to turn that off. — Arthur Rubin (talk) 16:20, 23 August 2014 (UTC)
- Are we talking about the personas at Wikipedia:Flow/MVP and if so, what does sticky mean in practice? Dougweller (talk) 18:45, 23 August 2014 (UTC)
- @Dougweller: I'd imagine it refers to how often an editor looks at a talk page. Some editors read an article's talk page every day while others may glance at it once and then never read it again. @Quiddity (WMF): Pardon my cynicism but one point in the personas really stuck out for me as making things easier for the developers rather than accurately describing roles. No, Watchers don't want to hide inappropriate comments, they want to delete them, like you have Admins listed as doing. I'd wager the good majority of talk page deletions now are done by non-admins. --NeilN talk to me 20:07, 29 August 2014 (UTC)
- Are we talking about the personas at Wikipedia:Flow/MVP and if so, what does sticky mean in practice? Dougweller (talk) 18:45, 23 August 2014 (UTC)
- I don't think I understand this. I think you're talking about a watchlist trimmed with time. But, perhaps, one of the features of WP:FLOW was to be an enhanced WP:NOTIFY whenever one of your comments was replied to, in which case, yes, you need to be able to turn that off. — Arthur Rubin (talk) 16:20, 23 August 2014 (UTC)
Problems accessing mediawiki flow page - and too many Echo notifications
I see some people have been able to access the Flow comments page on MediaWikiwiki, but I've not been able to do so for a day or two, regardless of what computer I'm using. It times out and/or never fully loads. Systems used: Win7/IE9, Win7/FF, Win7/IE11 (most current versions of all the browsers). Risker (talk) 13:14, 26 August 2014 (UTC)
- I don't edit on Mediawiki any longer, and am even less inclined to do so now that they seem to have ruined Echo through Flow (without changing my preferences, I now have gotten 23 echo notifications for Flow discussions in 3 days time). Great job, WMF, the only good new feature you created in the last few years (Echo) now made useless (at least in the default settings) by another oops-it's-harder-than-expected development. But I am able to access this page quite easily: is that the one you mean? Fram (talk) 13:45, 26 August 2014 (UTC)
- That's the page, but after 2 minutes of the "blue circle" whirling around I closed the window; it hadn't fully loaded. (That's on my slower computer with IE9.) But I agree with you about the number of notifications being received, my mailbox has been flooded in the last few days and that's actually what spurred me to look at the mediawikiwiki page again. Flow should use the same standard as regular talk pages: echo notification for the first "new" edit and then no more until one visits the page/thread being watched. Risker (talk) 14:10, 26 August 2014 (UTC)
- Yeah, we're trying out a new way to handle notifications for Flow pages. The new system just launched on Thursday, and I'm really glad that you've brought up the problems. To be honest -- we haven't done any work on the email notifications yet, because we've been focusing on changes to the notification panel. But clearly we need to retune email notifications very soon.
- So -- now that we've ruined the world -- Fram, can you tell me some more about your 23 in 3 days experience? Questions that I have: Which pages/conversations were you watching? Were the 23 notifications in email, or in the Echo dropdown? What's the volume you would have expected?
- If you can give me some more details, that'll help me come up with a fix for it. Thanks! DannyH (WMF) (talk) 00:45, 27 August 2014 (UTC)
- And Risker -- sorry about the blue circle -- did you happen to file a Bugzilla ticket for that? If not, I can create one. Thanks for the report... DannyH (WMF) (talk) 00:46, 27 August 2014 (UTC)
- Well, I set my "echo" notifications back to zero yesterday (the number in the red circle you see at the top of every page your user name and "talk"). Today, it is back up to 15. When I open them, at the top I get in big red "No formatting defined for notification". WTF? The first notification is [https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&curid=39332539&diff=622886755&oldid=622886022#Problems_accessing_mediawiki_flow_page_-_and_too_many_Echo_notifications Too many notif... 98.165.42.183 responded on [No page]. 21 hours ago Two other notifications, one after another: *Notifications? Jay8g and 1 other responded on Talk:Flow. 13 hours ago | View board *Notifications? Jdforrester (WMF) responded on Talk:Flow. 13 hours ago | View board
- Then I get all the new topics on Talk:Sandbox and Talk:Flow (the only two pages responsible for these echo flood). I would expect to only get notifications when I am pinged, and perhaps once when one or more topics are started on a talk page I follow.
- But first and foremost, I would expect any page where I tick the "green star" to REMEMBER THAT CHOICE. It is extremely off-pissing to remove Talk:Sandbox from the watchlist, only to get it added back immediately when I return there. It turns out that I have to remove the main page (Sandbox) from my watchlist, and that the green star, even though it changes its appearance, doesn't do anything. Anyway, I want it to behave like any other talk page does that I have on my watchlist, not to bury me under notifications. Just imagine someone having WP:ANI on his watchlist in Flow... Fram (talk) 11:43, 27 August 2014 (UTC)
- Gentlemen: I have some 4000 pages on my watch list at the German Wikipedia. Among them 'all high traffic talk pages for admins and editors. Do you really intend to "notify" me by raising up the echo counter for every single edit anyone does on any of those pages? Don't! Or what you've seen with MV will be some light April breeze against the storm you will face. As I mentioned time and again: Have you ever tested Flow in a high traffic environment? Maybe a lively discussion with -say- 400 contributions by -say- 25 different editors in -say- 15 subchapters all stemming from one root posting? Now multiply that by 8 current threads plus 15 older ones. And imagine I have been away over the weekend and now try to catch up. The current system can deal with this situation. And I can, too. Does Flow? --h-stt !? 12:40, 27 August 2014 (UTC)
I would agree that sending a notification for every action on every Flow page on your watchlist is overkill. Flow notifications should be reserved for when someone posts on a topic you've posted on (or maybe even just for direct replies). The notify-for-everything system drowns out important notifications in a flood of less vital ones:Jay8g [V•T•E] 17:18, 27 August 2014 (UTC)
A compromise way to deal with this would be to split the existing Flow notifications option in preferences into "Flow reply" (direct replies to your posts or comments on threads you have commented on) and "Flow subscription" (all actions on threads you have subscribed to), with the latter probably off by default:Jay8g [V•T•E] 19:12, 27 August 2014 (UTC)
- Right now, Flow notifications do not ping you separately for every message on a page. The model that we're moving towards is to have one notification item for every discussion thread. The notification items (when they work properly, which is maybe 80% at the moment) roll up multiple posts into one notification item.
- So if there are three active conversations that you're subscribed to on a board, the most notification items that you should get at one time is three. That is true even if one of them is super crazy active, with dozens of new posts every minute. You still only get one notification item in the Echo dropdown, and the number in the red circle is 1.
- This is a big change, and an interesting one, and we knew that some of it would be awesome and some of it might not be, but often it's hard to tell what the biggest problems are until you try it out and see how it feels. This new system has been out on Mediawiki.org since last Thursday, about six days. We've found some surprising bugs -- like the weird "no formatting defined" error message that just appeared yesterday. Also, I wasn't paying enough attention to email notifications, because I've been heads-deep trying to get the Echo flyout to work. That obviously needs to get fixed soon.
- But this is the kind of bold experimentation that you can do while the feature is basically on five pages on Mediawiki.org, one of which is a sandbox and another is specifically about Flow feedback. We're not going to send the new Echo code on the release train to English WP tomorrow, because it's not ready -- we need another week to fix some bugs, and it's good to do that work before it affects more than five pages.
- There are a ton of different points and questions raised above, and I'll try to respond to all of them, but first I have to write a couple bug tickets. :) I'll be back. Thanks as usual for your thoughts and questions. DannyH (WMF) (talk) 19:50, 27 August 2014 (UTC)
- We're currently being super deliberate and thoughtful about the plans for development, testing and rollout. We're starting by working on the simpler use cases, and learning from there. You are absolutely right when you say that the feature as currently released on Mediawiki.org will not scale to the Village pump. We're not going to get there for a little while.
- First, we need to nail the simple use cases. We haven't even done that yet. :) There's no way that we could try out some of the interesting experiments that we want to try, and expect it to instantly scale to Village pump. There's a lot of time and thought and work between now and then. The job for today is to make it scale to four medium-volume pages and a sandbox. So you don't have to stress too much today about suddenly seeing the current form anywhere other than where it is. The world is not ruined yet. DannyH (WMF) (talk) 20:07, 27 August 2014 (UTC)
- Oh, also -- what are you watching the Sandbox page for? Even I'm not watching the Sandbox page. :) DannyH (WMF) (talk) 20:23, 27 August 2014 (UTC)
- To clarify, Flow can be enabled in non-talk namespaces? I had been led to believe that it was talk pages only. BethNaught (talk) 20:26, 27 August 2014 (UTC)
- Also, I hope being "super deliberate and thoughtful" about testing and rollout includes gaining community consensus for the rollout of Flow. BethNaught (talk) 20:34, 27 August 2014 (UTC)
- Super deliberate and thoughtful definitely includes lots of involvement with lots of people in the community, including and especially the people who care enough about it to post on this page right now, while we're still on five pages. You will be allowed backstage access.
- Currently, Flow is deployed on a single page basis, and I believe it can go anywhere. The next places we're working towards are some help & mentorship spaces on English and French WP, but we've got more discussion and work before we actually get to that step. DannyH (WMF) (talk) 20:55, 27 August 2014 (UTC)
- From your avoidance of the word consensus I can only assume that, after a lot of discussion, the WMF still intends to force it on the community whether it wants it or not. Also, you say we will be allowed backstage access – the WMF shouldn't be presuming to give and take access to the most major change to the wiki interface for a long time. BethNaught (talk) 10:47, 28 August 2014 (UTC)
- Currently, Flow is deployed on a single page basis, and I believe it can go anywhere. The next places we're working towards are some help & mentorship spaces on English and French WP, but we've got more discussion and work before we actually get to that step. DannyH (WMF) (talk) 20:55, 27 August 2014 (UTC)
- While I appreciate that you only get one notification per thread, on most threads that means one notification per action, and if you are watching a page, you are subscribed to many threads which all send out separate notifications, so it still feels like it is flooding Echo:Jay8g [V•T•E] 21:51, 27 August 2014 (UTC)
- DannyH, you've not thought this through. If someone wants to know that a new thread has been started on a page that is important to them, they have to watch the page. Watching threads, while a cool idea and certainly an important improvement, is secondary to the effect of being able to watch an entire page. I have, today, received a notification for every single action on the mediawiki Talk:Flow page. The choice you are giving us seems to be "Know about new threads but get pinged for every action" or "Don't know about new threads". This is exactly what I mean by Flow actually having a negative effect on discussion. My mailbox is full of junk messages right now, and anything not related to that page is totally buried in my Echo list. The only way I can stop the flood is to stop watching the Flow page, or to turn off notifications for it. I've gone for the latter. But I only go to Mediawikiwiki when I get an email notice that something has happened on one of the pages I watch there, so my participation on the Talk:Flow page is guaranteed to be reduced now. This is not an example of "Better methods for collaboration will improve collaboration, which will improve all of the projects." (Incidentally, there's no evidence of that correlation. Lots of our better articles have nearly-empty talk pages and we're already rather overwhelmed by articles that are horrible or battlefields because of, effectively, too much collaboration.) Risker (talk) 23:24, 27 August 2014 (UTC)
- (Note: This following idea has been suggested before, but needs more feedback/research/design/feedback, and also feedback.) (See also the "Separate notifications ..." thread below)
- A few people have suggested, that we will need (and have really wanted for many years) at least 2 levels of watching a talkpage.
E.g. 1) not watching. 2) just watching new topic creations. 3) watching everything.
Or an option where I could have a page appear in my watchlist, but not get any notifications?
And possibly an option where I could watch a page, but not it's talkpage? (I'd love to watchlist all the Manual of Style subpages, but not the associated talkpages for most of them)
- A few people have suggested, that we will need (and have really wanted for many years) at least 2 levels of watching a talkpage.
- We need something with sensible defaults, that can be adapted/tweaked for different wikis, or namespaces, or use-cases. (e.g. a very active noticeboard could default watchlist me at level#2, but most article talkpages could default watchlist me at level#3).
- What ideas haven't been mentioned yet? What options would be powerful enough for our needs (and even satisfy our wants) ? (without requiring an instruction manual as some of the userscripts do) ? What is your dream setup, a few years from now? Quiddity (WMF) (talk) 02:53, 28 August 2014 (UTC)
- It seems to me that you're no longer talking about Flow here, you're talking about Echo/notifications and/or watchlists. Is Flow supposed to take over both of them as well? I'm very serious about this, the Mediawiki page on Flow is so horribly out of date that the community has no way of knowing what its actual objectives are or what it's really intended to do. Risker (talk) 03:19, 28 August 2014 (UTC)
- @Risker: The broad mw:Core Features team is responsible for Echo, and some of the developers who originally worked on Echo are still on the team. They're broadly responsible for what some staff are calling "messaging" - on-wiki communication via talkpages and notifications. Additionally, Flow is (obviously!) responsible for whatever it puts into the specialpages/feeds (RC/watchlists/contribs/history/logs). It's not going to "take them over" in any way, but having Topics as individual pages means they need (or at least could have) some sort of slightly tweaked entries, particularly for watchlists. Hence we're asking what your preferred scenario would be. Would One additional option be sufficient, and if so how might you want it to work? Jay8g has one good idea below.
- I'm used to watchlists, and I can just about use the "25 changes since your last visit" to read through VillagePump updates, but I'd really like some better tools, available for both me (who can find/install userscripts) and for everyone else who wants more options.
- (Tangentially FYI: there are separate and completely-unrelated-to-Flow efforts to improve RC and watchlists, eg mw:watchlist wishlist and user-specific page lists RfC, and a few more specific bugs listed in the userpreferences RfC, that you might be interested in). Quiddity (WMF) (talk) 19:44, 29 August 2014 (UTC)
- Well, separate settings for watchlisting something and notifications-listing it would be nice. That way, you could have some things be watchlist only (current wikitext watching system) and have some things be notifications only, and some things even be watchlist + notifications (current Flow watching system) (though I don't know why this would be needed...). That way, people could get notifications for things that they consider extra important (normal and Flow pages) and just watchlist entries for things that they don't consider as important (again, normal and Flow pages):Jay8g [V•T•E] 03:39, 28 August 2014 (UTC)
- It seems to me that you're no longer talking about Flow here, you're talking about Echo/notifications and/or watchlists. Is Flow supposed to take over both of them as well? I'm very serious about this, the Mediawiki page on Flow is so horribly out of date that the community has no way of knowing what its actual objectives are or what it's really intended to do. Risker (talk) 03:19, 28 August 2014 (UTC)
- (Note: This following idea has been suggested before, but needs more feedback/research/design/feedback, and also feedback.) (See also the "Separate notifications ..." thread below)
Can you please make sure that whatever new version of Flow gets deployed on Wikipedia, the Echo bombardment is not included. I just looked at my mw page again, and I got 11 notifications again, all from the Talk:Flow page. Bringing this to Wikipedia will only cause people to remove the Flow pages from their watchlist, without any actual benefits. Fram (talk) 07:17, 28 August 2014 (UTC)
- Yeah, the current version that's on Mediawiki is going to change, thanks to the feedback that we've received here. We just had a team planning meeting, where we talked about changes that we're going to start on next week -- changing "subscribe to a board" to give one-time notifications for new topics rather than automatically subscribing you to new topics 1, and a couple of steps to limit the number of email notifications 2. I have to have a couple more conversations about email notifications, because I think there's some more work that needs to be done besides what's on that card. That'll happen over the next couple days.
- There are going to be a lot of changes and experiments to come; that's how this kind of software development works. We've got a very limited number of test pages running, most of them on Mediawiki.org, because we need to have the flexibility to try out a new element, see how it behaves on production, and then make further iterations as we go along, based on feedback and observation. We're holding back the latest version of Echo so that it doesn't deploy on Wikipedia this week, so we can fix some bugs and make some more changes. Thanks for telling us how it's working for you; you're giving us exactly the kind of feedback that we need.
- It's true that the project page isn't getting updated enough -- many of these changes are happening on a daily basis, and it's mostly getting recorded in Trello, Bugzilla and the mailing list. If you want to stay up to date with the team, feel free to join the Editor Engagement mailing list; there's a lot of interesting work coming up. DannyH (WMF) (talk) 19:42, 28 August 2014 (UTC)
- So basically, you're saying that in order to "keep current", the average editor would need to find the applicable Trello (I can't find any links to it), follow bugzilla and carry out regular searches for Flow bugs (but of course not add anything non-technical to bugs, or they'll be given a hard time), and subscribe to another mailing list. Do you understand what the challenges are here? Meanwhile, none of those are going to tell us what the objectives of Flow actually are. There's no big picture here. You can't get to where you're going unless you know where you're going. Right now I'm not getting a sense that anyone knows what the objectives are here; I'm assuming good faith that they aren't being deliberately obfuscated. I'm more getting the sense that there's a lot of pie-in-the-sky dreaming and adding in ideas and features without having a solid master plan in place. There are no measurable objectives here. I urge you to consider that the lack of clearcut, easily articulated objectives is by itself a reason to pull this project off the front burner, because after almost two years of following Flow, I still have no idea what you're trying to build here, and nothing I'm seeing coming from the WMF perspective tells me that you've really worked that out either. Risker (talk) 20:16, 28 August 2014 (UTC)
- I think a lot of the big objectives are actually handled pretty well on the Wikimedia project page. What I've been responding to on this page for the last couple of days are some concerns that people have about specific items in last week's code release. We use an agile software development process that prioritizes making lots of small changes, being flexible in the short-term, and testing assumptions by trying things out and then iterating. In the short-term view, this process can look chaotic. Taking a broader view, it's actually the most effective way to plan a project. You don't waste a lot of time creating pixel-perfect specs for an enormous grand vision, and then realizing a year into production that you've made some mistakes. Instead, we make our mistakes in real-time, and we adjust quickly. You're not under any obligation to follow this process on a weekly basis; I wouldn't if I were you. But those tools are available, for anybody who's super interested in how the sausage is made. DannyH (WMF) (talk) 21:33, 28 August 2014 (UTC)
- DannyH, I don't see what you're seeing. I see seven "deliverables", two of which already exist, four of which could be written in the Mediawiki interface (avoiding the need to force users to learn another editing interface, two for editing and one for discussion), and one of which I've never found any evidence of anyone asking for ("Rigid predictable technical restrictions on who can edit what" - in fact, anyone who's dealt with a vandal knows that is contraindicated). None of those deliverables are "eliminate watchlists" or "send an echo notification every time someone edits a watched page", yet based on vague discussion points it's pretty obvious that's where you're going. Some of this is a failure to understand the benefits of existing processes and the weaknesses of new ones. There's a huge leap from the passive watchlists, which whisper to a user that something happened on a page they're interested in but make no demands on their attention, to getting a big flag waved at them every single time a page on their list gets any kind of activity. (For many other wikis, there's the intermediate option of receiving a single email the first time a watched page has some activity, which isn't repeated until or unless the user visits the page while logged in. It has this very nice diff-link that shows them all the changes since the last time they viewed the page. It's not active on large wikis because apparently it would have killed the mail servers, although that might be able to be revisited.)
In other words, there's barely been a case made for developing an entirely new editing interface specifically for "discussion". There has been a good case made for improving the mediawiki interface to do a lot of the things that are on the deliverables list here. (Example: remove the option to sign with anything other than one's username. Would take a few lines of code, or more likely removal of a few lines of code. Just wait until the broader community realises you're taking that away.) Now I know it's a lot of work to clean up mediawiki and improve it, and starting with a brand new interface is easier and a lot more fun, but you've go so very, very little user feedback on what you've created to date that I'm really questioning the basis on which decisions and prioritizations are being made. Risker (talk) 22:28, 28 August 2014 (UTC)
- DannyH, I don't see what you're seeing. I see seven "deliverables", two of which already exist, four of which could be written in the Mediawiki interface (avoiding the need to force users to learn another editing interface, two for editing and one for discussion), and one of which I've never found any evidence of anyone asking for ("Rigid predictable technical restrictions on who can edit what" - in fact, anyone who's dealt with a vandal knows that is contraindicated). None of those deliverables are "eliminate watchlists" or "send an echo notification every time someone edits a watched page", yet based on vague discussion points it's pretty obvious that's where you're going. Some of this is a failure to understand the benefits of existing processes and the weaknesses of new ones. There's a huge leap from the passive watchlists, which whisper to a user that something happened on a page they're interested in but make no demands on their attention, to getting a big flag waved at them every single time a page on their list gets any kind of activity. (For many other wikis, there's the intermediate option of receiving a single email the first time a watched page has some activity, which isn't repeated until or unless the user visits the page while logged in. It has this very nice diff-link that shows them all the changes since the last time they viewed the page. It's not active on large wikis because apparently it would have killed the mail servers, although that might be able to be revisited.)
- I think a lot of the big objectives are actually handled pretty well on the Wikimedia project page. What I've been responding to on this page for the last couple of days are some concerns that people have about specific items in last week's code release. We use an agile software development process that prioritizes making lots of small changes, being flexible in the short-term, and testing assumptions by trying things out and then iterating. In the short-term view, this process can look chaotic. Taking a broader view, it's actually the most effective way to plan a project. You don't waste a lot of time creating pixel-perfect specs for an enormous grand vision, and then realizing a year into production that you've made some mistakes. Instead, we make our mistakes in real-time, and we adjust quickly. You're not under any obligation to follow this process on a weekly basis; I wouldn't if I were you. But those tools are available, for anybody who's super interested in how the sausage is made. DannyH (WMF) (talk) 21:33, 28 August 2014 (UTC)
- Flow was in development for a while before I joined the Foundation in April, so it's absolutely possible that somebody during that history suggested that we wanted to get rid of watchlists or ping people for every single edit on a watchlisted article. All I can tell you is that I don't have any plans to do anything like that. A lot of the discussion that we've had lately about what subscribing to a Flow board should mean has specifically been about making sure that we don't break watchlists.
- The Flow team has two main goals. One is to make discussion on wikis more accessible for new people. That part was easy; we passed that a while ago. The second goal is to make wiki discussions more efficient and more pleasurable for experienced people. That's the thing that we're working on now, and there's still a lot of interesting work to do. You may not agree that that's a worthwhile or an achievable goal. I think it's worth a try. DannyH (WMF) (talk) 03:42, 29 August 2014 (UTC)
- "One is to make discussion on wikis more accessible for new people. That part was easy; we passed that a while ago." Quite a bold statement. Any actual evidence? The few real live test cases I have seen have actually less activity than before they were Flow-enabled. Obviously, they are still just as hard or easy to find as they were before Flow was introduced. Once you have found them, they may be somewhat easier to contribute to, once. But IMO they are harder to actually follow than standard Wikipedia discussions (or than most threaded discussion formats on the internet, with the exception of mailing list logs and IRC logs probably). So what do you really base the "more accessible for new people" on? Fram (talk) 07:04, 29 August 2014 (UTC)
- @DannyH (WMF): I'ld really like an answer to this, as it is rather fundamental. Fram (talk) 20:16, 29 August 2014 (UTC)
Deletion
- A flow talk page can't be deleted directly. Why?
- When deleting the non-talk page part, e.g. Wikipedia:Flow/Developer test page, one gets the option to delete the talk page anyway: this is not consistent with point 1 above
- After deletion, one gets an error: [589656fd] 2014-08-26 13:54:07: Fatal exception of type MWException
- It is impossible at that time to create the talk page (even though talk pages without non-talk page should be possible, e.g. for user pages or some subpages)
- After restoring the main page, the talk page automatically reappears
- The page then had 22 "deleted revisions" at [1], but after restoring them, they seem to have simply gone from the logs (they can't be found in the history, which is of course still deficient).
All this is rather counterintuitive and not really internally consistent. It still looks suspiciously as if Flow pages can be used as large balck holes to get rid for things once and for all... Fram (talk) 14:03, 26 August 2014 (UTC)
- This is an element that we don't need right now -- it's not important for the next set of use cases. We're focusing on the features that we need to build for the next stage, and then move on. So what you're seeing in your test isn't an indication of how this will work later on. This is a huge project that's going to take a little while, so we're being deliberate about what elements we need to build for each iteration. DannyH (WMF) (talk) 19:27, 28 August 2014 (UTC)
Separate notifications for flow updates and user events?
I see a problem in the way the new notification system conflates the functions of Echo and the Watchlist. The previous system issued alerts only for rare events that directly affect the user (direct mentions, comments at your talk page, reverts, links to pages created by you, etc), so I knew that I should review any warning appearing in it. The use case for watching threads is different; I'll have a huge number of watched threads, and I'm not really interested in reviewing everything that appears in it, all the time, only in skimming through it to find something to work on.
Unfortunately, as H-stt explains above, the system doesn't scale to high volume "follow lists": the important warnings risk getting buried among the long list of trivial thread updates.
Now, I can see the benefit of having a single stream for both types of notifications. Is it possible to have it without losing the benefit of the current Echo notifications? What I want is a way to tell apart when there are updates from separate channels, so that I can know when there are new important warnings. Maybe alerts should be highlighted with different colors for warnings (red) and updates to watched topics (green or blue?). Diego (talk) 13:47, 27 August 2014 (UTC)
- There are a few ideas along those lines:
![](https://upload.wikimedia.org/wikipedia/commons/thumb/8/87/CPB_flyout_icons_v2.png/180px-CPB_flyout_icons_v2.png)
- At mw:Compact Personal Bar#Design V2 there are ideas (and 2 Mockup images) around having separate flyouts for each of the 3 main standard workflows - 1) Watchlist 2) "Talk messages" 3) Alerts.
So #2 would cover all of the "discussion" types of notification (replies, mentions, usertalkpage posts). This option has been partially discussed amongst the Flow dev team, and the current "2 tabs in 1 flyout" (as seen on mediawiki, if you have Flow contributions there) is just a temporary setup until a better long-term solution is determined. - At Wikipedia talk:Notifications/Archive 5#Granularity, there was an idea to separate each of the Notification-Types into a separate icon, and only have the icon appear if there was a fresh Notification of that specific type.
For a really active editor, it could look something like:1
3
15
2
And then if I had 0 new notifications, it would be the default single number/icon on grey. - At Wikipedia talk:Notifications/Archive 5#Color-coding the dot, there was a related idea to just color-code the badge/number background, but that's complicated by cultural-nuances of colors, and color-blindness, etc.
- At mw:Compact Personal Bar#Design V2 there are ideas (and 2 Mockup images) around having separate flyouts for each of the 3 main standard workflows - 1) Watchlist 2) "Talk messages" 3) Alerts.
- (Personally: I really like #1, although I want words in addition to icons. I really like some aspects of #2 but I also worry about the variable-width and the potential number of icons if I had many types of new alerts. In the end, I suspect we'll need a combination of #1 and/or #2, plus another option for levels of "watching" a Flow board, which I'll explain in the "too many Echo notifications" thread.)
- Of the 3 ideas above, what do you think are the best/worst aspects? And what other options are there? Quiddity (WMF) (talk) 01:53, 28 August 2014 (UTC)
The best idea is no drastic change; flow updates come in the watchlist, just like every other kind of update. There is no need to invent the wheel again here. Give me an echo if I get pinged on Flow, of perhaps when a topic I started gets deleted or hidden or whatever; but that's it. Color-coding the dot is definitely the worst idea of them all (having multiple dots would at least be better than that). Fram (talk) 07:12, 28 August 2014 (UTC)
- All the notifications will slow down work, even if you can turn it off. At least I will not turn it off (I am too curious) and I will check every time... As it is now - if its really important it is posted on the user talk page (or somebody ping you, or thank for an half year old edit)... Christian75 (talk) 11:25, 28 August 2014 (UTC)
Move doesn't work
Why can't a Flow page be moved? This will need to be corrected before this can be used (if ever). Fram (talk) 07:20, 28 August 2014 (UTC)
- You're right; this is a piece that we have to build. It's not at the top of the list right now, because we won't need it until we move on to a later deployment stage. DannyH (WMF) (talk) 19:22, 28 August 2014 (UTC)
- Let's reverse that, shall we? You should not move to a next deployment stage (however small) unless this is in place (and a few other things, like the rights setup, and some finished idea of how the watchlists and notifications should work, oh, and perhaps finally a history that is working, and ...). Thinking about further deployments should be the last of your worries now. Fram (talk) 06:58, 29 August 2014 (UTC)
- Need or no need, the point is that if you want to convince the community Flow is useful then it will need to actually be functional (as Fram says) before being deployed to a high volume area, as people will notice the missing functionality. BethNaught (talk) 07:10, 29 August 2014 (UTC)
- That is absolutely true, and that's why it's not going to a high volume area yet. Right now, the two use cases we're focusing on are the French WP Forum des nouveaux (their version of the Teahouse), and a new mentorship project on enwiki that just got grant funding. Those are going to be the next stage of Flow deployment, possibly with a third mentorship space that we're talking to. For those projects, there are features that they absolutely need (table of contents, searching on a Flow board, a way to generate new Flow boards on subpages, an update to the hide topic feature), so that's what we're prioritizing for the next month or so. Those projects don't need to move Flow boards, so we're putting that off until the next stage.
- But I totally understand the confusion. I just updated the project page here, I'll start a new thread to explain... DannyH (WMF) (talk) 17:16, 29 August 2014 (UTC)
- "It is absolutely true", but we'll deploy it further anyway. Please, don't agree with me when I say that "you should not move to a next deployment stage (however small)" and go on to tell me that you'll do just that anyway. Testing new software on a new mentoring project is about the worst idea I'v heard here. What they need is a stable environment, where the focus can be on the mentoring. Using such a project as the testing ground for software (which doesn't need a testing grond as there are plenty of show-stopping bugs noted already anyway) is a recipe for disaster. Fram (talk) 19:59, 29 August 2014 (UTC)
- I trust the developers that there will eventually be a "move" function, and that Flow will probably not be rolled out on a wide basis until it's there (although not necessarily working correctly, as some edge cases probably won't be tested). However, the ability to copy between Flow messages and _WikiText_ (not just VE) is a minimum requirement, with most WikiText, including complicated templates, working correctly. I see no indication that that's in the plan. — Arthur Rubin (talk) 01:50, 30 August 2014 (UTC)
Rights
A. Who has the rights now to put an enwiki page in or out of Flow-mode?
B. Who will have the rights to put an enwiki page in or out of Flow mode in the future? Fram (talk) 11:51, 28 August 2014 (UTC)
- Special:ListGroupRights and Special:GlobalGroupPermissions (for stewards, sysadmins and staff) mention Flow, but not about activating flow mode, as it were. I suspect this is currently at database level? BethNaught (talk) 12:05, 28 August 2014 (UTC)
- Right now, only the Flow team can enable/disable Flow pages, which is not sustainable in anything but the shortest of short-terms. The next step is for us to have a special page to enable and disable Flow on pages, which will be tied to a user right. We've done some planning work on this, and we're looking into some ongoing WMF database work that might be blocking this development. DannyH (WMF) (talk) 19:19, 28 August 2014 (UTC)
History and watchlist
At the moment, neither the history nor the watchlist really work for Flow. Any indication when this rather basic functionality will work? Without it, any work on developing Flow is useless, as it is impossible to follow discussions in an easy way. Flow has been prematurely deployed in, what, February, so half a year later one would expect that these most basic of things would be working most of the time. But at the moment, I don't get changes to Flow pages in my watchlist at enwiki, and I do get them in mediawiki, but when I try to see the history from my watchlist, I get a "Fatal exception of type Flow\Exception\FlowException" error.
Problems with these things have been raised from day one, and while the actual problems have changed of the months, they have never really improved, never mind been fixed. This seems to indicate basic flaws with either the concept or the development of Flow. The current "Echo" bombardment problems are only the umpteenth example of the struggle you all seem to have with this. Could you please get back to your drawing board and get this really fixed (I note at Trello that this was opened before Flow was enabled at enwiki, and supposedly solved in April already; I can't remember any time when this truly worked though, you have just replaced one set of bugs with another set... Fram (talk) 07:30, 29 August 2014 (UTC)
- Thanks for reporting the bug about the history link in the watchlist. I just checked it out -- it's actually only happening for hidden topics (as far as I could tell). Other history links in the watchlist work correctly. I filed a bug ticket for this, and it'll be fixed soon.
- However -- I am seeing topics that I'm subscribed to on my enwiki watchlist. They're now in the form "Topic title on Talk:Board name" -- maybe you're looking for the old-style items? Let me know what you see -- it might be a bug that isn't happening to me, for whatever reason.
- In more general terms, bugs are always a part of software development. It's absolutely impossible to build software that doesn't get at least occasional bugs, especially during a stage when there's fast-moving, active development. They're not good, obviously, and they need to get tracked down and fixed, but they're also not a harbinger of disaster. :) I appreciate that you're helping us identify bugs when you see them. DannyH (WMF) (talk) 17:07, 29 August 2014 (UTC)
- I note that you are copying the style of testing that the VE people from the WMF also use. Not a good development. Generally, you are rapidly losing the trust that the earlier WMF people discussing Flow had slowly built.
- The bug about the history link is not only happening for hidden topics (which would be bad enough), it happens for e.g. this topic when I click "hist" in my watchlist. Note also that in general, there is no possibility to see the state of a topic (never mind a complete talk page) at a certain moment in time anymore. Not good... But on the plus side, we get countless "topic" links, one on every line of this page, which are utterly useless since you are already at that topic. Good UI!
- "I am seeing topics that I'm subscribed to on my enwiki watchlist". Good for you. I'm watching Wikipedia talk:Flow/Developer test page, the whole page, like I have done since the start, and I don't see anything on my watchlist except for my own attempts to delete it. Ah, and now my edit to the header as well. Anything else? Nope, no new topics, nothing. Isn't the purpose of adding a page to your watchlist that you see when e.g. a new topic or section is added?
- In more general terms, I have to agree, major bugs are alwayzs a part of WMF software development. "Fast-moving, active development"? Well, I don't see much "fast-moving development", and "active" development is rather superfluous, passive development would be a novelty.
- VE had the same "thanks for noting the bugs, don't expect us to draw any conclusions or change or plans accordingly though" attitude. Hasn't the WMF learned anything from VE, MV, and so on? Fram (talk) 19:54, 29 August 2014 (UTC)
Updated information
I've just updated the WP talk:Flow page with a lot of new information, including the rough plan of our quarterly goals for the next year.
I have to apologize -- this is a page that we updated on Mediawiki earlier this month, with the intention that we'd mirror the new version here, and I forgot to actually do that, because apparently I am a genius. So I was very confused yesterday, when Risker said that the page here didn't have information about what we're working on. I thought I'd already copied over the updated version.
So -- I'm very sorry about the confusion there. Totally my fault, and I feel vaguely foolish about it. On the plus side -- lots of updates on the page! If you're interested, please take a look, and I'm happy to hear what you think and answer questions. Thanks! DannyH (WMF) (talk) 17:22, 29 August 2014 (UTC)
- "Done Subscribing to Flow board = notifications for new topics on that board" Doesn't work
- "Done Roll-up notifications for activity, one notification item per topic" Not wanted (next ones all related, so...)
- "Done Log item improvements for Watchlist and Contributions" Doesn't work, never did
Simply showing all changes to a board since last visis is still impossible. Simply getting the watchlist to display whether a Flow board has changed since the last visit is impossible. These aren't planned for the next year apparently. Are people at the WMF even aware that these are a problem?
A rollout to articles on enwiki in Q4 is a completely absurd idea but a very good way to create the next WMF-community clash. The WMF devs still seem to live in cloud-cuckoo land, or they have to meet some unrealistic deadlines to keep their jobs, or some other unsavoury reason lies behind all this, whatever, but this is just the same old nonsense. Has any destructive testing been done yet? I know I have done it once and broke the watchlist of a serious number of people here, with an act that any vandal could have done very easily. Is it really that kind of untested software that you want to release to talk pages or a brand new moderation project? Please no. Fram (talk) 20:15, 29 August 2014 (UTC)
Mathematics problems
Is mathematics supposed to be working? At mw:Talk:Sandbox, I found myself unable to reply (clicking reply did nothing) with a <math>...</math> formula: I could create a comment with maths in but the formula doesn't appear in the comment. This looks rather like the situation from last October [2] -- not identical, perhaps, but the executive summary is that mathematics markup under Flow is not fit for purpose. Sigh. Deltahedron (talk) 19:29, 29 August 2014 (UTC)
- Yes it should be. It was working before (even a week ago, as you saw at mw:Topic on Talk:Sandbox), so this is a new bug. I've filed bugzilla:70187 after replicating it. Thanks as always. Quiddity (WMF) (talk) 20:37, 29 August 2014 (UTC)
- Thanks. Just my bad luck to come back after a year and hit a time when it isn't working again, I suppose. Deltahedron (talk) 20:41, 29 August 2014 (UTC)
Wiki misconceptions
There are some important issues in the current design of Flow related to talk page mechanics which I would like to bring to people's attention:
- Maximum level three indent. Almost every discussion in Wikipedia goes past that level and if it bottoms out at three then separate threads in a conversation become lost and hard to work through. The assumption that such threads should be split off is often not true.
- No custom sigs. There is no evidence I've seen that they are causing a problem. Personally I'm ambivalent, but they are a popular and longstanding feature and any attempt to remove them will cause a massive stink.
- No refactoring of posts except by admins. This could cause serious problems – what if a serious issue arises in a post and it needs to be redacted (legally dangerous libel, highly offensive and upsetting personal attacks) but there's no admin around? How can individual comments by a banned editor or a troll be removed? I am aware there is a hide function, but that is not total removal and that doesn't account for editing. In the words of Jimmy Wales (with whom I do agree on this matter) it "is a bad idea for a lot of very deep wiki reasons".
I think the community needs to discuss the reality of wiki discussion mechanisms here more to help the WMF develop a more effective model for Flow, and the WMF needs to be less keen on major talk page dynamic changes without community approval – since it is the community who will be doing discussion with it. BethNaught (talk) 21:57, 29 August 2014 (UTC)
- Commenting on BethNaught's issues above:
- I agree completely. Indentation in discussions is incredibly useful to knowing who is responding to what, and reducing the threading level to three may not be helpful, even when it's just a small number of people talking. Even back-and-forth between two just two editors can go beyond three levels.
- I did see that the team brought up some arguments here about HTML causing display and formatting issues. Have signatures ever been enabled on Flow and if so, what problems did you find? I acknowledge from usability standpoint, the fact that links to user/talk page/contributions can appear in different places in one's sig is a bit strange, but all a new editor has to do is click on it to see where it takes them. There is also a very human element to signature customization that would be an unfortunate loss from a community standpoint.
- I think the question of who can refactor things is still somewhat open, and I don't think any permanent decisions have been made about that just now. In fact, here under Post moderation, they write:
"Hide", "Delete" and "Suppress" - analogous to revert, revision-deletion and oversight - are current features for Flow, and will be present before the first deployment on Wikipedia. Users will also have the ability to delete/suppress entire threads.
- with the addition comments of:
Flow currently includes a version of these features (as of August 2014). However, we're not completely satisifed with how "hidden" and "deleted" discussions are displayed on the Flow board; we'll come back for another revision before the end of the year.
- So, it seems there is a plan to make sure comments can be deleted by editors, not just admins. It looks like they tried to implement this in an earlier stage, but it wasn't working so well, so they are probably back at the drawing board for the time being. I, JethroBT drop me a line 22:56, 29 August 2014 (UTC)
- Hi, Beth -- I think I can answer some of those concerns.
- First, just to clarify why we're prioritizing some pieces ahead of others -- There is a big list of features and requirements for Flow, if it's going to do all of the things that we'd like it to do. You can see some of that on the Wikipedia:Flow page under the quarterly goals -- but even that is a condensed list. We have lots of ideas. So for this next stage, we've chosen specific places where we're talking to the community about trying out Flow. The two places where we'll (almost) definitely roll out are the French WP Forum des nouveaux (the French version of enwiki's Teahouse) and a new mentorship project called the Co-Op, an enwiki community project that just got grant funding. There are a couple similar mentorship spaces around the wikiverse where we're talking to the folks who work on them. So with those use cases in mind, we're working on features that they need (search, table of contents, a better version of the moderation actions, the ability to create Flow boards as sub-pages), and we're putting off building features for other use cases.
- So, for example -- people have pointed out that Flow isn't good enough to be on a Village pump right now, or an RfC-style structured discussion, or other high-volume areas. That is correct, and that's why we're not planning to go there until we've passed through several of these use case stages. RfCs is actually one of the most complex use cases, so it'll be a while before we tackle some of the features that we would need. Basically -- we're building Flow to handle the simple conversations first, and once we nail those, we move on to more challenging areas.
- Here's where we are with the three items you mentioned...
- Indented replies: There are two big reasons why we use indenting on wiki talk pages. One is a workaround for a deficiency in wiki talk pages -- most discussion systems automatically display people's posts in a way that makes it clear visually where one person's message ends and the next one begins. Using colons to indent is a workaround that has become the culturally accepted default. In Flow, we don't need to use indenting in order to separate people's posts visually -- the board does that automatically.
- The other use for indenting is, as you said, to allow for branching discussions on big, complicated conversations, especially RfC-style consensus/voting conversations. That is a very important part of those kinds of complex discussions, and we won't be able to use Flow for those kinds of use cases until we have a way to handle those branching discussions better. The level of indenting that we have right now is appropriate for the simpler one-on-one and group conversations that we're focusing on in this stage. We have some big-picture ideas for how to handle the more structured branching discussions, but it's a ways off.
- Custom signatures: Custom sigs are another beloved workaround that grew because the system doesn't sign your posts for you. The basic system that you see on Flow right now automatically signs and dates a message, which at least means we don't have to deal with the headache of unsigned templates and teaching newbies to add four tildes.
- But one of the good things about custom signatures is that you get to change the name that you sign -- for example, my personal account is User:Toughpigs, but my custom signature is [[User:Toughpigs|Danny]]. We are definitely talking about building a "preferred name" into Flow signatures, possibly something like Danny (Toughpigs) in my case, where Danny comes from a preferred name field that I fill out somewhere. The only reason why we haven't planned for that yet is that a preferred name would be useful for a few different Wikimedia projects, and we have to discuss it with some other product teams to make sure it works for all of us.
- The other stuff that people use in their custom sigs -- colors, sparkles, catchphrases, etc -- that's a very controversial subject among the Flow team. Those elements can add a lot of personality and fun. They can also get really annoying if they're not done right. So we're punting on those until we get a clear mandate from the people. :)
- Hiding/refactoring: There's a few different elements here. The basic functionality that we absolutely need to provide (and we don't quite do it correctly yet) is the ability of any user to take obvious spam and vandalism off the page. That stuff happens, and the best way to deal with it is the way that wikis always have -- if you see something bad on a page, then you hit the edit button and clean it up, without having to go and report it to someone else. The bad thing is still accessible in the history, and people have the ability to undo your edit if it wasn't actually that bad after all.
- So we've got a Hide function right now, and any user can hide a bad topic, or a single bad message within a conversation. The problem is that the first version that we built doesn't actually hide things enough -- it leaves a big clickable button on the page that basically shouts "come look at the bad thing!" The next version, which you'll probably see in a few weeks or so, will actually take the hidden thing off the page, so that it's still accessible in the history but not on the page anymore. We're also going to add undo and rollback functionality on the thread and board history pages.
- The other piece is the ability to edit other people's messages. Flow doesn't allow this right now, but I know it's something that we have to address. The most basic use case is that somebody includes a link that doesn't work, and it's nice if someone else can fix it. We're talking about a few different ways that we can address that, but we haven't found the perfect idea yet. It would be great to talk to you more about it, if you're passionate on that subject. I'd love to have another person to bounce some of these ideas off.
- Anyway -- I hope that was a helpful look behind the scenes a little bit. As we get into the next stage of development, I'm going to be doing a lot more of this kind of thing -- getting ideas, answering questions, bringing interested people into the process more. If you're really interested in the ins and outs, we're using the public EE mailing list for a lot of discussions about what we're working on. You should feel free to join that list, or let me know what you think here on the wiki. Thanks! DannyH (WMF) (talk) 23:19, 29 August 2014 (UTC)
- DannyH (WMF), what's so difficult about indenting to more than three levels? That's really, really, really basic functionality others have solved long ago. Look at Reddit. My advice would be don't even think about bringing anything to the community until you have replicated that functionality. You'll be a laughing stock or worse, and rightly so. Andreas JN466 00:40, 30 August 2014 (UTC)
- Jayen466: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --Jorm (WMF) (talk) 00:47, 30 August 2014 (UTC)
- So Flow is designed for mobile use? Do you expect people to do encyclopedic work while standing in the subway with their mobile phone? Fair enough, occasionally one might want to fire off a talk page reply in such a situation, but then I think it would be rather better to cater for that situation by having mobiles display the talk page indents differently, perhaps with micro indents. Does anyone know what Reddit threads look like on a mobile? Andreas JN466 01:46, 30 August 2014 (UTC)
- Having borrowed a mobile, I find that Reddit looks much the same there as it does on a desktop computer. And it's perfectly usable, infinite indentation and all. (By the way, one thing I really like about Reddit is that when two people go on and on replying to each other ad infinitum, eventually, after 10 indents or so, Reddit will just put an arrow link to a new subpage.) I honestly don't see the problem. Andreas JN466 02:05, 30 August 2014 (UTC)
- Jayen466: Infinite indentation simply does not work in a mobile context. In order for Flow to be successful (e.g., "meet its design goals"), it needs to work for the future, and not only for the past. --Jorm (WMF) (talk) 00:47, 30 August 2014 (UTC)
- DannyH (WMF), what's so difficult about indenting to more than three levels? That's really, really, really basic functionality others have solved long ago. Look at Reddit. My advice would be don't even think about bringing anything to the community until you have replicated that functionality. You'll be a laughing stock or worse, and rightly so. Andreas JN466 00:40, 30 August 2014 (UTC)
- Anyway -- I hope that was a helpful look behind the scenes a little bit. As we get into the next stage of development, I'm going to be doing a lot more of this kind of thing -- getting ideas, answering questions, bringing interested people into the process more. If you're really interested in the ins and outs, we're using the public EE mailing list for a lot of discussions about what we're working on. You should feel free to join that list, or let me know what you think here on the wiki. Thanks! DannyH (WMF) (talk) 23:19, 29 August 2014 (UTC)