New Recent Changes Discussion

I've found RecentChanges of little use in my two intense weeks of watching wiki. Instead, I have written a half dozen new tools and hacked wiki to support them. Most of these tools are way too expensive in system resources to make generally available. However, I will be constructing from them a fully automatic replacement for RecentChanges. NewRecentChanges is a preview. -- WardCunningham

See NewRecentChanges, NewRecentChangesPatterns.

The page length deltas might become icons (images) or something but for now I'm leaving them numbers because I see patterns in them. More of them will offer diffs eventually. -- WardCunningham

You can click on each number to see the corresponding diff.

Numbers are preferable to icons because some browsers slow down excessively if there are large numbers of images. The current process of preserving RecentChanges in ChangesIn? pages is useful, and the timings given by QuickChanges are sometimes of interest - e.g., they can make inappropriate editing of RecentChanges more noticeable.

Most interesting. I wish I could see who made each change, however. -- JeffGrigg

Without name or IP, the new list would not be useful. ID is needed to help selective review. -- dl

I like it too. And I want numbers, please do not use images. The current size would be useful too. I also miss at least the LastEditDate?. But adding each change date would probably overload the page. How about RecentChangesDetails? for each page?

Am I the only one who finds it more intuitive to put the most recent delta at the left of the list and go back in history as you move to the right? That way the most recent deltas all line up column-wise. I know that is contrary to the usual pattern of reading left to right - I think my bias stems from the fact that financial statements put the most recent period in the leftmost column. -- MarkTilley

Yes, that would be even better - especially if it is preceded with the current size. To line up neatly some table construction or fixed-font formatting would be required though.

It is really great for identifying spam. One look at it will spot all pages hit (same byte-difference).

Images would be a great idea, especially for the visual learners among us. Plus images are really good for seeing what is happening to wiki at a glance. If you set up proper caching headers on the client, and used the "sprite method", then most of the browser issues would be dealt with. -- JonathanArkell

I wonder whether Ward would look at what other Wiki like sites are doing with Recent Changes, take good advice from their experiences, and implement it here. That would surely set a good example of EgolessWiki.

Would a delta based on number of words be slightly more informative, for some very simple definition of "word"? Typo corrections would typically have a delta of zero. However, I've seen vandalism that involved replacing individual words with nonsense or offensive words, and these would also have a delta of zero. -- DanMuller

I'd like a +n/-n delta like cvs log does (+n being chars/workds/lines added, and -n thos deleted), that would help identify large changes, that don't change the cummulative size. -- GunnarZarncke

From JeffGrigg

"Ah-ha!" experience: Now I'm starting to understand the numbers and the patterns. Most interesting. Most interesting indeed. I still wish I could see the 'one of (UserName | HostName | IP Address)' indication on each change. Maybe it could be an optional parameter? (I do understand that having lots of parameters in the URL can be confusing and difficult.) -- JeffGrigg

See also FunnyWikiProcesses, that can be spotted with the NewRecentChanges.

Note: ChangesInNovember? blew a fuse: Adding November 30th data caused the following error message (reported in ChangesInNovemberThirtieth?). -- JeffGrigg

 The WikiWiki Server Can not Process Your Request
 Out of memory.
 This information has been logged.
 We are sorry for any inconvenience.

[Historical Note: This comment about ChangesInNovember? was, of course, from a few years ago, when we did 'ChangesIn<Month>' rather than 'ChangesInWeek<Number>'. This was one of the symptoms of 'ChangesIn<Month>' pages getting excessively large that prompted the change to the 'ChangesInWeek<Number>' style.]

New-Page issue:

There has been some interest in the logic by which pages are identified as new. I took a quick look at the source and found twisted logic typically associated with heuristics. In short, a page is new if its rev number is one. However, there are two separate histories that interfere with this simple rule. First, a page is considered new if its newness has not yet rolled off of (old) RecentChanges. Second, in a delete war, the rev number for a new page could be retrieved from PageHistory that is kept for several days. The logic in NewRecentChanges differs slightly so it may not align with RecentChanges. -- WardCunningham

Thanks Ward. I was getting the idea that there was a little more going on then what appeared as obvious.
But why has the use of "(new)" in RecentChanges been dropped without explanation or announcement?
- It was a result of Ward (recently) hacking the software and creating new tools to analyze the activity on Wiki (of which NewRecentChanges was one). I guess he never considered it a big deal for RecentChanges (and most likely was not worth the effort to try to fix) when the function still works for NewRecentChanges.
- How do you know that Ward was aware of it?
  - It was an issue that cropped up right away. Others have been complaining for a while, and at one point there was another discussion on the matter, from my recollection, in which Ward participated (if I remember correctly).

Ward - just out of curiosity, will you be getting rid of QuickChanges, then? I switched from using RecentChanges to QuickChanges some time ago, but it looks like NewRecentChanges may subsume its functionality. -- TimLesher

I hope not! QuickChanges has its uses too.

I would like to merge the functionality eventually. -- Ward

I'd like to rename NewRecentChanges (after all, it's no longer new). But it seems to stick.

I know that Ward originally intended to redo RecentChanges completely, but I'm not sure that would be wise now. At first, it looked as though NewRecentChanges would just be a sampling of what he is doing, but an interesting thing seems to be coming about. It seems that all of the current tools have their unique advantages: RecentChanges, NewRecentChanges and QuickChanges. I would hate to see any of them go away. As for renaming NewRecentChanges to RecentChangesScript, I have to ask: What is the name of the script that now produces the current page RecentChanges? I think that it could become very confusing. "New" seems to be a good way to distinguish between the two different pages and functionalities of the tools. It was Ward who named this page, really, as he started the page NewRecentChangesDiscussion, so I just dropped the discussion and put the tools in this page. Might be best to wait and see what final direction Ward decides take with all of this. These newer scripts: quickChanges and RecentChanges, are quite resource heavy on the server. That is one of the reasons why I further broke down the output links from days to include additional hours and also added minutes and seconds, so as to have choices that would be easier on the server. I hope, that in the end Ward does not try to put all of the functions into one resource-hogging utility, but rather that he provides us with many individual tools to be used when wanted or needed. I really think that it would be much better for the server, and that Wiki would be snappier running and make for happier users. Maybe Ward would care to comment on this, and in the meantime a little patience might be best, as things seem to take their own path sometimes and kind of insist on their own agenda and final outcome.

Would the name RecentChangeLog be an appropriate name for this new RecentChanges? At least that would imply that it is not updateable.

The new script's output is not an editable page, so it is more reliable than RecentChanges (for example, it can't be deleted) but can't contain arbitrary comments.

Bugs:

If there are more than two edits to a page, the first change is not viewable; the first change shown is not a link. (Links 2..(n-1) are HistDiffs, and link n (which may be 1) is the QuickDiff.)

NOTE!!! February 2010: Lately, no matter the page, when there gets to be a few edits by different IP addresses, both the IP addresses and the edits, soon make no sense, and are attributed to the wrong IP address, etc. Very confusing, and is causing all sorts of conflicts and misunderstandings. If it were not so frustrating and harmful, it would be humorous, but the miss-attributed edits to IPs, is creating serious troubles. Especially when an individual will make one small edit, but then that IP is suddenly associated with all edits, and those edits contents change with any other edit, etc., etc.,... The edits get all fouled up and do not reflect the actual edit changes in any way, or who made them, and so on. Have noticed that it is causing all sorts of conflicts, discontent, and arguments between users. So, I have no other recourse other then to declare NewRecentChanges EditsHistory? corrupt and broken. I have noticed this problem getting continually worse over this last year. It always was somewhat prone to corruption, but lately is totally off-the-deep-end. Also, if we had RecentPosts back, it may at least help in knowing who or how many times someone edited a page (never understood why that was disabled, as it is just too darn important). -- Seattle1

The problem appears to be confined to pages that have been deleted and restored, particularly if done repeatedly.

Edited RecentChanges description of NewRecentChanges, and got a whole lot of wrongful edits "-4609" when it should have been only a total of "+3" ["last day or so." -vs- "last 3 days or so."]. I still usually prefer NewRecentChanges though. The edits shown for the page GrammarVandal seem to be permanently messed-up, as there is no way to know what editing I did/not do.

CategoryWikiMaintenance