Schedule

This article now represents the general concept of how we want to integrate the time/schedule/inbox/changes concept into our wiki-based organisational system.

Ideal Feature

Dynamic

Like the old changes in the logo (logo.as), but a new one would work based on livelets using AJAX/SWF for push-based updates.

Multiple Sources

Allow the changes to be a more generic list of events in which the local wiki's changes are just one source. Other good sources would be file-system events, logs, remote wiki's, web-scrapers and pop-boxes. Of course this also implies that the changes lists are specific to users.

Filtering & Sorting

The list needs to be more flexible like a file system folder in a file browser.

Selections

It seems logical to combine the filtering and sorting with the existing selections extension.

Reports

A report is effectively just a fancy template-based way of rendering a selection. Reports could be as simple as a calendar-based view of the selected events, or could involve processing such as in the case of a report for filling in a tax return.

Sound on change

Can we have a customisable sound to be triggered by a change? Could work really well in conjunction with filtering. Good for when doing a job, for instance Borgification and being in dynamic communication using the wiki.

Yip I'll do this one sometime soon - I was actually going to do that, but got side-tracked into the merged changes instead.

RSS

Currently we're using the generic URL-matching rules to extract RSS changes title's. This is not ideal though because the generic URL-matching is based on detecting the differences between items, so if a comment is added which has the same title as a previous one it won't show up. Also it would be good to extract the author and timestamp etc, so a specific RSS reader should be added some time which would be quite easy to implement.

At this website we see an RSS-reader dashboard widget described that just allows you to pull the changes off a Basecamp. There might be some ideas for ultra-changes layout (tabbed changes?) here. On the other hand, maybe it would be possible to borgify Basecamp-changes into the ultra-changes using a similar technique to what the coder of the widget uses. Basecamp is very email-push oriented, it would be nice to free up the inbox and also to be able to follow the changes on a Basecamp without having to deal with its confusing layout. Maybe this is impractical but it can't hurt to ask.

Here's one: http://ccguest:ccguest@cocreators.grouphub.com/feed/recent_items_rss

And here's the login to the Co-creators Basecamp, maybe that's helpful:

With the Co-creators guest login you will be able to access all Projects on the Cocreators Basecamp. Have a look around to see what is going on at http://ccguest:ccguest@cocreators.grouphub.com/clients

See also

• Interface
• Extension:TransformChanges.php - Currently running extension to restructure existing MediaWiki changes
• changes.as - legacy incomplete SWF changes project based on logo.as
• transform-changes.php - old XmlWiki component

Changes added in OD's TransformChanges.php

<php>

1. We're using these cols and ordering

$cols = array('time','diff','title','comment','user','info');

1. this is added before the final row-assembling line of wfTransformChangesLI()

$talk = preg_replace('| \\|.+</a>|',,$talk); $diff = preg_replace('|curid=[0-9]+&(amp;)?action=history|','action=edit',$diff); $diff = preg_replace('|>hist<|','>edit<',$diff); $user .= " $talk"; </php>