Hi Erik, While I have a lot of reservations about the usefulness of the Media Viewer, I agree with you that talk pages are now inefficient for all and complex for new users. Personally I am willing to try any system which offers the features missing in the current talk pages, specially removing the need for manual signatures.
Regards, Yann 2014-09-06 10:19 GMT+05:30 Erik Moeller <[email protected]>: > 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>
