Windows Notification Platform

Comments on the previous posts (here and here) about Growl for Windows and Snarl has made me realise that the problem is not about the frameworks, it is about platforms. Let’s get one thing straight: Windows doesn’t have a notification framework, it only has components of it, mainly a place for Tray Icons and that is hardly enough.

A framework for notification should allow developers to delegate their notification tasks to it and forget about them. Users can choose the minimum level they want to get notified about, how they would like these to be displayed/sent, when are the “quite” hours and so on. These are problems that keep popping up in most UI notification scenarios and without a framework in place, developers have to address them separately every time themselves. This means these are addressed inconsistently since each programmer sees the problem in light of different use cases.

Growl started its life for Mac as a solution for the lack of a “system tray”. It was widely adopted by developers since the alternative was to write the system tray themselves. This subtle point makes all the difference between the original Growl and Growl for Windows. Growl for Windows tries to be a clone of Growl and thinks the problem of market penetration is down to the fact the the original Grown has enjoyed a longer life. Give it enough time and it will become popular they claim.

I don’t think that way. The relative low cost of using System Tray in Windows means many developers are not going to bother using GfW as their notification tool. Add this to the relative cost of learning how to integrate GfW/Snarl into your app and it becomes less attractive.

The reason Growl for Mac was successful was that developers had incentive to use it. GfW/Snarl as they stand, offer very little incentive and I believe the current adoption rate of these tools is a result of that. This means GfW and Snarl should rethink their offerings. They should change them from mere tools to “platforms”. This means a better and tighter end-to-end experience for users and developers.

Currently not many Windows apps use GfW or Snarl natively. This means there are going to be loads of “bridges”. These bridges define the user experience for both tools and at the moment neither of the tools offer much to control these bridges.

GfW and Snarl should offer centralized configuration for plug-ins. Make installation and upgrade of plug-ins dead easy and integrated. Have a central “app store” like plug-in directory and control who is putting the plug ins on it. If a plug in installs its DLLs directly into Snarl extensions folder and therefore breaks the uninstall process of the tool as well as causing other issues for the user, it should be stopped. Now it is not a question of Apple App Store like policing. It can be done easier by forcing the use of a controlled set of APIs that offers the above features as well as blocking “DLL droppers” to work. If a dropped DLL cannot work, no developer will bother doing it and they will go through the proper way which is actually easier for them as well since they don’t need to worry about installation and in most cases even any UI exposure.

A range of high quality bridges will help the adoption rate which in turn give developers more incentives to leverage the large user base GfW and Snarl will enjoy. The rest will be a self fulfilling prophecy!