Attention Central - A concept for user driven notifications

The probably most popular category of application build with Lotus Notes and Domino are workflow applications. Those applications need to notify respective users about changes in status and need for user action. In other words they are attentions seekers. Early or simple workflow applications simply used code like @MailSend( DocApprover ; DocRequester ; CentralArchive ; "Request for approval: "+subject ; "Please approve leave as specified in the request from "+docRequester ; Description ; [IncludeDocLink]). eMail wasn't such an annoyance and the world was good. Later more sophisticated approaches using NotesDocument.send were added, but basically the principle stayed the same.
With the raise of alternative notification mechanism more options were added. Today we eventually find notifications using RSS/ATOM, eMail, SMS, Text-To-Voice calls, automatic todos, Tweets or Instant Messaging (I haven't seen a workflow application writing on your Facebook wall so far). All these attention grabbers have in common, that they are part of the application and what I would call "publisher driven". I would like to make the case for a change and suggest an intermediary that takes in all the notifications of all the enterprise applications and lets users decide how and when (and when not to be notified). Since notifications are designed to attract your attention I call this intermediary " Attention central". You could see attention central as precursor or filter for the "river of news" envisioned by IBM's project Vulcan. The interesting difference: it is possible with the Notes and Domino infrastructure you have today.
What properties would such an application have? Here you go:

• Universal Interfaces: Applications can deposit notifications using REST, eMail, SOAP, Sametime or MQ. Libraries for LotusScript, JavaScript, Java and other languages make deposition simple (actually with a REST API any active language can do that)
• Universal delivery: Notifications can be delivered to users via eMail, Sametime (both pull and push), SMS, as RSS/Atom feed, using MQ or being polled through a web service
• Application Profiles: Applications that are allowed to use the service have a profile where the default mechanism for notifications is defined. The profile can specify what channels users can choose from.
• Prioritization: It can be specified in what sequence notifications are delivered. E.g. "use Sametime if user is online, otherwise use email" or "Use Sametime, wait until user is online" or "Use eMail unless OOO is active, then send one summary when back"
• Conditions: Use RSS for normal priority, use Sametime for "urgent"
• User profiles: Not every user would bother, so the user profiles are optional. In a user profile the defaults for the given user can be specified and how they are mapped to application defaults. e.g. "If app default is eMail, send me one summary per day, but notifiy per Sametime if urgent"
• Delegation: Users can specify on an application per application base or as a default if notifications should be delegated. A delegation can be temporary (from/to), or conditional (if OOO is active or this webservice returns true) or permanent (my PA handles all leave requests for my team)
• Transparent: Regardless of notification channel a summary of notifications would be available via ATOM/RSS and on the main site
• Transient: Notifications that have served their purpose would be removed from plain view (that might need some adjustments in the participating applications)
• Integrated: The UI (profiles and notifications) are available a component for composite applications or iWidget integration. Workflow applications can make the notification settings part of their own UI without actually storing them other than in Attention Central
• Distinct: Applications that call the API can specify what quality the notification has: progress report, completion, action request etc. This information can be used to define notification channels

Once you get the general idea the list of ideas will grow. Definitely it will allow to manage the stream of attention and action demands more effectively. To be clear: The application would handle notifications only. It wouldn't grant access or perform workflow steps or anything else since this would require too deep changes in your existing workflow architectures. Also the hallmark of flexible application architectures is: one module, one task. Of course you might end up with your deputy getting notifications of events where the originating system doesn't allow access. But that is already the case today if you just give your deputy access to your inbox, so Attention Central doesn't degrade from what you have now.How could the Setup UI for such an application look like? We definitely need application profiles and user profiles. Having spent too much time in the air, here are my ideas:
The application profile defines how an application notifies Attention Central and how that is translated into user notifications. For most users this will be the setting effective for them (unless they create their own user profile)

The user profile screen allows users to map incoming notification types to their personal preferences. Might be overkill or not enough. Alternatively instead of mapping the notification channel a mapping of message type to channel would probably make sense

An important aspect of notifications is the ability to bring information to the attention of others.

This are first drafts and probably will change radically when subjected to usability tests, but you get the idea.
Bonus tip:
Once you build this application how can all the existing email centric applications take advantage of it without the need of being rewritten? Well - we can take a page from the spam defense: Notification messages are well defined in text, sender, subject and structure. It should be fairly easy for a server side spam filter to sort them out and drop them into a shared database where an agent extracts the relevant information to create an entry in "Attention Central".