[Wikipedia-l] Recent changes page
lcrocker at nupedia.com
lcrocker at nupedia.com
Tue Jul 23 21:48:12 UTC 2002
This is a general reply to a couple of mails relating to the new
software's Recent Changes page.
It was a guiding principle of my new design that it be *fast*. I
think the performance of this page is critical to usability. Speed
is a feature too. So if you're going to suggest features, make sure
they are either (1) not hindrances to performance, or (2) really,
truly, vitally necessary.
1) If you wan't 1000, 2500, or more changes, you can do that by
editing the URL directly. They are removed as links from the page so
that robots won't spider them, putting a load on the server. The
occasional human use shouldn't be a problem. If enough people
complain, I might consider putting 1000 back, though the need for it
might be supplanted by other features mentioned below.
I'd also be happy to put in some shorter time limits: currently the
shortest is "1 day", but I can see that it might be useful to have,
say, "3 hours", "6 hours", and "12 hours". This would make it
possible to extend the limit to a bigger number and still have a
reasonably fast query, because the time limit really trims down the
result set and makes things fast.
Along those lines, I've had enough requests to restore the "show only
new changes" feature, and that feature can actually speed up the
database query, so I plan to put that back.
Yes, it is confusing that the "diff" link on early edits shows a
recent diff. I agree that this is a bug, and I will fix it as soon
as I can figure out a good method. This one just happens to be
trickier than it looks, but it's not a performance issue, so I'm all
in favor of doing it right.
Any other desired feature that limits the set of pages returned is
also likely to get a favorable hearing. Maybe a feature that shows
only pages beginning with a certain letter or string, pages edited by
certain people, etc. If we can design a reasonable interface for it,
these kinds of changes must meet a lower burden of acceptance because
they will generally be fast.
The tricky one is consolidating multiple edits to a page into one
entry on the Recent Changes page, the way UseMod and Phase II did.
This is a big performance hit. Perhaps a later redesign of the
database would make it more reasonable, or perhaps a new
implementation will come to mind that cures the problem, but for now
I just don't want to burden the server with extra work for what is,
to me, a cosmetic change that doesn't add functionality.
More information about the Wikipedia-l
mailing list