Talk:LiquidThreads 3.0/Design

See also Extension talk:LiquidThreads.

Previous page history was archived for backup purposes at Talk:LiquidThreads 3.0/Design/LQT Archive 1 on 2015-06-10.

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?

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)

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

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

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

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

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)

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.

I don't know that finding a single word that matches perfectly; we really need to come up with a concept that matches, something that flows naturally and implies a parent-child relationship.

This is the type of thing where knowing fifty languages would be useful.

I agree, and I think that "discussion" is the best concept to adopt. :-)

I do not know if it will be possible or useful to cater for all languages even though this would be the best case scenario. At some point we have to rely on what the translators do. The English should make sure that the wording is ok for them and describes the situation best as Jorm already wrote. E. g. to directly translate “thread” into German, though there is a matching word for it, would lead to disaster. Thus “thread” was ignored in favour of a word that describes best what is meant. I think this should be possible in all other languages, too. Just speaking as a foreigner, but Jorm's proposal still sounds good to me.

Indeed, the portuguese translation currently is "Tópico" (topic), because the words corresponding to thread are not that acceptable in this context.

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

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

Mechanics

Scrollable table of contents

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

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

Dismissible pop-ups

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

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

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

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

Automatic polling

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?

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

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

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

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.

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.

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

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

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!)

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,

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

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.

Great, I have done. I also added a feature request here. Sj 19:35, 4 July 2011 (UTC)

is anything being done on this? how far along is the code? and where's the code for this? I'd love to use this on my wiki

This design continues to inspire me :-)

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

Good question.

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

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.

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

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.

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.

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?

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.

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

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 :-)

I would take umbrage at that remark, but it appears that MediaWiki does not have high expectations for civility. If thought-terminating clichés such as "crappy" and "anal" are characteristic of decision making at MediaWiki, notwithstanding smiley faces and quotation marks, it would go a long way towards explaining the perception in some quarters of a disconnect with Wikimedia user communities.

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

Preferences are the enemy.

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.

Here the signature is updated automatically

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.

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

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.

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.

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

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.

I think that is an easy thing to agree on.

• 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

So I know this is an old topic but I couldn't help but chime in. The term "graphic distraction" is an interesting one. I think if you ask most "usual" web surfers, they would state that they'd rather see a web page with both images and text rather than a text-heavy page with no images. Where one says "content-rich," I think, man, I really have to read all that? Images help give your eyes something different to look at and connect the text you are reading with something visual, making the connections stronger in your mind. Images make a page fun to look at.

Have you seen reddit?

The summary proposal is an interesting one; I haven't seen a discussion forum with such a feature before. A couple of questions:

1. Would there be a mechanism to cross-reference individual posts in the summary? I could envision a summary along the lines of "Participants have proposed some advantages [1], [2], [4] and disadvantages [3], [2] of such-and-such." (where the bracketed numbers refer to posts within the discussion)
2. Would there be a mechanism to ensure that all posts/ideas are covered in the summary? The ability to "control" the summary might allow participants to bias the direction of a discussion substantially. For instance, in a contentious discussion, a summary author might ignore some opposing points of view that were raised; there would then be a risk that the opposing ideas would be ignored by all but the most careful followers of the discussion. Even for conscientious users, I'd imagine the task of maintaining an accurate summary would be daunting once the conversation gets "interesting." Do you see any ways to mitigate these problems?

Ideas that come to mind for #2 are:

• thresholding the number of times a given user is allowed to edit the summary relative to the rate of new posts
• varying which users are prompted to work on the summary so as to encourage a diversity of perspectives
• when the user goes to update an existing summary, highlight all posts added since the last time the summary was updated to call their attention to the user
• require that all posts having some minimum number of words be "covered" in the summary, either cross-referenced explicitly or rejected as unimportant when the summary is edited
• a voting/rating or reviewing mechanism for the quality of a summary or individual "improvements" to it; this could be tied to a trust score for users, such that some are seen as more trustworthy when it comes to writing adequate summaries, and are thus given wider latitude in doing so

I'm not sure which of these would be workable/desirable/necessary, but it seems like a viable summary feature will require a fair bit of experimentation. :-)

There are a couple things brought up here that I think are worth talking about. First, I'll (try) answer your questions.

1. Such a mechanism already exists. You can find the links to any post within a thread and reference that, just like you would any other wiki page. For example, the link to your question (that I am responding to) is here. Currently, the "link to" action is located under the "More" menu. References to posts in a summary can just be done using those links.
2. Since (currently) the summaries in LiquidThreads topics are hand-generated, there won't be any way to ensure full summary of all posts or ideas. Just like an article, summaries can be edited by anyone (so if there is a contention that certain POVs were not included, they can be added by anyone.

Now, the problems inherent with issue 2 are very interesting. We (the WMF) are currently talking with a couple researchers from the University of Washington who have developed a technology called REFLECT that does pretty much what you're looking for (or begins the technology roadmap for it). You can read about their design proposal here.

I am clearly interested in this technology but am unsure when we'll be able to start the study, which is a concern.

On #1: there are some problems and suggestions for links to posts/threads: see bugzilla:24813 and the links I put there.

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?

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?

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

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.

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.

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.

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

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

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.

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

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.

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.

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.