[Home]RecentChangesSuggestions

MeatballWiki | RecentChanges | Random Page | Indices | Categories
This page contains suggestions for features or changes to the RecentChanges display. See MeatballWikiSuggestions for more general suggestions.

I added bookmarking to MoinMoin:RecentChanges, so the system can hilight the pages that changed since you last looked (or actually, clicked on "update my bookmark"). The next step will be to change the "diff" links so that you do not get the last edit diff, but the diff between the version that was valid when you set your bookmark and the current version. Any further ideas to improve this? -- JürgenHermann

That's cool. Note that what you are suggesting requires VersionHistory, not just the EditCopy. FullVersionHistory? breaks the WikiNow. However, there is KeptPages, which I recommend over a full history. If the visitor hasn't viewed the diff in one expiry period, perhaps that's ok. That user isn't necessarily important anyway. As you should choose your expiry period to be sufficiently large that enough of the community can review the change, that user is probably not part of the community, implying that his or her case will be rare (or not worth the effort). Indeed, this kind of "long diff" seems very much in step with KeptPages. (Oh, how I love thee..) -- SunirShah

Even with expiry of old versions which will eventually creep into MoinMoin, as you already noted, it works for frequent visitors, which is enough for me (literally, it's a feature I've done for me me me ;). Others will get the "oldest stored version to current" diff, when no version older than their bookmark is available. -- JürgenHermann

I'm almost convinced to add it to UseModWiki--maybe a 0.91 or 0.92 feature. In some ways bookmarks seem similar to the "show changes since" link, but you get to save the time for your next session. I have some raw notes at MbTest:WikiIdeas for future reference.

One scenario I was concerned about is people who read a list of changes, but forget to update the bookmark. The next session they have a choice between reviewing redundant diffs or skipping the new updates. (I was thinking of an "adjust bookmark" link/menu that could adjust the time if someone cares enough to do so.)

Still, this seems like a worthwhile feature, at least for the really serious wiki-mongers among us. --CliffordAdams

Since UseModWiki stores user information server-side, perhaps you could automatically add entries to the user profile to indicate what was the latest version of each page visited.

The "diff to version older than my bookmark" feature is now in, and I really like it. What I hate lately in the C2 wiki is that if one single author edits a page over a period of time, you cannot see what he changed in the last 3 days on a page he kept editing for 2 weeks. -- JürgenHermann

I saw this page for the first time now. I don't know how much the "bookmark" feature is implemented in UseModWiki. However, I had added it to UseModWiki in my homepage. It acts similarly to that of MoinMoin. You can see it in [here]. (You have to register and login to use bookmark, because the bookmark timestamp is saved in each user's db in server) I wish it be helpful - UseMod:GyPark

RecentChanges and summary improvements: (pending)

Are the summaries useful? What should we be putting in them? Why would a minor edit need a summary?

Generally if there is a major edit to a page with an interesting title, I will read the page. The summary isn't helping me decide whether to read. If I want to know what has changed, a diff is more reliable. -- DaveHarris

Summaries are not very useful given the current level of traffic. I suggest using them to either draw attention to substantial edits, or to notify a user of less-interesting changes (like rearranging text without significant additions). I suggest summarizing the changes rather than the entire page.

Summaries may be useful with minor edits to indicate the kind of change, so a later reviewer can easily skip uninteresting edits. (For instance, if a range of edits are all summarized as "Category XP", I might sample a few at random, but I wouldn't check all the changes.)

Some people will not use the "diff" feature. Summaries may be especially useful when making non-obvious edits in the middle of pages. Finally, I'm not completely happy with "Summary"--maybe it should be changed to something like "Change Notes"? --CliffordAdams

They're more useful if this Wiki had full history because then they'd function as check in comments for a versioning system. As it stands, they are only for RecentChanges. Kind of extra advertising, especially useful for pages with boring names. For instance, the summary I made for this edit was "Baywatch." -- SunirShah

If I habitually skipped all changes with the summary "Baywatch", I would have missed Clifford's comment. I am comming to the conclusion that adding a change to RecentChanges should not cause the previous change to be removed. -- DaveHarris

I think it would help for a couple of reasons. First, it would make clear what the hot pages are for the day, as there would be many entries for that page. Second, and more importantly, it wouldn't inhibit minor edits. As it is now, I hesitate to make minor edits to things on RecentChanges, as it removes the information provided by QuickDiff?.

The (n changes) entry on RecentChanges does this for you. It tells you how many times the page has changed in the RecentChanges timespan (1, 3, 7, 30 or 90 day(s)). The higher the number, the hotter the page... -- SunirShah

Given the multiple requests to display all changes, I will add this as a feature. (You can already display all changes using the RecentChangesOptions, but it is not very usable.) I'm currently considering something like:

June 8, 2000

June 7, 2000

...and I may make it the default for RecentChanges. This would make the summary lines more useful, and allow people to easily see which pages are popular. User preferences will eventually allow much more customization, but this may help in the meantime. --CliffordAdams

I like it. I think that listing the multiple entries under the same page name is even better than just leaving the page name where it was and adding a the name again at the bottom. Your example conveys much more information at a glance than the RecentChanges on WardsWiki.

I like this too (provided it was collapsable to (n changes)for those hardcore junkies like me). UserName is evil. -- SunirShah

I am not sure grouping the changes by page is good. It is more verbose, in that it adds a line to the display. It loses information about the order in which the edits happen. It just seems more complex. I'm not sure it is solving a real problem. Have you tried the simpler list? -- DaveHarris

Can we try it as an experiment? If it turns out to not help, then lets get rid of it. I thought of the problem of being verbose as well, but even at my usual connect speed of 26400 at home, the long RecentChanges on WardsWiki comes down in just a couple of seconds. Keeping history may add a small amount to that. (I do not know how many pages have multiple edits, but I suspect it is less than half, and just a few have more than a couple of edits on a given day.)

By verbose I meant that specific format, which added a line per page. I am not bothered about the verbosity of showing all the changes. Although perhaps consecutive changes by the same person should be collapsed. See below. -- DaveHarris

Actually, the format above doesn't add any extra lines. The first line of a group (which has the WikiName link) is the most recent change, while the indented lines are previous changes. I plan on keeping the existing RecentChangesOptions, and "soon" (version 0.9) allowing users to easily customize the display.

The main question is what should be the default RecentChanges view. I am leaning toward the grouped view with all non-minor changes. --CliffordAdams
Show views: (rejected)

A ChangesViewsQuotient? on RecentChanges instead of only changes would enhance the use value. E.g. "4/20" meaning: "4 changes, 20 views" -- fp

I don't think the number of views is important enough to be listed on RecentChanges. --CliffordAdams

See HitCounts.

Change the default Summary value on the edit page to be the last summary. This will a) stop annoying me when I back up to correct a typo or add more information, b) encourage the use of summaries. If this ends up being annoying, perhaps only do this if the author is the same as last time. -- SunirShah

Here's the steps to reproduce the problem.

  1. Edit SandBox
  2. Type "Major edit" in the main text field
  3. Type "Major edit summary" in the summary field.
  4. Ensure that the minor edit box is not checked.
  5. Save.
  6. Check MeatBall:action=rc&showedit=1

All is good. Continue:

  1. Edit SandBox (make sure you fetch a new edit page, not just load the one in your cache)
  2. Type "Minor edit" in the main text field
  3. Leave "*" in the summary field.
  4. Ensure that the minor edit box is checked.
  5. Save.
  6. Check MeatBall:action=rc&showedit=1

All is not good. The summary was blasted during the minor edit. -- SunirShah

As I understand it, the real problem is that useful summaries are not displayed after later edits. I'm planning to soon change the default RecentChanges to show all (non-minor) edits that have a summary. Advanced users will be able to change the display, but new users won't miss summaries. For instance, the display might look like:

If this was the default view, would it be good enough?

...In any case, the summary isn't quite "blasted". Currently RecentChanges shows the most recent eligible change. Normally "minor edits" aren't eligible for display (they are removed from the list at an early stage), but "showedit=1" means that the minor edits are not removed. Try MeatBall:action=rc&showedit=1&all=1 to see the earlier summary.

The "showedit" option isn't intended for most users to play with. The only good reason to turn it on is to check for bad or malicious "minor edits". (Good people will mark edits as minor because the edits shouldn't attract attention. A few people will check for abuses, so most people can safely ignore minor edits.) For those watching for abuse, I may add an option to show only minor edits newer than any major edit of the same page (which would detect otherwise "hidden" edits). --CliffordAdams

why is it that sometimes pages appear on RecentChanges without an (n changes) link? for instance, right now RatingAsContent and WikiVoting are both on RecentChanges, yet with no (n changes) next to them. However, the changes can still be accessed by action=history (via the "View other revisions" link on the pages themselves). (perhaps this happens when there is only 1 change? in this case this is a suggestion rather than a bug. the suggestion, namely: add a similar feature for single changes)-- BayleShanks

If you look at all changes MeatBall:action=rc&all=1 you will see n entries on RecentChanges for your particular configuration. Try changing it from 1 day to 3 days to see how n increases or decreases. -- SunirShah

thanks. so now my suggestion is have an option that puts "(n changes)" next to every item, so that there is an easy way to go right to the action=history version of each page. -- BayleShanks

I am considering whether to replace the (diff) link with a link to history a la Tavi, as the new Tavi-style history includes the diff already, so it's almost redundant to have both. I haven't asked people about the idea yet because I want to improve the history interface still. Conceivably, I can unify the two functions. This will improve the FeatureKarma of the software in my opinion. -- SunirShah

I'd still want to see the full page displayed below the diffs - it lets me see the full context. Idea: change the "Added: 61a62,65" diff headings into links to corresponding page anchors within the full text. That would be useful! -- EricScheid

In retrospect, that's so painfully obvious it hurts. Excellent idea, Eric! We should definitely implement this. I want to add Alex's UseMod:WikiPatches/AccessibleDiffs before I leave for Europe as well, so maybe we can combine the two. -- SunirShah

One more minor enhancement -- if multiple diffs are being listed on RecentChanges, make the (diff) link do a comparison specific to which diff it was ... ie. use the links which are accessible in View Other Revisions. This makes it quick and easy to see who made what change. -- EricScheid

Community-filtered hotspots with a couple of lines of summary

Over on the IaWiki: I'm noticing that people are visiting the wiki but not joining the discussions. This could be due to that audience being used to the blog-model, where the users encounter a more indepth (and provocative) posting with a lead off to a comments area, as compared to just a title and optionally a half dozen word summary in the recent changes log. Thus, in the wiki, the new content doesn't get the opportunity to engage the visitor unless they first click thru to the individual page ... which has considerable costs involved (eg. response time, scrolling, locating the addition).

I'm considering setting up a blog alongside the wiki, integrating the two. I imagine it being implemented as a 5 line text box on the edit page, so people could just cut & paste the more provocative edits. This textbox would then get pre-pended onto the blog page along with the the users name and an automatic link to the page just edited. The blog page itself wouldn't be editable so as to avoid splitting the discussion.

-- EricScheid

Alternatively, you could just create a discussion page that is maintained manually like ZWiki. (I think it's a pretty wiki solution.) -- SunirShah

PikiePikie sends the whole wiki page (or up to some large limit) in the description field of its RssFeeds?. With PikiePikie's templates and AbbeNormal:JavaScriptRssViewer i could probably do what Eric's talking about right now. --JohnAbbe

See also WikiLog.

Why should RecentChanges simply show past changes?

Why does the latest version of a page always have to be the current version? Since WikiSpam is becoming more common, why should the last user to change a page choose what is the current version of the page. Why not let the reader choose if a recent change is acceptable. When a page is changed, how about adding a link at the top of the page to advise the reader that the page has been changed recently, and needs a PeerReview. When enough suitable readers have read the page and found it acceptable, only then does the change become the current version.

Any user should be able to flag a change as unacceptable (eg Spam, irrelevant content etc.) Changes rated as unacceptable would remain as proposed or pending changes until the page is edited again, then drop to being an old revision or could even be purged depending on an unacceptability rating system. Currently this is done by reverting a page - a complex process.

Changes rated as acceptable by a suitable number of different readers/reviewers get accepted. I am thinking of a jury of (say) the first 12 different (identifiable) users who review the changes and find them acceptable. Reviewers could even be weighted (or rated) depending on their reliability. The vote of a reviewer who's opinion always agrees with the majority of a reviewing jury could rate higher than an anonymous or untested reviewer while reviewers who go against the majority consistently, or try to review their own work are given little or no weight, apart from reverting the page to undo a change they have proposed.

The wiki itself could learn what is unacceptable. Users who repeatedly submit the same unacceptable changes could find all their submissions ranked as unacceptable (or suspect) by the wiki itself. Users who consistently submit acceptable changes could acquire a level of trusted status.

Some changes, such as an addition with no deletions could require far less [[PeerReview]]s than the replacement of a page of text. Similarly, small changes, say a few characters, a word or a line could be considered acceptable minor edits. Also pending changes could be ranked on a percentage basis of the amount of change made to the page, with recent changes only showing pages changed above a certain percentage.

The RecentChanges log could show any proposed or pending changes in a separate pending changes section or flag them as pending review.

This scheme probably sounds a lot more complex than it need be. The simplest solution would be to provide a mechanism to easily revert the page(s) and not have the latest spam survive in the page history.

CategoryWikiTechnology CategoryRecentChanges CategoryMeatballWikiSuggestion

Discussion

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