Re: [Wikimedia-l] To Flow or not to Flow

Erik,

I think a lot of reasons for the "document mode" commenting system got missed. But there are very good reasons we must retain that.

One huge thing is that article talk pages are not only for discussions, but also for metadata (article assessments, history, Wikiproject data, as examples from the English Wikipedia). The top of the talk page also, on many pages, serves notices and FAQs to new visitors to the talk page.

For reviews like that, it may be necessary to have wikitext act as wikitext, another very significant concern. ("Your use of Template:Example is what's causing the text formatting to break in that section, because it does like this: (insert example). You should actually use {{example|arg1|arg2}}.") In other cases, subpages or other pages need to be transcluded in, and all the functions of the transcluded page must be preserved. Discussion pages aren't -only- used for discussion.

I think there's a serious flaw in thinking with the current development processes, that Wikipedia needs to be more like Facebook, or Instagram, or Twitter to attract new users. Jan-Bart has even mentioned Quora at several points. Quora is cool. I love Quora. But that's not Wikipedia, and it's not what Wikipedia should aspire to. They're not a competitor. (For that matter, there -are- no competitors, we give our "product" away for free, not only to read but to repackage and reuse!)

Making the interface easier to use is fine, but never at the expense of quality or flexibility. The second is the real sticking point here. We need maximum flexibility to handle complex discussions and complex problems. We may need some stuff at the top of the page, not left in "infinite scroll" hell. (Infinite scroll has to be one of the worst, user-unfriendliest UI ideas I've ever seen.) We need the ability to rapidly archive "forum" style posts or stuff that's become unproductive, and we need -any- editor able to do that, not just admins. Non-admin editors help out all the time in that regard. We need the ability to have real archives; again, infinite scroll with or without search is nowhere near a replacement for that. We need the ability to easily wikilink to specific sections.

Adding some "rails" is fine, but never at the expense of the underlying functionality. VE, once it works, is the model to look at there: It supplements, not supplants, the existing functions. That will be a huge step in the right direction, the problem there was not design but execution. Once it works properly, that issue goes away.

With Flow, the issue is flawed design. Supplanting current talk page functionality will not work. We need the flexibility of subpages and freely editable documents. The only other option there would be to use article-space subpages for that, and that would be messy and horribly inefficient.

Facebook, Twitter, forums, etc., don't need that, but it cannot be emphasized enough that we ***are not, and should not aspire to be or look like, a social media site***. We handle complexity that sites designed around "LOL OMGZ LOLCAT PIX!" do not need to handle.

The resistance you're seeing here is you're trying to take things right out of someone's hand, while they shout "Hey, I was USING that, and this thing you're trying to hand me won't do the same thing!". No amount of tweaks to Flow will change that, unless you can somehow layer it onto existing talk pages rather than replacing them. But any workable solution must retain that backwards compatibility, as VE will.

Maybe Flow could see limited use in a few newbie help areas to aid them in making the transition from reader to editor, but serious editors will by and large not want it sitewide. Ease-of-use helpers will be much more easily accepted, provided they're actually ready for wide scale use when rolled out as site defaults and have easy opt outs. Why not, at the very least, try the less radical change first and see how it works?

Todd

On Fri, Sep 5, 2014 at 10:49 PM, Erik Moeller erik@wikimedia.org wrote:

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-request@lists.wikimedia.org?subject=unsubscribe