Talk:LiquidThreads 3.0/Design

Jump to: navigation, search

About this discussion

See also Extension talk:LiquidThreads.


By clicking "Add topic", you agree to our Terms of Use and agree to irrevocably release your text under the CC BY-SA 3.0 License and GFDL
Yair rand (talkcontribs)

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

Reply to "Too colorful?"
Trockennasenaffe (talkcontribs)

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?

Reply to "Use of color"
Ancient Apparition (talkcontribs)

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?

Peachey88 (talkcontribs)
"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.

Ancient Apparition (talkcontribs)

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.

Sj (talkcontribs)

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.

Reply to "Viability on the English Wikipedia"
188.134.35.136 (talkcontribs)

Where we can find LiquidThreads new branch for testing?

Reply to "can we try new version?"
Toshio Yamaguchi (talkcontribs)

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?

Sj (talkcontribs)

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.

Reply to "Really wanted?"

transferring current talk pages to liquid threads?

6
Jerilderie (talkcontribs)

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?

Redekopmark (talkcontribs)

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

Werdna (talkcontribs)

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

Jerilderie (talkcontribs)

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?

He7d3r (talkcontribs)

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

Reply to "transferring current talk pages to liquid threads?"
Myrtone (talkcontribs)

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.

Reply to "Thread namespace"
MZMcBride (talkcontribs)

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?
Ningauble (talkcontribs)

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.

Nemo bis (talkcontribs)

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.

Reply to "General comments"
MZMcBride (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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?

MZMcBride (talkcontribs)

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.

Reply to "Truncation"

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

8
Smile Lee (talkcontribs)

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.

Myrtone (talkcontribs)

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

Redekopmark (talkcontribs)

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

Jorm (WMF) (talkcontribs)

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.

Yair rand (talkcontribs)

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

174.50.85.207 (talkcontribs)

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.

Smile Lee (talkcontribs)

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.

Sj (talkcontribs)

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.

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