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.
lcrocker@nupedia.com wrote:
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.
- 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.
Any other desired feature that limits the set of pages returned is also likely to get a favorable hearing.
I was quick to read how more than 500 pages could be listed when higher number page links were removed from the Recent Changes page, but I didn't need this feature as much with the old system as with the new. I suppose some people would like to track all the multiple changes on Recent Pages, and I know that when I reread some of my own work it often needs changes, but making them kills the explanatory note that went with my substantive changes.
What I really miss is not being able to use the back button to get back to where I was. It now forces a reload whenever I do so. I've noticed it most with Recent Changes, but I've also had it come up while editing a page. My habit has been to use search to go to verify a page name when I'm trying to create a link from the page I'm editing. Now when I back-button from the search results I get a brand new edit page with my partial edits deleted.
Simply being able to alter personal preferences to choose between a reload or personal cache when using the back and forward buttons would be a great advantage.
Eclecticology
On Tuesday 23 July 2002 18:45, Ray Saintonge wrote:
What I really miss is not being able to use the back button to get back to where I was. It now forces a reload whenever I do so. I've noticed it most with Recent Changes, but I've also had it come up while editing a page. My habit has been to use search to go to verify a page name when I'm trying to create a link from the page I'm editing. Now when I back-button from the search results I get a brand new edit page with my partial edits deleted.
Back works fine for me in Konqueror, unless I've viewed more than ten pages since. What browser are you using?
phma
Pierre Abbat wrote:
On Tuesday 23 July 2002 18:45, Ray Saintonge wrote:
What I really miss is not being able to use the back button to get back to where I was. It now forces a reload whenever I do so. I've noticed it most with Recent Changes, but I've also had it come up while editing a page. My habit has been to use search to go to verify a page name when I'm trying to create a link from the page I'm editing. Now when I back-button from the search results I get a brand new edit page with my partial edits deleted.
Back works fine for me in Konqueror, unless I've viewed more than ten pages since. What browser are you using?
Netscape 6
On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker@nupedia.com wrote:
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.
Do we have some measurements on this? Would it be worth the effort if I tried to come up with some SQL that did this for the new script?
-- Jan Hidders
On Tuesday 23 July 2002 19:23, Jan.Hidders wrote:
On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker@nupedia.com wrote:
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.
Do we have some measurements on this? Would it be worth the effort if I tried to come up with some SQL that did this for the new script?
I prefer not consolidating, as that lets me see if there's a vandal about, even if most of the vandalisms have been overwritten. (I still put the IP address of the vandal/newbie in the comment when fixing.) If you must consolidate, at least don't consolidate major edits with minor ones.
phma
Pierre Abbat wrote:
On Tue, Jul 23, 2002 at 02:48:12PM -0700, lcrocker@nupedia.com wrote:
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.
I prefer not consolidating, as that lets me see if there's a vandal about, even if most of the vandalisms have been overwritten. (I still put the IP address of the vandal/newbie in the comment when fixing.) If you must consolidate, at least don't consolidate major edits with minor ones.
I'd prefer to group edits together by page if we can figure out a way to do it efficiently, but I do like seeing all edits in the list.
-- brion vibber (brion @ pobox.com)
--- Pierre Abbat phma@webjockey.net wrote:
On Tuesday 23 July 2002 19:23, Jan.Hidders wrote:
On Tue, Jul 23, 2002 at 02:48:12PM -0700,
lcrocker@nupedia.com wrote:
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.
Do we have some measurements on this? Would it be
worth the effort if I
tried to come up with some SQL that did this for
the new script?
I prefer not consolidating, as that lets me see if there's a vandal about, even if most of the vandalisms have been overwritten. (I still put the IP address of the vandal/newbie in the comment when fixing.) If you must consolidate, at least don't consolidate major edits with minor ones.
It used to be an option on the user preferences page. That's what I would like to see.
-- Stephen G.
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
Stephen Gilbert wrote:
It used to be an option on the user preferences page. That's what I would like to see.
Stephen's talking here about the ability to see all the edits, or to see them consolidated by article.
I, too, prefer to see this as an option on the user preferences page. Both are useful, and I've used both, and I used to switch back and forth pretty often depending on what I was trying to do.
Efficiency, of course, is crucial, more important than most other features, because all the fancy features in the world won't create joy for humankind if the server is so bogged down that we can't even use the site. :-(
--Jimbo
On Wed, Jul 24, 2002 at 05:06:16AM -0700, Jimmy Wales wrote:
Stephen Gilbert wrote:
It used to be an option on the user preferences page. That's what I would like to see.
Stephen's talking here about the ability to see all the edits, or to see them consolidated by article.
I, too, prefer to see this as an option on the user preferences page. Both are useful, and I've used both, and I used to switch back and forth pretty often depending on what I was trying to do.
I don't think there ever was such an option. Wat we did have was an option to hide minor edits and that is still there, although currently not operational but Lee promised to repair it soon. I suspect it will alleviate most of the pain of seeing all the separate edits.
-- Jan Hidders
--- "Jan.Hidders" hidders@uia.ua.ac.be wrote:
On Wed, Jul 24, 2002 at 05:06:16AM -0700, Jimmy Wales wrote:
Stephen Gilbert wrote:
It used to be an option on the user preferences
page.
That's what I would like to see.
Stephen's talking here about the ability to see
all the edits, or to see them
consolidated by article.
I, too, prefer to see this as an option on the
user preferences page. Both
are useful, and I've used both, and I used to
switch back and forth pretty
often depending on what I was trying to do.
I don't think there ever was such an option. Wat we did have was an option to hide minor edits and that is still there, although currently not operational but Lee promised to repair it soon. I suspect it will alleviate most of the pain of seeing all the separate edits.
It was a checkbox labeled something like: "Show all edits on Recent Changes (not just most recent)" on UseModWiki. The phase II software had something similar. Trust me, it was there. I toggled the status every once and a while.
-- Stephen Gilbert
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
On Wed, Jul 24, 2002 at 03:27:37PM -0700, Stephen Gilbert wrote:
It was a checkbox labeled something like: "Show all edits on Recent Changes (not just most recent)" on UseModWiki.
Ah, that could be, I wasn't around then.
The phase II software had something similar. Trust me, it was there. I toggled the status every once and a while.
Are you really sure? I implemented the SQL behind the Recent Changes page for the phase II script, so I should have noticed. :-) (Or perhaps it's my fault the option was removed.) Anyway, I believe reintroducing the option is considered at the moment.
-- Jan Hidders
--- "Jan.Hidders" hidders@uia.ua.ac.be wrote:
The phase II software had something similar. Trust me, it was there. I toggled the
status
every once and a while.
Are you really sure? I implemented the SQL behind the Recent Changes page for the phase II script, so I should have noticed. :-) (Or perhaps it's my fault the option was removed.) Anyway, I believe reintroducing the option is considered at the moment.
*Very* sure. Someone should back me up here, before I feel the need to add more astericks. :)
-- Stephen G.
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
--- lcrocker@nupedia.com wrote:
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.
It's not a cosmetic change for me. Having the changes on the same article consolidated makes Recent Changes usable. The current setup makes it impossible for me to quickly scan the page for changes I might be interested in; my eyes trip over the seventeen changes in a row made to one particular article.
-- Stephen Gilbert
__________________________________________________ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com
wikipedia-l@lists.wikimedia.org