LQT 2.0

25 views
Skip to first unread message

Erik Moeller

unread,
Jul 17, 2008, 2:25:25 AM7/17/08
to wikied...@googlegroups.com
Hi all,

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

Leigh Blackall

unread,
Jul 17, 2008, 2:42:18 AM7/17/08
to wikied...@googlegroups.com
Hi Eric, this is good news.

The main grief I have with LT is:

Not being able to delete or edit replies. I think anyone should be able to delete anything - like in a trad talk page. Several times I have needed to delete a reply left by someone because it was simply a mistake on their part or was in the wrong place. I think a simple option to toggle between a LT or wikitext view would fix everything.

I have not been getting alerts to my email when a talk page changes. 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. Of course, the watch unwatch options would enable those who prefer not to get email alerts to opt out of this function. For me, I need the email reminder.

Finally, the default where most recent active thread moves to the top of the page is very frustrating. As a course manager, I want a particular thread to always be at the top - such as the welcome thread. I am aware that there are options for controling this from a personal user POV, but I would prefer it if threads generated a contents box and just left it up to the users to organise the ordering - as in a traditonal talk page.

Thanks for the opportunity to offer feedback. I hope the ability to toggle between traditional and LT is enabled soon so we can work around the problems for now.

Leigh
--
--
Leigh Blackall
+64(0)21736539
skype - leigh_blackall
SL - Leroy Goalpost
http://learnonline.wordpress.com

Peter

unread,
Jul 23, 2008, 8:48:47 AM7/23/08
to WikiEducator
Eric,

I completely endorse all the grievances Leigh has mentioned.

In particular, having the ability to toggle LQT off is a VERY
important feature as I have multiple references to where the
discussion regarding a pages content ended up in Google Groups, not on
the discussion page. This is not good as we all know one of the
strengths of the wiki is the ability to review the discussion page.

I have a concern about implementation. I know that when LQT was
implemented it was installed into WE without a previous UAT. Now this
may have worked a year back when the WE community was smaller, I don't
think it is a good idea for today. The WE community has grown and
needs to vet beta features being added to the WE MW infrastructure
(particularly if they are not standard MW features).

Eric, would it be possible to have a small WE user group perform a UAT
on how LQT 2.0 will work before it goes live on the WE production
server(s)?

Thanks,

James Neill

unread,
Jul 23, 2008, 1:31:09 PM7/23/08
to wikied...@googlegroups.com
I endorse all of these comments. LQT is probably the single main issue/reason I'm currently using Wikiversity over Wikieducator. Quite simply - it is confusing and is a beta-quality extension. It tends to break rather than facilitate conversation. As a result, the main hub of conversation defaults to what's easier - Google Groups, which isn't really a great idea for a wiki :(

What's UAT? If it refers to usability analysis, absolutely - take a look over a few user's shoulders as they try to work out LQT and I think a fairly obvious list of needs will become apparent.

Peter

unread,
Jul 23, 2008, 1:42:54 PM7/23/08
to WikiEducator
James,

Good to read others speaking up about this. I do realize the LQT item
has been discussed too much already. I do read that Eric is prepared
to provide resources to get it to a 2.0 state. This is a very good
thing... to be honest I am really waiting for it's 2.1 state.

UAT is a software development term for User Acceptance Test, the
wikipedia page defines it very well;

"User Acceptance Testing (UAT) is a process to obtain confirmation by
a Subject Matter Expert (SME), preferably the owner or client of the
object under test, through trial or review, that the modification or
addition meets mutually agreed-upon requirements. In software
development, UAT is one of the final stages of a project and often
occurs before a client or customer accepts the new system." -
http://en.wikipedia.org/wiki/Acceptance_testing

I'm actually surprise that LQT was originally slipped into WE without
a UAT... Then of course we were a young community and I believe that
WE could have been considered a beta wiki in itself. In the last year
I see WE is now far from beta. And mature software practices need to
apply here.

Cheers,

Wayne

unread,
Jul 23, 2008, 4:57:45 PM7/23/08
to wikied...@googlegroups.com
Hi Everyone, Apology for the long post -- but want to clarify some of the facts.

LQT is clearly an important and topical issue for our community -- and we need to find the best way forward for the WikiEducator family. 

I hope that we can avoid the temptations of siding with one of two camps -- ie the "for" and "against" LQT and continue to work together in finding the solutions that will best serve our collective educational aims.  As with all things there are advantages and disadvantages with regards to the technologies we choose to use.  It's a complex issue with multiple facets and we should weigh up all the issues as we plot our future path.

My suspicion is that more experienced wiki users dislike the technology for all the reasons already stated, and that Newbies find the technology easier to use.  I consider myself to be an average user of wiki technology -- and personally I believe that LQT is a very powerful technology.  At the same time, I value and appreciate the flat and open talk pages of a standard MW install.

I also know that Newbies have difficulty with the open/flat talk pages. They are confused as to the appropriate space where they should respond on a talk page, not sure of the wiki conventions associated with talk pages etc. Newbies tend to find the structure of a more traditional threaded discussion easier to follow.  I base this assertion on my experiences of facilitating face-to-face workshops for Newbies in seven different countries (mainly in the developing world) and a further ten online workshops with the WikiEducator community -- I have interacted with and trained more than 900 Newbies.  Sadly the voice of our Newbies is not a loud voice in our main WikiEducator list -- so I'm taking the liberty of speaking on their behalf :-). The counter argument is that learning to use a standard wiki talk page is a skill that new users should acquire. 

I also recognise that there are significant usability issues with the current LQT implementation -- most notably the personal message manipulation  on your user page --- I really wish we could get this sorted as a priority!!!

A LITTLE HISTORY

When talking about these things, it's worth going back into the history of our decision to implement LQT.

In January 2007, we hosted the first pilot offering of our WikiEducator Newbie Tutorials.  73 participants from about 30 countries enrolled for this pilot offering. I set up this online training session using the Moodle Learning Management system to facilitate online discussions while linking to the content on WikiEducator.  This was back in the days when the number of WIkiEducators who had edited more than 10 times since they arrived was a grand total of 61 people! (Today as of June 2008 we now have 631 people who have edited more than 10 times on WikiEducator.)

During this pilot workshop, there were numerous complaints from participants who were confused by using a Learning Management System in conjunction with the Tutorials on the wiki. At this time COL made a commitment to find a solution to improve discussion functionality of the Mediawiki software. 

The first public announcement of improving discussion functionality was made on 19 February 2007, and COL announced that it would provide resource funding for this project on 21 February 2007 (You can view the history here: http://www.wikieducator.org/WikiEducator_roadmap ). This development was co-funded by COL and Wikia. The announcement to implement LQT was not posted to this list, because on 19 February 2007  there were only 2 registered members -- Myself and Brent Simpson. Both of us were aware of our intentions to improve discussion functionality. Gee -- this is what I like about wikis -- we have a clear history of everything that has happened!

THINKING ABOUT THE FUTURE

WikiEducator distinguishes itself from many of the other wiki projects because we believe in a forward-looking disposition working together to find appropriate and sustainable solutions for e-learning futures. This is a core value of our community project and clearly articulated on our front page. We are the first production wiki to implement wiki ==> pdf technology, the first production wiki to experiment with collaborative video editing and the first production wiki to implement the LQT technology. Being innovators and pioneers means that we have adopted a learn-by-doing approach -- doing our best to iron out kinks and improve through repeated implementation cycles. I think we have done a pretty good job so far given our continued growth and international interest in the project. The industry hit rate for innovation is about 2 successes for every 7 attempts -- our track record is pretty impressive taking these metrics into account. At the same time we have to get better at implementing innovation which I would define as creativity successfully implemented. Sure there are teething problems with LQT -- but given our collective knowledge and experience, I know that we will come up with a solution that is better for all involved.

As communities grow and become more successful -- it becomes harder to innovate and stay ahead of the curve. This is well documented in the research of disruptive technologies as the "innovators dilemma" -- see for example: http://en.wikipedia.org/wiki/Disruptive_technology . I would like to see our WikiEducator family to continue to grow with its forward-looking disposition and to effectively pioneer "next-generation" OER development. I hope that we can avoid the seductive allure of not wanting to try anything new because we feel that if its not broken we don't fix it. I think its better to fix things which are broken because we're prepared to try new approaches -- rather than accepting convention :-).

I think that our capability to innovate will improve once we set up our Phase 2 hosting solution.  Currently, WE runs off a single server -- which has the downside that historically we were forced to run new technologies live.  We did not have the advantage of a beta-WikiEducator environment for the community to experiment with new technologies before moving over to the main production/live environment.  However, this problem will be resolved with our phase 2 hosting where we plan to administer a separate server for new innovations (among other things).  In this way we will be able to implement Peter's suggestions around "User Acceptance Testing".  I do apologise for the delays in setting up our Phase 2 hosting. That said, as an international agency we have rigorous processes around procurement and contracting for services (http://www.col.org/colweb/site/pid/4091 ).  In the long run, I believe that this rigour will contribute to our future success and sustainability of the project.

To date, COL is the sole funder of the technical infrastructure of the WikiEducator project and we have been prudent in our decision-making pertaining to the technology which supports the project. We have also pushed the envelope in putting our hands up to fund and support important strategic developments in wiki technology to widen access to free content -- particularly for those people who may not have connectivity to the Internet.

So let's keep the discussion open and find approaches and ways to build a better future for the global OER initiative. 

I recommend that we should set up a task team to investigate the LQT dimension more thoroughly making sure that we cover all the bases. My gut feel is that we may be throwing out the baby with the bath water -- in the absence of more detailed analysis.

Cheers
Wayne

Peter

unread,
Jul 24, 2008, 3:53:42 AM7/24/08
to WikiEducator
Wayne,

I think that fixing the mail / messaging problem and allowing the
ability to toggle between having LQT or not wouldn't be throwing the
baby out with the bathwater. It would allow us to decide if we wanted
to give the baby a bath in the first place ;) And allow people the
ability to decide if they wanted a threaded discussion or not. To
thread or not to thread, that is the wiki way...

;)
> history here:http://www.wikieducator.org/WikiEducator_roadmap). This
> for example:http://en.wikipedia.org/wiki/Disruptive_technology. I
> would like to see our WikiEducator family to continue to grow with its
> forward-looking disposition and to effectively pioneer "next-generation"
> OER development. I hope that we can avoid the seductive allure of not
> wanting to try anything new because we feel that if its not broken we
> don't fix it. I think its better to fix things which are broken because
> we're prepared to try new approaches -- rather than accepting
> convention :-).
>
> I think that our capability to innovate will improve once we set up our
> Phase 2 hosting solution. Currently, WE runs off a single server --
> which has the downside that historically we were forced to run new
> technologies live. We did not have the advantage of a beta-WikiEducator
> environment for the community to experiment with new technologies before
> moving over to the main production/live environment. However, this
> problem will be resolved with our phase 2 hosting where we plan to
> administer a separate server for new innovations (among other things).
> In this way we will be able to implement Peter's suggestions around
> "User Acceptance Testing". I do apologise for the delays in setting up
> our Phase 2 hosting. That said, as an international agency we have
> rigorous processes around procurement and contracting for services
> (http://www.col.org/colweb/site/pid/4091). In the long run, I believe
> ...
>
> read more »

James Neill

unread,
Jul 24, 2008, 8:44:33 AM7/24/08
to wikied...@googlegroups.com
Thanks for sharing the background, Wayne, appreciate it.

I see nothing wrong with innovation - bring it on. But there might also be something to be said for KISS - and elegance. Maybe something less ambitious around some togglable functions which can facilitate conversation using existing strengths of MW functionality, e.g., a link to fullurl&action=edit&section=new is simple and kind of nice.

Unfortunately, if I can't easily converse on an educational wiki, for me, there is not much point.

Erik Moeller

unread,
Aug 6, 2008, 7:07:53 PM8/6/08
to wikied...@googlegroups.com
Just beginning to work through this - David will probably start with
us later this month.

> 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.

Wayne

unread,
Aug 6, 2008, 7:21:39 PM8/6/08
to wikied...@googlegroups.com
Hi Erik --- this is good news :-).

You want forget about the issues of clearing messages on the User:Talk page. Would be nice if we could have one click to clear all.  Perhaps I'm being a little too fancy here -- but on User:Talk pages the default appear to repeat the whole thread with all its replies. So the user preference for listing according to date gets a little confusing. If I remember correctly -- this sorts according to the date of the thread and not the date of the reply.

Chat to you soon.
Wayne

Leigh Blackall

unread,
Aug 6, 2008, 8:09:39 PM8/6/08
to wikied...@googlegroups.com
I would like to know in more detail what the technical issues are with FCK?

Everyday I try to teach Otago teachers how to use the wiki (we don't even get to the discussion page) and everyday I have to explain why it is so difficult to edit. Knowing that FCK is working on Australian TAFE wikis just fine is very disheartening

Wayne

unread,
Aug 6, 2008, 9:02:10 PM8/6/08
to wikied...@googlegroups.com
Hi Leigh,

The FCK implementation for mediawiki is maturing. I've tested an installation about 2 months ago. 

The moment you enter something that the editor can't interpret properly -- it reverts to saving standard html on the wiki page instead of wiki syntax.  I think this will be a bigger usability issue.  I also noticed a number of rich text feature which were not stable yet.

When we get our phase 2 hosting sorted -- we will set up a beta Mediawiki for putting these technologies through their paces.  Rich text editing is a high priority item for us -- but its going to need a fair chuck of money to get this technology to the point where we can implement.

Look -- I'm coming down to Otago Poly. Why don't you schedule a session with all the folk who are complaining about rich text editing and I'll do my best to respond to the queries. How about Thursday 21 August 2008 at 9:30 --- Arrange an open Q&A session and I'll be there to help answer any questions.

Cheers
Wayne

Leigh Blackall

unread,
Aug 6, 2008, 9:33:11 PM8/6/08
to wikied...@googlegroups.com
Wayne, I am pretty certain that your explanations will not help improve the perception.. it is not so much people complaining (that's me) its getting people to start. If it was easier to begin with, then we'd be getting places in terms of more people more collaboration. But that has already been explained.

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

Wayne

unread,
Aug 6, 2008, 9:46:09 PM8/6/08
to wikied...@googlegroups.com
On Thu, 2008-08-07 at 13:33 +1200, Leigh Blackall wrote:
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
Sure, there are advantages to setting up and maintaining your own wiki.  There are also disadvantages that should be taken into account as well.

Running an international wiki comes with its fair share of demands and responsibilities --- we've done our best to be as responsive as we can, taking into account the administration loads combined with optimising cost effective decision making around hosting services.

My offer still stands to speak with any WikiEducator at Otago Poly -- however, you will need to be the judge of whether I can add any value.

Cheers
Wayne 

Peter

unread,
Aug 7, 2008, 3:24:01 AM8/7/08
to WikiEducator
Erik,

I believe all that you identify as improvements would be welcomed from
the WE community. I can also see your points on a number of these
issues. Here is my understanding of a few things;
1) Deleting is about cleaning up mistakes, maybe the ability to hide
would be good rather than delete, or an admin delete, that doesn't
really delete, it archives...
2) I can understand the technical (database) issues around LT vs
wikitalk and the ability to toggle... I am curious why LT didn't
extend the wikitalk db structures it could have provided many
benefits... like toggling... (but that's water under the bridge now).
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..
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?
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?

Thanks for you attention to this...

Peter

Leigh Blackall

unread,
Aug 7, 2008, 3:28:09 AM8/7/08
to wikied...@googlegroups.com
My apologies Wayne. looking back at my email I see how I was out of line.

I specifically wish to correct this:


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

I was not talking about Wikieducator here - although it certainly does seem like it! I'm guilty of thinking about another thing while writing this. I was thinking about our local situation and the lack of responsive admin crew we have here (compared to Wikieducator) I was not at all referring to Wikieducator! how careless of me and I hope everyone will accept my apology and correction as honest and sincere.

Wayne, the innovations that you and a few others have implemented and continue to manage on Wikieducator are outstanding - and in most instances where I was quick to criticise I have come to a more mature understanding of the technology and see that you (and others were wise). Not all implementations mind, I still have reservations over the Kultura install and the LQT and I still stand by my arguments for embedding 3rd party media etc, but over all the technology on WIkieducator is impressive and far better than any other MediaWiki install I have used. Additionally, I have found Wikieducator (specifically you Wayne) incredibly responsive and always willing to communicate promptly - even if it hasn't always gone the way of my demands. Credit to your patience.

I look forward to a future when our respective organisations can offer an equal amount of resource to the running and maintenance of the Wikieductor, the same as we are trying to do with content. I think the sooner our organisations can share the cost of running the thing the sooner we will have a truly shared investment and the misperception of Wikieducator being a solely COL initiative will lessen. I can only hope that we will be ready to answer that call when it comes.

Apologies Wayne and WE, I can get very careless with email at times.

Erik Moeller

unread,
Aug 7, 2008, 3:57:00 AM8/7/08
to wikied...@googlegroups.com
2008/8/7 Peter <praws...@gmail.com>:

> 2) I can understand the technical (database) issues around LT vs
> wikitalk and the ability to toggle... I am curious why LT didn't
> extend the wikitalk db structures it could have provided many
> benefits... like toggling...

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.

Wayne

unread,
Aug 7, 2008, 3:57:10 AM8/7/08
to wikied...@googlegroups.com
Hey Leigh

Thanks for the clarification.  Wikieducator is blushing now <blush>.

Keep up the critical disposition -- it keeps us on our toes. We need leaders like yourself to turn tomorrow's promise of OER futures into today's reality for WikiEducator.

With the calibre of our community, pretty soon we'll have institutions around the world asking how they can become part of the magic!

Cheers
Wayne

Robert Kruhlak

unread,
Aug 7, 2008, 10:56:20 AM8/7/08
to wikied...@googlegroups.com
What if we set up something like:

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

Robert Kruhlak

unread,
Aug 7, 2008, 11:06:30 AM8/7/08
to wikied...@googlegroups.com
or would it need to be:

User_talk:Sandbox

?

Cheers

Rob

Peter

unread,
Aug 7, 2008, 11:52:34 AM8/7/08
to WikiEducator
Erik,

All good thanks.

Given the no db-structure for wikitalk pages I could see it hard to
"merge" LQT...

Hmmm... mixing the two discussion models in my mind is a requested
feature from the user community. I do not believe it is the
"programmers" responsibility to argue whether it should be done. I
actually don't see these two discussion approaches being mixed. A page
would be one or the other, the teaching situation and learner
population would determine which approach would be best. This would be
the decision of the teacher / facilitator when the course (page) is
created. I don't agree with your argument that two discussion models
would be hugely challenging for new users (what research is your
statement based upon?) 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? The confusion you speak of may actually
come from why in Wikipedia one discussion approach is available and in
WE LQT is available. Aren't they both MW implementations? It would
seem that MW has chosen to break the predictability and consistency
rules by using different models across implementations. One of the
great things about MW is the consistency across wikis, when I learn to
discuss in Wikipedia this should transfer to WE... I still see the
ability to toggle at page creation as a requested user feature.

RSS feeds would be great for all LQT discussions I am a participant.

I didn't notice the ability to persist the sort order until now,
thanks.

I believe the sort order inconsistency is created by having the
ability to change the order. I believe the inconsistency (and the
users cognitive load to deal with it) is already in place by it being
an option. So why not have a user set their preferences for sort
order. Have the option to use the user preference and then override by
the page preference and the site preference. have the user set these
preferences in their profile...

Again, thanks for your attention to this.

Peter

On Aug 7, 12:57 am, "Erik Moeller" <eloque...@gmail.com> wrote:
> 2008/8/7 Peter <prawstho...@gmail.com>:

Erik Moeller

unread,
Aug 7, 2008, 9:50:35 PM8/7/08
to wikied...@googlegroups.com
2008/8/7 Peter <praws...@gmail.com>:

> Hmmm... mixing the two discussion models in my mind is a requested
> feature from the user community. I do not believe it is the
> "programmers" responsibility to argue whether it should be done. I
> actually don't see these two discussion approaches being mixed. A page
> would be one or the other, the teaching situation and learner
> population would determine which approach would be best.

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.

Peter

unread,
Aug 12, 2008, 7:13:16 PM8/12/08
to WikiEducator
Erik,

Thank-you for all your comments / clarification / arguments... It
prompts feedback that will make LQT and WE better. Thank-you.

After reading through your recent email the one outstanding question
goes back to;

> 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.

So, the WE community needs to make it officially official ;) that we
would like the ability to toggle LQT on or off on page creation.
turning it off would be as simple as un-installing the feature from
the WE server (which I don't think is a good idea for many reasons, or
even possible given we have an existing set of discussions held within
LQT).

So if I may be so bold, I will make the feature request on behalf of
the WE community. And the user story would be (drum role please);

User Role(s): Teacher, Facilitator, Instructional Designer
User Story: I would like the ability to select if I want threaded
discussion (like LQT) or traditional wikitalk pages whenever I create
a new page, course or module within WE.

Sincerely, Peter

On Aug 8, 8:50 am, "Erik Moeller" <eloque...@gmail.com> wrote:
> 2008/8/7 Peter <prawstho...@gmail.com>:
>

Leigh Blackall

unread,
Aug 12, 2008, 7:33:35 PM8/12/08
to wikied...@googlegroups.com
Could we have 2 tabs perhaps? One called something signifying a LQT discussion page, and another for a trad wiki discussion area. Already, a few people have set up sub pages as surrogate talk pages so as to avoid LQT

It has been my experience that LQT does in fact lower the barrier of entry for some people not with Mwikis. But it is equally  barrier of entry for most people how are used to Mwikis. Based on that simple equation - and the fact that people stil need to know how to use wikitext to engage with the rest of the wiki, I have personally decided to side with the idea of removing LQT from WE and request that further development of LQT continues on a development server until such time as its significant issues are resolved.

However, if the option discussion pages in a traditional wiki talk was enabled along side LQT, I think this would be a suitable compromise. And it occurs to me, in light of Erik's reasonable arguments against a toggle feature, we might have 2 tabs for the optiopns. How to signify each properly so as to make sense to new and old users of wikis would be a small design challenge I think.

Perhaps:

Tab1: Discussion | Tab2: LQT Discussion

I may result in 2 seperate discussion areas (which actually has its pluses in some situations) and it encourages more rather than less discussion. With these options we would quickly see the preference of the users I think.

Peter

unread,
Aug 12, 2008, 9:22:14 PM8/12/08
to WikiEducator
Great suggestion Leigh.

I really really like the tab idea...

Peter

On Aug 13, 6:33 am, "Leigh Blackall" <leighblack...@gmail.com> wrote:
> Could we have 2 tabs perhaps? One called something signifying a LQT
> discussion page, and another for a trad wiki discussion area. Already, a few
> people have set up sub pages as surrogate talk pages so as to avoid LQT
>
> It has been my experience that LQT does in fact lower the barrier of entry
> for *some *people not with Mwikis. But it is equally  barrier of entry
> for *most
> *people how are used to Mwikis. Based on that simple equation - and the fact
> SL - Leroy Goalposthttp://learnonline.wordpress.com- Hide quoted text -
>
> - Show quoted text -

Erik Moeller

unread,
Aug 12, 2008, 9:52:58 PM8/12/08
to wikied...@googlegroups.com
Tabs have many of the same issues as toggles. If LQT is not
user-friendly enough to contributors who have "graduated" past the
first workshop, it should be turned off, in my opinion. The
administrative and community cost of such a change is very high. I
believe we can make significant progress on the key annoyances that
have been identified so far very quickly, to the extent that LQT
should become more tolerable for the core contributors -- and then we
can begin work on adding some of the described features like RSS
feeds, email-to-wiki pages, etc.

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.

Leigh Blackall

unread,
Aug 12, 2008, 11:02:11 PM8/12/08
to wikied...@googlegroups.com
Tabs have many of the same issues as toggles.
Really? I was under the impression that a new tab (could) simply provide a link to what amounts to be something like a subpage. It would be separate to LQT so would not present technical issues with LQT.

If you need further convincing of the benefits of two discussion areas here's one:

  1. Teachers use the traditional wiki talk tab because they know how to work wikitext.
  2. Students use the LQT tab because LQT provides them with easier interface.
  3. Having the separate discussion areas helps keep page development discussion separate from course or subject discussion, which IS very confusing when LQT jumps thread positions around unless a user knows how to adjust their settings.

Even when LQT is sorted, I would probably ask for two discussion areas for the 3rd reason above.

Enabling 2 discussion areas now seems to me to not only address the tension between LQT and traditional talk pages, but gives us an opportunity to assess the validity of LQT compared to traditional talk pages. When LQT is sorted (or not) we could simply apply it to the 2nd talk page if it was deemed necessary.

Erik, your review process is a good suggestion, but could you clarify why adding another tab is fraut with issues? It seems to me that it would fix a rather large issue now - the issue of LQT turning some users away, mainly content developers.

Leigh Blackall

unread,
Sep 25, 2008, 2:41:37 AM9/25/08
to wikied...@googlegroups.com
OK, LQT is still not working.

I am not getting emails
I just tonight got a "New Messages" notice at the top of the wiki.. finally letting me know about some 100 or more messages I had no idea about! Some of those messages were crucial and related to courses I was running, others were important updates to collaboration initiatives getting started...

LQT must be removed if this is being experienced by most people trying to use the wiki to communicate and document discussion.. is it that it technically can't be easily removed Eric? I remember when it was introduced we lost old messages through that archiving process.. would removing LQT mean losing discussions that have run in LQT to date?

Peter

unread,
Sep 25, 2008, 12:51:08 PM9/25/08
to WikiEducator
I completely agree LQT must be turned off. And yes I too have lost
crucial information for a deadline based project. I see LQT as an
alpha release of software, to call the next release 2.0 implies new
features. The 1.0 features do not yet work properly, hence the alpha
status...

Anyhow, this is what I suggest.
1) We turn LQT off immediately! This should not lose any of the
existing discussions as they will still be saved in the LQT database.
From a technical perspective they will NOT show up on the traditional
talk pages nor will the existing LQT discussion pages show up once it
is turned off.
2) we go back to using traditional talk pages for discussion.
3) we request the following user story (I trust the technical people
are familiar with Agile approaches, here is a good read if you want
more info; http://www.mountaingoatsoftware.com/book/2-user-stories-applied)

User Role(s):
Teacher, Facilitator, Instructional Designer
User Story:
A user should have the ability to select if they want threaded
discussion (like LQT) or traditional wikitalk pages whenever they
create a new page.
Test Case:
Selection of either option successfully creates a page with the
requested discussion approach.
Constraint:
The selected discussion approach must integrate with existing
MediaWIki messaging and email features

4) Formally request this user story be implemented and see how the
technical people respond.

I could also write a user story for a tabbed approach... My experience
tells me that requirements definition yields the best results when it
is iterative and also includes the development side... so lets see how
they respond to our user request.

Be Well...

On Sep 24, 11:41 pm, "Leigh Blackall" <leighblack...@gmail.com> wrote:
> OK, LQT is still not working.
>
> I am not getting emails
> I just tonight got a "New Messages" notice at the top of the wiki.. finally
> letting me know about some 100 or more messages I had no idea about! Some of
> those messages were crucial and related to courses I was running, others
> were important updates to collaboration initiatives getting started...
>
> LQT must be removed if this is being experienced by most people trying to
> use the wiki to communicate and document discussion.. is it that it
> technically can't be easily removed Eric? I remember when it was introduced
> we lost old messages through that archiving process.. would removing LQT
> mean losing discussions that have run in LQT to date?
>
> On Wed, Aug 13, 2008 at 3:02 PM, Leigh Blackall <leighblack...@gmail.com>wrote:
>
>
>
> > Tabs have many of the same issues as toggles.
>
> > Really? I was under the impression that a new tab (could) simply provide a
> > link to what amounts to be something like a subpage. It would be separate to
> > LQT so would not present technical issues with LQT.
>
> > If you need further convincing of the benefits of two discussion areas
> > here's one:
>
> >    1. Teachers use the traditional wiki talk tab because they know how to
> >    work wikitext.
> >    2. Students use the LQT tab because LQT provides them with easier
> >    interface.
> >    3. Having the separate discussion areas helps keep page development
> >    discussion separate from course or subject discussion, which IS very
> >    confusing when LQT jumps thread positions around unless a user knows how to
> >    adjust their settings.
>
> > Even when LQT is sorted, I would probably ask for two discussion areas for
> > the 3rd reason above.
>
> > Enabling 2 discussion areas now seems to me to not only address the tension
> > between LQT and traditional talk pages, but gives us an opportunity to
> > assess the validity of LQT compared to traditional talk pages. When LQT is
> > sorted (or not) we could simply apply it to the 2nd talk page if it was
> > deemed necessary.
>
> > Erik, your review process is a good suggestion, but could you clarify why
> > adding another tab is fraut with issues? It seems to me that it would fix a
> > rather large issue now - the issue of LQT turning some users away, mainly
> > content developers.
>
> SL - Leroy Goalposthttp://learnonline.wordpress.comhttp://www.wikieducator.org/User:Leighblackall

Peter

unread,
Sep 25, 2008, 1:18:47 PM9/25/08
to WikiEducator
I just posted this message in the WikiEducator Technical Discussion
Google Group... Let's see where all this goes...

********* Message Start ************
Consider this a formal request to turn off Liquid Threads

Key people working on important WE projects have essentially lost
critical messages due to Liquid Threads (LQT). Given traditional
definitions of software development LQT is still in an alpha state for
it does not yet implement basic features (messaging and email
notification) required by the user community.

For the sake of transparency here are two recent discussion that
outline our problem;

http://groups.google.com/group/wikieducator/browse_thread/thread/846628e4111a1e42?hl=en
http://ww.wikieducator.org/User_talk:Leighblackall#lqt_thread_4494

Sincerely,

Peter Rawsthorne
********* Message End ************

Cheers.

On Sep 24, 11:41 pm, "Leigh Blackall" <leighblack...@gmail.com> wrote:
> OK, LQT is still not working.
>
> I am not getting emails
> I just tonight got a "New Messages" notice at the top of the wiki.. finally
> letting me know about some 100 or more messages I had no idea about! Some of
> those messages were crucial and related to courses I was running, others
> were important updates to collaboration initiatives getting started...
>
> LQT must be removed if this is being experienced by most people trying to
> use the wiki to communicate and document discussion.. is it that it
> technically can't be easily removed Eric? I remember when it was introduced
> we lost old messages through that archiving process.. would removing LQT
> mean losing discussions that have run in LQT to date?
>
> On Wed, Aug 13, 2008 at 3:02 PM, Leigh Blackall <leighblack...@gmail.com>wrote:
>
>
>
> > Tabs have many of the same issues as toggles.
>
> > Really? I was under the impression that a new tab (could) simply provide a
> > link to what amounts to be something like a subpage. It would be separate to
> > LQT so would not present technical issues with LQT.
>
> > If you need further convincing of the benefits of two discussion areas
> > here's one:
>
> >    1. Teachers use the traditional wiki talk tab because they know how to
> >    work wikitext.
> >    2. Students use the LQT tab because LQT provides them with easier
> >    interface.
> >    3. Having the separate discussion areas helps keep page development
> >    discussion separate from course or subject discussion, which IS very
> >    confusing when LQT jumps thread positions around unless a user knows how to
> >    adjust their settings.
>
> > Even when LQT is sorted, I would probably ask for two discussion areas for
> > the 3rd reason above.
>
> > Enabling 2 discussion areas now seems to me to not only address the tension
> > between LQT and traditional talk pages, but gives us an opportunity to
> > assess the validity of LQT compared to traditional talk pages. When LQT is
> > sorted (or not) we could simply apply it to the 2nd talk page if it was
> > deemed necessary.
>
> > Erik, your review process is a good suggestion, but could you clarify why
> > adding another tab is fraut with issues? It seems to me that it would fix a
> > rather large issue now - the issue of LQT turning some users away, mainly
> > content developers.
>
> SL - Leroy Goalposthttp://learnonline.wordpress.comhttp://www.wikieducator.org/User:Leighblackall
Reply all
Reply to author
Forward
0 new messages