Hi all,
With the Foundation's support, I've spent the last few months churning away at LiquidThreads [1], a new discussion system that is proposed for use on Wikimedia projects.
Essentially, it's an attempt to marry the radical openness of the wiki paradigm with the usability and practicality of a forum-like system. As the name implies, LiquidThreads is designed to allow any user to easily refactor discussions while maintaining edit history, to edit other users' comments, and to collaborate on a summary of an ongoing discussion. LiquidThreads also brings many standard communication features lacking from wiki discussion pages, such as watching and protecting individual discussion threads, RSS feeds of comments in a discussion or on a discussion page. In the world of online communication, its approach is entirely unique.
LiquidThreads has been in alpha testing on Wikimedia Labs [2] for several months, and, more recently, it's been used in a production context on the strategy wiki, where it has been quite well-received. It's been easy to run these smaller trials, as the extension allows the activation and deactivation of LiquidThreads discussions on individual pages with a simple parser function.
While there are still some issues remaining before wider trials, I believe I can resolve most of them quite quickly (within a few weeks when my vacation finishes at the end of next month), and I'd like to get the ball rolling in proposing small-scale trials on some of the larger wikis, so that a full discussion can be had, and so that adjustments can be made on the basis of ongoing feedback. I'd especially like to see LiquidThreads used on some of the higher-traffic discussion pages on English Wikipedia (such as the technical village pump), and progressive rollout on some of our mid to large sized wikis.
So, I'd like to encourage you to have a play with LiquidThreads, either on the strategy wiki or on the test site (which generally runs a newer version). Tell me what you like about it, and (far more importantly) what improvements you think it needs before we can expand our trials to wider parts of the Wikimedia Universe, and perhaps move towards a full rollout of this very exciting technology.
I should give the following caveats about LiquidThreads as it stands. These are all issues that I intend to address before any trial expansion occurs. * Presently the system is somewhat vulnerable to abuse. I intend to make changes to the way signatures work, and improve tracking and listing of thread actions by specific users. * While LiquidThreads allows for thread summaries and discussion headers, the system does not currently have support for collaboratively-edited posts which are unsigned or signed by a group of people. These are a key piece of any decision-making framework, and I intend to make adjustments to make this possible. * There is no support for embedding LiquidThreads discussion pages on other pages. * There are plenty of minor interface issues which I intend to clean up.
Feedback is best directed to the dedicated Feedback page [3], or, alternatively, to bugzilla [4] (although before filing a bug, you should check the list of existing LiquidThreads bugs [5]).
[1] http://www.mediawiki.org/wiki/Extension:LiquidThreads [2] http://liquidthreads.labs.wikimedia.org [3] http://liquidthreads.labs.wikimedia.org/wiki/Feedback [4] https://bugzilla.wikimedia.org/enter_bug.cgi?product=MediaWiki%20extensions&... [5] https://bugzilla.wikimedia.org/buglist.cgi?product=MediaWiki%20extensions&am...
"With the Foundation's support"
Is there a board resolution on this matter ? I think the question of how we talk to each other is a question even more important than the license problems. As there was a referendum on the license change, I think there should be a referendum on the talk pages' software change.
"it's been used in a production context on the strategy wiki,"
This is an alternative wording for saying that the Strategy wiki's users have been used as guinea pigs for software experiments without their consent. Being treated as a guinea pig means in my case that my computer freezes. I want apologies for this and that the software is removed from the strategy wiki.
This software should be called "Liquidthreat" because it is a threat to community life. For example the disparition of fixed tables of contents and archiving numbers, preventing to memorize where a talk page you have contributed to or enjoyed reading is located. For example the "protecting individual discussion threads" feature which is an invitation to censorship. For example the "summary" feature which is an invitation to gross misinterpretations of other people's opinions. For example the possibility to reactivate old talks from two years ago, instead of linking to their location in their archive as a reference and starting a new fresh talk, contributing to a prospect of never-ending "monster talks"...
The worst is probably the waste of screen space which prevents people with a small screen to "understand" the structucture of the talks, and to find quickly which message an answer is supposed to be answering, and who is the last person who talked. Even finding the edit box in the middle of a long page, playing with the vertical scroll bar, is not easy.
Wiki talk pages are dense, and this enables to quickly discriminate between what is important and what is not.
Wiki talk pages are easily turned into archives and can subsequently be used as references.
Wiki talk pages as they are now are good. Don't kill them.
2009/12/16, Andrew Garrett agarrett@wikimedia.org:
Hi all,
With the Foundation's support, I've spent the last few months churning away at LiquidThreads [1], a new discussion system that is proposed for use on Wikimedia projects.
LiquidThreads has been in alpha testing on Wikimedia Labs [2] for several months, and, more recently, it's been used in a production context on the strategy wiki, where it has been quite well-received.
On 12/19/2009 09:25 AM, Teofilo wrote:
Wiki talk pages as they are now are good. Don't kill them.
Having not used LiquidThreads yet, I can't speak to your experience with it. But the existing discussion system is a usability nightmare.
As a software developer, I'm perfectly comfortable dealing with its dark mysteries. I've spent tens of thousands of hours typing mysterious codes into giant files interpreted by unforgiving machines. But for the 98% of humanity that doesn't have much technical background, our discussion system comes across as somewhere between perplexing and actively hostile.
For proof, just look at how many software packages have copied our approach to discussions. As far as I know, the number is zero. The common solutions seen in forums, blogs, and community sites across the internet have a lot in common with one another, and are rightly nothing like what we have.
I have no idea whether LiquidThreads is the right solution, but if we want to broaden participation, increase the number of active editors, and improve our image, we definitely need something better than what we have. Hopefully we can do that in a way that keeps the benefits of the current system, but I think it's vital to mitigate the many and glaring current flaws.
William
mysterious codes? All that is needed is knowing how to indent and sign.
David Goodman, Ph.D, M.L.S. http://en.wikipedia.org/wiki/User_talk:DGG
On Sat, Dec 19, 2009 at 1:17 PM, William Pietri william@scissor.com wrote:
On 12/19/2009 09:25 AM, Teofilo wrote:
Wiki talk pages as they are now are good. Don't kill them.
Having not used LiquidThreads yet, I can't speak to your experience with it. But the existing discussion system is a usability nightmare.
As a software developer, I'm perfectly comfortable dealing with its dark mysteries. I've spent tens of thousands of hours typing mysterious codes into giant files interpreted by unforgiving machines. But for the 98% of humanity that doesn't have much technical background, our discussion system comes across as somewhere between perplexing and actively hostile.
For proof, just look at how many software packages have copied our approach to discussions. As far as I know, the number is zero. The common solutions seen in forums, blogs, and community sites across the internet have a lot in common with one another, and are rightly nothing like what we have.
I have no idea whether LiquidThreads is the right solution, but if we want to broaden participation, increase the number of active editors, and improve our image, we definitely need something better than what we have. Hopefully we can do that in a way that keeps the benefits of the current system, but I think it's vital to mitigate the many and glaring current flaws.
William
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
Indeed. I am aware of the usability problems, but the talk pages are hardly the biggest problem. How much more complicated is LiquidThreads. There is the concept of a thread as such, I see a "first page" and so on, a roll down menu that hides a lot of mysterious functions... I find it especially annoying that the columns of a thread are so extremely large: http://commons.wikimedia.org/wiki/File:New_messages_-_Strategic_Planning.png I must say that it is a very bad idea to confront people with such a change without asking them, and even with a beta version that is obviously not working yet. Is there a decent turorial, anyway? Sorry, but I am not a software specialist. Kind regards Ziko
2009/12/19 David Goodman dgoodmanny@gmail.com:
mysterious codes? All that is needed is knowing how to indent and sign.
David Goodman, Ph.D, M.L.S. http://en.wikipedia.org/wiki/User_talk:DGG
On 12/19/2009 10:54 AM, David Goodman wrote:
On Sat, Dec 19, 2009 at 1:17 PM, William Pietriwilliam@scissor.com wrote:
As a software developer, I'm perfectly comfortable dealing with its dark mysteries. I've spent tens of thousands of hours typing mysterious codes into giant files interpreted by unforgiving machines. But for the 98% of humanity that doesn't have much technical background, our discussion system comes across as somewhere between perplexing and actively hostile.
mysterious codes? All that is needed is knowing how to indent and sign.
David Goodman, Ph.D, M.L.S.
For a person with a PhD in molecular biology, a master's degree in Library Science, and 3 years experience on Wikipedia, I'm sure it all seems pretty transparent. As somebody who played with punch card machines in kindergarten and was coding well before my voice changed, it sure looks that way to me. But we're pretty far out on a few different bell curves.
I haven't seen an actual usability study on our current discussion system, but I have seen and done plenty of other usability studies, and my guess is that you'd get a combined drop-out plus failure rate of over 80% for first-time users. Followed by predictable reactions: discouragement, feeling dumb, and taking both the system and our community as hostile or unwelcoming.
Whether we want to attract less technical and/or less persistent users is a reasonable question. (My view: we should.) But from the usability experts I've worked with, I think the nicest reaction they'd give to our current discussion system is politely disguised horror. If people are skeptical of that, I'd encourage them to reach out to our very sharp usability team; I'm sure they have opinions on this, and possibly some data.
William
I did not write that, except for the final sentence--The rest was an earlier comment by someone who actually knows programming, not my elementary awareness of html and the rudiments of regular expressions. The only software I've ever developed is some VBA macros for Excel.
I was saying that just the most elementary knowledge is enough for talk pages. Of all the parts of Wikipedia syntax, it's the easiest. The problems for users in learning things is elsewhere. Even things I do know how to use, like the cite templates or tables, I find too complicated to bother with. What I think the usability studies show to be the hardest--and also my own experience teaching raw beginners--, is figuring just how to edit in the first place. We think we made it easy, but they still don;t find it.
As for keeping track of discussions generally, the exchanges here show the difficulties, and this one is as good an example as any for how easily it is to get confused (in this case I think what did it is other comments coming between what I was answering and my own reply--the same problems as caused by edit conflicts. I'm not sure there is any way to sort it out when a number of people are talking about the same thing at the same time.
David Goodman, Ph.D, M.L.S. http://en.wikipedia.org/wiki/User_talk:DGG
On Sat, Dec 19, 2009 at 4:24 PM, William Pietri william@scissor.com wrote:
On 12/19/2009 10:54 AM, David Goodman wrote:
On Sat, Dec 19, 2009 at 1:17 PM, William Pietriwilliam@scissor.com wrote:
As a software developer, I'm perfectly comfortable dealing with its dark mysteries. I've spent tens of thousands of hours typing mysterious codes into giant files interpreted by unforgiving machines. But for the 98% of humanity that doesn't have much technical background, our discussion system comes across as somewhere between perplexing and actively hostile.
mysterious codes? All that is needed is knowing how to indent and sign.
David Goodman, Ph.D, M.L.S.
For a person with a PhD in molecular biology, a master's degree in Library Science, and 3 years experience on Wikipedia, I'm sure it all seems pretty transparent. As somebody who played with punch card machines in kindergarten and was coding well before my voice changed, it sure looks that way to me. But we're pretty far out on a few different bell curves.
I haven't seen an actual usability study on our current discussion system, but I have seen and done plenty of other usability studies, and my guess is that you'd get a combined drop-out plus failure rate of over 80% for first-time users. Followed by predictable reactions: discouragement, feeling dumb, and taking both the system and our community as hostile or unwelcoming.
Whether we want to attract less technical and/or less persistent users is a reasonable question. (My view: we should.) But from the usability experts I've worked with, I think the nicest reaction they'd give to our current discussion system is politely disguised horror. If people are skeptical of that, I'd encourage them to reach out to our very sharp usability team; I'm sure they have opinions on this, and possibly some data.
William
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
On Sun, Dec 20, 2009 at 1:36 AM, David Goodman dgoodmanny@gmail.com wrote:
I did not write that, except for the final sentence--The rest was an earlier comment by someone who actually knows programming, not my elementary awareness of html and the rudiments of regular expressions. The only software I've ever developed is some VBA macros for Excel.
David, the part William quoted was his own prior post. I think he was replying to what you had actually written, but neglected to include it in his quote.
~Nathan
On 12/19/2009 10:36 PM, David Goodman wrote:
I did not write that, except for the final sentence [...]
Sorry; that was my editing error. I was trying to reply while providing more of the context; specifically the part of my message I thought you were replying to. That clearly didn't work!
I was saying that just the most elementary knowledge is enough for talk pages. Of all the parts of Wikipedia syntax, it's the easiest. The problems for users in learning things is elsewhere.
I agree that there are big problems elsewhere; I'm just trying to say there are also significant usability problems with discussions.
My broad point is that although the talk page may only use the most elementary parts of Mediawiki, and therefore seem easy to us, it still has very low usability compared with typical discussion systems on the Internet. In placing a much smaller burden on the software, we have placed a much larger burden on the user.
Even if our current discussion system were somehow superior, it's still very different than other systems, which is in itself a design mistake. Indeed, it's one of the most common mistakes in web design, appearing at #8 on Jakob Nielsen's top 10 list of design mistakes:
http://www.useit.com/alertbox/9605.html
If we want broad participation, we have to accept it in a way that most people are familiar with. Whether we want broad participation is a reasonable question, as is what to do with that participation when we get it.
William
On Sat, Dec 19, 2009 at 9:25 AM, Teofilo teofilowiki@gmail.com wrote:
This is an alternative wording for saying that the Strategy wiki's users have been used as guinea pigs for software experiments without their consent. Being treated as a guinea pig means in my case that my computer freezes. I want apologies for this and that the software is removed from the strategy wiki.
I'm very sorry that you've had trouble with LiquidThreads. If we want participation, then the software has to work, and when it doesn't work, that defeats our purpose.
I made the decision to use LiquidThreads on the strategy wiki, knowing full well that it was beta software and that it would have warts. For those of you who have found LiquidThreads to be a barrier, I take full responsibility for that, and I'm doing everything I can to address that. For the rest of you, I thank you. Andrew Garrett, the author of LiquidThreads, has been incredibly diligent in fixing problems and improving the software since installation. Everyone who has contributed to strategy has been very patient in reporting problems, learning the nuances of the tool, and most importantly, using the tool to engage in strategic discussion, which is ultimately what this whole thing is about.
To take this discussion onto a more constructive path, I think there are two interesting followup threads:
1. If our goal was to broaden and improve participation on strategy, was LiquidThreads the right decision? 2. How should the decisions to try new things be made?
I'm going to make a few points here, and I encourage people to continue the discussion at:
http://strategy.wikimedia.org/wiki/LiquidThreads
First, was LiquidThreads the right decision? The goal was to broaden and improve participation. There have been hiccups, as Teofilo and Ziko have noted here, and as others have noted on the wiki.
On the other hand, in the two months LiquidThreads has been running, there have been almost 200 unique contributors to the discussion, many of whom were new to strategy wiki and some of whom were entirely new to wikis period. There have been 2,000 total posts, for an average of about 30 a day. Additionally, overall contributions to strategy wiki continues to rise.
Most importantly, the quality of the discourse overall has been outstanding. Contributors have been doing productive work with the help of voices that may otherwise have not participated.
Participation on strategy has been very good since LiquidThreads was installed. It's impossible to be scientific about the causal role that LiquidThreads has played in this, but the notion that LiquidThreads is disastrous, as some have attempted to paint it, is completely ludicrous. Based on actual experience, we can make a strong case that LiquidThreads has been beneficial to this process.
Second, how should the decisions to try new things be made?
One of the themes that has emerged from the strategic planning process is that there seems to be a community-wide paralysis when it comes to trying new things. People fear backlash. Some have espoused the view that every decision should be put up to vote before being made.
I find this ironic and sad and scary, because what makes wikis wonderful is that they are empowering, and the enemy of ongoing success is stagnation.
Ours is the first and best example of doacracy-at-scale. Why is this? Wikis are permissive. (Has there ever been anything more empowering than, "Edit this page"?) Wikis are also forgiving. (They have this beautiful feature called, "Revert.") Permission and forgiveness are what allow innovation to happen and beautiful things to emerge.
If we want to retain this original spirit (which seems to be waning), we first need to acknowledge and honor it. We then need to think about how we can support it. What social and technical infrastructure could be put into place to better support experimentation? Who should be empowered to make these kinds of decisions? How can we as a community learn how to build up rather than tear down?
The Movement Roles Task Force is exploring questions like this, and I would strongly encourage everyone to post their thoughts there:
http://strategy.wikimedia.org/wiki/Talk:Task_force/Movement_Roles
That discussion is using LiquidThreads, so if you haven't tried it yet, that would be an excellent place to start. :-)
=Eugene
Hello, The appraisal of LT is not quite universal; I have my problems with this feature and actually it prevents me from contributing to the strategy wiki. I would have preferred a discussion before forcing people to use that kind of tools/toys. Kind regards Ziko
2009/12/16 Andrew Garrett agarrett@wikimedia.org:
Hi all,
LiquidThreads has been in alpha testing on Wikimedia Labs [2] for several months, and, more recently, it's been used in a production context on the strategy wiki, where it has been quite well-received.
wikimedia-l@lists.wikimedia.org