AggregatorPages

MeatballWiki | RecentChanges | Random Page | Indices | Categories

RecentChanges serves as a focus for PeerReview within a community. However, by only aggregating changes on the local wiki, it forces the community to live within the confines of that wiki, or lose out on PeerReview. This prevents projects adopting new online technologies, and limits the capacity to EnlargeSpace.

One option is to merge several external feeds with the site's changes on RecentChanges; however, this limits the opportunity to avoid HijackingRecentChanges with multiple off-site changes. Regular users of the site may become frustrated by such a blunt approach.

Therefore, allow pages to act as aggregators for external feeds. Changes to an aggregated feed are treated as changes to the page itself; that is, they show up as edits to the page on RecentChanges. This minimizes the impact of a sub-project without hiding it completely.

Aggregator pages allow a community to remain cohesive in the face of division of the corpus, allow two synergistic communities to join together, and allow a division in the community to be handled gradually, keeping those who remain behind informed of the progress of the migrators until the split is complete. Overlapping PeerGroups are a good complement for this use of AggregatorPages, allowing fine control over which page changes are aggregated.

Aggregator pages let a community member move their wiki-bound WebLog to a blogging tool, where it is often better served. The ability of modern blogging software to "tag" entries and serve feeds of individually-tagged entries complements this, allowing the author to choose which entries are relevant to the wiki community.

But, aggregator pages can be abused, e.g. if a single user starts creating dozens of aggregators for external sites that interest them. The technology should only be used for community PeerReview. (Obviously, personal wikis can be used however their owner likes, as they are the community.)

Great care needs to be taken over interface design. For instance, what would be the best way to summarize feed changes? Simply to display the first few lines of the summary of the latest change in the feed? To display all recently-changed pages? To concatenate summaries if they're small? To allow a whole-feed summary to be provided? How do we deal with the reflex-click on "History"? Display aggregated changes — or at least a list of aggregated feeds — on the History page? Drop the "History" link?

Finally, aggregation can create a great deal of traffic, especially if rapid reflection of feed changes is desired. Much overhead can be trivially avoided by caching. Even better is if the external site supports a push model such as Rest:HttpEvents. De-synchronization between a feed and an aggregating wiki can be dealt with by marking an aggregator page as changed when the feed update is received, rather than using the last change time of the feed itself. Assuming all wikis that adopt AggregatorPages also adopt a push model, this leaves weblogs as the remaining use-case; stale web-logs are generally acceptable, as long as the changes appear eventually, so polling could be done as infrequently as once a day, to minimise traffic.

CategoryWikiTechnology CategoryUnimplementedWikiTechnology

AggregatorPages

Discussion