Thread:Talk:Wikimedia Commons:Village pump/Confusing?

Experimentally enable LiquidThreads on some test pages

 * For more informaton about LiquidThreads, see LiquidThreads

I propose to experimentally enable LiquidThreads (lqt) on commons. Quick overview: "LiquidThreads replaces discussion pages with actual forums, giving the following benefits:
 * A clear, simplified post/reply workflow so new users can jump right into the discussion.
 * Simple management of threads, including automation of archival, refactoring, and other tasks currently undertaken by bots and humans.
 * A powerful, flexible notification system, allowing users to keep abreast of developments in areas in which they are interested, ranging from entire discussion pages to discussion fragments.
 * Support for following discussion pages with RSS feeds.
 * Flexible post ordering, allowing users to keep track of which threads on a talk page are dead, and which threads are active.
 * A modern, AJAX-based interface, that allows users to post and reply to other posts quickly, without clumsy page loading.
 * Automatic signatures."

- http://liquidthreads.labs.wikimedia.org/wiki/Main_Page

I don't mean to enable it for every talk or discussion page, but only to enable the technical possibility, for admins, to create LiquidThreads. This would enable us to test how Lqt would work with our existing processes (for example deletion requests), what would be needed to be fixed before it can be used more widely & how our existing Javascript gagdgets would need to be modified with to work with Lqt. Lqt is already used on a few wikis, eg.


 * strategy.wikimedia.org (in places)
 * English Wikinews (in places)
 * English Wiktionary (in places)
 * MediaWiki.org (in places)
 * translatewiki.net (all talk pages)

You can test the extension here--DieBuche ( talk ) 12:47, 5 August 2010 (UTC) (bold by Saibo ( Δ ) 19:53, 22 August 2010 (UTC))
 * Strongly support. Deploying LiquidThreads on real WMF wikis is a step long overdue towards a superiour discussion system that eliminates an entire host of frustrating problems. Dcoetzee ( talk ) 12:50, 5 August 2010 (UTC)
 * I wouldn't mind enabling it completely. However, we should make sure that we archive all talk pages of the old system, so that the both systems don't conflict. This was one issue that I noticed at Translatewiki (where it however didn't really matter since only few talk pages exist there). --The Evil IP address ( talk ) 13:22, 5 August 2010 (UTC)
 * Based on my expirience on Translatewiki, functionality is definitely good. However, visual style, look and feel is out of sync with other MediaWiki pages. I think Usability team should work with this extension before wider deployment. --EugeneZelenko ( talk ) 15:03, 6 August 2010 (UTC)
 * The style could most likely be refreshed per MediaWiki:Vector.css to better fit to vector.--DieBuche ( talk ) 17:03, 6 August 2010 (UTC)


 * Definitely an awesome feature with a huge potential. We should help it by implementing it and providing feedback. And yes, we can fix the design ourselves if needed. Those design fixes are be part of the feedback as well. :-) Dodoïste ( talk ) 01:53, 8 August 2010 (UTC)
 * I needed to stop working of strategy because lqt doesn't work good on mobile phones, when this will be enabled here on Commons I would be forced to stop working here on 80% of the time I'm online. First fix the extension so it works always, than maybe I would support.
 * Secondly we are a multilangual project, very few people knows what lqt is, we should wait untill more people know the extension otherwhise we will scare new people away.  Huib   talk  Abigor @ meta 11:03, 20 August 2010 (UTC)
 * As I stated "I don't mean to enable it for every talk or discussion page", but only on test pages so that problems like these can be evaluated. How is multilinguality an argument? It seems to be localized in most languages & how would people know it, if they never see it? Especially for newcomers it should be more intuitive, because it's more like classic forums, they can't forget to sign etc..--DieBuche ( talk ) 11:11, 20 August 2010 (UTC)


 * It's better. -- Davidpar (disc.) 11:46, 20 August 2010 (UTC)
 * LQT, as already pointed out, still has lots of bugs, there's an ongoing major redesign and AFAIK it's quite likely that won't be enabled soon on bigger projects because of current scalability and performance issues. --Nemo 11:50, 20 August 2010 (UTC)
 * . IMO it solves a non-existent problem. It detatches people from wikistyle editing. The resulting discussion pages are not more clearly structured than what we have now. It takes away flexibility. To me it falls in the same category as WYSIWYG-editing, at first glance a great idea, at a second look it does more harm than good. --Dschwen ( talk ) 12:07, 20 August 2010 (UTC)
 * It is a must --Extra999 ( talk ) 12:12, 20 August 2010 (UTC)
 * - "A modern, AJAX-based interface" Duh?? - Please clarify. - MPF ( talk ) 12:33, 20 August 2010 (UTC)
 * Google is your friend. First result. Rocket000 (talk) 19:28, 20 August 2010 (UTC)


 * , of course. It would be more better for new users. JenVan ( talk ) 12:46, 20 August 2010 (UTC)
 * But Commons talk pages (at least those for individual images) are almost entirely used only by the most experienced users, and that is clearly not primarily a matter of difficulty, since that is not the pattern for talk pages of Wikipedia articles. - Jmabel ! talk 03:06, 21 August 2010 (UTC)
 * . Yes, lqt are pretty good for a small number of short discussions on a page. But they are making discussions enormously large if there is a large number of brief comments. Even if these comments are very short (like just “Support” or “Oppose”), each comment takes some three or four lines, so that 10 comments already take a full screen. This system is more appropriate for something like comments to blog entries than for wiki-discussions as it hides some comments (unlike blogs, comments here are usually not senseless), is very difficult to administrate (deleting/protecting such pages is a problem) and has too many bugs (like problems with wiki-markup in headers, which makes translatewiki:Project:Translator rather unattractive) — NickK ( talk ) 12:48, 20 August 2010 (UTC)
 * I can't say I'm particularly enthusiastic about this feature, but testing it in a "real" context and gaining feedback from real-life experience can only lead to a much better integration when/if it goes mainstream.
 * . – Tryphon ☂ 12:56, 20 August 2010 (UTC)


 * We need a better discussion system, too many people are locked out by the learning curve of the present system. LT has its limitations, but unless it starts deploying, these cannot be sorted out. --Vigilius ( talk ) 13:27, 20 August 2010 (UTC)
 * "enable LiquidThreads on some test pages" - this does not mean support for an migration, yet. Enabling it on test pages is a good thing to try it out in a real wiki with my user settings and such. Please tell us, where to test then. Cheers --Saibo ( Δ ) 13:41, 20 August 2010 (UTC)
 * the current system has its flaws, but it is reliable and the same as the other wikis.--GrapedApe ( talk ) 13:43, 20 August 2010 (UTC)
 * unless look and feel will be not adjusted to style of wiki skins. It's task of Usability Team if I'm not mistaken.--EugeneZelenko ( talk ) 14:56, 20 August 2010 (UTC)
 * Same reason as Vigilius. --Kozuch ( talk ) 15:46, 20 August 2010 (UTC)
 * I'm on the fence about this. LQT seems like a very good concept, and definitely represents the general direction Wikimedia discussions should go. The promised functionality is a great leap over where we are, will ease the way for new users, and will reduce the confusion inherent in large and complex discussions. And I don't share the allergy some folks here have to pioneering an changed/improved approach on the Commons. THAT SAID, from the comments above (esp. Nemo's) it sounds an awful lot like LQT is still an alpha product, not even advanced to beta yet. I'm okay testing out a beta in production systems, but an alpha needs to stay in the labs until it's mostly baked. Even restricting it to only a few production pages is not a good approach. But I'm not in any way an expert in dev control standards and I have hardly read comprehensively on the status of the LQT dev effort. Maybe someone else could clarify whether I'm correct in my application alpha/beta definitions? &mdash;Werewombat ( talk ) 15:57, 20 August 2010 (UTC)
 * please don't. Per above opposers. I find them not very practical & rather confusing. --Dferg ( talk · meta) 16:08, 20 August 2010 (UTC)
 * lets give it a try. Amada44   talk to me 16:14, 20 August 2010 (UTC)
 * Very cluttered and makes pages several times larger. Long threads will be unreadable, and hiding comments is certainly not a good idea. I'm not in favor of heavy use of AJAX because of browser and platform compatibility issues, not mentioning load times on slower connections, so instead of making talk pages accessible to more people, we could end up doing the opposite. If the main disadvantage of the current system is inaccessibility to new comers, why don't we improve it in that regard without changing it completely? For example adding automatic signatures when saving a new section, maybe adding a "reply" link at the end of signatures, or improvement to the editor interface. -- Orionist ★ talk  16:43, 20 August 2010 (UTC)
 * Before taking position, I would suggest first a larger scale experiment on a wiki where they have many discussions with many participants, such as on en:wiki. I don't feel that Commons is a place to do such experiments. --Foroa ( talk ) 17:00, 20 August 2010 (UTC)
 * - I like them and they work well on the liquidthreads test wiki.   — Jeff G. ツ 17:27, 20 August 2010 (UTC)
 * - I don't see a real benefit here. Perhaps, as suggested, we can get en.wp or some other pack of gullible fools to perform a large-scale test. -mattbuck (Talk) 17:39, 20 August 2010 (UTC)
 * overdue. --rtc ( talk ) 18:04, 20 August 2010 (UTC)
 * - I personally find liquid threads unnecessary and confusing. Tiptoety  talk 19:08, 20 August 2010 (UTC)
 * LiquidThreads is amazing. --Yair rand ( talk ) 19:14, 20 August 2010 (UTC)
 * Unnecessary and I don't like the current design at all. Let's wait for en.wp or some other major wiki this time. Rocket000 (talk) 19:28, 20 August 2010 (UTC)
 * What is a "major" wiki? en.wn, en.wikt, strategywiki, Mediawiki, and translatewiki are already using it, and pt.wb, sv.ws, se.wikimedia, and Hungarian Wikipedia have requested it. Are any of these "major" wikis? :) --Yair rand ( talk ) 19:37, 20 August 2010 (UTC)
 * Not really. I guess I meant a large Wikipedia, i.e. a site that's usually a new user's first wiki experience (where they learn things like commenting). Rocket000 (talk) 19:43, 20 August 2010 (UTC)
 * why not? it seems good.. let's try it :D --Pino723 ( talk ) 19:40, 20 August 2010 (UTC)
 * A potentially helpful experiment. Let's give it a try. Steven Walling 20:46, 20 August 2010 (UTC)
 * per NickK and Abigor --by Màñüé£†¹5 talk 22:31, 20 August 2010 (UTC)
 * . It's got performance issue for me.  As an example,  spends 45 seconds formatting the page after it loads; I'd hate to see what it would do on some of the longer discussions here.  It's also not too Lynx-friendly: it works, but each comment and associated tools take up so much vertical space that I can only see two or three comments per page. --Carnildo ( talk ) 22:36, 20 August 2010 (UTC)
 * This is supposed to be an improvement? The design is awful and the threads could actually lead to more confusion and therefore less participation than the present system. Experiment by all means, but please don't introduce this here as it is. Personally I never even realised there was a problem - apparently - with the present system, until now. Anatiomaros ( talk ) 22:55, 20 August 2010 (UTC)
 * There's still a lot more development to go on LiquidThreads before it's ready for primetime. Might be best to wait a while longer. Kaldari ( talk ) 23:50, 20 August 2010 (UTC)
 * As Ryan notes, LiquidThreads is under continued development. We've enabled it in production on a few wikis, and we believe that MediaWiki badly needs a next-generation discussion system that's easy, fast, and enjoyable. LiquidThreads still has quite a few quirks at this stage, so I would primarily recommend it for narrowly defined use cases (e.g. a new user help forum). If you're interested in LQT's ongoing development, please provide feedback on the proposed redesign.--Eloquence ( talk ) 01:34, 21 August 2010 (UTC)
 * Not a real benefit, no real need. Some technical issues (speed, etc., I've had it "crash" on me before), and logistical questions about integration/adaption by other users make it a big hassle for an answer to a nonexistent problem. On the English Wikinews, it is used for user comments only, not talk pages, and I think that is a good application. Here, there is no need.  fetch  comms  ☛ 00:11, 21 August 2010 (UTC)
 * Weak oppose. I wouldn't scream if consensus went that way, but personally I see no significant upside, and I find it a bit annoying. - Jmabel ! talk 03:04, 21 August 2010 (UTC)
 * I agree with Rocket000. And I'm not sure whether lqt will be efficient for Commons. Discussions about important topics is usually accompanied by many users' comments. I'm concerned the scroll bar will become too long and in severe cases, browser might be crashed in low-performance computer. – Kwj2772 (msg) 14:18, 25 August 2010 (UTC)
 * I found a new bug. LiquidThreads's signature detection is unfunctional without JavaScript. And while testing the extension without JavaScript. It was very hard and slow to use. – Kwj2772 (msg) 14:36, 25 August 2010 (UTC)
 * Useful --minhhuy*= ( talk ) 06:26, 21 August 2010 (UTC)
 * In my view superfluous eye candy. As Dschwen stated: the resulting discussion pages are not more clearly structured than what we have now. --High Contrast ( talk ) 11:25, 21 August 2010 (UTC)
 * for now: Let's wait until the issues are sorted out some more, e.g. mobile phone support and bug fixes. No point testing it when we already know quite a few bugs. Further, it doesn't seem to support right-to-left languages, which is a bad thing on a multi-lingual project, even if they're a small part of our userbase. Adam Cuerden ( talk ) 12:41, 21 August 2010 (UTC)
 * per Trần Nguyễn Minh Huy --shizhao ( talk ) 13:34, 21 August 2010 (UTC)
 * I like having a reply button Jane023 ( talk ) 13:38, 21 August 2010 (UTC)
 * Please, please keep it simple. The plain text is good enough - it's fast, it's easy, it's reliable. Throwing in JavaScript eye-candy is only going to slow down the interface, create more bugs and I'm not even convinced it would be easier to use (how hard is it to type or read plain text as now anyway??). I completely agree with Fetchcomms - "a big hassle for an answer to a nonexistent problem". Laurent ( talk ) 15:49, 21 August 2010 (UTC)
 * It's fantastic. These talk pages suck so hard compared to Lqt. Siebrand 16:54, 21 August 2010 (UTC)
 * The talk interface is not some sacred formula, and can be very cumbersome with long discussions, so yes, let's give this a try.-- Patrick {o Ѻ ∞} 17:02, 21 August 2010 (UTC)
 * I think quite some of you have clearly misunderstood the proposal. The plan is to test this on a few' talk pages and work out the problems still preventing it from enabling it on all talk pages. It's not the idea to enable this on all pages. --The Evil IP address ( talk ) 17:33, 21 August 2010 (UTC)
 * Ooh, shiny! But no. Dschwen, Carnildo, Adam Cuerden and others have raise serious doubts and nobody seems to have a compelling argument in favour. Why bother testing something which is years away from being remotely useful? Waste of time. Angus McLellan (Talk) 17:37, 21 August 2010 (UTC)
 * for "test on a few talk pages". Geagea ( talk ) 18:12, 21 August 2010 (UTC)
 * Why do we need to have a more complex system? Editing a talk page with LiquidThreads produces more complexity when you're at Special:Contributions: rather than going to a user's talk page on which you've commented, you have to go to the thread and then to the user's talk page.  Moreover, if you're responding to multiple sections of a talk page, you have to make multiple edits, rather than just one.  Nyttend ( talk ) 18:26, 21 August 2010 (UTC)
 * this system don't seems comfortable for me. Анастасия Львоваru (ru-n, en-2) 18:58, 21 August 2010 (UTC)
 * The LiquidThreads is a solution for many-many non-existing problems. I think the present system need no change, the newcommers are abel to use it, just like the older contributors. --Beroesz ( talk ) 18:59, 21 August 2010 (UTC)
 * Limited Support - to enable this LiquidThreads on some test pages as the headline says. I recognize that this system is powerful, but some aspects of it can be confusing, and I think that a test should be a two-way street, with some feedback going from Commons to the developers of LiquidThreads. Wnt ( talk ) 19:05, 21 August 2010 (UTC)
 * The current system is conceptually simple. Keep it that way. Everybody is used to the present way and the problems are not worth rocking the boat. Also my limited experience with them at the strategy wiki is that they are slow, clunky, and slightly confusing. Jason Quinn ( talk ) 19:21, 21 August 2010 (UTC)
 * Matt ( talk ) 19:52, 21 August 2010 (UTC)
 * oppose, working with lqt on a WMDE wiki is quite annoying. Current talk pages allow more structured work. Kind regards, —DerHexer (Talk) 20:55, 21 August 2010 (UTC)
 * I don't wish to vote against the new technology, but I'm not sure that it is proper one for this very moment. It should be more compatible with the current look'n'feel. The texts should be more condensed, like current discussions, and there should be a compatible history view mode. So I support LQT, but NOT NOW YET. Dr Bug ''(Vladimir V. Medeyko) 00:30, 22 August 2010 (UTC)
 * per above. I don't believe there's anything wrong with our current system.  If it ain't broke, don't fix it.  - F ASTILY  (T ALK ) 00:30, 22 August 2010 (UTC)
 * There really isn’t anything wrong with the current version (though it does get kind of sloppy), but it doesn’t hurt to give it a try. Azcolvin429 ( talk ) 03:02, 22 August 2010 (UTC)
 * I don't mind testing LiquidThreads on a small scale, so uptill here you may consider this point a "support". However, I know too little about the software. Several of the comments above suggest that LiquidThreads may be very slow, may not work on mobile devices, may not offer the information density of current discussion pages, may be less fit for very short discussions or information exchanges, and may have a user interface which is very different from the usual wiki interface. Each of these problems alone would be enough for me to oppose a large-scale application of LiquidThreads on the longer term. It should be possible to solve the issues within the current system. Besides, it is still unclear to me whether it is possible to use wikisyntax in LiquidThreads. I consider that an absolute must as well.
 * Just test it here. I made an example for you: here. Note: this an direct(!) link to my answer in a long discussion (linked there on top of the page) - try this with the current system. This poll here is just about testing (no customization without testing) lqt in a real environment not about using it here. Cheers --Saibo ( Δ ) 16:27, 22 August 2010 (UTC)
 * OK, but is there any option to see what you have answered to? The “Parent” button does not work OK — NickK ( talk ) 18:07, 22 August 2010 (UTC)
 * See the line on top and it's links: "Fragment of a discussion from Talk:LiquidThreads testing". The "discussion" link shows you to the associated thread and the second link shows you the whole diiscussion page. The "parent" button seems only to work when viewing the whole thread - maybe it can be hidden when displaying (the special case) only one comment. It shows you the comment I answered to (only useful in long discussions where the parent comment is far away on the top of the page). Cheers --Saibo ( Δ ) 19:14, 22 August 2010 (UTC)


 * , perhaps allow here at village pump.--Avala ( talk ) 19:22, 22 August 2010 (UTC)
 * Strongly a general use of this system. Old style discussion pages have the unbeatable advantage that you see the whole discussion at once and that you don't have to click through series of posts and get repeating quotes and the like. Wiki discussion are much more readable, unless they grow to a length of more than a few screen pages. This system IMO only makes sense for use on heavily segmented pages with hundreds of very long discussions.User:Chrkl
 * It seems to bring us further and further away from the scope of wikipedia/wikimedia --Havang(nl) ( talk ) 20:00, 22 August 2010 (UTC)


 * Symbol support vote.svg Support for experimentally enabling this extension on some pages. Lqt is very useful. When it reaches a stable status, it can be enabled for all pages. Srhat ( talk ) 21:48, 22 August 2010 (UTC)
 *  upstate NYer  02:06, 23 August 2010 (UTC)
 * on the fence collecting splinters, anything that reduces participation is a concern, running a test on a few pages is interesting but how would it run parralled to ensure everybody gets to participate. A trail on somehwere like FPC where a duel discussion can occur? Gnangarra 10:19, 23 August 2010 (UTC)
 * Symbol oppose vote.svg Oppose&mdash;extension is not mature and it's an attempt to make MediaWiki anything and everything. There are plenty of web applications out there that provide threaded discussions without needing to reinvent the wheel. Adrignola ( talk ) 12:36, 23 August 2010 (UTC)
 * , for now atleast. There are way too many issues at the moment. The answer for testing was given in the opening, so I see no reason to enable it here for testing. "You can test the extension here". –Krinkletalk 13:17, 23 August 2010 (UTC)
 * I can see why people would like to support this extension. But I have two problems. First, pages set up this way encourage all the same problems that threaded discussions elsewhere tend to have ... eventually they get lost in themselves and become unproductive very quickly. In our present system that has evolved into common conventions over time without the help of any software, it is usually easy to tell who is responding to whom without clicking back and forth. That's not always the case with threaded discussions. Second, it might encourage the sort of new user who thinks this is just a place to hang out and chat. We have enough users who think Wikimedia projects are social networks without encouraging them. Daniel Case ( talk ) 05:06, 24 August 2010 (UTC)
 * A trial would not hurt, perhaps on a message board-type page like Village Pump. If we don't like it we don't have to continue. -- Mattinbgn/talk 07:36, 24 August 2010 (UTC)
 * Yes we should at least give the new Liquid Thread system a trial. If it does not work out we can always go back to the old wiki system. Just Imagine if we succeed in creating a better discussion system then that will be for the global good. The new users are the ones that face maximum hurdles getting used to the wiki concept. I am still learning. The future of the wiki project depends on the new users so making it easier for them is what we should be aiming at.  Pattanaik  --Pattanaik ( talk ) 08:23, 24 August 2010 (UTC)
 * , does not appear to have any serious benefit or drawback. Stifle ( talk ) 08:23, 24 August 2010 (UTC)
 * , it's a good extention. --DS- fax 10:27, 24 August 2010 (UTC)
 * 'If it ain't broke...' Jebus989 ( talk ) 10:46, 24 August 2010 (UTC)
 * Bleh. This is a wiki. 85.112.147.118 18:28, 24 August 2010 (UTC)
 * Some users seem to like features offered by liquid thread and dislike the freedom offered by the standard wiki text, why not let them enable it on their talk pages? -- User:Docu
 * Because others have to leave them messages? And it would probably break all scripts and bots that add user messages (making them work for both types would be quite a challenge I think). There's no way to do it the old fashion way on pages that use it, otherwise, I wouldn't mind it as an alternate way of commenting. Rocket000 (talk) 20:36, 24 August 2010 (UTC)
 * re "scripts and bots", wouldn't that be another reason to test it? --  Docu   at 05:07, 25 August 2010 (UTC)
 * Sure, but that's why we have test wikis. There's plenty of known bugs that need to be fixed, it's too slow for long pages, it's supposed to be redesigned, etc. It's just not ready for production use. (But obviously some people are ok with using it anyway so this is just one opinion.) Rocket000 (talk) 13:33, 25 August 2010 (UTC)

Now I kwow some people find wikisyntax the best and wysiwyg crappy and blablabla..........wake up guys!!!! Not everybody in this world is a computerexpert.....
 * . I've tried this on . It's neat; the future. Cheers, Jack Merridew 20:34, 24 August 2010 (UTC)
 * confusing and completely useless. --Siciliano Edivad ( talk ) 21:45, 24 August 2010 (UTC)
 * wikpedia needs a better system for dicussions If we want new people to join, we have to make things eassier, this wel help.
 * For one "LiquidThreads is currently undergoing a redesign." It's not cross-compatible with what we have, so you can't just paste part of a discussion from a normal talk page to LiquidThreads page. We have one coherent system; let's keep it that way.--Prosfilaes ( talk ) 22:59, 24 August 2010 (UTC)
 * The search box alone justifies adoption.Bdell555 ( talk ) 07:25, 25 August 2010 (UTC)
 * We can try out a village pump over here lqt_labs:Wikimedia Commons:Village_pump. –Krinkletalk 13:52, 25 August 2010 (UTC)


 * It freezes my computer. I had to stop working on strategy: for that reason. I'm not 100% sure but I guess it is no longer possible to refer to past talks with diffs, if we implement that system. The fact that very old talks (even those older than 1 year ago) can be reopened is not a good idea. I prefer old talks to be kept as closed archives. I also dislike the potential competition between different threads to be the "first thread" at the top of the page. This is not a good way of talking about serious matters. Forums are OK for chit chat, but not for serious talks. Teofilo ( talk ) 14:02, 25 August 2010 (UTC)