On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn &lt;schneeschmelze(a)googlemail.com&gt; wrote: Flow has to be improved further until reaching a state where it will be deployed generally. That tipping point is not going to be soon, and will be at different times on various wikis. During the process of getting there, the team needs as much patient and insightful feedback as we can collectively give them, regarding what existing features we need to match (along with examples and edge-cases) and what new features we'd love to have created. It aims to result in something better for newcomers *and* better for all types of poweruser. Just like VE, it's an epic-scale and long-term project, that has to be deployed step by step as VE should have been instead of its quick early introduction. Slow and steady feedback at the talkpage <https://www.mediawiki.org/wiki/Talk:Flow>, over the months and years ahead, is much appreciated. -- Quiddity / Nick Community Liaison

2014-06-06 22:28 GMT+02:00 S Page &lt;spage(a)wikimedia.org&gt;rg>: I am sorry, S, this is certainly not what I intended. I apologise for the tone of my last mail. The most important point about everything new the WMF is currently developing is that it really can frustrate and drive away even more old editors. The WMF only talks about new editors, but does not take into account that we need to keep the old ones in the first place. @Gerard: Losing old editors is the biggest cost of all those changes. This is why we have to keep these as small as possible and we have to avoid them wherever possible. There always has to be a switch for disabling everything new and to return to the old state. To give you some more background: Our community has suffered a lot of stress over the past years which results in frustration in many places. Many long-time editors have gone inactive because of that. Some of the stress is self-made, some came in from the German chapter, mostly last year (this will hopefully change now), and some of the stress comes from San Francisco. The latter stems mostly from new developments in technical terms. Remember that this is only a small community of only a few hundred regulars, and that we had to fight against visual editor, and when media viewer was announced the first question was whether it would still be possible to switch it off when it would not be beta any more. Many of us are exhausted and tired to fight against the Wikimedia bodies. That's why I interfere when there is talk about Flow. Both visual editor and flow have the potential of providing another and perhaps final blow to the still active old editor community. There is only one community. We don't have another one as substitutes to take over. If a wiki project is dead and broken once it will be broken forever. Regards, Jürgen.

2014-06-07 2:44 GMT+02:00 Arcane 21 &lt;arcane(a)live.com&gt;om>: Again, I would like to invite you to think twice. I talked about the psychological foundation for participating in such a large project as Wikipedia. It needs tact not to harm an already suffering community when such sweeping changes should be introduced. No one has ever asked for our opinion whether we want this or not. It is decided over our head, par ordre de mufti. Most of us insist on community processes taking place for introducing new technology on such a big scale, not in order to deactivate it. Again, this is all about breaking a community. And we cannot discuss this in terms of what is good or bad because you cannot revert the negative impact new technology will have on old editors. This is not only about technology. It's about psychology. And the latter will prevail. Regards, Jürgen.

2014-06-07 3:11 GMT+02:00 Max Semenik &lt;maxsem.wiki(a)gmail.com&gt;om>: To sum it up for tonight, I was speaking about tact and psychology in the first place. And I said that this is not about some old-timers, but about the bulk of our community. The heart of this project is comprised of some 300 to 400 editors you cannot substitute. Regards, Jürgen.

Dear Anne, Thank you for the thoughtful critique. Indeed, Flow is designed to address these issues, as well as others: - Overall reduced user experience latency (time spent loading pages, positioning the cursor, typing characters, etc.). - Support for cross-wiki discussions, to reduce fragmentation of conversations. - Better tools for organizing (e.g. tagging) and searching conversations. - Making it easy to see what's new/changed, irrespective of watchlisting. - Simple ways to participate in relevant conversations on mobile devices. The architecture reflects these combined needs. While it is possible to incrementally hack away at a single wikitext representation of an entire discussion, logically, without clear boundaries for each comment, any kind of functionality that operates at the comment-level is difficult or impossible to build. With that said, we will likely experiment with improvements to the existing talk page model as well, just to see how far we can push it. The mobile apps team is interested in implementing talk page support in the apps, and since Flow is still some way out, that may be a good case study to see what we can do on the basis of the existing wikitext conversational model. Flow is intended to be a system that is effective both for new and experienced users. Everyone working on the system understands that it cannot succeed if it doesn't serve the needs of experienced users. This is why we're intentionally designing it in the context of a gradually increasing number of real-world use cases. As an example, the Teahouse would be an interesting real-world use case where both new and experienced users interact. Longer term, high volume pages like Village Pumps may make for good use cases. We can measure and compare the characteristics of conversations in such venues over time. At the most basic level, how many new and experienced users participate? At the more granular level, how long does it take users to perform tasks? Only if Flow compares well to other methods of organizing talk pages, should it be used. The WMF technical staff is a pretty healthy mix of people with prior Wikimedia editing experience, people who became Wikimedians on the job, people who contributed to MediaWiki before, people who've not contributed to MediaWiki but who've been part of other open source efforts, and people who're completely new to both Wikimedia and open source. I'll let them speak for whether they like wikis or MediaWiki core, but I think a love/hate relationship with both is not uncommon nor unwarranted. ;-) Flow stores the comments as a structured tree, so it's possible to build different interfaces for it. I personally don't have a strong opinion in the threaded vs. flat vs. hybrid debate -- I think we should pick the system that proves effective and that users will adopt and embrace. When I originally proposed the (now doomed) LQT effort nearly 10 years ago ( https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 ), I defaulted to a thread view, because that's what I was familiar with from the forums that I used. Many very successful forums use either approach. A strong argument in favor of a flat, chronological view is that it is just that -- it lets you easily see the most recent comments. Structure is then supplemented by quoting comments, as I'm doing in this email, which my mail client renders as part of a flat, chronologically ordered conversation. In a long thread that spans multiple screens, quickly noticing the comments that have been added after a certain date is otherwise difficult. LQT's implementation actually tries to solve for this -- LQT does deep threading, and you can track the history of an entire thread, with highlighting of when comments have been added: https://www.mediawiki.org/w/index.php?title=Thread:Project:Support_desk/hel… Flow, which displays threads with a limited depth, currently shows the history as a meta-structure, which then gives you access to the individual comments. https://www.mediawiki.org/w/index.php?title=Talk:Flow&workflow=rvzy5wgx… Neither user experience feels efficient (nor does mentally parsing a wikitext diff). It may be possible to create intuitive ways to display change over time in a thread view -- if folks have seen examples of that, I'd love to see them. With that said, rather than maintaining that any given display is inherently superior, or that a fundamental change is inherently bad, I think we should formulate changes as testable hypotheses to the greatest extent possible. Are we increasing readability? Are we improving the quality of conversations? Are we enabling people to participate who otherwise would not? Flow doesn't yet have any kind of quoting functionality, which I think would be necessary to add even if we ultimately commit to a deeply threaded default display. It's a hybrid model with limited thread depth, which arguably gives us some of the drawbacks of threading (no clear chronological structure) with some of the drawbacks of flat forums (no consistent reply-level structure). Danny (Flow PM) very much wants to test different user experiences; it's even possible that the "best" experience will vary by use case. The current archiving system for talk pages is an adequate way to retain the history of conversations, but it doesn't actually make it very accessible. I can't easily see all posts by a certain author, for example, and individual threads cannot be categorized or tagged. Summaries, to the extent that they exist, don't automatically surface in relevant places. Suffice it to say that one of the design goals of the Flow project is very much to build a searchable and understandable history of conversations. We will want to test different mechanisms and see how well they function to manage large conversational archives, including intuitive search tools, tagging of specific threads, etc. The current "comment corpses" have already been identified as an issue and we'll experiment with different ways to manage hiding/deletion of comments. There's an "Edit" button which pops up next to the header when mousing over it. I agree that discoverability could be improved, and this UI pattern is also not mobile-friendly. LQT solved this through [Edit↑] [History↑] [Delete↑] links right next to the header. This is absolutely a fair criticism -- there are pretty significant silo effects in the current org, and mechanisms and venues for cross-functional conversation and cross-team mobility are lacking. These are common organizational challenges at times of fast growth, and ones we're tackling on multiple fronts right now. Specifically with regard to Flow: - Flow was always designed with VisualEditor in mind, and already uses Parsoid as its parser. Having many mini-VE invocations on a single page is not entirely trivial, but a challenge the team absolutely wants to take on (currently slated for Q2 in the next fiscal). - Jon Robson from the Mobile Web team will soon begin day-to-day work with Flow to help the team develop in a more mobile-oriented fashion, and also to share code/templates to the greatest extent possible (currently through an extension shared by both projects). - The Mobile Web team has recently ported VisualEditor to the tablet user experience in alpha mode, and in the process, helped uncover and address issues with VisualEditor's libraries and development assumptions. - We're looking into the best ways to resource the mediawiki.ui efforts for better integration of standard utility libraries, frameworks, assets, and templates in MediaWiki core, to ensure better standardization of the user experience. The main product lines have a pretty clear common through line: enabling more users to become part of Wikimedia projects and enabling existing users to work more effectively, by modernizing the user experience, in partnership with the community. We tend to err on the side of being bold, but we're also prepared to walk back when we move too quickly or haven't paid sufficient attention to concerns. All best, Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

Oops, sent too soon. More comments below. On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: That seems a fundamental mistake. A discussion isn't a tree, it's a dag at best. It's possible for a single comment in a discussion to refer to zero or more earlier comments, and it's also possible for a single comment to refer to part of an earlier comment, which means a comment isn't an indivisable node. If it's sturctured as a tree, you won't be able to catch all context, ever. Indeed, following the wiki model, it should be ok to make technical mistakes, and those mistakes should be easily fixed by someone else. If you mess up the graph in an edit, it should not only be possible to fix that after the fact, but easy. --Martijn

On 8 Jun 2014, at 17:22, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: — Krinkle Throughout the years I've had to use at many different incarnations of conversation workflows. Such as: * Inline comments (such as on StackOverflow). * Issues trackers (like Bugzila or GitHub Issues). * Mailing threads (as rendered by Gmail or Apple Mail, both for 1-on-1 threads and those from mailing lists). * Helpdesk ticket systems. * Disqus. * Feedback systems (like GetSatisfaction and UserEcho). * WordPress comments. * LiquidThreads. * Your typical 90s-style forum board (like phpBB or vBulletin). * .. And I can't really come to any conclusion other than that the user experience is significantly worse when any of these used a tree structure (especially LiquidThreads and forum boards). It always ends up a mess. Fortunately, most of these have now either exclusively opted for a linear model or have an option to view it as a linear model (I think LiquidThread is the only exception on this list). Some systems, like Disqus and WordPress comments, handle it by only allowing a very limited number of nesting levels, though I'm not convinced this is useful. I agree with James and feel that having a good system for citing would significantly increase user experience more than any tree structure ever would (and having a tree of any kind always negatively impacts user experience). -- Timo

Can I just chime in briefly and say I am glad this conversation is happening before Flow goes into production. This is the kind of conversation that leads to better software, especially when power users participate in the discussion and influence design decisions long before software is pushed out the door, and when production team members take the time to thoughtfully engage in the discussion as they are here. Thanks all. Pine On Sun, Jun 8, 2014 at 11:42 PM, Federico Leva (Nemo) &lt;nemowiki(a)gmail.com&gt; wrote: -- Pine

On Sun, Jun 8, 2014 at 8:22 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: That takes care of the issues of replying to one comment (a new node in an existing tree), zero comments (a new root node), but not multiple comments (which would break the tree). Current MediaWiki talk pages do this, as well as mailing lists. That's precisely my point. Because current talk page discussions are - on the software level - unstructured, it allows social conventions to do everything you want it to do structure wise, and to invent new uses as we go. The domain model is just that complicated that we found that we need that power in implementation (even if we all(tm)[citation needed] agree that the current discussion form is pretty horrible UI wise). If you're going to force a software structure on in it will most likely not be as powerful[1] as what there is now and represents a trade off without us having a clear sight of what we will lose, even if we can have a somewhat clear picture of what we will gain: easier use and navigatability for the kinds of discussions we do support. Discussing a trade off where only one side is known is hard. [1] i.e. a tree structure is far less powerful than what we have now to approximate the domain, a dag with dividable nodes probably comes closer, and is already fiendishly complicated to pull off on a UI level. And then I haven't even gone in to the current practices of taking a comment back by striking it, which means that nodes aren't only arbitrarily and multiply dividable, but also mutable over time in a linear(?) history? 'sblood man, discussions are complicated. -- Martijn

Am 09.06.2014 11:42, schrieb David Gerard: or Etherpad

[beating my own drum:] Indeed, I have a working (rough draft of) realtime collaborative editing at https://www.mediawiki.org/wiki/Extension:TogetherJS. It is quite an interesting UX when you allow realtime "writing at" each other in this form. Old-timers will remember "ytalk" chats as a very different sort of discussion, with its own conventions. At wikimania Erik and I will be presenting two sequential talks (or maybe one combined talk, TBD) on real-time collaborative mediawiki editing, and what it would look and feel like and how that would affect community interactions. (As a brief plug: I would like to make WP feel more like an active community of *people* and less like a sterile collection of pages authored by some invisible cabal; from some previous threads about the "last edit" banner on mobile I'm sure there are some who prefer the anonymous font of knowledge look. But ultimately for real-time collaboration to be useful, a prospective editor needs to find someone to collaborate with...) Among the interesting issues is how to handle fine-grained attribution of content/changes in a real-time collaboration. This might also influence how we feel about fine-grained attribution of comments in a larger talk page. I look forward to hearing ideas and discussion. --scott [weighing in on the nesting/quoting bikeshed: the structured quoting which Simple Machines Forum (SMF) provides is a nice compromise: it preserves the exact origin of the quoted material, for easy backreference, but it also allows flexible editing of the quoted content and for combining multiple quotations into a single response.]

On Mon, Jun 9, 2014 at 9:56 AM, Nathan &lt;nawrich(a)gmail.com&gt; wrote: The assumption I am making is that Flow will (not may, or aims to, but will) replace all current discussion mechanisms on all(?) Wikipedias[1], and possibly all other WikiMedia projects as well, and that if that happens, we should know which trade-offs we are making when we're doing away with the virtual unlimited structuring power before we do. So I think a much better goal, and one that I know others share and has yes, please! But again, at what cost? What are the possibilities we are going to lose when Flow is turned on? Will we know before it's turned on? Should we discuss it before it's turned on? I would think so. We're talking about taking away most power of our current discussion system, and since it's a social system rather than a technical system, it's difficult to define all ways we are currently using it, and how valuable each of those ways is. This is simply insufficient. If Flow replaces all talk, all processes will have to be re-tailored to use Flow. AfD, RfA, ArbCom proceedings, mediation, Sockpuppet investigations, FA evaluations, RfCs, they will all become Flow. While it is very important that we have a mechanism that is easy to use, it must be powerful enough to accommodate all these processes. They're going to need re-engineering, but I'm afraid that in some cases we will lose more than we'll be willing to swallow in order to make other discussions easier to participate in. I'm not only willing but very much hoping I will be proven wrong. But from where I'm standing, with the only possible exception of AfD and SPI, I can't see yet how tree-based software will handle these processes. It would be interesting to see a random RfA, ArbCom case, mediation case, and FA nom and an RfC being "flowified", so we can take a look how the new processes will work on a techinical level, and what problems turn up. [1] http://www.mediawiki.org/wiki/Flow: "Flow is a project of the Core features <http://www.mediawiki.org/wiki/Core_features> team at the Wikimedia Foundation to build a modern discussion and collaboration system for all Wikimedia projects. Flow will eventually replace the current Wikipedia talk page system"

On Mon, Jun 9, 2014 at 12:12 PM, Risker &lt;risker.wp(a)gmail.com&gt; wrote: Hey Anne, We're of course pretty familiar with many of the highly specialized workflows that exist across wikis, and have had lots of conversations about how/when we could improve such workflows. Brandon originally titled the system "Flow" because of precisely that reason - the idea that Flow would provide building blocks through which workflows can be created, much the same way that an ordinary wiki page provides a very flexible mechanism by which users can create their own workflows. To keep the project manageable, however, I recommend a more staged approach: Solving for discrete use cases that can reasonably be solved with a new user experience, testing/validating whether the new user experience is in fact superior to the old one, and iterating from there. In this process we need to be wary of UX fragmentation -- but I think this is reasonably manageable as long as we're careful how we're staging use cases (e.g. I don't think it's unreasonable for a page like the Teahouse to have a different UX than an ordinary article talk page). Danny knows that I'm worried about the user talk page use case (called out in the goals) in that respect, because it represents a possible major fragmentation (old user talk vs. new user talk). My recommendation so far has been to target use cases where there exists local consensus to support them _and_ fragmentation of the user experience can be avoided. Beyond just managing scope, I think it's important to recognize that wiki-based workflows like AfD and RFCs are built around what a wiki allows you to do. If it's easy to tag comments/threads in such a way that they show up on relevant noticeboards, this may enable completely new workflows that are significantly simpler. So I think we need to be careful when modeling a new user experience to not just try to "copy the old one, but better". We may find that users actually like some of the capabilities a new tool creates, just like Echo's completely new, never-asked-for mention notifications became very popular, very quickly. :) It's absolutely true that Flow is a risky project, but it's not true that it's designed to solve problems nobody's asked to be solved. You yourself quoted some of the issues with talk pages. And did you attend Jimmy's talk at Wikimania (I think 2012) about how difficult it is to perform simple tasks in the wiki precisely because every workflow is wiki-based? I absolutely want to make sure that WMF solves real problems and not just imagined ones -- but you'll need to allow for people in WMF to have reasonable debates (with each other, and with the community) about what the solutions could look like, and to try different approaches. It's indeed a complex migration that needs to be done carefully, as any issues would be difficult to resolve/debug and could cause massive angst. And it needs to involve people with deep Wikimedia subject matter expertise, and folks from the MediaWiki core team. Engineers aren't fungible -- we have to schedule a project like that with the folks who're best suited and most interested in working on it, and that's what we're doing. But we've scheduled it, and we'll take that commitment seriously, so please do hold our feet to the fire if we try to kick the can down the road. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

On Mon, Jun 9, 2014 at 11:14 PM, Pine W &lt;wiki.pine(a)gmail.com&gt; wrote: *nod* The watchlist is an awesome tool, and there's so much more we could do with it. :) I like the theme Danny's proposed for the first quarter work on Flow: "Never miss a message". When Flow begins to deliver on that promise, I think power users will start seeing some of the advantages such a system affords. Please don't hesitate to note requests/suggestions on the Talk:Flow page here: https://www.mediawiki.org/wiki/Talk:Flow And please comment on the overall roadmap here: https://www.mediawiki.org/wiki/Talk:Wikimedia_Engineering/2014-15_Goals Thanks :) Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

On Tue, Jun 10, 2014 at 1:09 AM, Thomas Gries &lt;mail(a)tgries.de&gt; wrote: It already has basic notifications, yes. Enable the overly literally labeled "Flow" email notification type your user preferences, leave a comment in the sandbox, get the sock puppets out and watch the fireworks: https://www.mediawiki.org/wiki/Special:Preferences#mw-prefsection-echo https://www.mediawiki.org/wiki/Talk:Sandbox -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

So, LiquidThreads. :) If most of the discussion goes around tree structure discussions, and how some advanced users find wikitext's free form to be an advantage, maybe we can agree on certain points based on where exactly is LiquidThreads being used. * User talk pages. Do we need multithread tree discussions in our user talk pages? No, we don't. * Regular talk pages. In most cases a section gets 2-5 replies at most. The benefit of a simple entry point for newcomers and junior editors clearly surpasses the potential inconvenience for some vets, especially if our priority is to be welcoming and open to diversity of people and opinions. * Forums open to new / junior editors like https://www.mediawiki.org/wiki/Project:Support_desk . If you notice the number of replies per thread, you will see that almost always they keep themselves under 10 posts, so I don't envision major problems if we move those to Flow as well. * Hardcore forums for insiders. I wonder if there is any using LQT nowadays, the ones that come to mind are based on pure Wikitext, and in fact they are not even in a *Talk namespace. Therefore, even if Flow would be powering 100% of the talk pages in Wikimedia wikis, it would be still a decision of these forums to decide whether they want to stay with Wikitext or use Flow. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

On Tue, Jun 10, 2014 at 10:34 AM, Quim Gil &lt;qgil(a)wikimedia.org&gt; wrote: {{citation needed}} I suspect this is just like the point below. Until some complex discussion happens and Flow's lack of threading makes it nearly impossible to actually follow divergent subthreads. It's bad enough in something like Gmail where quoting is used extensively to supply the needed context, and Flow currently has no automatic support for quoting. I suspect this would quickly turn into an argument based on "Everything else uses Flow, this should too!"

On 9 June 2014 02:30, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: Really? Hello | +- Hey! | +-+- Wow! | | | +-+- I know! | | | +-+- I'm here too! | | | | | +- It's wonderful! | | | +-+- Crazy, right? | +- Yeah. … J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On 9 June 2014 11:12, Martijn Hoekstra &lt;martijnhoekstra(a)gmail.com&gt; wrote: … You think people want dual inheritance for comments? Seriously? That's… (to be polite) completely insane as a discussion system from a user perspective, and perhaps more importantly for your argument, completely not something that happens right now in MediaWiki conversations. J. -- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

On Mon, Jun 9, 2014 at 11:20 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: You generally see them in the form ::@namex @namey @namez Lorem ipsum

On Mon, Jun 9, 2014 at 11:33 AM, James Forrester &lt;jforrester(a)wikimedia.org&gt; wrote: Yes, I have no idea how to display a DAG in an orderly fashion, let alone make it usable for an end user in a discussion system. In this case, which post are you replying to in flow when you reply to multiple people? In mediawiki you sort of work around the issue, and it sort of works because you try to create some ad-hoc solution. When the software creates a hard dependency between posts, where it is difficult now to keep track of these kinds of discussion, it may become even more difficult to follow them then. Since we've established that this is something that currently does happen, I think even if it is (to be polite (?)) completely insane, it's something that should be supported anyway. -- Martijn

On 9 Jun 2014, at 20:58, Bartosz Dziewoński &lt;matma.rex(a)gmail.com&gt; wrote: I have used many different desktop and mobile e-mail applications that aren't web based. The last time I've seen it displayed threaded instead of flattened by default was when I installed Microsoft Office on Windows 98 SE which hid Outlook Express and intruced Microsoft Outlook and with it it exposed me to threaded display of mailing lists[1]. Every other mail client I've used did not do this (not for mailing lists, not for regular inbox). Outlook Express, Eudora, Thunderbird, Apple Mail and various web-based clients. These different clients may have carried over my preferences, but they all had an option to display it flattened. And I believe it was the default. While we may or may not know what the default was, I'm pretty sure that "most e-mail clients display discussions in a threaded fashion" is pertinently not true. -- Krinkle [1] Would've roughly looked like this: http://i.imgur.com/fK1NV2G.png