Topic on Talk:LiquidThreads 3.0/Design

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.