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
9 comments ↓
What’s your point? You’re just complaining about “the way things are” without any helpful suggestions for improvement, and furthermore, you’re comparing apples to potatoes, fruit to root:
A keyboard can SEND commands to *any* application it wants to — the applications are expecting messages from the keyboard.
But in that analogy, the notification framework is the application, the keyboards are the other applications — they’re the ones that have to SEND the notifications.”
Both Growl and Snarl provide frameworks and libraries to help application developers take advantage of their notification frameworks — but neither of them can force the app developers to use them (any more than the original Growl can).
What’s your suggestion?
I think you’re missing the point here. My suggestion clearly stated in the post is to guid the developers using the framework to be more integrated. I am not going to suggest anything technical in a blog post like this where I think is not the right forum for it. Not sure which part of the post you got as “complaining” either. I have tried both tools twice in different times and on both occasions found them useless. Here I am suggesting not complaining.
You are not seeing the difference between Mac growl and the Windows ones: in Mac applications themselves are integrated. In Windows third party developers have to do that and that calls for a framework in programming sense if you know what I mean. And frameworks can enforce their views of best practices. Look at MS Enterprise library, most of Ayende Rhino stuff and so on. There are plenty real frameworks out there for you not to call these two a framework.
I’m confused…
Growl for Mac has the exact same issue as Snarl/GfW, the only thing it has in it’s favor is time.. it’s been out long enough for developers to get use to having it as “standard”.
Growl for Windows and Snarl aren’t even the issue, third party devs don’t have to worry about it, all the NEED to support is the Growl PROTOCOL…
So the major issue seems to be that app developers aren’t currently integrating Growl/Snarl support in their apps.. the only thing to change that is to ask for it.
No, see … this is what I keep saying, you have it backwards.
On Mac, the APPLICATIONS HAVE IMPLEMENTED GROWL. Growl didn’t integrate the applications.
The Growl team has, in a few cases, included apps like GrowlMail or GrowlSafari, and even HardwareGrowler … but those are very much external apps like the ones that Growl for Windows and Snarl use
The difference is that on OS X they didn’t have a “notification tray” like Windows did at first, and Growl was a good solution, and eventually became so common that many Mac developers have chosen to implement support for it.
The situation on Mac for third-party apps is exactly the same as on Windows: when a developer writes an app without Growl support, users have to complain and ask for it — the difference is, on Mac, Growl has been around for over 5 years, and has a much higher percentage of users.
@Joel, not sure why you keep suggesting I’ve said anything about GfW or Snarl integrating the applications? Can you quote it from my post please?
@Michael: Although Growl in Mac has the advantage of time the environment it has grown in makes a difference. As @Joel mentions, Macs didn’t have a notification tray and that made an opening for a tool like Growl. This meant developers adopted it more widely since doing it themselves was much more expensive. In Windows everyone who puts a couple of scripts together can put something in the Tray icons. This is exactly why that GfW or Snarl should be more than just clones of the Mac version by providing other incentives to developers to use them.
[...] ← Windows notifiation framework [...]
I’m confused, I just don’t get what your point is. I think that is because of sentences like this:
“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.”
Jaykul, Sven and Brian are all correct. You’re getting things confused. For Snarl (and GfW) there are THREE ways an application can create notifications/interact/call-it-what-you-will:
1) PREFERRED: implement the Snarl/GfW API directly in its code. This is so incredibly easy it can be done instantly and with zero bloating. No nasty linker libraries, COM objects; just simple in-line code.
2) NEXT PREFERRED: create a plugin which interfaces between the application and Snarl/GfW. WinAmp springs immediately to mind here. NullSoft don’t want to keep updating their core app code so they’re kind enough to create an API for 3rd party devs to use. So why not use it?
3) FINALLY: if all else fails, create a proxy application. This would be a separate application (i.e. process) which would run and do whatever necessary (screen sniffer, message queue sniffing, etc.) to capture the events it wants and then forward them to Snarl or GfW.
Also, Snarl offers an alternative to (3) whereby the proxy application can be coded as a plugin to Snarl itself. This has the benefit of not chewing up resources as a separate process but instead runs in Snarl’s own process space.
The BIG ISSUE here is that developers of applications need to get their head around the idea that Windows now has notification engines available for it. There’s no animosity between the Snarl and GfW teams so your app either supports Snarl or GfW or -ideally for the end user- both.
I agree that there needs to be a common notification API/framework/whatever and I’m sure we’d all be happy to (a) contribute and (b) subscribe to it.
In short, the only thing Growl has over it’s Windows opposites is a head start.