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