[Home]DifferenceSuggestions

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Suggestions related to differences between versions (the "diff" link). See MeatballWikiSuggestions for other suggestions.

I want to be able to follow conversations.. That means I want to be able to easily see if someone has replied to something I wrote on. If the diff command gave me all the changes since I last contributed (or maybe read the page?) that would help. My only real worry about growing too large is that I won't be able to shut out the background noise of other conversations and follow the ones I'm interested in. I don't have the spare cycles to devote to always remembering what I've been commenting on (sad but true), so technological aids are good. Another possibility would be a RecentChanges that was actually a log of all changes (so the same page could appear multiple times, with edits by different people). [--ErikDeBill]

Ahem. MeatBall:action=rc&all=1&showedit=1.

Is almost it. diff doesn't seem to show me the incremental changes quite right, though. Which also brings to mind the notion of configurable context to be included with changes - so you can see what someone is adding/replying to right there with the diff.

You haven't memorized all of the wiki pages yet? :-)

See also a similar idea on CatchUp.

I feel that the underlying goal of tracking replies really requires ThreadingForWiki.

ScottMoonen created a Python diff script that generates Wikipedia-style diffs (highlighting word differences within paragraphs wherever possible). JürgenHermann incorporated this into MoinMoin [1]

RecentChanges and diff improvements: [moved from WhatIWantForMeatball]

An improved version of RecentChanges showing all edits is on the big TODO list, although it's not as high a priority as it used to be. See RecentChangesSuggestions for the old discussion. The diff-from-last visit idea is interesting, but it is rather difficult to implement well. Updating a last-read time for every reader on every page-read is unlikely to happen soon--I want to keep the normal read-path free of any writes. Other interfaces I've tried (for the old "advanced diff" idea) were too inconvenient for normal use.

Not necessarily a last read time, but a last changed time - let me see all the changes to a page since the last time I changed it myself. For instance, on this page that would have let me see the sum of all changes by you and Sunir by looking at the diff. As it is, I get the changes by you, and not Sunir - so context of things where you reply to Sunir are lost. (Much as I like to blather on, I'd rather not have to go sift through reams of my own verbosity to find where people responded to things ;-) The options for showing all edits in the diff area (discussed below) might make this less important. The only reason I brought this up was as an illustration of how to cope with community growth - my only problem with the idea of MeatBall hitting 100 edits a day being that the current infrastructure would make it nearly impossible for me to keep up with a conversation. [--ErikDeBill]

Showing the differences since your last edit may be possible, presuming the old version has not been expired yet. I was thinking of having the user-ID database store one's recent edits anyway (page name and version numbers), which would make it easy to add this feature. Perhaps I could even have a RecentChanges option or separate area that lists all the pages that have edits after your edits. This probably won't make it into 0.92, unless lots of other features drop off my TODO list or Meatball becomes *far* more active. (Version 0.90 is pretty much frozen (November 8, 2000), and 0.92 is filling up quite quickly.)

Some form of "favorites" or "bookmarked pages" is planned (not immediately, but hopefully before the site becomes too large). One will be able to add pages to a list which could be used:

...I hope this would help one keep up with one's favorite conversations, while not requiring one to sift through the raw output of RecentChanges. --CliffordAdams

Now, if you implemented the "add to list" as more of a "click the checkbox conveniently displayed at top and bottom of page"...

Planned features and recent-diff list idea:

Once KeptPages are implemented I should be able to offer diffs from prior kept versions to the current version. (Most of that code works today, but it needs a user interface.) Perhaps this could be combined with the all-edits version of RecentChanges to allow one to click on the first (oldest) "new" version of a page. This would get the diffs from the prior version to the current one (all the changes starting with the first "new" version).

Another possibility I just thought of would be to (optionally) list the recent edits of a page on the page itself, perhaps in the current "diff" area of the page. (The "recent" time might be a user option defaulting to 3 days or so.) One could choose to fold multiple edits by a single author or hide/show edits, etc. Selecting one of the old versions would show the difference between that version and the current one. The list might look something like (using this page for an example):

November 7, 2000 9:59 am by CliffordAdams [More on RecentChanges and diffs]
November 7, 2000 2:59 am by SunirShah [replies to Erik]
November 7, 2000 2:07 am by ErikDeBill [the title says it all...]

...with the dates as the links? (Perhaps an option for separate dates (like RecentChanges) could be added so that one isn't repeating the whole date on every line.) This is beginning to sound useful. Comments? --CliffordAdams

Best idea yet. Including this on each page would scale much better than everything on RecentChanges (maybe with an interim edit count on RecentChanges?)

Folding all changes by a single author is probably good - no point publicizing how many re-edits it takes some of us to get things the way we want them. Showing me 4-6 lines of context before the beginning of inserted text when showing the diff would also help place things on the page - something like the effects of 'grep -B 6 foo' (I believe diff(1) itself has a -C option which allows for this, but I'm not so familiar with the result). --ErikDeBill

Erik, take a look at what I have in the way of diffs on my own wiki-in-bootstrapping-stage, [2], where arbitrary diffs are provided for the last 14 days of activity. I think providing arbitrary diffs may be a tad too powerful and confusing, but for now it's what I'm sticking to. I might try to trim it down somewhat.

What if you created a separate layer containing the diff, and had one of those little "expand hierarchy" arrows that had some JavaScript to materialize the layer? -- anon.

Unfortunately, I browse with javascript turned off (and CSS off as well, under Linux - some induhviduals insist on setting font face too small to read under X). And no, I'm not turning javascript back on - it's a giant gaping security hole. Any interface that depends on it just won't work for me. Some people really like it, though (and I don't mind the occasional rollover, myself). I just wish they'd taken security into account before they allowed it to grow like a fungus (err... began writing their design documents).

Maybe I'll just make every page a huge .gif file using imagemaps for all kinds of user-interface features. It would probably be more portable than the layers and JavaScript, although a bit slower. Hmmm... Maybe I could dynamically generate VRML... :-) --Cliff

The list of diffs on a page would definitely be optional, much like the current "Show differences on all pages" (which defaults to off, but I usually turn it on). I think it will work even better for larger sites than the "show differences" option, especially for very active pages. One idea (mentioned briefly above) is to show only the *recent* differences--if a page was not edited recently the list would be blank.

Context diffs are possible, but they would definitely have to be optional since I don't like them. :-) One problem is that they don't fit in well with the pre-generated diffs (cached at edit-time). I expect that only a few people would choose non-default diffs, however, so maybe I could just generate the context diffs dynamically. (I'm also considering an option to generate all diffs on demand to save disk space (for those with more CPU available than disk).) --CliffordAdams

Personally I hate the output of the diff command, no matter the format chosen (unified, context, ed...) They all look ugly. grep -B, on the other hand just prepends some lines to the one you were looking for. Unfortunately, I realize this would require you to implement your own diffing routines (or hack one from the perlix distro or something...) It would also make the diff area at the top just that much longer.

Old Discussion: (September 2000 and before)

Diff and edit-copy: (explained)

[Note that much of the text below describes old views--I've changed my mind about a few things. --CliffordAdams]

WardCunningham's versions of the diff and "previous copy" features (Wiki:QuickDiff and Wiki:EditCopy) only make a new backup copy when the page is changed by a different address from the previous copy. This is an imperfect (but still useful) attempt to keep a backup of the previous author's version, and not just the previous version. Should UseModWiki and/or MeatballWiki emulate this behavior? -- AnonymousDonor

It already emulates this behavior. There are two issues here:

Consider the following rule: If 2 edits are (a) consecutive; (b) by the same person; (c) have the same Summary line, they should be considered part of the same edit. This would affect Diff, collapsing lines in RecentChanges, the number-of-edits count, "edit previous copy" and probably other things I don't know about.

Maybe add (d) the edits are less than 6 hours apart, or (e) both or neither are flagged as minor edits. Maybe not - I suspect being allowed to force differences explicitly by changing the summary would be enough.

If the previous edit was by the same person, the Edit page should show the previous summary by default. This is to maximise the number of changes that can be collapsed.

I think this fixes the "Many pages are only updated by one author" problem. -- DaveHarris

I'm still thinking about it, but I'm not enthusiastic. My old "advanced diff" code tried to do a lot of "intelligent" things, but wound up greatly complicating a lot of code. (I finally just abandoned it, and went back to an earlier version.)

Here are some of the specific problems:

I am very unenthusiastic about changing the "diff" handling--it has been too much work for very little benefit. I might implement part of the request (hiding adjacent edits by the same author) as an option for RecentChanges display.

In general, however, I see two situations where the same author would re-edit a page:

...In both cases the "minor edit" feature should work well. --CliffordAdams

[June 19, 2000] I've become more enthusiastic about changing "diff" handling for "minor edits". My current plans are to save the last non-minor edited version as well as the current and author-copy versions, and make the following diffs available:

[August 23, 2000] These forms of differences are currently available. The default difference is the last non-minor edit. Soon the default will be selectable as a UserPreference?.

The reason for this change is that "minor edits" currently have too much impact on the diff feature, which discourages minor edits. (I've been discouraged from minor edits.) I'm not certain what the "last edited" time should show--I'm leaning toward the last edit (either major or minor). (I might be convinced to show only the last major-edit time. This might be another user preference.) --CliffordAdams

Cliff, I agree that diff as is inhibits minor edits. Doing by showing changes to previous author or last non-minor edit would both solve this problem. Usually, when I submit content, I write it up and hit save. Then, I review how it showed up, looking for spelling errors, mistyped CamelCase words, etc, and fix those. I don't like to click minor edit, as I am usually just fixing a non-minor edit I have just submitted. I prefer to use minor edit just for spelling fixes, etc, not the last little corrections to new content being "debugged". If people use the minor edit click box your suggestion would work. If they don't, it would be better to just have diff show changes from last author. -- AnonymousDonor

Stupid question: Is all this conversation above new or did it happen before Cliff added the author diffs?

Let's say I have RecentChanges list all changes since September 10th. When I ask for a diff I want to see changes between the current version and the pre-Sept 10th version.

It sounds like you don't store enough info to generate this - it needs full version control. But I think this, or something like it, is what diff should really be aiming for.

That's a good explanation of what the "Advanced diff" code did. Also, if the older versions weren't available (the old code kept a limited number of copies), the diff code would show the oldest difference and a message that more changes were made. The major problems were:
In the end, it seemed that only the "advanced" users would really use the advanced diff, and most of them wouldn't really need it. The author-based differences make most people happy. The diff functions may be changed/improved when UseModWiki is ported to a relational-DB system (after version 1.0 is released).

Given that you must have multiple versions of a page in order to have multiple differences, the interface is simple. On the VersionHistory listing, put checkboxes beside each version (initially off). Users simply click on the version(s) they want to diff. Presumably only two "should" be turned on, but there's no reason why. If multiple checkboxes are turned on, just list the whole bunch of diffs. For instance:

[Diffs] <-- A FORM button.

In this case, show the diff between Version 7 and Version 4, followed by the diff between Version 4 and Version 3, then Version 3 and Version 1, and finally Version 1 and the current version.

Questions/Issues

Would this make summaries pointless? Usually you can figure out what has changed from the diff.

Summaries are most useful for determining whether a page is worth reading at all. Summaries will be more useful once the new RecentChanges code gets implemented (to show all edits which have a summary). See RecentChangesSuggestions for more details.

Also, summaries are vital to provide temporal information to atemporal changes. Consider if I delete a paragraph of text. I don't want to leave a note why I did that because that would just be noise. Instead, if I use a summary, "Refactored Joe Random User's comment to main document." then presumably I don't have to explain why.

Would a truly effective diff be bad for a Wiki? People would be less likely to read entire pages and so miss out on context (when both reading and writing).

Hopefully people will read pages once, and also reread the entire page before writing anything new. UseModWiki makes it easy to read the full page by displaying it under the differences. If readers don't read full pages, it's their loss. If writers don't read the full context, their redundant edits can be removed (and a rolled-up newspaper applied to the miscreant ;-).

Moreover, often the diffs aren't useful as they are out of context. Even worse, the diff process gets confused. Diffs are much more useful as pointers to the actual document.

I remain quite impressed with how well the "Recent Changes Since" works. This may be because I have my browser do aggressive caching, so it effectively remembers when I was last here. Does anyone else get that?

It's almost certainly your caching. The "changes since" timestamp is set when the RecentChanges page is created. I've considered doing a fancy "visit" kind of scheme, but haven't figured out a decent interface for it.

WhyClublet has implemented a neat difference feature called Why:GoldBar. Presently it only works in IE.

New Discussion (2005)

I'm ruminating on some improvements to the current diff/history system on MeatballWiki. The problems as I see them:

I've therefore rolled a new look to the system that combines diff and history on one page. On browsers that support it, the history log takes up a third of the height of the page, newest changes AboveTheFold, and with a scroll bar to see earlier history. That means half of the page AboveTheFold is filled with difference text, and one can scroll the history off the page to fit more diff in.

The two sections, history and diff, can now be fetched asynchronously, the history automatically incorporating new changes, and the diff changing without a superfluous hit of a Compare button. I'm not going to work on implementing that straight away, mind.

I'll bring the changes to mb2 when the current "public beta" of my Ajax script goes live, I think. In the meantime, though, I'd love ideas and suggestions. -- ChrisPurcell

20 Oct 2005 - A brief status update:
I've added version history to my prototype PeriPeri script, which is making integrating Javascript into the new history page easier. I've written a nice simple script to fetch the diffs asynchronously as one hits different radio buttons (no more Compare button!), and the whole thing already feels more fluid. I'll probably bring that to the main site before adding AsynchronousAutorefresh to the history listing. I hope to have the "history" links on RecentChanges bring up a better diff by default, too. Nothing as complex as remembering what revision one saw last, though, as that takes too much cookie space. More soon, I hope.

26 Oct 2005
Okay, a version of the site with the new history code in place is up at [the MeatballWiki public beta]. There's AJAX in there to remove the Compare button, but new changes are not automatically incorporated into the history listing. Also, the "xx changes" link on RecentChanges still links to the major/author diff (because UseMod is evil), and doesn't display the correct number instead of xx. It's all nicer on PP2, and may improve here as and when we finally roll off UseMod.

As ever, the changes will go live in a couple of weeks, so please PeerReview now. (I know that IE doesn't display it properly, by the way - sorry! Hopefully the new version, with its better conformance to CSS, will fix that sometime soon. Or I might bite the bullet and learn how to use frames.)

One thing I am considering adding soon is displaying a digest diff instead of simply the digest. See also DigestedChanges for an alternative solution of Sunir's. -- ChrisPurcell

27 Oct 2005
Fixed a bug that was defeating the purpose of the second column of radio buttons - the diff was always against the latest version. (The GetDiffHTML? function only uses the $newer parameter to change the line at the top of the diff, not to actually fetch the relevant revision: this must be done by the calling code. But it does fetch the older revision. Ouch.)

Interesting stuff. I like the graceful degradation to no JavaScript. (don't mind me. I'm just playing around.) -- SunirShah

Thanks :) I'm trying to make the Javascript/AJAX add life to the site, rather than making it the be-all-and-end-all. -- ChrisPurcell

11 Nov 2005
Okay, I've moved the changes to the mainstream version of MB. Hope it works for everyone. -- ChrisPurcell

It works in Firefox. It doesn't work at all (no fall-back) in Opera 8.50 or IE 6.0. I think it would be a good idea, to install a small set of browsers and make new features work with all of them before releasing them. Javascript is a PITA with respect to compatibility and I admire you that you attack that task. -- HelmutLeitner

Aah, rats. I'm rolling back to the old version. (See, this is why I put the public beta up, so people could tell me these things before they go on the main site :) -- ChrisPurcell

Okay, I've fixed the problem (it was a name conflict between a div and an input element). Let me know how that works. I can't test it on Windows, so that means I can't test it on IE 6. -- ChrisPurcell

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: