Growl 2.0 requirements reduction

[Christopher Forsythe]

Folks,

I've been looking at the requirements, and then the timeline I'd like
to see 2.0 come out in (end of april), and the amount of manpower we
have, and I don't think the three work well together. Here is the list
of requirements right now for 2.0. I would like to have them all, but
I don't think that's a realistic approach:

http://code.google.com/p/growl/wiki/Growl2Requirements

Any thoughts on which items are just too far reaching at first glance?
Myself, I think the prefpane redo needs to be pushed off, along with
the framework changes. Does anyone have any objections to these moving
to another version? Does anyone have any suggestions for what else to
remove from this list?

Chris

[Rachel Blackman]

On Thursday, December 2, 2010 11:43:10 PM UTC-8, Chris Forsythe wrote:

Any thoughts on which items are just too far reaching at first glance?
Myself, I think the prefpane redo needs to be pushed off, along with
the framework changes. Does anyone have any objections to these moving
to another version? Does anyone have any suggestions for what else to
remove from this list?

As a third party developer /using/ Growl, I think the installer is really the key portion to be redesigned.  (I cannot stress that enough in plaintext; I'd need variable font weights and an underline format option.)  So I'd at least vote for NOT removing the installer revamp -- even if it's just a little tweak -- from the list.

Based on watching my own users, I can say that the majority of them don't bother to configure Growl away from the defaults.  Some don't even understand what the Growl installer prompt is!  They decline it, and then complain that there are no notifications -- they're used to built-in systray toast notifications from our Windows version. When they find out they need to install Growl for notifications, they complain that the dialog didn't make that clear enough when the Growl install option popped up.  (I'm guessing similar feedback was part of the logic behind Dropbox's poor choices where Growl is concerned.)  I've actually had 'give me an option to install Growl from the application preferences,' and so even just a call that could be made to GrowlApplicationBridge to force Growl to pop the dialog up again -- a way an app could have a 'Click to enable Growl notifications' button -- would even be an improvement. :)

That's just my $0.02 (plus state sales tax in applicable regions).

[Peter Hosey]

On Dec 20, 2010, at 16:50:14, Rachel Blackman wrote:
> Some don't even understand what the Growl installer prompt is!

This is an issue of wording. We could fix this simply by clarifying/simplifying the existing prompt.

[Chris Forsythe]

That said we're considering the removal of the withinstaller framework altogether in another thread. It would be a good idea to review that thread and comment.

2.0 is already a decent amount of unfinished projects. My concern is about getting it out before 2012.

Chris

> --
> You received this message because you are subscribed to the Google Groups "Growl Development" group.
> To post to this group, send email to growl-de...@googlegroups.com.
> To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.
>

[Sparks]

> >> Some don't even understand what the Growl installer prompt is!
>
> > This is an issue of wording. We could fix this simply by clarifying/simplifying the existing prompt.
>
> That said we're considering the removal of the withinstaller framework altogether in another thread. It would be a good idea to review that thread and comment.

The current installer situation is enough of a headache for me as a
third-party dev that I'd be willing to pitch in. I can certainly try
to help whoever's already working on it, in order to get the proposed
network-enabled bootstrap installer up-and-running. Ideally along
with a way to trigger that install again from in a program (so that
users who blow past the Growl notification screen the first time have
the opportunity to set it up again from an 'Enable Notifications'
button in the program).

[Peter Hosey]

On Dec 24, 2010, at 11:13:25, Sparks wrote:
> Ideally along with a way to trigger that install again from in a program (so that users who blow past the Growl notification screen the first time have the opportunity to set it up again from an 'Enable Notifications' button in the program).

That seems highly ripe for abuse. As it is, I'd like to move any installation code—including the current installation code—into a static C function so that it can't be called from outside the framework.

[Rachel Blackman]

Let me detail the issue from the third-party perspective. I admit, I wrote that post before reading up on the thread suggesting a built-in notification for Growl.framework when Growl itself /isn't/ installed; that would probably be a better solution to the problem.

Basically, we rewrote an existing Windows program for Mac OS X. On Windows, obviously, everyone has to roll their own notification tool, and so we did. When we created a Mac OS X version, as the one responsible for that platform, I argued strongly for using Growl in place of our own notification system. I won the argument, largely due to the existence of Growl-withInstaller; the idea that the user would have to seek out and download a third-party app in order to enable a core function was not popular, but the installer's existence made the debate slightly easier to win.

However, a huge portion of our userbase are people who are recent Mac OS X converts; they pick up our program because they're used to the Windows version, and they want the familiar app on their new box. They install the program and see the Growl notice and click 'no' (having been trained by Windows programs that want to install Bing Toolbar or whatever), then enter bug tickets because "I don't see any notifications; I want to be able to see notifications like I get on Windows. Please add them!" When I point out that notifications on Mac OS X require Growl, the constant refrain I get in reply is "But I skipped that. There should be a button or something to let me reinstall it from in the Preferences Pane!"

My current solution -- on my ToDo list for my next build -- is to detect when Growl isn't installed and offer, in the app's preferences, a way to bring up an informative dialog box, then launch http://growl.info/ and let them download it and install it themselves. That's still non-ideal, but at least an improvement.

I actually had quite a battle to convince folks our Mac version should use Growl in the first place, because there was a feeling that requiring the installation of a third-party tool to enable a fairly core function was not a great user-experience, especially when (as my bug tracker indicates) many Windows users are trained to immediately decline additional software installs. I would guess that a similar argument took place inside Dropbox, albeit with different outcome.

Now, having read through Chris' other proposal for built-in notifications if Growl isn't installed, I think that actually works better. That allows Dropbox and other apps (me included) to bundle stock Growl without worrying that notifications will be disabled, while still supporting normal Growl for those of us (like me!) who have 8 billion custom rulesets. Even better would be having a way to direct the user to install Growl if multiple apps are running with Growl.framework but Growl itself is not installed, though that'd be merely gravy.

If, however, the installer remains in place, the ability to at least trigger it again somehow (with some sort of sane limit) would potentially be useful for the situation described above. And I think you're going to see more and more people who /do/ blow past the installer simply because they're coming from Windows, and are trained to uncheck or decline/cancel all the 'additional software' popups that happen over on the Windows side. ('Do you want to install Yahoo! toolbar? Do you want to install Xobni? Do you want to install Bing toolbar? Do you want to install Google toolbar?')

[Peter Hosey]

On Dec 24, 2010, at 13:38:00, Rachel Blackman wrote:
> They install the program and see the Growl notice and click 'no' (having been trained by Windows programs that want to install Bing Toolbar or whatever), then enter bug tickets because "I don't see any notifications; I want to be able to see notifications like I get on Windows. Please add them!" When I point out that notifications on Mac OS X require Growl, the constant refrain I get in reply is "But I skipped that. There should be a button or something to let me reinstall it from in the Preferences Pane!"

Exposing a method that would unconditionally re-run the prompt would be OK, but there will never be any API support for simply installing without a prompt. That would make it too easy to do what Dropbox did.

[Rachel Blackman]

Oh! No, a method to bring the installer prompt up again was all I meant.

Really, having Growl.framework support built-in notifications if Growl isn't installed, but also be able to offer downloading and installing Growl proper if multiple apps are using the framework without Growl installed... well, that seems to be the best of all worlds. Even just having Growl.framework support built-in notifications if Growl isn't installed would at least eliminate Dropbox-esque situations and allow Dropbox to still run stock Growl without modifications. (And probably would make life easier for other developers, as more Windows users get drawn over to the Mac side.)

But having Growl-withInstaller.framework support pulling the installer back up to re-offer the prompt would be the somewhat-selfish five minute solution to my own headaches in supporting Windows switchers.

I think the key problem is that a lot of existing Mac users are aware of what Growl is and already know they want to use it. Many switchers aren't, are trained by years of Windows use to skip/decline/deny anything that pops up 'additional installs,' and then get confused as to why their apps don't support notifications. As switchers become more common, Chris is probably correct that there'll be others besides Dropbox where notifications are not merely useful but actually /vital/, and so who either roll their own options or try to bundle Growl like Dropbox did. :/

[Chris Forsythe]

We can debate this back and forth, but at the end of the day it's the person(s) which implements it who will decide most of how this works initially, and then we can refine and release.

Someone on this thread mentioned working on this. Can you come up with a proof of concept of Growl.framework having a smoke display built-in which handles firing a notification, and also handles not overlapping other Growl.framework notifications on screen?

I think it's important to show how this works with multiple apps, so two test apps should be used in whatever demo is shown.

I would like to see an example of this by the end of February.

Please respond with any modifications you would like to make, including timeline.