a couple of weeks ago, David McCabe, the original developer of
LiquidThreads, contacted me and indicated that he would be available
for long-term development work on LiquidThreads. LQT is of strategic
interest to the Wikimedia Foundation: having a user-friendly
discussion system - not necessarily to replace talk pages, but at
least to have in place in highly public-facing areas such as the WMF
website - could really help us. So, we're willing to sponsor
development work on LQT on a going-forward basis, with 10 hours a week
of David's time.
We need to figure out where to prioritize development work, and it
would be good to hear from the WikiEducator community what the major
gotchas are. Some I can think of:
* Deletion is not ideal because it leaves admin-visible "stubs", and
perhaps commenters should be able to delete their own comments.
* Talk page notification can get cluttery and annoying when there's
lots of new comments.
* Quoting in replies could be made more intuitive.
* Recent changes log display could be improved.
Are there other things which should obviously be fixed, or improved?
Are there fundamental challenges that you see with the LQT approach?
To recap, the main benefits of a system like LQT as opposed to the
traditional wiki talk page are:
* In a wiki talk page, to properly position and indent a comment, you
have to manually move the cursor to the right spot and add the
indentation syntax before you start typing. In LQT, you just hit
"reply" where you want to respond, and the system does everything else
automatically. New users often don't understand how to place comments
correctly, which means that it can be confusing to understand a
thread.
* In a wiki talk page, you always have to sign your comments - in LQT,
the system signs your comments for you. New users often don't know how
to sign and thereby leave comments whose origin cannot be immediately
identified.
* Because a wiki talk page is unstructured, raw text, there's no way
to sort comments, or to do anything with an individual comment in an
automated fashion. In LQT, threads can be sorted, each comment has an
individual edit history, threads can be more systematically watched,
etc.
I also want to caution that LQT is built exactly for the kinds of
users who _don't_ participate in discussions about its merits: it's
meant to help newbies to participate in discussions without getting
lost in wiki syntax. Does it achieve that goal, and if not, why not?
It would be interesting to hear more about the perceived
disadvantages, and to try to work towards fixing them, now that we
have developer resources available to do so. So, any feedback would be
welcome!
All best,
Erik
--
Erik Möller
Deputy Director, Wikimedia Foundation
Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate
> Not being able to delete or edit replies. I think anyone should be able to
> delete anything - like in a trad talk page.
It's worth noting that not anyone can delete a wiki page, so I'm not
sure why this should apply to LQT threads. The most obvious first
steps seem to be:
1) Make visible deleted posts less annoying to administrators;
2) Allow users to delete their own posts if they have not received any
responses yet.
There may also be some JavaScript tricks we can use to reduce
duplicate posting behavior.
Delete-undelete by anyone creates all kinds of challenges. It's not
inconceivable -- unlike any discussion system I know, LQT has a thread
level history which is the foundation for wiki-like versioning of
deletion operations -- but we should probably keep it simple for
starters.
> I think a simple option to toggle between a LT or
> wikitext view would fix everything.
A page cannot really exist in both states at the same time - the two
are technically fundamentally different. And, a per-page toggle to
decide whether a given talk page behaves as wikitext or as LQT seems
like a potentially huge usability issue to me. Imagine that you run a
wiki workshop, explaining to people how to use LQT (or how to use talk
pages), and then they encounter the opposite system in practice, in a
seemingly arbitrary fashion.
I want us to understand the impediments for LQT discussion and address
them -- to the extent that we, after doing so, still feel the need for
separate wiki style discussion pages, we can probably find ways to
provide them.
> I have not been getting alerts to my email when a talk page changes.
Yes, I think alert mechanisms are the other large category of
improvements. Note that with LQT we can write alerts that are much
more informative than anything that would be based on talk pages,
because only in LQT does a comment have an identity as such. So, we
know
* how many replies there are to a given comment
* who left them
* what the text of each individual reply is
etc., and we could potentially include some of that information in an
e-mail alert.
> Fixing this will be important - and getting the thread posted through to email and
> even being able to reply by email would really enhance the flow of
> discussion in my view.
Yes, an e-mail gateway has been a big dream of mine for a long time.
Again, with a traditional wiki page model, such things are
inconceivably ugly, because you are trying to parse stuff into a page,
instead of being able to machine-address comments reliably.
> Finally, the default where most recent active thread moves to the top of the
> page is very frustrating.
We can change the default; my view would be that the community should
decide what the site-wide default should be.
The work around for us is to set up our own wiki with FCK and ask people to author in there and copy paste what has been created into the Wikied.. now.. getting our own wiki with a responsive admin crew.. looks like I'll be doing this one myself
The work around for us is to set up our own wiki with FCK and ask people to author in there and copy paste what has been created into the Wikied.. now.. getting our own wiki with a responsive admin crew.. looks like I'll be doing this one myself
There is no "wikitalk DB structure". A talk page, from a database
point of view, is _exactly the same_ as an article page. Adding any
functionality to the talk page model is almost impossible, because a
comment (subject, body, signature) does not have a database identity
as such. In fact, because users can use any syntax they want, comments
are often mixed with templates, inline responses, incorrectly indented
or unsigned responses, etc. It's a programmer's nightmare.
LQT treats a talk page as a set of pages, where each comment is (from
a database point of view) the same as a wiki page. That gives us a
whole set of advantages, but obviously leaving the free-form
free-for-all wiki talk page model also creates new challenges.
> Is it possible to choose LT or wikitalk when a new page is first
> created? Then we would really have a UAT of LT vs wikitalk, the usage
> stats would tell all. Particularly if a default could be set on the
> user profile for when a new page is created by the user..
Please see my response to Leigh - I think from a usability and
wiki-educational point of view, the seemingly arbitrary mixing of two
completely different discussion models in the same environment would
be hugely challenging, especially for new users.
> 3) Alerts are really good when they work. Could this all be set up as
> an RSS feed? for both LT and wikitalk? Or is the wikitalk RSS a part
> of another module?
It would be possible to build RSS feeds for LQT. Non-LQT talk pages,
like ordinary wiki pages, have a history RSS feed for all edits.
> 4) Does the sort order of the LT have to be site wide? Could it be
> another option to toggle on the user profile or at the page level?
It's already possible to persistently set your personal preference
using the checkbox next to the sort order. As for a page level
setting, again, I worry about the usability implications: It seems to
violate usability heuristics such as predictability and consistency to
change sort orders from page to page.
Thread:Sandbox
where people could practice LQT and make a tutorial around it?
Cheers
Rob
--
Robert Kruhlak
Burnaby, BC
CANADA
(M) +1 778 230 1875
(E) kru...@gmail.com
User_talk:Sandbox
?
Cheers
Rob
The problem is that a wiki is not designed to be ephemeral. Different
talk page models would continue to exist in the same wiki, and any
user who participates beyond a single course would encounter botth
models. This would trigger the usability issue of having to learn two
different ways to do, essentially, the same thing. Not just in
commenting, but in the entire framework around it.
Take, for example, alerts: LQT implements an alert mechanism based on
single comments & threads. With LQT and talk pages existing in
parallel, user interfaces for alerts would be confusing, as users
would get alerts for LQT replies, but not for ordinary talk page
responses. The same is true for any of the other features we might be
talking about: RSS, e-mail to wiki gateways, and so forth. It's just a
recipe for confusion and collusion to have two completely different
approaches coexist in the same environment.
Yes, it would be nice if there was only a single talk page model, and
the goal of LQT is to be, as much as possible, a drop-in replacement
for talk pages. But while different wikis will find different
solutions, applying two different solutions in the same environment
strikes me as highly problematic.
If WikEd wants to implement a per-page toggle or turn off LQT
entirely, that is obviously its prerogative. My goal is to direct
resources of the Wikimedia Foundation usefully in order to
approximate, as much as possible, the needs of current and potential
future LQT users. I would also like us to get some real research done
with new users into the usability of both systems. If any institutions
on this list are interested in participating in such research, let me
know.
Does LQT actually make the life easier for people new to wiki talk
pages? If the answer is no, then obviously the case for it is a lot
weaker. But if the answer is yes, that would lead to some interesting
questions about the value of friendliness for new users vs.
versatility for existing contributors, etc.
I also hope that LQT could become the foundation for lots of other
very interesting features. Many GMail users love GMail's built-in real
time chat with automatic transcription, but there's nothing magical
about it -- and there's no reason that participants in an LQT
discussion shouldn't be able to switch into real-time conversation
when it makes sense. And e-mail interfaces as envisioned by Leigh are
a distinct possibility.
What I would argue for at this point in time is patience and ongoing
feedback as we try to improve the system. We can always take more
drastic steps later if it turns out to be necessary.
> Currently MediaWiki has two discussion models,
> this is a situation created by and perpetuated by MW. If you are
> concerned about the two different models then why aren't ALL MW
> implementations using LQT?
That would, of course, be the goal. I'm uncertain at this point
whether LQT can meet the needs of all wiki users, but we're certainly
going to try.
What I'd propose is a community review with a firm deadline, say,
December 1 2008 as a start of the review process, and a decision made
by January 1 2009. That way
* We'll have time to make any obvious improvements to the system
without committing ourselves to a never-ending "it'll be great one
day" process;
* We'll also have an opportunity to think about what a review process
like this should look like. It's a problem that the WE community will
encounter again as new features are incorporated, so it seems
important to have a well-defined process for feature review.
Any solution - continuing usage, disabling it, creating toggles,
creating tabs - has very serious implications and I advise against
making such a decision lightly.
I would advise going with workgroup approach, and trying to identify
WE community members who potentially bring different perspectives to
the table, e.g. a more newbie-focused perspective vs. that of the
routine user, but also different expertise to the extent that it is
present: pedagogical expertise, technical expertise, community
building expertise, etc.
Tabs have many of the same issues as toggles.