Talk:LiquidThreads 3.0/Design

From MediaWiki.org
Jump to: navigation, search
Start a new discussion

Contents

Thread titleRepliesLast modified
Using the screenshots elsewhere823:16, 29 April 2014
General comments213:56, 5 January 2013
progress on redesign?1608:36, 18 November 2012
Page Updates and Refreshes1009:00, 25 April 2012
Too colorful?015:30, 25 March 2012
"Discussion" versus "Topic" versus "Thread"1221:47, 9 November 2011
Use of color017:55, 4 October 2011
Viability on the English Wikipedia321:12, 4 July 2011
Is it really necessary to allow users to edit each other's posts?720:15, 4 July 2011
Really wanted?120:12, 4 July 2011
Some thoughts620:08, 4 July 2011
Diffs (was: Huge watchlist and high traffic environments)219:36, 4 July 2011
transferring current talk pages to liquid threads?513:54, 9 June 2011
Thread namespace307:11, 6 May 2011
can we try new version?107:05, 6 May 2011
Avatars are unacceptable718:55, 31 December 2011
Truncation206:45, 28 January 2011
My complaints504:20, 28 January 2011
Two questions104:36, 6 December 2010
"To Top" Button612:32, 19 February 2011
First page
First page
Previous page
Previous page
Last page
Last page

Using the screenshots elsewhere

I would like to use some decent screenshots as depictions at w:Wikipedia:LiquidThreads and commons:Commons:LiquidThreads. Why are they not GFDL? There are no WMF copyrightable elements in the images, just maybe few avatars might not be free, which can be removed...

Kozuch16:18, 20 August 2010

You know, I only use that license because I was told to. Let me ask around and see if that's totally required. If not, I'll change it.

Jorm (WMF)16:50, 20 August 2010
 

Also, may I ask your motivation for using them elsewhere?

Jorm (WMF)16:51, 20 August 2010

For example, informing different communities? Whatever the reason in this particular case is, Wikimedia community adheres to free content, and you shouldn't use non-free stuff on these sites unless it's absloutely vital.

Max Semenik17:07, 20 August 2010

I wasn't asking because I wanted to prevent it; I was asking to see if there was a way I could help.

There shouldn't be any issue with using the images on other Wikimedia Foundation projects with that license, but I am opening (nearly all) of them up to the GFDL. The ones I can't have avatar images and I need to get permission from those people first.

Jorm (WMF)17:19, 20 August 2010

Scratch that; I have put them to Cc-by-sa-3.0 per suggestion by User:Eloquence

Jorm (WMF)20:19, 20 August 2010
 
 
 

I've updated the licenses on all the images save the ones that display avatars (for now). I don't have the time right now to cut new ones without the avatars but if I can find the time this afternoon or weekend I will do so.

Jorm (WMF)17:30, 20 August 2010
 

And, hey. Turns out all the avatar images are cc'd as well. So I'll fix that one, and you can use any of them.

Jorm (WMF)21:23, 20 August 2010

Thanks for helping, I made another screenshot in the meantime anyways, but these will come in handy too I think.

Kozuch06:12, 21 August 2010
 
 

General comments

I looked at this version of the redesign plans. These are my comments. They are currently incomplete.

Mechanics[edit | edit source]

Scrollable table of contents[edit | edit source]

My primary concern with a scrollable table of contents is that when scrolling from the top of the page to the bottom, a user can get "trapped" in the top part and never be able to scroll down below the table of contents. Users already sometimes have this issue with textareas on the edit screen.

Questions
  • Will there be any mechanism to mitigate the risk of users getting "trapped" in the table of contents area?

Hovering[edit | edit source]

While hovering works nicely on platforms that support mice or cursors, some mobile platforms (the iPhone in particular) don't really support hover capability.

Questions
  • Will clicking these items that are intended to be hovered over have the same effect?

Design[edit | edit source]

Dismissible pop-ups[edit | edit source]

Screenshots such as File:LQT-v2-Polling-Error.png, File:LQT-v2-Editor-LoginPrompt.png, and File:LQT-v2-Editor-Reply.png all use words in the top-right corner to dismiss or cancel the pop-up, rather than an icon.

Questions
  • Is this deliberate?
  • Are there concerns about other languages using longer words?
  • Wouldn't an "x" icon of some kind be easier to implement?

Replies[edit | edit source]

Screenshots such as File:LQT-v2-Editor-Reply.png show no "show preview" button.

Questions
  • Is the lack of a "show preview" button deliberate?

Headline links[edit | edit source]

In screenshots such as File:LQT-v2-Summary-Prompting.png, there are a number of links ("watch this topic", "move", etc.) in the top-right that look cluttered and have been discussed previously.

Questions
  • Are there plans to address these links in some way?

Dual control bars[edit | edit source]

The dual control bars are described in the redesign plans, but not justified.

Questions
  • Are there particular reasons for including the control bar twice?
  • Will it be possible to disable one of these two control bars in user preferences (to save screen real estate, for example)?

System behavior[edit | edit source]

Automatic polling[edit | edit source]

While I think automatic polling is a feature, some users are going to want to be able to disable this. On slow connections, it can cause serious performance issues. Otherwise services such as Google Instant will automatically disable polling if it senses that the connection is slow and allows users to disable the polling altogether.

The polling behavior is currently planned to display a pop-up when it disables. I view this as intrusive and unnecessary. Many users keep multiple tabs open at a given time, meaning that this message could quickly become a serious nuisance.

Questions
  • Will there be a user preference to disable polling?
  • Will the polling have connection speed detection?
  • Will the notification that polling has stopped be disableable?
MZMcBride21:58, 28 January 2011

As one of those people with a slow connection, I heartily endorse MZMcBride's last point about Automatic polling. Quite apart from the "performance issues" of slow page loading, I strongly suspect that polling for dynamic updates is what has made Liquid Threads to consistently crash my browser. However, when I previously raised the issue of allowing users to disable this, it was met with thought-terminating clichés about "crappy" preferences and "anal" users, so I don't expect much accommodation for those of us who have limited bandwidth available.

Ningauble (talk)15:10, 4 January 2013

Ningauble, there's little use in commenting LQT plans now, LQT is dead and LQT 3 will never be produced. Anyway, yes, LQT can crash your browser: don't keep pages with LQT indefinitely open in your tabs.

Nemo13:56, 5 January 2013
 
 

progress on redesign?

i think the redesign looks very interesting and was just wondering how far along the coding for it is and when we can expect a release? thanks it looks great

redekopmark18:09, 16 November 2010

bit of a bug i just came across i tried signing the post above and got the warning message that i don't need to sign it but it was hard to read as the area for the message was only about half as high as it should have been, I'm using chrome 9 on windows and the div is only 5 or 6 pixels high

redekopmark18:14, 16 November 2010
 

Hi redekopmark,

We're currently working on this, though our development will speed up further in January. At this stage we'd like to run a pilot in January/March 2011.

Andrew Garrett04:33, 6 December 2010

Heh. Just to note, this comment was made before the decision to redo large portions of both the frontend and backend. A pilot launch in January or March of this year seems very unlikely at this point.

MZMcBride06:47, 28 January 2011
 

As you can see, we have released the lastest revision of the re-design. Take a look and tell me what you think.

Jorm (WMF)01:52, 28 January 2011

This is looking really nice! Is there any news when this will be public? Because, it looks awesome.

Smile Lee21:51, 8 February 2011
 

Just wanted to stop by to add my encouragement on the redesign: it looks fantastic, and is obviously a ton of work. Good luck with it, I am REALLY looking forward to using it (and so are all the members of the wiki I run!)

Chris Hennes17:00, 21 February 2011

I also think it's looking good, if this is how it's supposed to look when the redesign is done then "Wow" I can't wait for it to be released, It'll be an incredible improvement over the current design,

redekopmark05:32, 25 February 2011
Edited by author.
Last edit: 23:50, 25 March 2011

This is AMAZING! Thank you for your work on this.

Sj23:50, 25 March 2011

Thanks!

I'm continually refining the design and improving upon it (even though we're in a holding pattern on it). I love this project; I think it's super important for about twenty bazillion reasons.

Feel free to add this to your watch list.

Jorm (WMF)23:58, 25 March 2011
 
 
 
 

What is the status of this latest iteration of LT? It has been almost six years...

Petter11:17, 7 January 2012

Good question.

The latest status update was on 2011-10-31. Any news?

Helder20:18, 13 February 2012

There has been no progress because I have been assigned to other tasks. We will probably be waiting until Echo (our notification framework) is under development before considering reviving this project.

Andrew Garrett (talk)01:32, 31 March 2012

That is very unfortunate. Many people find it very hard to discuss in MediaWiki.

Petter12:05, 25 May 2012
 
 
 
 

Page Updates and Refreshes

I really, really do not like pages continually pinging the server.
Can we have a user preferences option to turn this off?

  • Why an option? I understand that many people like a real-time chat experience, but not everybody prefers this mode of interaction and, as noted, active content does not come without a performance cost.
  • Background: I am one of those folks with lots of things scattered about on my physical and virtual desktops (a type that may be more prevalent among encyclopedists than in the general population). I often leave things open expecting to return to them in a couple minutes, or a couple hours, or a couple days. I often log out from my dial-up connection in the meantime. When I want an update, it is easy enough to refresh a page or check its history. I do not want a page view to spontaneously requisition resources when I did not request an update, and I really do not like the browser interrupting another foreground application to complain about latency or disconnection.

Thank you for considering offering the best of both worlds by making this an option.

Ningauble19:13, 9 September 2010

I don't think it's a good idea to have a user preference for this. Presumably we can find a way to get rid of the problems you're experiencing, instead.

Andrew Garrett13:45, 20 September 2010

One way to way to get rid of the problems with web pages that "call home" is to disable scripts, which is my default security setting. I would prefer not to remove Wikimedia sites from my whitelist because some of their JavaScript is useful.

I realize that my perspective is a little old-fashioned, but why do you think it is not a good idea to accommodate those who do not want unrequested active content running on their computers?

Ningauble17:54, 20 September 2010

There's significant research that indicates that more preferences means "crappier".

There are ways to solve what you're asking about (for example, automatically turning off the ping system after X minutes, or causing it to slow down, or whatever); preferences are rarely the answer.

Jorm (WMF)19:22, 20 September 2010

The usual solution to that is to have a lean, user-friendly settings page for the average user and some sort of hidden expert settings (think about:config in Firefox). MediaWiki already sort-of has the latter through the user js subpages; it only requires a bit of thought to make sure the timer objects or the configuration constants controlling them are available from global scope (which is usually easy with jQuery's wonderful data function).

Tgr08:42, 2 October 2010

I don't think that's necessarily a good idea. It's typical of open-source projects because it's a concession to anal users :-)

Andrew Garrett09:47, 4 October 2010
 

I cannot imagine a world in which I would design a preferences system like "about:config."

Preferences are the enemy.

Jorm (WMF)19:56, 4 October 2010
 

The DOM actually has a little bit of information available on if the page is focused on. ie: It's possible to tell the difference between when the user has the tab open in front of them, and when it's an inactive tab, or iirc even if the browser isn't right up at the front. That's another good way to check if any update polling should be done.

Dantman16:17, 13 September 2011

Here the signature is updated automatically

Naveen.kumar (talk)09:00, 25 April 2012
 
 
 

I appreciate that end-user configuration options can be a barrier to ease of use (not to mention that their proliferation complicates revision management). It is far better to stick to features and implementations that work well for everyone without need of customization. I can see the appeal of dynamic updates, although I am not convinced the benefit is great. The old-style method of user-initiated updates, i.e. whenever the user loads or refreshes a page, does seem to be problem-free.

Hopefully, Andrew's presumption that the problems can be fixed is correct. Bear in mind that, for some platforms, demands on communication resources can present problems long before demands on RAM (as described in the Redesign page) become an issue. I do think it a good idea to accommodate those who have limited bandwidth.

Ningauble21:32, 5 October 2010
 
 

Too colorful?

I'm starting to think that people might get sick of the bright-ish colors in this design after it's been used for a while... Maybe toning it down a bit would be an improvement?

(Also, it's quite a bit bulkier than the current talk page format. It might make sense to do something about that, too.)

Yair rand (talk)15:30, 25 March 2012

"Discussion" versus "Topic" versus "Thread"

I think most everyone is agreed that the word "Thread" is not as user-friendly as we would like. To that end, I've been standardizing on "Discussion". However, there are some places where that word becomes awkward (at least in English). I have thus been thinking about using the word "Topic" as well, though I'm not keen on using both terms simultaneously.

Right now, I'm leaning towards having it be a "Discussion Page" that contains multiple "Topics", which are comprised of a single "Summary" and n+ "Posts":

  • Page
    • Discussion Page
      • Topics (n+)
        • Summary (0-1)
        • Posts (n+)

The big value here is readability of buttons and actions ("New Topic", "Drag Post", etc.) .

Does anyone have any thoughts?

Jorm (WMF)23:00, 3 August 2010

Hi Jorm, I am not very happy with threads either. Your proposal sounds good. Why not saying dialogue page instead of discussion page? I think this is what it is all about. Discussion has a slightly negative touch. Cheers --kgh 10:18, 4 August 2010 (UTC)

kgh10:18, 4 August 2010
 

"Topic" is hardly translatable, please avoid it. What's the problem with "Discussion"? A discussion, multiple discussions in the discussion page, or talk page if we use the same name as now (in English).

Nemo bis11:02, 4 August 2010

Why should topic be hardly translatable? Discussion it pretty narrow to be quite frank. Cheers --kgh 11:13, 4 August 2010 (UTC)

kgh11:13, 4 August 2010

For example there's no translation of "topic" in Italian. Literal translation would be "argomento", but it can't be used for a discussion.

Nemo bis17:19, 4 August 2010

Is there an italian word that has a similar semantic concept? What does phpbb3 use? If I recall correctly, they have "Forums", "Topics", and "Posts".

Jorm (WMF)17:33, 4 August 2010
 

There is another way out. As I understand this is about English. However, all of this will be localised at betawiki. Thus every language may choose what fits best? --kgh 17:39, 4 August 2010 (UTC)

kgh17:39, 4 August 2010

phpbb uses "argomento", but that's not a valid example (they don't have many/good translators to Italian; I was asked to help but I didn't have time). Sometimes "topic" is left untranslated. Yes, translation can be adapted, but if you choose such a "problematic" word as source you can be sure that many translations will either 1) be misleading or incorrect, as "argomento" in Italian, 2) be in some jargon that general public doesn't understand (while your aim is to improve usability), 3) be a loanword (topic itself) or maybe a neologism – and that's even worse.

Anyway, I'm not sure that "topic" is good in English: the "topic" of the talk page is the associated page; there are multiple discussions on several sub-topics (or often on recurring sub-topics). On a forum, you would often use only one thread/topic for such related discussions, and if we borrow this term I'm afraid that people could do the same on wiki. Actually, an analogy is impossible: you can call the thread "topic", then the talk page would be like a "subforum" (or "section" in some forum systems). Even if phpbb3 has unlimited nested levels, you won't find any forum with hundreds of thousands or millions of subforums.

Anyway, I appreciate that you're considering these linguistic problems: obviously, "thread" is even worse in that respect, e.g. in Italian there's no translation at all, apart from a neologism.

Nemo18:33, 4 August 2010
 
 
 
 

Hmm, when I think of Wikipedia and so forth, I think of "opening a discussion" and really a thread is just referring to an entire discussion right? The problem I have with "topic" semantically is that it's fairly broad, because you can have multiple discussions on a single topic. For instance, a proposal which encompasses a topic can be opened, then closed multiple times. The topic is the same, but multiple discussions have taken place on it. If this makes any sense or helps...

   Thorncrag  21:46, 9 November 2011
 

Use of color

The Extension seems to use many colors. For accessibility reasons: Have you made sure that color is not the only method used to convey important information?

Trockennasenaffe15:18, 4 October 2011

Viability on the English Wikipedia

I don't see LT as viable on the English Wikipedia and where its use is intended for the following reasons:

  1. It's slow and if enabled on the Village Pumps would cause all sorts of strife for users with unstable connections
    The Village Pumps are already slow enough to load as is
  2. It takes up far too much space, the current system ain't broke so why create a problem?
  3. It is not aesthetically pleasing
  4. Wikipedia is not a forum

Did I mention it's slow, laggy and ugly?

Ancient Apparition08:09, 4 June 2011
"2. It takes up far too much space, the current system ain't broke so why create a problem?"

Yes it is, And there is requests every so often on the VP:* to get a decent system to replace them.

"3.It is not aesthetically pleasing"'

It doesn't look that bad ((in it's current state) and I quiet like it) but I haven't paid that much attention to the redesign theme ideas.

Peachey8810:21, 4 June 2011

I would certainly love a linear discussion format on the VP, that way people won't get confused as to who's talking to who given how long discussions can become. You don't think this current design is ugly as fuck, because the last thing I'd want is to go to the VPs and have a chunky, laggy, waste of space messaging system, no rudeness intended at you or the developers but this design and its speed is just not viable for enwiki, at all.

Ancient Apparition04:40, 26 June 2011
Edited by another user.
Last edit: 21:12, 4 July 2011

I agree with some of your observations:

1) It's important to find a way to load faster - particularly the top part of the page / the first threads. LQT does not load quickly on any of my current machines, even for a talk page this size.

2) You can save a few pixels with a 1-px border, 2px less padding. You can save 1.5 lines (on most displays) by floating the sig and reply/parent/more options to the right of the comment. In the v3 designs, you can move the Reply/Comment/Edit Summary buttons up into the header of that thread/node.

3) I'm not a fan of the current design. However the New design is scrumptious!

4) Talk pages are indeed forums, they simply need to stay on topic. You may be misinterpreting that section.

Sj20:05, 4 July 2011
 
 
 

Is it really necessary to allow users to edit each other's posts?

Edited by author.
Last edit: 07:18, 16 January 2011

I think that should only be allowed by admins. Or, perhaps there should be a way to disable it on some wikis like a permissions thing.

Smile Lee07:18, 16 January 2011

On forums powered by forum software, only moderators can edit other users posts.

MyrtonosUsing liquid theads11:50, 16 January 2011

I'd agree with that, same with the drag to new location, especially for annon users

redekopmark17:17, 18 January 2011

Drag to location is extremely likely to go away. It isn't really a useful feature in its own right: the effects it has can usually be implied with a "split" topic.

Moving posts within the same thread tree is non-intuitive and highly confusing to users.

Jorm (WMF)02:06, 21 January 2011
 
 

On Wikimedia wikis, I think it would be better if anyone could edit anyone's posts, like in the current system.

Yair rand21:49, 11 February 2011

I agree that allowing it on Wikipedia's talk pages is beneficial to collaborative efforts.

But I think that having it set by permissions to edit each other's posts. Because, it'd be nice if certain usergroups couldn't edit other's posts. An unregistered user, or maybe a user with that particular permission revoked, should be disallowed from editing other people's posts.

174.50.85.20709:18, 24 February 2011

I just read the "Shared Posts vs. Private Posts" section, that's a brilliant idea. I think this is an awesome step in the right direction. Can't wait for this to launch.

Smile Lee09:23, 24 February 2011

I agree 100% with Yair - anyone should be able to edit anyone else's posts. We have a well-developed culture of knowing how and when to do this constructively, and there are many instances where it is essential to be able to edit someone else's posts to make their work and the thread asd a whole understandable.

Adminship was not intended to be a barrier for doing that sort of textual editing, and I find the idea of this becoming an admin-only option contrary to our principles.

Sj20:15, 4 July 2011
 
 
 
 

Really wanted?

It seems to me the main argument in favor of using liquid threads is to make it easier for new editors to communicate. While I agree that Wikipedia needs to attract new editors, I still have to question this rationale. I think (and I may be wrong), that a communication system that makes discussion more "forum-like" might be encouring more new editors to contribute to Wikipedia. But I also think it increases the desire to use the system for non Wikipedia related discussions. At the very least, could someone (and yes, this might be called stupidity or ignorance) point out to me the key points that are considered the benefits of this new system?

Toshio Yamaguchi15:40, 16 April 2011

Inviting people to have more discussions around articles and wiki projects is an important goal in itself. The idea that we should try to stop people from "using the system for non-wikipedia discussions" is outdated, in my opinion.

Having conversations in, around, and inspired by wikipedia is a great thing for us to support. and all of those conversations will in the end contribute to the breadth and quality of the encyclopedia. the same holds for wikisource, wiktionary, and other sister projects.

Sj20:12, 4 July 2011
 

Some thoughts

I don't know if this is still under discussion, or even still "live", but after reading the reverse page, and after playing with it a bit, I wanted to express a few thoughts.

First, I agree with the others about avatars. I personally don't think the potential issues and resource overhead is worth it. (And regardless, even if it's possible to activate for wikia sites, I strongly hope it's never on wikimedia sites.)

Also, as someone who has spent a lot of my wiki-editing time without having javascript activated, I sincerely hope that the technology would not cause java-less people from being able to communicate.

And also, maybe I'm not finding the link, but AFAIK, there's no way to edit the talk page itself. So for lengthy discussions, which may become confusing, or when someone uses an asterisk instead of a colon (which can screw up threading), those things cannot be fixed.

And since we're dealing with newbies, helping them with formatting is not uncommon.

My guess is that the intent is to try to isolate comments so that people do not edit each others' comments. Probably a good thing. But being able to adjust/modify/add/remove formatting would be helpful.

And that includes setting up a thread header. It is common for someone to "split" a discussion by making a sub header, once it becomes obvious that this part of a topic is no longer part of the "main" topic. so you drag out certain parts to a new thread.

Again, not changing what someone has said, (the text), but adjusting the formatting.

Maybe the way to do this would be to be able to edit a whole page as we can now, but the words are "highlighted", and can only be moved as whole blocks, and not edited when editing in that screen. Which could allow for adjusting of formatting, but still leaving text intact. (With some user right allowing the ability to edit anything, I would guess.)

Anyway, if these capabilities already exist, then I'm sorry if I wasted your time : )

Jc3709:25, 29 November 2010

There's no need for asterisks or colons to distinguish replies from each other. Each post is already self-contained.

Reach Out to the Truth15:53, 29 November 2010
  • Nod.
Though
I
Can
Still
Use
Them : )

Which, I'll agree is nice, for possible formatting needs within a message.

But (to use an example) - someone posts to a talk page a copy from the associated main page something they want help with (for example, a piece of an article at Wikipedia), for various reasons.

No one would be able to edit that.

Or perhaps it's help with some template coding.

No one would be able to help with that either.

Talk pages are used for more than just "talk".

Ad of course, this doesn't deal with things like turning a section and its sub threads into its own subthread.

Or for that matter, if for no other reason, due to people's current indoctrination due to existing online message boards, the talk pages won't be threaded at all, but just be a hodge podge of posts.

When that happens (and it does even now on some article's talk pages), someone typically (hopefully) comes along and tries to make sense of the posts, threads.

Since Wikipedia (at least) is based on the consensus model, having posts threaded all over the place is gonna be hell on whoever has to "close" a discussion to say that consensus is determined.

And that's another thing.

How will discussions be closed?

And can multiple threads be closed simultaneously as part of that closure?

I'm sincerely not trying to be difficult here (I do like the concept), but I'd like to see the implementation be workable so that it's not a hindrance to communication in any way.

Maybe a test could be to see how liquid threads would look if you look at archives at wikipedia of talk:ambox, talk:Darth Vader, Wikipedia talk:RFA, the several village pumps and administrators' noticeboards. Maybe the various RfCs on T1.

I mean, looking at VP (technical) I don't see how that would work with this.

Unless the intent is to "push" discussions off of talk pages and onto main pages, like the noticeboards...

Which is my other concern.

If this becomes even a little too complicated for the new user, it could promote edit warring. since it would be easier to say something brief in an edit summary than go to the talk page.

Oh and one more thing. let's say that I look at this lengthy post, and decide to split it into several sub threads for individual commenting (I'm not, this is just a "what if") - How would I do that with this system? Would it require ten windows simultaneously open to copy paste the sections, and creating several threads at once? Or at least successively?

Now I realise that I'm mostly looking at this from a wikipedia/media perspective.

But I'm hoping these things can be resolved.

Jc3720:25, 29 November 2010

"Oh and one more thing. let's say that I look at this lengthy post, and decide to split it into several sub threads for individual commenting (I'm not, this is just a "what if") - How would I do that with this system? "

Good question. After some time using the extension on Portuguese Wikibooks, I still don't know a good way to do this. Does anyone have suggestions for this?

Helder00:08, 3 June 2011

Great points - I summarized some of them in a feature request here: Talk:LiquidThreads_3.0

The issues you raise - not /requiring/ js, and supporting refactoring - are the main things keeping me from supporting LQT for large wikis.

Sj20:08, 4 July 2011
 
 
 

Yes, avatars are terrible idea.

Bulwersator21:26, 23 June 2011

I love the idea of avatars. just make them small by default and optional. [users who want can set a preference that hides them altogether, or that makes them larger...]

Sj20:08, 4 July 2011
 
 

Diffs (was: Huge watchlist and high traffic environments)

Edited by another user.
Last edit: 22:51, 1 September 2010

Has Lt been tested in high traffic environments and with huge watch lists? I am an admin in two high traffic project and have a watch list with 3500 entries. The "new messages" page is useless under these conditions. Furthermore LT is unusable in high traffic environments: Try finding the three new messages in a tree of 400 or more contributions. Or worse, the 26 new messages in a 1600 entries tree. And yes discussions like that happen, my fav example are discussions over notability criteria on deWP. On traditional wiki-style talk pages I can call a diff over 26, 65 or in extreme cases 220 versions and scroll down. I then have to read the new stuff in the small font or zoom my monitor display, but it works. Perfectly fine, once I understood how things work.

H-stt22:51, 1 September 2010

Yes, diffs are useful. Their problem is that you don't easily see the context. Perhaps we need LQT to allow collapsing of already read messages in a thread, beside highlighting of unread messages.

Nemo06:35, 5 September 2010
 

We'll be working on New Messages in a design meeting in the coming days.

Andrew Garrett03:22, 7 September 2010
 

transferring current talk pages to liquid threads?

When this is released (hopefully sooner rather than later!), will there be an ability to somehow move current discussions into this format? Or would all discussion pages that currently exist be unable to use this format forever?

Jerilderie03:10, 15 April 2011

I have nothing to do with the redesign, but going by my own experience with programming I don't think there will be a way to switch over existing discussions to this format, it would be more effort than it's worth in my opinion. However if I'm understanding things right existing pages would still be able to use this format, the liquid threads section will just appear below the existing talk part, then as the existing discussion gets older and moved to an archive page all that would be left is the liquid thread part.

At least that's how i understand it, I could be totally wrong

redekopmark07:55, 16 April 2011

Yes, it's unlikely that there will be an automated migration path for old talk pages. It's a difficult problem to solve correctly.

Andrew Garrett07:08, 6 May 2011

Thanks - I noticed in what I am typing now that I can edit the signature, so technically someone could come in and recreate the conversation if they really wanted to save it and not just archive it, so that ability to edit the username will still exist in the new version, right?

Jerilderie15:01, 12 May 2011

Probably, yes.

Andrew Garrett01:15, 17 May 2011
 

On Commons there is a bot which keeps an index of the current discussions, containing items of the form

  • [[PageName#SectionName|SectionName]] on [[PageName]]. Last comment by [[User:Name|Name]] on Timestamp.

The Python script used by the bot reads each page which should be indexed and do some kind of regex-based parsing to get the sections and comments in those discussion pages, being able to determine the title, section, user and timestamp of each comment.

Maybe the script could be adapted so that the info above could be used to save the page in the LQT format. Such an script could be added to the Pywikipediabot for easy use in other projects.

Just my two cents...

Helder13:54, 9 June 2011
 
 
 

Thread namespace

On this wiki and other wikis with this extension installed there is a thread: namespace. I wonder if it might be better to have mutiple tread namespaces like all thoso talk namespaces.

14:35, 12 February 2011

There will be no Thread namespace at all when I'm finished with it \o/

Andrew Garrett09:01, 20 March 2011

sweet, any idea when that will be?

redekopmark16:54, 22 March 2011

July, hopefully.

Andrew Garrett07:11, 6 May 2011
 
 
 

can we try new version?

Where we can find LiquidThreads new branch for testing?

Purre02:58, 17 April 2011

At the moment it's actually broken, but you can find it at http://svn.wikimedia.org/svnroot/mediawiki/branches/lqt-rewrite

Andrew Garrett07:05, 6 May 2011
 

Avatars are unacceptable

Avatars greatly increase the noise on a page while providing absolutely no signal. They make page loads even slower (and LQT already has issues on mobile devices). They're distracting, add needless whitespace with short comments (which are a majority of comments in a discussion), and in general are an incredibly poor use of finite development resources.

MZMcBride21:02, 24 August 2010

I think avatars are a nice feature to have as it provides visual identification without unreadable signatures. Perhaps the size of the avatars could be reduced drastically though.

207.233.109.10019:18, 25 August 2010

I'd point out that unreadable signatures are usually prohibited by local policies.

Nemo06:28, 5 September 2010

I confess I'm far from keen on avatars too. But can we at least all agree that there will be absolutely no animations in avatars? That would truly be a hideous development.

Bodnotbod16:38, 9 September 2010

I think that is an easy thing to agree on.

Jorm (WMF)18:24, 9 September 2010
  • Avatars are going to be a headache in terms of moderating offensive images.
  • Avatars add graphic distraction to pages that were previously content-only.
  • Avatars may increase the personalization of Wikipedia and make people more friendly.
  • Avatars make short messages which take up minimal vertical space impossible. In effect, they create a message-size floor of several lines, where previously single line messages were possible (and they are very common all over WP).

I think the last issue is the biggest problem with Liquid Threads. It is not conservative with vertical space. Fix that and you've got a great improvement to Wikipedia.

Thanks Ocaasi

69.142.154.1017:00, 19 September 2010
 
 
 
 
 

Truncation

The "Secondary Requirements" and "Dynamic Insertion" sections are truncated.

MZMcBride11:54, 27 January 2011

I'm not seeing truncation on Dynamic Insertion but I am on Secondary Requirements (which I'm trying to fix now).

Is it that the dynamic insertion section doesn't seem detailed or complete enough for you?

Jorm (WMF)18:14, 27 January 2011

If the server indicates that a new post has been made within the topic, the system will retrieve the posts and insert them into the page dynamically without the need for refreshing. A notification that

The current "active" post will not change position. New replies are inserted regardless of position.

The sentence just ends.

MZMcBride06:45, 28 January 2011
 
 

My complaints

  • What's with the grey background? It seems to be entirely useless, and does nothing but make the text slightly more difficult to read.
  • The "Thanks" bit is a waste of space, IMO.
  • Avatars should definitely not be used on any Wikimedia projects.
Yair rand02:35, 29 August 2010

Yes, the background currently seen on TWN is pretty unpleasant. Making it brighter would definitely improve readability.

Max Semenik07:31, 29 August 2010
 

Avatars aren't that bad. They're better than custom sigs, for sure. I think the size of the avatar should be reduced, perhaps to 100x100px or less

Penubag22:19, 29 August 2010

Yes, smaller avatars would be an improvement. Ocaasi 17:07, 19 September 2010 (UTC)

69.142.154.1017:07, 19 September 2010

I have reduced the avatars to 32 pixels in size at this time. There is also an obvious switch to flip to turn them off on the page so that you don't see them.

Jorm (WMF)01:55, 28 January 2011

The new version is certainly a big improvement, in my opinion, but it really needs to be possible to eliminate avatars completely on a wiki, and the duplication of the "Start new discussion" bars could be a problem on pages with only one or two discussions. On the screenshots, I don't see the header anywhere, where is it? Also, is this going to be rolled out to any of the Wikimedia wikis with LQT currently enabled anytime soon?

Yair rand04:20, 28 January 2011
 
 
 
 

Two questions

When this extension is finally completed, perhaps far off into the future, will it be enforced upon Wikimedia sites, or will each have the option of choosing whether to implement LiquidThreads and how this may be done? It was hard enough when Vector skin was enforced, and that thing was technically optional. I'm just worried that, for example, someone simply flicking the switch to enable it on, say, Wikipedia could carry highly disastrous consequences. It would be nice if the projects are given the opportunity to discuss the specifics of implementation, and highlight potential problems that need to be addressed.

My other question is whether some sort of section break feature could be implemented? Sometimes it's nice to be able to break a discussion in two, and yet have a sort of anchor to jump midway through it or whatever. --86.29.33.236 21:57, 30 November 2010 (UTC)

86.29.33.23621:57, 30 November 2010

We'll certainly be doing our best, in co-operation with the Community department, to make sure that the rollout is smooth, orderly, and that the community is consulted throughout it.

I don't understand the use of the "section break" feature on Wikipedia. It seems to be a strange practice that emerged because it was the habit of one or two prolific posters on certain popular noticeboards. We don't presently have any plans to implement anything similar to it; but the problem of "finding your place" in a discussion is one that we are thinking about.

Andrew Garrett04:36, 6 December 2010
 

"To Top" Button

Edited by another user.
Last edit: 07:03, 22 August 2010

I don't think we need a button to take you to a post's parent. The parent is almost always directly above the post and not hard to identify due to the indentation. Having such a button only adds interface clutter, IMO, as I don't know why anyone would ever actually use it (other than to figure out what it's for).

Kaldari 07:03, 22 August 2010 (UTC)07:00, 22 August 2010

When its a long discussion and you quickly want to jump back to the top so you can reply directly to it?

Peachey8810:28, 22 August 2010

But that's not the way Talk page discussions generally work. People don't reply to the original post, they reply to the previous comment. Is the idea here to move people away from that sort of discussion behavior and towards a more traditional discussion board style? Kaldari 18:25, 27 August 2010 (UTC)

Kaldari18:25, 27 August 2010

I think that the scope it's the opposite: you need the "parent" link to understand what the post is replying to. Messages are often messed up with cross-references to previous ones, this is not so rare.

Nemo06:30, 5 September 2010

Please don't call it 'Parent'. It's object-programming jargon that has wound up all over web UIs. Parent to most people means the people who made them and took them to little-league practice; they are not used to seeing it as a technical navigation feature. Please just use Top (Top Post?).

Also, would a link to the top of the page (to the TOC be helpful?) Ocaasi 17:05, 19 September 2010 (UTC)

69.142.154.1017:05, 19 September 2010

It's not the top post, though. It's the immediate ancestor of the reply, hence the name "parent".

GreenReaper12:32, 19 February 2011
 
 
 

Speaking of which, whatever happened to the idea, previously discussed ([1], [2]) and tried out in the LiquidThreads Labs, of making "add a message to the thread" the default action, rather than "reply as a new sub-thread?" Can someone point me to the discussion where it was decided that it is better to steer discussions into a rightward crab-walk?

Ningauble18:08, 30 September 2010
 
 
First page
First page
Previous page
Previous page
Last page
Last page