They should use a browser that's not so brain-dead that it can't tell that the forward and back buttons are for zipping through pages that
are
already open and should not be loaded all over again.
My suggestion: a very simple change would reduce this load on the server considerably: add target="_blank" to each link on the 'recent
changes'
page only. Now articles will be shown in a new window. The 'recent changes' list will only be refreshed when the user explicitly asks
for
it (via refresh button or menu click). This may alleviate slow
response
times somewhat.
Have you considered a browser that provides tabbed browsing?
Follow up suggestion: make Wikipedia block all MS Explorer users. It will probably reduce traffic by 90%. Get real. This is the world we live in: web designers will have to adjust to their user base not vice versa.
Erik Zachte wrote:
Have you considered a browser that provides tabbed browsing?
Follow up suggestion: make Wikipedia block all MS Explorer users. It will probably reduce traffic by 90%.
Hmm, that could solve our lag problems _and_ block out most vandalism. All in favor, raise hands. ;)
Get real. This is the world we live in: web designers will have to adjust to their user base not vice versa.
How silly of me to suggest to someone who is clearly looking for a better browsing experience a way to achieve it.
-- brion vibber (brion @ pobox.com)
How silly of me to suggest to someone who is clearly looking for a better browsing experience a way to achieve it.
I agree with Brion here: enforcing new windows is not a good way to deal with this issue, especially since forced new windows are very annoying for users who use tabbed browsing (myself included). It could be a preference, but a smarter solution would be to suppress the no-cache header (which is necessary for a good editing experience in some browsers) on the RecentChanges page.
If anyone wants to do this, the code is open to you and fairly easy to understand [1]. It's probably not very high on anyone's priority list. The main problems with RC performance are being addressed by a change that loads the changes from an individual small table, instead of fetching them from the much larger article table. There are many other queries that generate high load on the DB server which need to be located and optimized. These are our real performance bottlenecks.
And if anyone has a lot of time to waste, a client side application that maintains a local RC table and fetches new changes (diffs) within regular intervals would be very neat, and a nice building block for the dedicated WP editor that some people are thinking about. We could help you by exporting our RCs as an XML-based web service ..
Regards,
Erik
[1] Feel free to contact me if you want to delve into it and I'll try to help as much as I can. I can help more if you're using a real OS (Linux,BSD etc.) though, as web development on Win32 is a PITA.
Erik Zachte wrote:
Follow up suggestion: make Wikipedia block all MS Explorer users. It will probably reduce traffic by 90%.
I'd vote for that. We'd be blocking a lot of junk edits :-)
Get real. This is the world we live in: web designers will have to adjust to their user base not vice versa.
Nope. The W3C sets standards and websites and browsers follow them.
If the people who program web browsers *don't* follow them, then it's unfortunate that the end-user gets caught in the crossfire. But there are now plenty of free, (fairly) compliant browsers out there, such as Mozilla: not that big a download on a modem & easy to install. Ditch IE and be free :-)
Most browsers open a link in a new window with a *modifier key*+click -- even IE -- though I would say that tabbed browsing is a necessity for RecentChanges weeding.
wikipedia-l@lists.wikimedia.org