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 <[email protected]> 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
> [email protected]
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> <mailto:[email protected]?subject=unsubscribe>
_______________________________________________
Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
[email protected]
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
<mailto:[email protected]?subject=unsubscribe>
