Entries from December 2009 ↓

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!

I’m glad that my previous post has attracted comments from the developers of both Snarl and Growl systems as well as others. I wasn’t expecting much agreement by posting such writing in Growl and Snarl users’ forum. They are all bought into the idea of those systems after all.

When I think of Growl and Snarl, I think of a consumer tool. To me they are not programming frameworks like Spring or Hibernate, neither they are tools for computer savvy people like Process Explorer. I see them and I think of my Logitech diNovo keyboard.

My old Microsoft media keyboard had some “media” keys: Play, Stop, Forward and so on. But it was pain to use: They only worked with Windows Media Player until iTunes 6. After iTunes 6 came out I think Microsoft realised there are more media players in the market than WMP. So a driver update later and I starting playing nice with iTunes. But still no WinAmp or others. While ago for reasons not related to the media keys I decided to buy a diNovo keyboard. And it was then when I realised I actually enjoy using the media keys that I had always thought were for non-IT users. Not only did they play nicely with WMP, iTunes and WinAmp, but they work with Spotify too! And for those who don’t know, Spotify is newer than diNovo by far.

Now try doing that with Gmail and Snarl or Thunderbird and GFW. I am not saying it is not possible, but the experience is by far different. Don’t get me wrong, I’m not suggesting GFW and Snarl teams should carry the burden of integration themselves. It is not about doing the work yourself, it is about making it more difficult for developers to do the wrong thing which in turn would make it easier for end users. As it is, the developers have to do the installation and configuration themselves. This makes the final product, non-integrated and inconsistent.

This for me is a good end-user experience. What was the GFW or Snarl equivalent? Well you got your diNovo and you have Spotify. Now you can go and search for a piece of software that connects them, install it spearately, configure it separately, upgrade it separately and so on. And probably every time you upgrade your diNovo driver or Spotify, you’d have to worry if they still are friends.

To me, good software is not equal to good code or even nice UI. For me consumer software is a full experience and I think GFW and Snarl can improve hugely by introducing frameworks and support tools (very similar to the ones used successfully by Firefox) for their developers. At the moment the burden is on the developers although in a consumer market the blame is mostly put on “Growl” or “Snarl” not the particular plugin. If you disagree I suggest you work in an IT support department of a non-software house to appreciate the value of this experience.

I am writing this as a contributing to both tools. Not all contributions have to be in code I’d like to think.

Good luck

Mac users have enjoyed an almost universal support for Growl for years. Almost all good Mac applications support Growl and just use it if it is installed. This makes the whole experience with notifications very pleasant. Windows on the other hand has never had a single an unified experience for user notification. Growl for Windows (and Snarl) is trying to be that. There are some problems with that however:

• Both Growl and Snarl have been in development/beta for a long time. Growl and Snarl are consumer software and need to be easy to find and install. You don’t really expect everyone to find the best version of a software on SoureForge and install it?
• There is no single application directory for their plug-ins. No reviews, ranking, bug reports. Nothing. Try finding a Google Wave notifier for Snarl now.
• The biggest problem with both Growl for Windows and Snarl is that their plugins are stand-alone applications. That is just stupid. I can write an application and use Growl for my notifications if it is installed. But why should I install a separate application if I just want to have Gmail notifications? This means a separate install, separate tray icon, separate “Start with Windows” settings and no unified configuration experience. What’s wrong with Firefox plug-in system. Snarl and Growl plugins don’t have to talk to the host application like an external tool. The external API is for external applications.

Should I start a new open source Growl for Windows replacement?!