|Thread title||Replies||Last modified|
|General comments||2||13:56, 5 January 2013|
|progress on redesign?||16||08:36, 18 November 2012|
|Page Updates and Refreshes||10||09:00, 25 April 2012|
|Too colorful?||0||15:30, 25 March 2012|
|"Discussion" versus "Topic" versus "Thread"||12||21:47, 9 November 2011|
|Use of color||0||17:55, 4 October 2011|
|Viability on the English Wikipedia||3||21:12, 4 July 2011|
|Is it really necessary to allow users to edit each other's posts?||7||20:15, 4 July 2011|
|Really wanted?||1||20:12, 4 July 2011|
|Some thoughts||6||20:08, 4 July 2011|
|Diffs (was: Huge watchlist and high traffic environments)||2||19:36, 4 July 2011|
|transferring current talk pages to liquid threads?||5||13:54, 9 June 2011|
|Thread namespace||3||07:11, 6 May 2011|
|can we try new version?||1||07:05, 6 May 2011|
|Avatars are unacceptable||7||18:55, 31 December 2011|
|Truncation||2||06:45, 28 January 2011|
|My complaints||5||04:20, 28 January 2011|
|Two questions||1||04:36, 6 December 2010|
|"To Top" Button||6||12:32, 19 February 2011|
|Avatar visibility||12||15:32, 22 September 2010|
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.
- 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.
- 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.
- 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.
- Is the lack of a "show preview" button deliberate?
[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.
- 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.
- 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.
- 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.
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
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.
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,
What is the status of this latest iteration of LT? It has been almost six years...
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.
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.
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
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 :-)
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.
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.)
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":
- Discussion Page
- Topics (n+)
- Summary (0-1)
- Posts (n+)
- Topics (n+)
- Discussion Page
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.
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 don't see LT as viable on the English Wikipedia and where its use is intended for the following reasons:
- 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
- It takes up far too much space, the current system ain't broke so why create a problem?
- It is not aesthetically pleasing
- 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.
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.
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
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.
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?
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.
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.)
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 : )
There's no need for asterisks or colons to distinguish replies from each other. Each post is already self-contained.
- 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.
"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?
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.
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.
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?
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
Yes, it's unlikely that there will be an automated migration path for old talk pages. It's a difficult problem to solve correctly.
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?
[[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...
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.
At the moment it's actually broken, but you can find it at http://svn.wikimedia.org/svnroot/mediawiki/branches/lqt-rewrite
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.
- 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.
The "Secondary Requirements" and "Dynamic Insertion" sections are truncated.
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?
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.
- 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.
Yes, the background currently seen on TWN is pretty unpleasant. Making it brighter would definitely improve readability.
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
Yes, smaller avatars would be an improvement. Ocaasi 17:07, 19 September 2010 (UTC)
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.
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?
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. --184.108.40.206 21:57, 30 November 2010 (UTC)
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.
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).
When its a long discussion and you quickly want to jump back to the top so you can reply directly to it?
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)
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.
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)
Speaking of which, whatever happened to the idea, previously discussed (, ) 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?
Lots of very good thoughts went into this -- thanks for all the hard work.
I would suggest reconsidering the notion that avatars not be visible by default. If indeed avatars are a good idea (and it would be great if we could somehow test that hypothesis), offensive avatars are likely going to be dealt with in much the same way that offensive usernames are currently dealt with, i.e. fairly quickly. If that is not the case, then I'm not sure an opt-out/opt-in mechanism is going to help much -- it just seems to add complication to the overall system that should be avoidable.
I'd like to discuss this at some point, along with Philippe.
I think the idea of hiding for anonymous users might be sound, but I'm not sure on hiding by default for logged-in users, and I definitely think it should be an AJAX button to turn them on.
I had a discussion with Mike about what our legal culpability would be in regards to this and he said that there was basically none whatsoever, so it doesn't matter if we hide or not.
Given that, I think it's probably smart to chop the entire opt-in/out system for avatars as an un-needed complication. The community may feel otherwise, but if this is the case we can always add the functionality then.
One thing I love about plaintext MediaWiki discussions is that they're extremely concise in appearance: minimum spacing between posts, inline signatures instead of the insanity an average forum offers, nothing to hurt my eyes (custom signatures that are really ugly are rare, not only due to technical limitation of 255 bytes per sig, but also due to community's negative attitude towards them). LQT already departs from some of these principles for a good reason - and I must say that it is implemented in a maximally non-intrusive way. Hovewer, avatars are a different things: they add more visual noise, take away valuable screen space (especially important for threaded discussions with ever-increasing indentation), encourage MySpacing and distract people from discussion itself. Even worse (much, much worse) are animated avatars, the abomination on the face of the Earth that increase the negative impact by orders of magnitude. Not to speak of new possibilities of trolling.
One must understand that avatars are features from media intended for communication (forums, social networks and IM), and not for content creation, which MediaWiki is intended for. Therefore I object strongly against avatars at all, and if they will be implemented, believe that they should at be hidden by default and animated avatars be uncompromisingly disabled.
+1 to everything Max said. I don't find avatars to be particularly useful for anything except trolling and used as status symbols.
To repeat what I said on IRC: ^demon: So anyway, I hate the idea of avatars. I know it's probably coming regardless of what I say, but meh...I want to go on record as saying "bad idea."
Edit conflict. Hi, I agree, this redesign proposal is really cool! I think it is best to disable avatars as a standard. If someone really needs them, he or she may turn it on. Cheers --kgh 10:51, 4 August 2010 (UTC)
Summing up (mostly) my notes from the little I.R.C. discussion:
- Visual Space waste, People love minimalism these days
- Visual Distraction sometimes
- Personally I love my fluro (example: pink, green) colour avatars, others obsessively don't. Although this does already exist with our sigs, its alot less abus-able.
- Copy Right issues, People love their avatars that they just grab off random sites
- Would need a way to restrict/disable users from uploading images after multiple warnings
- Cross-Wiki, People these days on WMF wikis want cross wiki for everything and anything, which means they would need to be uploaded to a shared repo.
- Our largest and only(?) cross wiki repo is Commons, which takes a very strict approach in regards to removing copyrighted stuff, which will just induce more moaning.
I think the decision strongly depends on who will be using avatars. Wikia undoubtedly will opt for avatars, Wikipedia as you already stated hopefully will not. Avatars might also be useful for other wikis out there in the web. Since Wikipedia is top priority, I think you will all agree on this, the redesign should not cater for avatars in the first place. If this works stable...
I actually think that avatars would be nice to have. Obviously, as pointed out above, there are a few things to consider.
A special page (or some other mechanism) for privileged users to allow removing other users' avatars would be helpful; or then we could do it how wikiHow does. Once an avatar is uploaded, an admin has to approve it before it is shown. SocialProfile extension handles the avatar system by providing an upload page, Special:UploadAvatar, to upload avatars and an avatar removal page, Special:RemoveAvatar, for privileged users to remove others' avatars.
Which brings me to the next point...how would avatars be stored? As normal files? SocialProfile stores them separately in
$wgUploadPath/avatars/ and they are not treated as normal wiki files (i.e. they don't have a File: page and so on).
Also, it would be useful to have a user preference to enable/disable the displaying of avatar images. This way people who don't want to see avatars wouldn't have to, but those who want to see them would be able to.
Maybe avatars could be simply stored in some .js user subpage (to avoid reinventing the wheel), or the same approach could be adopted: .css/.js subpages are editable by the user and by sysops. Avatars should obviously be free images, on WMF wikis, since they can't be allowed by any EDP. Best solution: don't develop avatars ourselves (we're not interested in them), let Wikia do that. :-)