My thoughts on Growl
Posted: Sat Feb 17, 2007 10:46 pm
Hello!
I have finally decided to write up my thoughts on Growl, and the forums seem to be the perfect place for them. It may be that everything I express in this post has already been spoken about elsewhere, and some of my issues may have already been dealt with in development versions, but below are my thoughts on Growl.
My major issue with Growl is the display of notifications. In my opinion, the whole preferences pane for both "Applications" and "Display Options" needs to be rethought. The central problem, in my view, is the Priority model. Notifications should not be set up based on a priority model, because priority is something that is rarely pre-determined, but instead is best left for the human brain to decide when it sees the notification. Right now when we look at the Display Options pane, there is a list of notifications, and a limited number of preferences which allow the user to adjust opacity, duration, and colour for different priorities. I see this as a flawed system. Suppose I want to have Adium notify me when my contacts sign on or off. Right now, I can select a notification for all of Adium's notifications, such as bubbles, and then I can individually enable or disable notifications, as well as changing their Display type and priority.
A better design would be to have "Display Presets" which would be customized under a new preset pane, which would replace the "Display Options" pane. A source list would still exist on the left side, but would be replaced with a "Default" entry, and +- buttons on the bottom (see Mail.app's Account prefs) To the tight would be configuration options. Under this new system, I could add a new preset, for example, "Contact Signs On," and customize the colour, duration, and other settings for this preset. Perhaps I want it to be green and last for 3 seconds. Then I could add a new preset called "Contact Signs Off," which may only be 2 seconds long, but would probably be red to indicate a negative function. The key is that notifications be sorted by type and not priority or display. The computer determines type, and the human determines priority, rather than the other way around.
The applications pane could exist, or it could be removed. If it were to remain, a list of applications plus their notifications would be visible, along with the presets created as per the previous paragraph. The user would select the appropriate preset for the notification, and drag it over or select it. If this is too redundant, the Applications pane could be merged with the presets pane. The preset source list would contain drill-down style applications, and then any notification could be selected and configured, including the top level application (replacing the app's default display). Finally, the application implementation could be moved to where I think it belongs – in the own application's preferences. Adium already has a whole section for events, so incorporating an API wouldn't be a big change for what seems to be Growl's most prolific notifier. Then, under the application's preferences, notifications can be enabled or disabled, as well as either having the option to select a preset or customize a preset specifically for that application's notification.
I know development takes time and is difficult for a small team like Growl's, so I hope I haven't been rude or too pushy. I really do love Growl, but I think it would be a lot better if these changes were implemented.
I have finally decided to write up my thoughts on Growl, and the forums seem to be the perfect place for them. It may be that everything I express in this post has already been spoken about elsewhere, and some of my issues may have already been dealt with in development versions, but below are my thoughts on Growl.
My major issue with Growl is the display of notifications. In my opinion, the whole preferences pane for both "Applications" and "Display Options" needs to be rethought. The central problem, in my view, is the Priority model. Notifications should not be set up based on a priority model, because priority is something that is rarely pre-determined, but instead is best left for the human brain to decide when it sees the notification. Right now when we look at the Display Options pane, there is a list of notifications, and a limited number of preferences which allow the user to adjust opacity, duration, and colour for different priorities. I see this as a flawed system. Suppose I want to have Adium notify me when my contacts sign on or off. Right now, I can select a notification for all of Adium's notifications, such as bubbles, and then I can individually enable or disable notifications, as well as changing their Display type and priority.
A better design would be to have "Display Presets" which would be customized under a new preset pane, which would replace the "Display Options" pane. A source list would still exist on the left side, but would be replaced with a "Default" entry, and +- buttons on the bottom (see Mail.app's Account prefs) To the tight would be configuration options. Under this new system, I could add a new preset, for example, "Contact Signs On," and customize the colour, duration, and other settings for this preset. Perhaps I want it to be green and last for 3 seconds. Then I could add a new preset called "Contact Signs Off," which may only be 2 seconds long, but would probably be red to indicate a negative function. The key is that notifications be sorted by type and not priority or display. The computer determines type, and the human determines priority, rather than the other way around.
The applications pane could exist, or it could be removed. If it were to remain, a list of applications plus their notifications would be visible, along with the presets created as per the previous paragraph. The user would select the appropriate preset for the notification, and drag it over or select it. If this is too redundant, the Applications pane could be merged with the presets pane. The preset source list would contain drill-down style applications, and then any notification could be selected and configured, including the top level application (replacing the app's default display). Finally, the application implementation could be moved to where I think it belongs – in the own application's preferences. Adium already has a whole section for events, so incorporating an API wouldn't be a big change for what seems to be Growl's most prolific notifier. Then, under the application's preferences, notifications can be enabled or disabled, as well as either having the option to select a preset or customize a preset specifically for that application's notification.
I know development takes time and is difficult for a small team like Growl's, so I hope I haven't been rude or too pushy. I really do love Growl, but I think it would be a lot better if these changes were implemented.