Re: [Wikitech-l] LiquidThreads - how do we kill it?
On 06.06.2014 22:17, Brian Wolff wrote: On 6/6/14, Brad Jorsch (Anomie) bjor...@wikimedia.org wrote: On Thu, Jun 5, 2014 at 4:38 PM, Jon Robson jdlrob...@gmail.com wrote: So I want to know: * What are the blockers for doing this? * Are there any use cases / killer features in LiquidThreads that are not in Flow that need to be ported over? Flow doesn't support actual threaded discussions beyond a very limited depth,[1] meaning that a real threaded discussion is likely to turn into a morass of comments without clear indication of what is replying to what unless people actively work around it.[2] Since converted LQT threads are likely to lack the quoting necessary to work around this misfeature, they're particularly liable to wind up unreadable if they're at all complex. Also, bug 57512 comment 31 could use a reply.[3] [1]: Although this is a matter of configuration rather than something hard-coded, I doubt the configuration is going to be changed. [2]: I won't go into more detail here about this or about why pings (as Flow encourages to work around the misfeature) aren't sufficient. [3]: https://bugzilla.wikimedia.org/show_bug.cgi?id=57512#c31 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Personally I have yet to see a discussion system that surpasses (or really even comes close) to standard talk page :::comment here. syntax. Honestly it would make me happy if we just used that in general. I also like wikitext more than any of visual UI because it's faster to type. Also, that kind of comments :::comment probably can be incorporated into VisualEditor so the users will see something like LQT while actual content will be a wikitext. VisualEditor could have separate scopes or modes for different NS_* page types. The exception being pages with large influxes of newbies, like Project:Support_desk. In those pages LQT really does make a difference to ensure things are well organized. --bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] LiquidThreads - how do we kill it?
On 6 June 2014 16:28, S Page sp...@wikimedia.org wrote: On Thu, Jun 5, 2014 at 4:24 PM, Juergen Fenn schneeschme...@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
Re: [Wikitech-l] LiquidThreads - how do we kill it?
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=LiquidThreadsoldid=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_to_restore_an_abandoned_wikilqt_method=thread_history 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:Flowworkflow=rvzy5wgxmdmgbfqaaction=history Neither user experience feels efficient (nor does mentally parsing a wikitext diff). It may be possible to
