Hi all, I'm breaking out this discussion about Flow/talk pages (apologies for repeatedly breaking the megathread, but this is a well-scoped subject which deserves its own thread).
Fundamentally, there's one key question to answer for talk pages in Wikimedia projects: Do we want discussions to occur in document mode, or in a structured comment mode? All else flows from there (pun intended). == Document mode == There are not many examples of document mode discussion systems beyond wikis. You sometimes see people use collaborative realtime editors as such, because people want to talk in the same space where they work, but Google Docs provided alternatives (a pretty powerful comments/margin system and built-in chat) early on, for example. The current talk page system is a document mode system. Individual comments have unclear boundaries (a single transaction can result in multiple comments, signed or unsigned; indentation levels are unpredictable and often inconsistent). All the joys and pain points of working on the same document are present (a heavily trafficked talk page will see many edit conflicts). You can't easily show comments in multiple contexts (cross-wiki, via email, as a notification, etc.) because of the boundary problem. You could try to make a document mode system work better. On the basis of wikitext, you can do some very basic things, like the "new section" link I added to MediaWiki back in July 2003 [1], when I wrote: "This feature could also be the first stage of a more sophisticated discussion system, where the next stage would be auto-appending signatures and providing a 'Reply to this' link after each comment." But due to the aforementioned unpredictability, even making a "reply" link work consistently (and do the right thing) is non-trivial. You can get some of the way there, and the Wikipedia Teahouse actually has a gadget, written by Andrew Garrett (more on him below) that does precisely that. https://en.wikipedia.org/wiki/Wikipedia:Teahouse/Questions Note the "Join this discussion" link. It does give you a pop-up, and posts the comment for you in the right place, with indentation (it does not auto-sign, but instead tries to teach users the signature habit which they'll need to use on other talk pages). It may be worth doing more research and development on this, to see just how far we can get without changing the fundamentals, since a wholly new system may still be years out for wide use. However, there are inherent limitations due to the lack of a predictable and consistent structure. You could go further down the road of a document mode or hybrid system, but IMO not without introducing fully predictable comment markers (think <comment id="234234">Bla ~~~</comment>) -- which would pollute the wikitext, be fragile (e.g. accidental or deliberate corruption of identifiers), and probably be considered unacceptable in a system that still supports unlimited wikitext editing for those reasons. == Structured == I personally gave up on patchwork on top of talk pages about 10 years ago. The advantages of having comments clearly identified as such are many: - Display comments in arbitrary order, arbitrary threading style - Search comments across date ranges - Search comments by author - Track comments as comments, not as diffs - Monitor changes at any part of a comment thread - Display comments independent of a given document (e.g. email, cross-wiki, etc.) - Display comment metadata in different formats easily (e.g. timestamps) - Update author names after a username change without having to update documents - Enables third parties to build new UIs (think Wikiwand for comments) more easily - Ability to tag/categorize individual comments/threads - and more. I identified some of these reasons when I wrote the proposal for LiquidThreads in October 2004 [2]. At that point, the Wikimedia Foundation had 0 employees, and this was too large an effort to likely get traction just from ad hoc volunteering. So after some time, I managed to persuade third parties to fund development, including Wikicities and WikiEducator, and found a developer to do the initial work, David McCabe. David did a good initial job but the system had many known issues and was only deployed at a small scale. At the same time, I think there were many things about even the original design that were good (and aren't found in most other forum systems): - It preserved "headers" on top of the threaded conversation as community-editable wiki-like spaces - It had a full history model for the thread itself, not just comments - It preserved comments essentially as individual wiki pages, with their own history - It had a built-in notion of thread summaries, collaboratively written, for closing comments As WMF started to grow, it took on development of LiquidThreads -- with one developer, Andrew Garrett, who did an amazing job cleaning up the codebase and rethinking many of the assumptions David had made. LQT got to a point where some Wikimedia wikis actually requested for it to be enabled and traction started to build in favor of it. To this date, it is still found in some nooks and crannies in the Wikimedia universe. translatewiki.net still uses it for its support page, and MediaWiki.org for its support desk, which are probably the highest profile uses left, and both get a fair bit of comment traffic. Andrew did a ton of work on the project, but he himself recognized many architectural issues he wanted to address, and there are also UI assumptions we wanted to revisit. The project didn't have a team behind it at that time -- just one very talented part-time developer who was still at university! This was when WMF was barely growing to do development work, picking up some stuff (like LQT and FlaggedRevs) that had been simmering at a smaller scale before then. In 2011, Brandon Harris, the first person at WMF ever to be tasked exclusively with design responsibilities, took a crack at some initial redesign drafts [5][6], which still contain many ideas worth looking at. But we pulled the plug at that time, because we recognized that we simply didn't have the personpower to put the resources behind the project to actually get it anywhere near completion -- and that a major architectural overhaul was required to do so. A new effort was launched about a year ago, now resourcing a full team including design, development, product management, community support. (We're still pretty short staffed on UX research, QA, and data analyst support, but we make do.) As the team (including Andrew with his LQT experience under his belt) thought through the architectural needs of a modern discussion system, they decided that the LQT architecture was not salvageable. A migration script [7] is in development by Andrew himself. The Flow architecture [8] differs in some important ways from LQT, including: - Flow doesn't pretend that comments are "pages", instead using its own separate tables to manage them. This is architecturally important to give us more flexibility on how to store, version, query, search, and describe comments. - Flow is built from the start to store comments in a central datastore, to make it easier to display comments and relevant notifications cross-wiki. - Flow users Parsoid's HTML underneath, to prepare it for VisualEditor. I don't think the architecture is perfect, but it should be a reasonable foundation to build on and iterate from. The Flow UI, similarly, represents a first pass at this point. A lot of basic functionality is still missing. Things we know will make users happy (like cross-wiki features) are still ways out. It doesn't support VisualEditor yet, and yet its wikitext input suffers from any issues Parsoid does -- decisions made to future-proof the architecture have negative short term impact. And like any brand-new UI, it could use lots of micro-optimization -- glitches here and there, which you may not even consciously notice, but which give you the feeling that you're using not-quite-ready software. Which you are. At the same time, we know from user studies that talk pages are incredibly hard for new users to figure out. The semantics are just extremely different from anything else on the web. So we think a support forum like the Teahouse, and its equivalent in other languages may be a good place to start -- provided the hosts agree that there are no dealbreaker issues for them. This parallels the long adoption of LQT for support desk type forums. In this context, we also want to do some systematic measurement: How does such a system affect the # of comments posted, and the quality of the discussion? We expect that we'd need to focus in on this use case in production for quite some time to get it right and really get people to fall in love with the system as it improves. At the same time, there may be other use cases that are less contentious and could serve as additional trials -- like talk pages in Wikidata. We're not pushing an aggressive schedule on Flow -- we understand it needs to happen at the pace of the communities, since you can't build an "opt-out" for this kind of system (unlike VisualEditor). So the schedule is going to have to give as needed. And as above, I'm open to us putting some short term effort into talk page improvements that can be made without Flow -- knowing it's still some time out. But based on the above long term functional and architectural considerations, I think a system that treats comments/threads as structured information, rather than as documents, is ultimately necessary, so I'd argue against procrastinating. It's going to be hard enough as it is to get this done without putting it on the backburner once more. Finally, any comment that is about specific Flow UI aspects should be treated with a massive block of salt. The UI will evolve dramatically as we learn what works for new and experienced users alike. Sincerely, Erik [1] https://lists.wikimedia.org/pipermail/wikipedia-l/2003-July/011069.html [2] https://meta.wikimedia.org/w/index.php?title=LiquidThreads&oldid=100760 [3] https://translatewiki.net/wiki/Support [4] https://www.mediawiki.org/wiki/Project:Support_desk [5] https://upload.wikimedia.org/wikipedia/commons/5/5c/LQT-v2-TalkPage-Full.png [6] https://www.mediawiki.org/wiki/LiquidThreads_3.0/Design [7] https://gerrit.wikimedia.org/r/#/c/119243/ [8] https://www.mediawiki.org/wiki/Flow/Architecture -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe>
