Fugliness

Jump to navigation Jump to search

better now?

-- Nx / talk19:41, 29 November 2010

My take on the fugliness has more to do with how chunky the whole thing is, and how much screen real estate each message takes up. It's got an unwieldy feel about it, if that makes sense. Although I know some folks were more motivated by the shaded background.

Kels (talk)20:32, 29 November 2010

Actually, it's just one extra line for the sig/timestamp and the buttons. I hope you don't have javascript disabled though, because then you'll see the buttons in the "More" menu below each comment. That's probably something I should fix.

-- Nx / talk20:38, 29 November 2010
 

And IMHO the grey background did add to the "heavy", clunky feeling, but with the white it almost looks like traditional talk pages.

-- Nx / talk20:42, 29 November 2010
 

Still seems a bit buggy/clunky to me, though I very much like the overall idea. Just sayin'.

Blue (pester)20:42, 29 November 2010

The idea is great, but it makes things take up far too much space. It's not just the sig/buttons, it's all the extra whitespace. With just 5 comments, this topic was already taking up half a screen. That will make long topics on WIGO:CP or SB almost unreadable.

SuspectedReplicant retire me20:56, 29 November 2010

I agree with you there - I'm not sure places like TWIGOCP and the Saloon Bar would benefit from this system. Perhaps for that type of informal discussion a modified, streamlined version of liquidthreads would be more appropriate, but they're obviously not developing something like that.

The forumspace, however, would benefit from looking more like an organized forum.

Blue (pester)21:03, 29 November 2010

TWIGO:CP and the Saloon bar would benefit more because they have a lot of unrelated threads, with a higher chance of ECs, and a huge db size overhead. The Forum is actually a partial solution to the same problem LQT is trying to solve, because it separates threads into individual pages, LQT goes further and makes each comment a separate page.

-- Nx / talk21:13, 29 November 2010

I am getting substantial load times on this page. Is it just me?

Tmtoulouse (talk)21:15, 29 November 2010

Nope. It's incredibly slow to load, and seems to be screwing up Firefox too - it's started taking up a lot more processor time than usual.

SuspectedReplicant retire me21:20, 29 November 2010
 

Problem is, if you had the same amount of comment traffic we do now, this version of LQT would increase the screen length what, four times? That's a hell of a lot of scrolling, and to my mind that makes things less readable, even with the benefit of doing away with the occasional EC (and they only ever happen to me occasionally, so to me they're not a big deal).

Kels (talk)21:22, 29 November 2010
 

This layout on those pages would be a total disaster. We'd make the World's Highest Website look like a speed bump.

SuspectedReplicant retire me21:22, 29 November 2010
 
 

I've decreased the padding and hidden the toolbar (the reply, parent, more buttons in the lower right of each comment) until you hover over a comment. Better?

-- Nx / talk21:43, 29 November 2010

That is actually quite a bit better.

Blue (pester)21:54, 29 November 2010

I agree its looking pretty good, just the load times on this page seem excessive.

Tmtoulouse (talk)21:56, 29 November 2010

Yeah, LQT could do with some optimizations. The problem is that since each comment is a separate page, there's a performance overhead - similar to how template signatures slow down the saloon bar drastically.

-- Nx / talk22:00, 29 November 2010

Isn't this essentially the same as the best of Conservapedia, in that you have hundreds of little pages being displayed on one using Ajax? Why does that load so much faster than?

- π00:08, 30 November 2010

Not ajax, it's assembled server-side, but it still has to collect all those pages (in the case of bestof, they're just database entries, not MW pages) and parse them separately. I think the separate parsing is the problem.

-- Nx / talk07:13, 30 November 2010

Definitely looks better now, although I still think the big talk pages will be too big - it's just the way this works. Plus it's so slow! SB takes 4s to load. This takes 20. I shudder to think how long it would take on the long talk pages.

SuspectedReplicant retire me12:55, 30 November 2010

I'll do some profiling and try to figure out a way to speed things up.

-- Nx / talk19:58, 30 November 2010

Without wanting to be called Captain Obvious, and without knowing the table structure, it looks like some serious indexing is needed - presumably there's some kind of ThreadId along with a PageId? A multipart index on those two - PageId first - would be my guess. But yes, profiling is the way to go. Actually, it already seems quicker than it was earlier.

SuspectedReplicant retire me20:06, 30 November 2010

I think the bottleneck is in the parser though, at least that's my experience with wigo, which has a similar problem performance-wise (lot's of small, separate pieces of wikitext)

-- Nx / talk20:07, 30 November 2010

I know you know more about MW than I do, so I shall defer to your better knowledge... but as a SQL DBA I would still suggest a quick look at the indexing.

SuspectedReplicant retire me20:19, 30 November 2010
 
 

Ok, here's an excerpt from an example output. Out of 13 seconds (it's slower when profiling is on), Article::getContent takes up only 0.314916 seconds. There are 254 Article::getContents calls, but only 157 call Article::loadContent calls, and 174 Revision::loadText (this is what loads the revision text from the db) calls. Revision::loadText takes up only 0.088527 seconds, so the database is definitely not the bottleneck. The parser is. In fact, the number of wfMsgReal calls greatly concerns me...

(format is seconds count name)

13.215451      1 - -total
3.611685  26819 - wfMsgReal
3.447692   1287 - Parser::parse
3.399038   1287 - Parser::parse-OutputPage::parse
2.164450    138 - WikiEditorHooks::addModules
2.131158   1292 - Parser::internalParse
1.788212   2005 - Parser::replaceVariables
1.526407    694 - Parser::transformMsg
1.496620    694 - Parser::preprocess
1.345063   3222 - PPFrame_DOM::expand
0.996161   1142 - Parser::braceSubstitution
0.904751   3313 - Preprocessor_DOM::preprocessToObj
0.775065      1 - Setup.php
0.762118      1 - Setup.php-SetupSession
0.580727   2004 - Parser::clearState
0.411560   3308 - Preprocessor_DOM::preprocessToXml
0.314916    254 - Article::getContent
0.302848    157 - Article::loadContent
0.278424   3313 - Preprocessor_DOM::preprocessToObj-loadXML
0.274240    795 - Database::query
-- Nx / talk21:46, 30 November 2010

You're right that it's not the major cause, but if I was a DBA on a system taking 1/3s to return this little content.... I'd be concerned. Is that the only call getting content? Remember - I know nothing about MW but loadContent seems to take a while too.

I know MySQL is only an open source database, not a proper product, but I wouldn't expect a database to be taking this long over a simple query based on a very few params.

SuspectedReplicant retire me21:53, 30 November 2010

The db stuff is much less than that actually - I'll have to insert more profiling calls to figure out why loadcontent takes so long (I have an idea), but the actual db access is in Revision::loadText, which is only 0.088 seconds. The profiling info also contains all the database queries, but I didn't write them down - they were really quick, so it's definitely not the database. And even 0.3 seconds is relatively small compared to the total.

-- Nx / talk22:09, 30 November 2010

True, but I hope you're right that the DB stuff is less than 0.3s - it should be (essentially) zero for a system of this size.

I'm not trying to annoy here, but please just take a look at the indexing anyway? Yes, it's mainly down to the parser, but every little helps.

SuspectedReplicant retire me22:20, 30 November 2010
 
 
 
 
 
 
 
 

I found the cause and fixed it, it should now be much better. This page is now slightly slower than the saloon bar. I'll see what other optimizations I can do.

-- Nx / talk22:59, 1 December 2010

That is a lot smoother.

- π23:06, 1 December 2010

That is much better. Thanks, Nx.

SuspectedReplicant retire me13:45, 2 December 2010
 
 
 
 
 
 
 

I think it looks loads better. It's also not much bigger than the usually talk page crap. And separating and boxing the comments makes it far more readable.

I assume that sectioning off threads properly would stop the massive load times. Loading something the size of the entire SB with this would be insane (I have issues loading it sometimes), but one section at a time wouldn't be too bad - indeed, it would be preferable compared to scrolling up and down it.

The biggest problem, IMHO, is that we're used to the "normal" system, so have gotten used to the quirks and can generally parse the horribleness and deal with the edit conflicts. This is a system that solves problems that we no longer notice! And because we're also used to talk pages running on, splitting it up into threads would be slightly different to get used to.

Scarlet A.pngpathetic13:25, 30 November 2010

Solving problems that we don't notice while creating problems which we do notice doesn't seem like it's going to help us massively. I think there's still quite a lot that would need to improve before this could be used on wider scale, like the mess it makes of recent changes, user contributions & watchlists by having edits & comments in conflicting formats.

I'm still not convinced that this will be an ideal system for wiki-noobs. Most online forums have a straightforward system where users either reply to an existing thread or start a new one, but liquidthreads is more complicated. Being able to cut & move threads may be useful, but the reply button against each individual post is confusing. It's not obvious whether the right thing to do when posting in a thread is to reply to the initial post, or reply to the post above. Plus there's always the possibility that a new user, who is used to wikis but confused by liquidthreads, may just click "edit" at the top of the page & hence start a thread outside of the liquidthread & make a mess of the talk page.

I guess the best way to check whether it really is user-friendly for noobs would be to post welcome messages etc. using liquidthreads on new users' talk pages & if they respond to it. But it's probably a bit early to try this yet.

tl;dr version: There is no ideal way of communicating on the internet.

By "not noticing" problems, I suppose should have said "problems we don't care about and just begrudgingly accept". Don't tell me you like edit conflicts! :P

Some forum systems do have reply buttons to individual posts and thread the comments in a tree like structure. I will grant you that those aren't as popular anymore as the linear ones (and seem mostly restricted to old-skool newsgroups), but the alternative to specific replies like this is to go completely linear then add the quote box option as done in other forum systems - so you quote and then add your response and this sort of thing is built in. This method is nice and all but it's a bigger deviation from the usual wiki-way, and anyone who's seen a dozen nested quote boxes will know how bad that can get if it's not controlled! I think this system is an good compromise between the usual wiki-way of doing things and a more flexible and powerful forum system. It's certainly far more compact than a lot of other ones where 90% of the screen is taken up with sigs and avatars and post counts and quote boxes and loads of extra buttons about things. Once you've spent some time in phpBB or SMF or whatever (this is what I am/was used to in my pre-RW days), you find that LQT is a minimalist breath of fresh air.

I see your point about those used to wikis getting confused, and indeed I think people might if they're used to editing. But the way of doing it by wiki is something you need to get used to and learn anyway - it's a complicated piece of etiquette that was designed out of a system not meant for discussing things and as such is not an ideal solution. The talk pages are meant for brief comments regarding articles, where things are focused, to the point, and likely to get one edit every few hours, if not less. So in the case of RW where we may have faster paced discussions where people with larger entries (an entry this large would certainly get an EC in the Saloon Bar, I'd wager) there are areas where LQT would be beneficial and removes the farcical aspects of the wiki-way. "Retraining" back to threaded comments can't be too hard comparing to learning the system in the first place.

I also don't think the etiquette of what comment you reply to is anywhere near as complex as the manual indentations of the existing wiki-way (in big discussions, this is borderline farcical). Here you simply reply to the thread you're responding to; talk to the OP, reply to them, talk to the last commenter (as I'm doing now) reply there, talk to a person above specifically and go there. Excessive nesting may be a problem, but that's a problem anyway, hence the "undent" trope. This is something that can hopefully be fixed in LQT and perhaps added automatically, again this would be solving a problem we begrudgingly accept. I think that's considerably more intuitive for branching discussions compared to the usual wiki-way, where it feels like you're actively discouraged from replying to an earlier comment (or need to add a lot of exposition in to explain yourself). You get a new message either way, so it will be read by those in the thread.

With clicking "edit", that can be switched off to make it n00b proof, as I believe it is on Nx's talk page. Similarly, such an edit button isn't visible when responding via the "new messages" page.

I'd be against adding LQT to new users pages, but I can see that would be an interesting experiment to try if they opt in. It be interesting to see someone with no experience of wiki-way etiquette use it - I honestly think it won't be a problem.

Scarlet A.pngpathetic14:57, 30 November 2010

Style-wise, I'd say this most resembles the comment system on LiveJournal and its derivatives (InsaneJournal, DreamWidth, etc.). Got its uses, but I dunno if this is one of them.

Kels (talk)22:43, 30 November 2010