Growl Framework changes WAS: Dropbox 1.0 and Growl

[Christopher Forsythe]

On Fri, Dec 17, 2010 at 11:02 PM, Evan Schoenberg, M.D.
<eva...@dreskin.net> wrote:
>
> On Dec 17, 2010, at 10:58 PM, Christopher Forsythe wrote:
>
> On Fri, Dec 17, 2010 at 10:35 AM, Peter Hosey <p...@growl.info> wrote:
>
> I've just tested it, and:
>
> 1. It still installs Growl without asking for permission. (We knew this
> would happen, since the Dropbox developers have said on multiple times that
> they don't want to ask non-technical users for permission to install
> anything.)
>
> 2. They have fixed it reinstalling after you uninstall.
>
> 3. It still installs Growl 1.2, not 1.2.1.
>
> 4. It installs Growl 1.2 even if you already have Growl 1.2.1. (This is a
> new bug in 1.0, if I remember 0.7's behavior correctly.)
>
> 5. It is a custom-built Growl 1.2, though I can't tell whether there are any
> Dropbox modifications to it (e.g., disabling other apps by default). The
> “Growl for Dropbox” branding is gone; to the user, it looks the same as our
> release. GrowlHelperApp's size is different, but I couldn't say why.
>
>
>
> I've been in communication with the Dropbox developers. Essentially in
> the next version after 1.0, they're going to make us all happy.
> They'll stop shipping Growl itself.
>
> There was a misunderstanding between our two groups (Growl team and
> Dropbox team) in that they didn't understand the problem we were
> seeing, and interpretted it as another problem. It's not worth going
> into this further, just needless to say I think they would have
> resolved this for us much sooner if they had understood the problem
> how we understood it.
>
> So the quickest thing they could do with 1.0 and still ship it on time
> was to revert their intended changes, and then in the next version to
> release without an installing Growl. They're hoping to have that
> version out soon.
>
> This is great news for us, and great news for Dropbox users. Hopefully
> very soon we won't have to worry about this anymore.
>
> It's really not great news as described, because now Dropbox notifications
> will compete with and potentially overlap Growl notifications.
> Shipping any notification system that isn't Growl and is used if Growl is
> installed should be considered a bug.
> Dropbox considers unobtrusive notifications a *must* for their app - this
> makes sense, as it has no other UI besides the prefs and a menu item.
> The correct solution for them is therefore to have a simple notification
> system implemented within their app and to utilize Growl instead if it is
> installed.
> They could even use the Growl code directly within their app to provide
> notifications if Growl isn't installed - a large amount of code for a small
> problem, perhaps, but one which would require less engineering effort.

I think it would be a good idea to provide this to applications in
general. If this is the behavior we want Developers to take when Growl
is not installed, we should be presenting it as such. I think it's a
better solution to present notifications if Growl is not installed
that overlap with other applications that also use this, than to not
provide guidance and something easy to use. If the Growl framework
that Dropbox developers initially downloaded would have a fire and
forget notification, I doubt highly that they would have even
attempted to use the G-WI framework, or then made their own ui for it.

We've gone back and forth about a fire and forget notification not
being good because the notifications would overlap, but they would
overlap anyhow with a custom notification system for applications. The
only difference is we'll be providing some easier to use code, which
means that developers won't be tempted to run into the same scenario
as the Dropbox developers did.

I want to propose removing the Growl-WithInstaller.framework and
instead having a simple fire and forget notification within the
Growl.framework. I know we've talked about it directly in the past,
but I really think that for most applications this is a better
solution that fits into something we can stomach than anything else we
can do. That said I'm open to other ideas, this isn't the only one out
there.

If we continue as-is, we're going to keep running into this.
Applications are shipping Growl, over and over again. Big companies,
small shops, etc etc. We need to address this problem. I think that by
continuing to ship the Growl-WIthInstaller framework, we're telling
developers that we approve of them installing Growl. Then we run into
developers who don't like our dialogue (and never will like any
dialogue we create) and want to make their own.

By shipping something else, providing code to build into applications,
or building a notification into Growl.framework, we're providing a
different scenario for the developer, which I think is a good idea.

I'm moving this to the Development list as I think we need to flesh
this all out, and I don't know that everyone on the users list wants
to see it.

Chris

[Evan Schoenberg]

On Fri, Dec 17, 2010 at 11:20 PM, Christopher Forsythe <ch...@growl.info> wrote:

I think it would be a good idea to provide this to applications in
general.

 

I disagree; details below.

We'd be providing a scenario that makes it very easy to go back to the Bad Old Days in which multiple applications presented overlapping notifications.

 

The current state of the art is that the vast, vast majority of applications either:

 a) provide no visual systemwide notification

or

 b) provide a visual systemwide notification via Growl.

 

Changing our framework to act independently if Growl isn't installed would turn this into:

 a) provide a visual notification that will overlap others and is no better than rolling their own except was trivial to implement

or

 b) provide a visual systemwide notification via Growl.

 

Providing this capability would mean that part of our framework was running *counter* to our goals.

 

-Evan

[Chris Forsythe]

What if they fired a distributed notification saying they were going to take up a specific area for n time period and all other Growl frameworks did the same?

Chris

or

 b) provide a visual systemwide notification via Growl.

 

Providing this capability would mean that part of our framework was running *counter* to our goals.

 

-Evan

--
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.

[Josh]

On 18 Dec 2010, at 17:39, Evan Schoenberg wrote:

We'd be providing a scenario that makes it very easy to go back to the Bad Old Days in which multiple applications presented overlapping notifications.

 

The current state of the art is that the vast, vast majority of applications either:

 a) provide no visual systemwide notification

or

 b) provide a visual systemwide notification via Growl.

 

Changing our framework to act independently if Growl isn't installed would turn this into:

 a) provide a visual notification that will overlap others and is no better than rolling their own except was trivial to implement

or

 b) provide a visual systemwide notification via Growl.

 

Providing this capability would mean that part of our framework was running *counter* to our goals.

 

However, given that the Bad New Days™ if the growl framework doesn't change may be to:

a) provide a visual systemwide notification via Growl.

or if not installed

b) roll your own visual notification, which will likely suffer from dissimilarity in appearance, function, and more as well as potential overlapping issues.

Which do we prefer?

Also, I'm sure at least for apps with the same Growl.framework built-in, we can figure out some way to avoid the overlapping issue…

[Sparks]

On Dec 21, 2:35 am, Josh <i.atent.d...@gmail.com> wrote:

> Also, I'm sure at least for apps with the same Growl.framework built-in, we can figure out some way to avoid the overlapping issue…

Not to mention, if two apps are both running the same Growl.framework,
it would be fairly easy to pop up a notification going, '<X> and <Y>
are both using the Growl Notification System. Would you like to
download the Growl Command Center, to give you a single place to
control the appearance and behavior of all notifications?' and offer
an installer, or at the very least a link to download Growl. (I call
it 'Growl Command Center' here merely as an example; then apps use
Growl, but you can unify and control them from the Growl Command
Center, or whatever.)

If only one app on their system (Dropbox?) uses Growl, they probably
don't care. If, say, five apps do? They may care rather more.