On 21 Oct 2010, at 07:09, Peter Hosey wrote:

> On Oct 20, 2010, at 22:04:58, Christopher Forsythe wrote:
>> Long and short of it, is I meant more along the lines of some kind of kill 
>> switch.
> 
> 
> I have been thinking of implementing an internal, hard-coded banlist. Any 
> application on the list would be disabled by default when it registers. It 
> would appear in the Growl prefpane (with the Enabled checkbox unchecked), so 
> that the user could enable the application if they want.
> 
> If the user enables the application, Growl adds its name to a list of banned 
> applications so enabled. Ideally, we'd make it as difficult as possible for 
> an application to add itself to the enabled list. Suggestions on this are 
> welcome (but remember that it's impossible to fully solve, since there's no 
> secure per-application storage and permissions are by user, so any process 
> running under the same account Growl runs under can write to anything Growl 
> can write to).
> 
> This could only benefit on-purpose users, though (I mainly thought of it as 
> an answer to applications like Adobe's that use Growl to display ads). The 
> CS5 installer and Dropbox both install a old version (1.2), which wouldn't 
> know about the banlist.

Surely an external banlist, host on growl.info eg. would be better than a 
hard-coded list, as you could update as apps were identified?

Anyway, I’m not entirely sure this would end up helping terribly much; I can 
envisage it frustrating users who actually want the notifications.
Also, I seem to recall a large proportion of the users who have come to us so 
far seem to only have become ‘aware’ of growl upon seeing the growl update 
notification, which presumably would not be on your blacklist ;)

The update notification side of things should be mitigated by the transition to 
Sparkle, so that’s already sorted.

I would suggest for the fresh install side of things, that perhaps all that may 
be needed is a first-run “Welcome to Growl” window?
This could be used to explain what Growl is, and run quickly through how to 
configure notifications and displays. For example reference, the first thing i 
can think of is a new iTunes install (well, the _first_ thing i thought of was 
quicksilver, but not everyone has that).
Anyway, benefits of this approach would be that: 
1) Users are immediately made aware of Growl when it is first run, thus more 
likely associating it with whatever else they happen to have just installed 
that bundled it.
2) The first thing they see of growl is a friendly window telling them what it 
is for, which should reduce the amount of knee-jerk ‘what the hell is this’ 
reactions.
3) Users are instructed on the basics of how to control growl, and ideally 
given the opportunity right there and then to configure it.
4) No-one gets shafted. Not even the ill-behaved developers.

I admit it won’t help with the dropbox re-installing it problem, but at least 
off the bat after the first time it installs, users are made aware of it so it 
doesn’t come as a surprise later on.

Thoughts?
Josh

-- 
You received this message because you are subscribed to the Google Groups 
"Growl Discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/growldiscuss?hl=en.

Reply via email to