The Flow team is going to work in a few weeks on automatically archiving talk pages, so that we can enable Flow on pages where there are already existing conversations. Basically, this means moving the old discussions on an archive page, and leaving a link for "See archived talk page" visible on the new Flow board.
That means there'll be a minute where a currently active discussion would get interrupted, and have to be restarted on the new Flow board. That will be a pain, but it would only be a one-time inconvenience during that transition moment.
The team's goal for LiquidThreads transition is essentially the same -- turning the existing conversations into a form that we can archive, and preserve for the future. If we tried to turn ongoing LQT discussions into ongoing Flow discussions, we'd actually be spending more development time on archiving the deprecated feature than we would spend on archiving wiki talk pages.
There's a few more big features for Flow that we're working on this summer; we'll have some new things to show off pretty soon.
Danny
2014-06-06 0:16 GMT+02:00 Danny Horn dhorn@wikimedia.org:
The Flow team is going to work in a few weeks on automatically archiving talk pages, so that we can enable Flow on pages where there are already existing conversations. Basically, this means moving the old discussions on an archive page, and leaving a link for "See archived talk page" visible on the new Flow board.
That means there'll be a minute where a currently active discussion would get interrupted, and have to be restarted on the new Flow board. That will be a pain, but it would only be a one-time inconvenience during that transition moment.
Interesting point. Thanks for keeping us up to date. You might like to know, though, that on German Wikipedia most discussions about Flow seem to focus on how to turn it off or how to keep it out of the project altogether. Switching to Flow would require a community consensus anyway. So could you please consider a global switch for communities that would rather like to disable these new features completely.
Regards, Jürgen.
PS. We have never enabled the LiquidThreads extension neither. And the new Beta link up right did not stay there for long.
Hoi, While some may think it perfectly ok to be contrary and argue vehemently to keep old hat technology operational for them and everyone around them, I wonder if they consider cost and consequences. * Cost to maintain duplicate and increasingly feature incompatible functionality * Cost to the users who are appalled by the archaic software they have to suffer * Cost to the increased problem of recruiting new contributors.
When I read what is said, it gives me a really bad impression of what "community" means. It is a priori not positive at all when you argue for a blanket switch to disable new features.
I find it impossible to argue to our donors that the additional money spend in keeping ancient software alive is well spend. Thanks, Gerard
On 6 June 2014 01:24, Juergen Fenn schneeschmelze@googlemail.com wrote:
2014-06-06 0:16 GMT+02:00 Danny Horn dhorn@wikimedia.org:
The Flow team is going to work in a few weeks on automatically archiving talk pages, so that we can enable Flow on pages where there are already existing conversations. Basically, this means moving the old discussions
on
an archive page, and leaving a link for "See archived talk page" visible
on
the new Flow board.
That means there'll be a minute where a currently active discussion would get interrupted, and have to be restarted on the new Flow board. That
will
be a pain, but it would only be a one-time inconvenience during that transition moment.
Interesting point. Thanks for keeping us up to date. You might like to know, though, that on German Wikipedia most discussions about Flow seem to focus on how to turn it off or how to keep it out of the project altogether. Switching to Flow would require a community consensus anyway. So could you please consider a global switch for communities that would rather like to disable these new features completely.
Regards, Jürgen.
PS. We have never enabled the LiquidThreads extension neither. And the new Beta link up right did not stay there for long.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn schneeschmelze@googlemail.com wrote:
2014-06-06 0:16 GMT+02:00 Danny Horn dhorn@wikimedia.org:
The Flow team is going to work in a few weeks on automatically archiving talk pages, so that we can enable Flow on pages where there are already existing conversations. Basically, this means moving the old discussions
on
an archive page, and leaving a link for "See archived talk page" visible
on
the new Flow board.
That means there'll be a minute where a currently active discussion would get interrupted, and have to be restarted on the new Flow board. That
will
be a pain, but it would only be a one-time inconvenience during that transition moment.
Interesting point. Thanks for keeping us up to date. You might like to know, though, that on German Wikipedia most discussions about Flow seem to focus on how to turn it off or how to keep it out of the project altogether. Switching to Flow would require a community consensus anyway. So could you please consider a global switch for communities that would rather like to disable these new features completely.
Regards, Jürgen.
PS. We have never enabled the LiquidThreads extension neither. And the new Beta link up right did not stay there for long.
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.
On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn schneeschmelze@googlemail.com wrote:
You might like to know, though, that on German Wikipedia most discussions about Flow seem to focus on how to turn it off or how to keep it out of the project altogether. Switching to Flow would require a community consensus anyway. So could you please consider a global switch for communities that would rather like to disable these new features completely.
Technically, the Flow extension first has to be installed on a wiki, and then Flow is enabled on particular talk pages or classes of talk pages on that wiki (currently 18 pages on production wikis). After a mis-step on meta-wiki, we seek consensus on both steps. Currently both are PHP changes; the Flow team is figuring out how the second will work in the future. We have no plans to install Flow on German Wikipedia let alone on any particular talk page, so your discussions can focus on other issues.
The tone of your message made me want to cry, quit my job, and punch the wall in frustration :( But I appreciate you being open about your dislike and suspicion of Flow, and can only hope that over time Flow's growing feature set leads users to *want* it enabled on the talk pages they visit.
-- =S Page Core Features (Flow) engineer
2014-06-06 22:28 GMT+02:00 S Page spage@wikimedia.org:
The tone of your message made me want to cry, quit my job, and punch the wall in frustration :(
I am sorry, S, this is certainly not what I intended. I apologise for the tone of my last mail.
But I appreciate you being open about your dislike and suspicion of Flow, and can only hope that over time Flow's growing feature set leads users to *want* it enabled on the talk pages they visit.
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.
Going to have concur on this. Flow and VE would be great for attracting new users, but leaving the foundation of the community in the dust in favor of innovation strikes me as a bad idea.
I support the idea of having the ability for the old methods of editing and talk pages to work when and where possible and for the transition to newer ideas to be as gentle as possible on those who might otherwise be alienated by the changes.
Date: Sat, 7 Jun 2014 02:39:17 +0200 From: schneeschmelze@googlemail.com To: wikitech-l@lists.wikimedia.org Subject: Re: [Wikitech-l] LiquidThreads - how do we kill it?
2014-06-06 22:28 GMT+02:00 S Page spage@wikimedia.org:
The tone of your message made me want to cry, quit my job, and punch the wall in frustration :(
I am sorry, S, this is certainly not what I intended. I apologise for the tone of my last mail.
But I appreciate you being open about your dislike and suspicion of Flow, and can only hope that over time Flow's growing feature set leads users to *want* it enabled on the talk pages they visit.
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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2014-06-07 2:44 GMT+02:00 Arcane 21 arcane@live.com:
Going to have concur on this. Flow and VE would be great for attracting new users, but leaving the foundation of the community in the dust in favor of innovation strikes me as a bad idea.
I support the idea of having the ability for the old methods of editing and talk pages to work when and where possible and for the transition to newer ideas to be as gentle as possible on those who might otherwise be alienated by the changes.
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.
So you propose to never ever change the look and feel because it might piss off some old-timers?
On Fri, Jun 6, 2014 at 6:01 PM, Juergen Fenn schneeschmelze@googlemail.com wrote:
2014-06-07 2:44 GMT+02:00 Arcane 21 arcane@live.com:
Going to have concur on this. Flow and VE would be great for attracting
new users, but leaving the foundation of the community in the dust in favor of innovation strikes me as a bad idea.
I support the idea of having the ability for the old methods of editing
and talk pages to work when and where possible and for the transition to newer ideas to be as gentle as possible on those who might otherwise be alienated by the changes.
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.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
2014-06-07 3:11 GMT+02:00 Max Semenik maxsem.wiki@gmail.com:
So you propose to never ever change the look and feel because it might piss off some old-timers?
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.
On 6 June 2014 16:28, S Page spage@wikimedia.org wrote:
On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn < schneeschmelze@googlemail.com> wrote:
You might like to know, though, that on German Wikipedia most discussions about Flow seem to focus on how to turn it off or how to keep it out of the project altogether. Switching to Flow would require a community consensus anyway. So could you please consider a global switch for communities that would rather like to disable these new features completely.
Technically, the Flow extension first has to be installed on a wiki, and then Flow is enabled on particular talk pages or classes of talk pages on that wiki (currently 18 pages on production wikis). After a mis-step on meta-wiki, we seek consensus on both steps. Currently both are PHP changes; the Flow team is figuring out how the second will work in the future. We have no plans to install Flow on German Wikipedia let alone on any particular talk page, so your discussions can focus on other issues.
The tone of your message made me want to cry, quit my job, and punch the wall in frustration :( But I appreciate you being open about your dislike and suspicion of Flow, and can only hope that over time Flow's growing feature set leads users to *want* it enabled on the talk pages they visit.
Spage, please don't take the criticism of the product to be a criticism of you or your own work. It's really not about you, or even necessarily about Flow, it's about a much bigger picture.
Flow is a product that wasn't asked for, is intended to do things that people didn't ask it to do, and is a fundamentally different user interface than the two major ones we already have (Mediawiki and VisualEditor). Thus, it is adding complexity to the editing experience that does not currently exist. Mediawiki may be difficult to learn, but it's only one interface. VisualEditor, an interface the community has been seeking for over 10 years, gives a visual result that, from the perspective of the editor, is still a wiki-page; it may work somewhat differently, but it still looks like a wiki.
There were four problems with talk/discussion pages that users across multiple communities over multiple years have identified:
- Automatic signatures for posts/edits - More efficient method for indenting that is not dependent on arcane wikicode knowledge - More graceful handling of edit conflicts - Ability to watchlist an individual thread or section of a page
The first two could undoubtedly be done in Mediawiki; we already have bots that add signatures automatically, for example, and it should be elementary to create an "indent" button that goes in the same line as the other editing icons currently in use. The third point has already had significant work, although more can be done there. I have had several experienced Mediawiki developers say that the fourth point is possible but very difficult. In other words, given sufficient focus, effort, talent and willingness, these issues are all likely to be solvable without creating a new user interface that wasn't requested and is visually divorced from wiki editing. Now, I know it's a lot more interesting and exciting to create something new than it is to make major renovations to something that already exists, and I'm pretty sure after all these years that Mediawiki code is a mess. But I've increasingly been getting the impression that there aren't a lot of WMF staff who actually like wikis, let alone developing Mediawiki core. (Even if that impression is not correct, it's out there and it's based on conversations with WMF engineering staff.)
Meanwhile, Flow does automatic signatures, but its current design actually makes indenting much more problematic from a reader perspective than the current indenting structure. It's difficult to tell which post is being responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion. Edit conflicts don't exist, but they result in odd threading of responses. It's not obvious how to watch specific threads at this point, or how one would make it possible. In other words, it's not really doing a great job of solving three of the four issues that have long been seen as problems. Meanwhile, it's introduced new issues, many of which users have identified as problematic: endless scrolling, inability to archive, inability to completely remove a thread from a page without actual deletion and/or suppression, categorization issues, complex process to find, create, and edit page headers, etc.
There was always an underlying assumption that the benefit of having a large number of engineers working together under the direction and leadership of the WMF would result in a much more consistent process for creating products, better prioritization, and more cross-product consistency. Instead, what we are seeing is that each product team is working in a silo. Common UI issues are being addressed differently across products, increasing the complexity of editing for both new and experienced users. There's no overall integration of the design process, and there really doesn't seem to be a serious master plan that goes into detail about cross-product integration. Yes, there's the roadmap, but it's all individual product teams working on their own product, with very little cross-pollination. In other words, this is a leadership issue that is playing out repeatedly across each product line, and it's pretty much the same issue over and over again, just focused on a different product. It's not the fault of the back-room engineers; it's at the PM level and above.
Risker/Anne
Dear Anne,
Thank you for the thoughtful critique.
There were four problems with talk/discussion pages that users across multiple communities over multiple years have identified:
- Automatic signatures for posts/edits
- More efficient method for indenting that is not dependent on arcane
wikicode knowledge
- More graceful handling of edit conflicts
- Ability to watchlist an individual thread or section of a page
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.
But I've increasingly been getting the impression that there aren't a lot of WMF staff who actually like wikis, let alone developing Mediawiki core.
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. ;-)
Meanwhile, Flow does automatic signatures, but its current design actually makes indenting much more problematic from a reader perspective than the current indenting structure.
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/help...
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=rvzy5wgxm...
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?
It's difficult to tell which post is being responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion.
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.
endless scrolling, inability to archive,
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.
inability to completely remove a thread from a page without actual deletion and/or suppression,
The current "comment corpses" have already been identified as an issue and we'll experiment with different ways to manage hiding/deletion of comments.
complex process to find, create, and edit page headers, etc.
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.
each product team is working in a silo. Common UI issues are being addressed differently across products, increasing the complexity of editing for both new and experienced users.
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
On Sat, Jun 7, 2014 at 3:51 PM, Erik Moeller erik@wikimedia.org wrote:
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.
But I've increasingly been getting the impression that there aren't a lot of WMF staff who actually like wikis, let alone developing Mediawiki core.
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. ;-)
Meanwhile, Flow does automatic signatures, but its current design
actually
makes indenting much more problematic from a reader perspective than the current indenting structure.
Flow stores the comments as a structured tree
That seems a fundamental mistake. A discussion isn't a tree, it's a dag. It's possible for a single comment in a discussion to refer to zero or more earlier comments.
-- Martijn
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.
If it's sturctured as a tree, you won't be able to catch all context.
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?
It's difficult to tell which post is being responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion.
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.
endless scrolling, inability to archive,
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.
inability to completely remove a thread from a page without actual
deletion and/or
suppression,
The current "comment corpses" have already been identified as an issue and we'll experiment with different ways to manage hiding/deletion of comments.
complex process to find, create, and edit page headers, etc.
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.
each product team is working in a silo. Common UI issues are being
addressed
differently across products, increasing the complexity of editing for
both new
and experienced users.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Oops, sent too soon. More comments below.
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
Flow stores the comments as a structured tree
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.
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.
If it's sturctured as a tree, you won't be able to catch all context, ever.
It's difficult to tell which post is being
responded to, who's responding to whom, the responses don't thread well, and it's not possible to rethread a discussion.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra < martijnhoekstra@gmail.com javascript:;> wrote:
Flow stores the comments as a structured tree
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,
Flow stores each discussion as a tree, with a Flow "Board" being a forest of discussions for precisely this reason.
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.
Hmm. I'm not convinced that there has ever been a successful/useful/good discussion system that encouraged sub-comment structured replies. In my experience they are unusable morrasses of confusion. Instead, a lightweight quoting tool achieves the specificity at the least complexity and greatest clarity for users.
I could be convinced otherwise, but it'd need to be a fairly stunning design concept.
J.
On 8 Jun 2014, at 17:22, James Forrester jforrester@wikimedia.org wrote: — Krinkle
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra < martijnhoekstra@gmail.com javascript:;> wrote:
Flow stores the comments as a structured tree
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,
Flow stores each discussion as a tree, with a Flow "Board" being a forest of discussions for precisely this reason.
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.
Hmm. I'm not convinced that there has ever been a successful/useful/good discussion system that encouraged sub-comment structured replies. In my experience they are unusable morrasses of confusion. Instead, a lightweight quoting tool achieves the specificity at the least complexity and greatest clarity for users.
I could be convinced otherwise, but it'd need to be a fairly stunning design concept.
J.
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
I see traditional email and newsgroup clients missing a bit from Krinkle's list. Subthreading works perfectly fine in Thunderbird (but even in Outlook Express!). Indenting is the one characteristic found in all wiki conversations: subthreading can't be discarded based on gut feelings. In my experience shepherding thousands of it.wiki conversations (mostly on their own subpages), the biggest issue are offtopic and personal tangents, hence the most important technical feature in wikitext is that I'm able to easily tell apart, link and move subthreads.
Nemo
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) nemowiki@gmail.com wrote:
I see traditional email and newsgroup clients missing a bit from Krinkle's list. Subthreading works perfectly fine in Thunderbird (but even in Outlook Express!). Indenting is the one characteristic found in all wiki conversations: subthreading can't be discarded based on gut feelings. In my experience shepherding thousands of it.wiki conversations (mostly on their own subpages), the biggest issue are offtopic and personal tangents, hence the most important technical feature in wikitext is that I'm able to easily tell apart, link and move subthreads.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
The key thing about Usenet and email is that the first-class entity was the individual message - on web forums, the first-class entity is the thread. On Usenet or email, a "thread" is something strung together on the fly from the surviving References: headers of whatever messages have made it as far as you. (This is why Gmane is a bit weird to use as a forum, even on a mailing list with no messages getting lost.)
Trees work in places like Reddit or LessWrong, and to some degree on Slashdot - though the latter lacks the ability to collapse a fruitless tree in the interface.
Some ramblings on Usenet vs web forums: http://reddragdiva.dreamwidth.org/566555.html
On 9 June 2014 07:42, Federico Leva (Nemo) nemowiki@gmail.com wrote:
I see traditional email and newsgroup clients missing a bit from Krinkle's list. Subthreading works perfectly fine in Thunderbird (but even in Outlook Express!). Indenting is the one characteristic found in all wiki conversations: subthreading can't be discarded based on gut feelings. In my experience shepherding thousands of it.wiki conversations (mostly on their own subpages), the biggest issue are offtopic and personal tangents, hence the most important technical feature in wikitext is that I'm able to easily tell apart, link and move subthreads.
Nemo
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Sun, Jun 8, 2014 at 8:22 AM, James Forrester jforrester@wikimedia.org wrote:
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra < martijnhoekstra@gmail.com javascript:;> wrote:
Flow stores the comments as a structured tree
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,
Flow stores each discussion as a tree, with a Flow "Board" being a forest of discussions for precisely this reason.
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).
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.
Hmm. I'm not convinced that there has ever been a successful/useful/good discussion system that encouraged sub-comment structured replies.
Current MediaWiki talk pages do this, as well as mailing lists.
In my experience they are unusable morrasses of confusion. Instead, a lightweight quoting tool achieves the specificity at the least complexity and greatest clarity for users.
I could be convinced otherwise, but it'd need to be a fairly stunning design concept.
J.
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
-- James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9 June 2014 10:30, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
[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.
I wonder how much everyone would hate us if we just replaced talk pages with Apache Wave ...
- d.
On Mon, Jun 9, 2014 at 2:52 AM, Thomas Gries mail@tgries.de wrote:
Am 09.06.2014 11:42, schrieb David Gerard:
I wonder how much everyone would hate us if we just replaced talk pages with Apache Wave ...
or Etherpad
Why stop at talk pages?
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[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 5:30 AM, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
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
The assumption I think you are making here is that the goal is to get a discussion system with maximum functionality and flexibility. I think that is an interesting goal as a technical exercise, but I'm not sure I agree that this is a valuable goal for Wikimedia (although it may be for MediaWiki). The problem we have is one of non-technical users put off by excessively technical (and unstructured) means of communication.
So I think a much better goal, and one that I know others share and has been the focus of development work, is to adopt a system of communication that is easy and intuitive for as many participants as possible. This may mean the problem of inventing a better mousetrap needs to be set aside in favor of determining what mechanism is the most familiar and easy for the majority of Wikimedia users. If that leads us to adopting something similar to vBulletin or another threading w/quotes discussion system, then so be it. This is a little part of what I think Risker was getting at; the technical side is focused on creating neat new products and features, but not always necessarily solving the problems that we actually have.
As a general principle, I see this kind of thinking come up a lot in Wikimedia settings - the community is deeply committed to a very innovative project, which leads to the impulse to be innovative in many ways. But the core innovation is the wiki and the mission; it's not necessary to invent the best-in-class [governance system, donation system, discussion mechanism, feedback tool, etc.], and in many cases the distraction and uncertainty of trying to innovative in multiple channels presents a liability.
On Mon, Jun 9, 2014 at 9:56 AM, Nathan nawrich@gmail.com wrote:
On Mon, Jun 9, 2014 at 5:30 AM, Martijn Hoekstra < martijnhoekstra@gmail.com> wrote:
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
The assumption I think you are making here is that the goal is to get a discussion system with maximum functionality and flexibility.
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
been the focus of development work, is to adopt a system of communication that is easy and intuitive for as many participants as possible.
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 may mean the problem of inventing a better mousetrap needs to be set aside in favor of determining what mechanism is the most familiar and easy for the majority of Wikimedia users.
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"
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9 June 2014 13:51, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 9:56 AM, Nathan nawrich@gmail.com wrote:
On Mon, Jun 9, 2014 at 5:30 AM, Martijn Hoekstra < martijnhoekstra@gmail.com> wrote:
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
The assumption I think you are making here is that the goal is to get a discussion system with maximum functionality and flexibility.
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
been the focus of development work, is to adopt a system of communication that is easy and intuitive for as many participants as possible.
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 may mean the problem of inventing a better mousetrap needs to be set aside in favor of determining what mechanism is the most familiar and easy for the majority of Wikimedia users.
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"
This. Nobody, but nobody, asked the WMF to create this sort of system, and it is a rather quixotic goal given that each project has its own set of workflows.
Meanwhile, core tasks like SUL finalisation are languishing on the back burner, to the detriment of several other projects and products. Yes, I know it's on the roadmap for Mediawiki Core in Q1 starting in July - but it will not be the priority product for any of the three people tasked to it. And the biggest challenge there isn't the code, it's the community interaction, negotiating the prioritization rules for who gets to keep a username (which currently varies widely amongst projects) and working with users whose longtime Wikimedia identities will have to be changed. This is optimistically a year-long project that's been passed around amongst WMF staff for years as if it was a hot potato. Well, I guess it actually is, so I can see why. But if this is hard, then I don't understand why anyone would think that forcing projects to conform to WMF's vision of how they should manage everything from Wikiproject templates to content quality reviews to RFA to any other process that isn't actually creation or editing of content is going to be perceived as anything but the WMF sticking its nose into areas that are none of its business.
Risker/Anne
On Mon, Jun 9, 2014 at 12:12 PM, Risker risker.wp@gmail.com wrote:
This. Nobody, but nobody, asked the WMF to create this sort of system, and it is a rather quixotic goal given that each project has its own set of workflows.
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.
Meanwhile, core tasks like SUL finalisation are languishing on the back burner, to the detriment of several other projects and products. Yes, I know it's on the roadmap for Mediawiki Core in Q1 starting in July - but it will not be the priority product for any of the three people tasked to it.
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
FWIW, for me as a power user who watches many discussions simultaneously on multiple wikis, a unified watchlist and more refined tools for watchlist management are among the features at the top of my development wish list.
Pine
On Mon, Jun 9, 2014 at 6:51 PM, Erik Moeller erik@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 12:12 PM, Risker risker.wp@gmail.com wrote:
This. Nobody, but nobody, asked the WMF to create this sort of system,
and
it is a rather quixotic goal given that each project has its own set of workflows.
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.
Meanwhile, core tasks like SUL finalisation are languishing on the back burner, to the detriment of several other projects and products. Yes, I know it's on the roadmap for Mediawiki Core in Q1 starting in July - but
it
will not be the priority product for any of the three people tasked to
it.
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.pine@gmail.com wrote:
FWIW, for me as a power user who watches many discussions simultaneously on multiple wikis, a unified watchlist and more refined tools for watchlist management are among the features at the top of my development wish list.
*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
Am 10.06.2014 09:33, schrieb Erik Moeller:
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.pine@gmail.com wrote:
FWIW, for me as a power user who watches many discussions simultaneously on multiple wikis, a unified watchlist and more refined tools for watchlist management are among the features at the top of my development wish list.
*nod* The watchlist is an awesome tool, and there's so much more we could do with it. :)
Watchlist and (fine-granular definable) E-Mail-Notifications are very important - for my daily work. LiquidThreads and Echo (if you opt-in to mail) offer that (using the MediaWiki UserMailer functions).
Does Flow also offer E-Mail-Notifications?
On Tue, Jun 10, 2014 at 1:09 AM, Thomas Gries mail@tgries.de wrote:
Watchlist and (fine-granular definable) E-Mail-Notifications are very important - for my daily work. LiquidThreads and Echo (if you opt-in to mail) offer that (using the MediaWiki UserMailer functions).
Does Flow also offer E-Mail-Notifications?
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
On Jun 10, 2014 9:33 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Mon, Jun 9, 2014 at 11:14 PM, Pine W wiki.pine@gmail.com wrote:
FWIW, for me as a power user who watches many discussions
simultaneously on
multiple wikis, a unified watchlist and more refined tools for watchlist management are among the features at the top of my development wish
list.
*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.
I never doubted there will be advantages, I'm quite certain there will be, both for powerusers and for newcomers. Yet there will also be disadvantages, and they will probably be major. Since the option to keep mediawiki discussions for some processes, or the ability to represent a discussion in both wikitext and flow are explicitly not on the table, I'm trying to bring up as many issues I can think of, even if they are qualified as insane. This is a big operation, and "why didn't you say something earlier" is a valid criticism; one I prefer to prevent.
--Martijn
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
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
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.
On 10 June 2014 15:34, Quim Gil qgil@wikimedia.org wrote:
- User talk pages. Do we need multithread tree discussions in our user talk
pages? No, we don't.
And yet this is a popular use for LQT on LQT-using wikis, so will need to be covered by Flow.
- 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.
This is the sort of phrasing that may raise the hackles of experienced editors; talk like this got a lot of people's backs up during the enforced VE trial.
I fear you will have to actually convince people to get them to accept this.
I do know objections for this use case have been raised already, e.g. being able to post a proposed slab of wikitext into a talk page. You need to allow for that one.
- 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.
That might work. What do the people volunteering on them think? (That's pretty much the question to answer for all proposed use cases.)
- 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.
What examples are you thinking of?
- d.
On Tue, Jun 10, 2014 at 10:34 AM, Quim Gil qgil@wikimedia.org wrote:
- User talk pages. Do we need multithread tree discussions in our user
talk pages? No, we don't.
{{citation needed}}
I suspect this is just like the point below.
- 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.
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.
- 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.
I suspect this would quickly turn into an argument based on "Everything else uses Flow, this should too!"
- 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
I think you mean on average. There are outliers here, and they aren't that uncommon. That said i agree that in general user talk page discussions are simple, and the whose talk do i respond at is a big issue there.
That said, i still hate user talk pages that use lqt. Maybe flow will convert me one day into a believer, but it hasn't yet.
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.
Diversity and all that jazz is great. But that is a means to an end, not an end in itself. The point of a talk page in not inherently to be welcoming. Its not a party or a space primarily for socialization. The point is to come to conclusions on how to make a better article. Now diversity of opinion is important to that, but i think its important to separate ends and means. If the increase in welcomingness makes them less suited to their actual purpose, that would be bad.
I think an apt comparison would be to a conference. Being welcoming is important, but if that's all you are, its not really a conference.
- 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.
Yes. Lqt has proven itself here to be useful.
- 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.
--bawolff
On 9 June 2014 02:30, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 8:22 AM, James Forrester jforrester@wikimedia.org wrote:
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra < martijnhoekstra@gmail.com javascript:;> wrote:
Flow stores the comments as a structured tree
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,
Flow stores each discussion as a tree, with a Flow "Board" being a forest of discussions for precisely this reason.
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).
Really?
Hello | +- Hey! | +-+- Wow! | | | +-+- I know! | | | +-+- I'm here too! | | | | | +- It's wonderful! | | | +-+- Crazy, right? | +- Yeah.
…
J.
On Mon, Jun 9, 2014 at 11:05 AM, James Forrester jforrester@wikimedia.org wrote:
On 9 June 2014 02:30, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 8:22 AM, James Forrester <
jforrester@wikimedia.org>
wrote:
On Sunday, June 8, 2014, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Sun, Jun 8, 2014 at 1:18 AM, Martijn Hoekstra < martijnhoekstra@gmail.com javascript:;> wrote:
Flow stores the comments as a structured tree
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,
Flow stores each discussion as a tree, with a Flow "Board" being a
forest
of discussions for precisely this reason.
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).
Really?
Yes, really.
Hello | +- Hey! | +-+- Wow! | | | +-+- I know! | | | +-+- I'm here too! | | | | | +- It's wonderful! ---------+ | | | | +-+- Crazy, right? |
| | | | Wonderfully crazy!------|
| +- Yeah.
…
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9 June 2014 11:12, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 11:05 AM, James Forrester jforrester@wikimedia.org wrote:
On 9 June 2014 02:30, Martijn Hoekstra martijnhoekstra@gmail.com 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).
Really?
Yes, really.
…
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.
On Mon, Jun 9, 2014 at 2:20 PM, James Forrester jforrester@wikimedia.org 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.
To be fair, this is something that happens on long talk page discussions. It is not correct to blanket-classify all talk page conversations as directed trees. When discussions get really long, it just becomes a blob of text of people talking back and forth with each other. It is massively disorganized, but it will not work to simply force the discussion into a tree structure.
*-- * *Tyler Romeo* Stevens Institute of Technology, Class of 2016 Major in Computer Science
On Mon, Jun 9, 2014 at 11:20 AM, James Forrester jforrester@wikimedia.org wrote:
On 9 June 2014 11:12, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 11:05 AM, James Forrester <
jforrester@wikimedia.org>
wrote:
On 9 June 2014 02:30, Martijn Hoekstra martijnhoekstra@gmail.com
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).
Really?
Yes, really.
…
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.
You generally see them in the form
::@namex @namey @namez Lorem ipsum
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 9 June 2014 11:28, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 11:20 AM, James Forrester jforrester@wikimedia.org 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.
You generally see them in the form
::@namex @namey @namez Lorem ipsum
Ah, right. Flow already supports pinging people in replies in exactly this fashion, which is a lot more free-form, flexible and understandable for users than trying to get people to build a DAG each time they comment.
J.
On Mon, Jun 9, 2014 at 11:33 AM, James Forrester jforrester@wikimedia.org wrote:
On 9 June 2014 11:28, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 11:20 AM, James Forrester <
jforrester@wikimedia.org>
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.
You generally see them in the form
::@namex @namey @namez Lorem ipsum
Ah, right. Flow already supports pinging people in replies in exactly this fashion, which is a lot more free-form, flexible and understandable for users than trying to get people to build a DAG each time they comment.
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
J.
James D. Forrester Product Manager, VisualEditor Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, 09 Jun 2014 20:52:44 +0200, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
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.
When I encounter this issue on mailing lists, I usually just reply to the lowest common ancestor of all the posts I want to reply to at once, or split my reply and respond to each separately.
(And mailing lists are interesting by itself, because most actual e-mail clients display the discussion in a threaded fashion, while most webmails like GMail display a flat list of replies.)
Introducing a structured discussion is hard enough, let's not invent issues where there are none. :)
On 9 Jun 2014, at 20:58, Bartosz Dziewoński matma.rex@gmail.com wrote:
On Mon, 09 Jun 2014 20:52:44 +0200, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
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.
When I encounter this issue on mailing lists, I usually just reply to the lowest common ancestor of all the posts I want to reply to at once, or split my reply and respond to each separately.
(And mailing lists are interesting by itself, because most actual e-mail clients display the discussion in a threaded fashion, while most webmails like GMail display a flat list of replies.)
Introducing a structured discussion is hard enough, let's not invent issues where there are none. :)
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
wikitech-l@lists.wikimedia.org