However, I misspoke: upon reviewing the email that David Euresti of Dropbox sent off-list, I see that I did not accurately describe their change. I'm not sure why it was off-list; I'd forgotten it hadn't been to here.
The next version they are releasing installs Growl by default in the 'typical' install setup but ships a custom version which will only display Dropbox notifications, not other app's notifications. I haven't had a chance to reply to this yet; we should move the discussion here, though.
David wrote:
> We've restructured the installation wizard a bit for 0.8 so now it's a
> lot different. The user is given two choices Typical or Advanced.
>
> We wanted to introduce a Typical flow that just does the right thing
> by default for most users. It's crucial that this flow is dead simple
> and does not burden anyone with unfamiliar choices. We think the best
> experience for most users is to use Dropbox with Growl notifications,
> so if the user does not have Growl installed, the Typical installation
> path installs it by default. However, we realize they may not want
> Growl notifications for other apps, so we changed our version of Growl to
> only enable notifications for Dropbox. (The user can manually enable
> notifications for other apps by changing it in the PrefPanel). We think
> most people will be very happy with this but by adding text to the About
> panel of the Preferences pane (calling it Growl for Dropbox) we can help
> make sure that that everyone who gets this installed knows who is to blame.
>
> In the Advanced installation we have two radio buttons "Install Growl to
> show notifications (recommended)" or "Don't show notifications".
> Technically we only install Growl if it's not already installed but
> that was wordy and confusing.
-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.
>
1) Users shouldn't have to know what Growl is to get notifications.
2) The install should be streamlined
The problem is they didn't account for our updater sucking so bad, so
we've felt the wrath of users because we never paid attention to that.
It's a scenario we never expected, since we always expected users to
at least agree to the installation due to the Growl-WithInstaller
framework. In a way we partially agree with what they are doing, the
installation portion. Hell, I even understand why they install it the
way they do. The updater sucking problem also exists in our G-WI
framework, we don't address it there either. A developer ships 1.1.x
in his app and doesn't have time to update, we fall into the same
trap. Why is dropbox different?
I think that the install route that they use isn't as intrusive as our
G-WI window. Users can somewhat recollect agreeing to some odd window
from some app about Growl. The "installation dialogue" in dropbox for
Growl is so nonobvious that it's comical though. In reality I wouldn't
expect any user to even read that box. There is so much text there,
that you kind of just glaze over it after a second, and just click
next to get past it all.
What I don't like is that users don't know what Growl is, and then
they get an update notification constantly. We'll solve that with the
sparkle update. If we put out a new version with just sparkle in it,
I'd be all happy about that. Dropbox should be addressing this in
their app too, but we can't depend on them doing anything since we
haven't seen anything from them which has addressed our concerns
really. Sure, they don't reinstall Growl continuously anymore, which
is a good first step, but that doesn't take care of the whole issue.
I have asked our contact with Dropbox to subscribe to this list, maybe
he can address some of our concerns at least here. However, I think we
need to take action into our own hands. The suggestion by Rudy is in
my opinion a bit too heavy handed. Some users would probably want a
notification from Dropbox, some don't. That's not our place, to decide
what gets notified upon so to speak. I've been thinking on this
problem for a while, and I would like to propose something else
entirely.
The key is to be simple and informative.
I do think that if this continues that we ship an update which throws
up a big NSWindow on the first launch that the user has to read saying
that if this is a Dropbox installed box, then here's what we know, and
here's what we've done to try to address the problem. We can easily
detect if Dropbox is installed by checking for the bundle and checking
for the application ticket. The window can offer to disable Dropbox
notifications, and provide some other options possibly. The main key
is to talk about how dropbox treats other developer groups, users, and
that we really don't recommend the use, and to provide alternative
options. Nothing slanderous obviously, just enough of a point that
we're really just tired of it all. We could even provide a "show me
this later" and when dropbox registers 3 times later, pop the window
up.
No matter what we decide to do, if we don't see a resolution to all of
our complaints about Dropbox by January 15th planned for a release
planned by them, then we should move forward with the assumption that
they just aren't going to do anything about it which helps us to
reduce our inbound support load and to reduce users being confused.
I'm not happy about the situation that we've been put into. Nobody is.
But we're better than blacklisting. Some users want to use this
functionality. I don't want to block that. I just want this issue to
go away in a way that makes our users and us happy.
Chris
On Thu, Dec 9, 2010 at 10:23 PM, Evan Schoenberg, M.D.
Yes, 1.2.
> … which they would have avoided if they had just used our G-WI framework).
No, because their current release (0.7.110) is so old that they would still be using the 1.2 framework, which would still be installing 1.2.
The planned download-and-install framework would fix this, but that doesn't exist yet.
According to that off-list conversation, only the “Advanced” path will have the explicit checkbox. The “Typical user” path will not have any mention of Growl.
If we do a blacklist, we should list the application among the applications, but struck through and in red, and there should be a way to find out the reason from that.
I think I suggested a blacklist awhile back, for other reasons (apps like CS Live that show ads through Growl), so you can find my thoughts on a blacklist in that thread in the archives.
The updater has nothing to do with it. It's just the messenger—how people are finding out that Growis on their system.
The problem is that Dropbox installs Growl without the user's explicit permission.
There are two solutions to this problem, and they're both on Dropbox's end:
a. Create an entire step in the installation wizard explaining briefly what Growl is and asking for permission to install it. (Skip entirely if Growl is already installed.)
b. Stop installing Growl under any and all circumstances.
> It's a scenario we never expected, since we always expected users to at least agree to the installation due to the Growl-WithInstaller framework.
Exactly. Growl's updater is not *that* bad; it's just designed for users who installed Growl by choice.
The only problem I can see with it is that it should say something different when it finds a newer version than itself is already installed. That fixes the “why are you updating Growl every *@#*!! day” problem, but not the “why is Growl on my system” problem.
> In a way we partially agree with what they are doing, the installation portion.
Who does? I don't.
> The suggestion by Rudy is in my opinion a bit too heavy handed. Some users would probably want a notification from Dropbox, some don't. That's not our place, to decide what gets notified upon so to speak.
Back when I suggested a blacklist, I mentioned that the user should have a way to enable the application if they really want its notifications. It would basically be off by default and specially listed to indicate why.
> I do think that if this continues that we ship an update which throws up a big NSWindow on the first launch that the user has to read saying that if this is a Dropbox installed box, then here's what we know, and here's what we've done to try to address the problem. We can easily detect if Dropbox is installed by checking for the bundle and checking for the application ticket. The window can offer to disable Dropbox notifications, and provide some other options possibly. The main key is to talk about how dropbox treats other developer groups, users, and that we really don't recommend the use, and to provide alternative options. Nothing slanderous obviously, just enough of a point that we're really just tired of it all. We could even provide a "show me this later" and when dropbox registers 3 times later, pop the window up.
This all sounds good, but it's the first step in a potential arms race:
1. We add this dialog box.
2. Dropbox doesn't update their Growl, since they won't want any such dialog box.
3. We ship an update that requires GNTP (removing the current notification methods), so all applications using old Growl frameworks can't notify. (We'll give due warning to all well-behaved applications' developers, of course.)
4. Dropbox updates their Growl, but removes/disables the dialog box.
5. We ship another update. Users who update see the dialog box.
6. Dropbox modifies their Growl again to remove/disable the updater.
7. We ask them to stop calling their mutant notifier Growl.
8. If they don't, we put up a web page describing everything they've done so far and asking people not to use Dropbox, and link it everywhere we can (Download.com, MU, Softpedia, any Reddit thread about Dropbox, etc.).
I'd like to not start down that road, but that's up to Dropbox.
Dropbox developers, you should be using an unmodified Growl and either only installing it with explicit permission or not installing it at all. It's that simple.
We do by providing a framework which effectively does the same thing.
>> The suggestion by Rudy is in my opinion a bit too heavy handed. Some users would probably want a notification from Dropbox, some don't. That's not our place, to decide what gets notified upon so to speak.
>
> Back when I suggested a blacklist, I mentioned that the user should have a way to enable the application if they really want its notifications. It would basically be off by default and specially listed to indicate why.
>
>> I do think that if this continues that we ship an update which throws up a big NSWindow on the first launch that the user has to read saying that if this is a Dropbox installed box, then here's what we know, and here's what we've done to try to address the problem. We can easily detect if Dropbox is installed by checking for the bundle and checking for the application ticket. The window can offer to disable Dropbox notifications, and provide some other options possibly. The main key is to talk about how dropbox treats other developer groups, users, and that we really don't recommend the use, and to provide alternative options. Nothing slanderous obviously, just enough of a point that we're really just tired of it all. We could even provide a "show me this later" and when dropbox registers 3 times later, pop the window up.
>
> This all sounds good, but it's the first step in a potential arms race:
>
> 1. We add this dialog box.
> 2. Dropbox doesn't update their Growl, since they won't want any such dialog box.
> 3. We ship an update that requires GNTP (removing the current notification methods), so all applications using old Growl frameworks can't notify. (We'll give due warning to all well-behaved applications' developers, of course.)
> 4. Dropbox updates their Growl, but removes/disables the dialog box.
> 5. We ship another update. Users who update see the dialog box.
> 6. Dropbox modifies their Growl again to remove/disable the updater.
> 7. We ask them to stop calling their mutant notifier Growl.
> 8. If they don't, we put up a web page describing everything they've done so far and asking people not to use Dropbox, and link it everywhere we can (Download.com, MU, Softpedia, any Reddit thread about Dropbox, etc.).
>
> I'd like to not start down that road, but that's up to Dropbox.
>
At this point it would push them to do something. Nothing else I can
think of forces them to do anything. We're stuck, they're the big
bully, and I'm tired of being in that position. We (users and the
Growl Developers) are not in control here, which is ironic for a group
who makes a product which has the sole purpose of giving control to
users.
The problem is I don't think the dropbox guys get/care what the
problem is for us, they have their requirements. I'm tired of feeling
like that girl on prom night that has no date until the last minute. I
need a way to say to users "we tried talking to them, that failed, so
here's our solution to this mess". What I proposed doesn't have to be
it, but I'm not happy with anything else I've seen proposed.
Blacklisting is a horrible idea, It still has the same problem that we
already have, with an added bonus of being hateful.
I think my proposal won't take the problem as far as you illustrate.
While possible, I think they'd probably just remove Growl instead of
doing half those steps.
> Dropbox developers, you should be using an unmodified Growl and either only installing it with explicit permission or not installing it at all. It's that simple.
>
David emailed me directly and said he would have an email out to the
list before the end of the day.
OK, so you mean we agree that they may install Growl. The difference is that our framework won't install without permission.
Exactly what I mean, that we're fine with that, just not with how they
are doing it.
I worry that users will think that “Growl for Dropbox” is the result of some sort of co-branding agreement we have with you. Maybe “Growl (Dropbox edit)”? That makes it more clear that it's your modified version of Growl.
> #5 We install an old version (1.2 for Leopard and Snow Leopard, 1.1.6 for Tiger) We know it's old but it's been well tested by us.
It's not just old, it also has bugs that we've fixed.
http://growl.info/documentation/version_history.php
Updater nagging is only one of the problems with installing an old version; this is the other.
> * Note: Some time ago I did consider moving to version 1.2.1 but there was a crash in Growl-WithInstaller that prevented it from installing. I regret to say I never tried again. I did report the bug though.
Since you've modified your Growl framework anyway, why not include the crash fix among your modifications?
Please stop shipping Growl, or use our provided methods unmodified.
Chris
Yet-another notification system. Clue: Growl is THE standard. Use
it. Folx like me, that provide a lot of tech support, have NO
interest in supporting yet-another notification system.
Dropbox's inability to properly use a standard such as Growl will be
taken into consideration during evaluations...
- Dan.
(Not a growl dev, just a user/admin)
--
- Psychoceramic Emeritus; South Jersey, USA, Earth.
And use it properly. I would rather Dropbox implement a custom notifications system than continue damaging our reputation by installing anything with the Growl name on it without users' explicit permission.
Some software already does that (take a look at Colloquy, for example).
It uses a built-in Growl unless it can find the actual Growl.
Tom
On Dec 11, 2010, at 6:38 AM, Tom van der Woerdt <in...@tvdw.eu> wrote:
> On 12/11/10 1:36 PM, Zachary West wrote:
>> On Sat, Dec 11, 2010 at 00:42, Peter Hosey <p...@growl.info
>> <mailto:p...@growl.info>> wrote:
>>
>> On Dec 10, 2010, at 21:23:50, Dan wrote:
>> > Growl is THE standard. Use it.
>>
>> And use it properly. I would rather Dropbox implement a custom
>> notifications system than continue damaging our reputation by
>> installing anything with the Growl name on it without users'
>> explicit permission.
>>
>>
>> Sounds like the perfect example of Growl.framework needing a "show
>> notification even if Growl isn't installed" feature—the basic Smoke
>> display without configuration. Perhaps Dropbox could bite the bullet and
>> implement /that/?
>>
>> Zac
>
> Some software already does that (take a look at Colloquy, for example). It uses a built-in Growl unless it can find the actual Growl.
>
I had wanted this for that reason, but it was vetoed. I forget why, but it made a whole lot of sense.
Chris
> Tom
>>> Sounds like the perfect example of Growl.framework needing a "show
>>> notification even if Growl isn't installed" feature—the basic Smoke
>>> display without configuration. Perhaps Dropbox could bite the bullet and
>>> implement /that/?
>>>
>>> Zac
>>
>> Some software already does that (take a look at Colloquy, for example). It uses a built-in Growl unless it can find the actual Growl.
>>
>
> I had wanted this for that reason, but it was vetoed. I forget why, but it made a whole lot of sense.
>
> Chris
>
something to do with if multiple things did it, you might end up with overlapping notifications?
shame, because on the face of it, i think it’s a really good idea!
i considered the possibility of sharing the GHA process somehow a little while ago and couldn’t immediately think of a problem with something like this:
https://groups.google.com/group/growldiscuss/browse_thread/thread/125970d8bfc061b1/74450051eeeed26b?#74450051eeeed26b
except for the changes-to-notification-protocol thing… which is quite a big one with gntp around the corner, i guess, although could potentially commit to ‘from gntp forward’?
Chris
On Dec 10, 2010, at 6:33 PM, David <eve...@gmail.com> wrote:
> Hello,
>
> This is David Euresti from Dropbox. I thought I should chime in on
> this conversation, and mention very explicitly all the changes that we
> have done to Growl. I personally believe, that even though they might
> not be how you'd like them they will solve most of your concerns. Our
> goals are basically to make the Dropbox user-experience great, and to
> get users with questions to come to Dropbox for support. After all,
> we're the reason they have Growl on their machine.
>
To be honest if you just changed your dialogue to be explicit about installing Growl, and to not reinstall Growl if removed, that would address 95% of my concerns. This itself is why I don't think you get what the problem is.
> Our latest version of Dropbox (version 1.0) is due to be on the front
> page of our website by next week barring major disaster. The Growl-
> WithInstaller that we ship with that version is modified as follows:
>
> #1 We only auto-enable notifications for the Dropbox application.
> Every other app starts as disabled. This way most users only get
> Dropbox notifications but if they want to they can enable other apps.
Please reverse this. This is counter to giving the user control
> #2 By default the version we install has "check for updates"
> unchecked. This is so that they won't get bothered with it.
This is bad. What if the version you're shipping has a security vuln? You are exposing users to problems here without them knowing about it.
> #3 Once installed, the name on the Pref Panel is changed to "Growl for
> Dropbox" We do this for two reasons, a) we've made modifications to
> it so they'll know who to blame, b) we want users to know why Growl is
> in their Pref Panel.
Please don't do this. This addresses nothing.
> #4 We added text to the About box of the "Growl for Dropbox" Pref
> Panel, mentioning how it got there, and where to go for support.
Same here, does not address a thing. Even could make us look bad.
> #5 We install an old version (1.2 for Leopard and Snow Leopard, 1.1.6
> for Tiger) We know it's old but it's been well tested by us.
> * Note: Some time ago I did consider moving to version 1.2.1 but
> there was a crash in Growl-WithInstaller that prevented it from
> installing. I regret to say I never tried again. I did report the
> bug though.
And this is why custom work like you've done has consequences.
> #6 We modified Growl With Installer to not prompt. (Yes we know you
> hate this but we feel all the other changes mitigate it)
If you tell the user you are installing software other than dropbox, this would be no issue. You don't. That is why we are angry with your company.
> #7 If the user uninstalls Growl, either by removing the Pref Panel, or
> by using the Growl Uninstaller you guys ship, Dropbox will not
> reinstall Growl unless the user goes into Dropbox preferences and
> selects they want to see Dropbox notifications using Growl.
>
Great.
> With all these changes we feel that users will not instantly go to
> your website to complain about how Growl got installed on their system
> since:
> * They'll only get Dropbox Growls.
> * The pref panel will say Growl for Dropbox.
> * The About Panel says "Contact Dropbox for support"
>
The complaints are annoying, but not why we're annoyed by your company giving Growl a bad name. You fucked us over, and now you think these half steps somehow fix that? All you had to do was two simple things, change a string and stop firing a method for reinstall. That's it. Instead we're here talking about stupid changes that do not help the user, just makes it so that you guys get some angry grams.
If you ship this version as-is, I'll be more apt to agree with a blacklisting approach, since it'll prove you just aren't getting it.
Chris
> All this being said, we have started working on 1.1 (which will have a
> shorter release cycle than 1.0) and we're working on having our own
> notification system to not have to install Growl.
>
> David
>
All you had to do was two simple things, change a string
and stop firing a method for reinstall.
Tom
On 12/11/10 9:28 PM, Evan Schoenberg, M.D. wrote:
>
> On Dec 11, 2010, at 2:04 PM, Chris Forsythe wrote:
>
>> All you had to do was two simple things, change a string
>
> Slightly more than that. We want it to be a clear and explicit step that
> Growl is being installed. I really like this being smoothly integrated
> into the first-run setup wizard rather than a separate popup window; I
> /don't/ like this being an automatic behavior of the 'typical' installation.
>
>
>> and stop firing a method for reinstall.
>
> That's been done for 1.0, per David.
>
> Doing the above removes the need for any of the other modifications
> discussed.
>
> -Evan
>
Because the user wouldn't be able to turn it off or uninstall it.
That's already fixed for the next version, and if they're going to ship a customized framework, they can ship it with that fix applied.
From the discuss list[1]:
> DropBox was the only app in the list, so I decided to uninstall that version [the version Dropbox installed] and install the newest which brought Skype to the list and it Just Works! :-)
I imagine we'll see a lot more of this once you ship a version of Dropbox that installs a version of Growl that disables all other apps by default.
given that it hasn’t been officially released yet, that’s a pretty impressive turnaround!
Other worrying questions:
* If I install Growl over the top of [modified growl] (without uninstalling [modified growl], however one does that), is it clean? Do existing tickets become enabled? Do future registrations now work?
* If I install Dropbox where an existing Growl installation exists, does [modified growl] overwrite it? …what about in the case of an older Growl version?
josh