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]
See also a similar idea on CatchUp.
I feel that the underlying goal of tracking replies really requires ThreadingForWiki.
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.
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:
Now, if you implemented the "add to list" as more of a "click the checkbox conveniently displayed at top and bottom of page"...
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):
...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
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
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.
Diff and edit-copy: (explained)
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:
[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:
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?
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.
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:
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.
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.
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
$newerparameter 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.)
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