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
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 "
". 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 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.