On May 17, 2010, at 6:32 PM, sourcehound <[email protected]> wrote:
On May 17, 5:51 pm, Christopher Forsythe <[email protected]> wrote:
On Mon, May 17, 2010 at 5:28 PM, Peter Hosey <[email protected]> wrote:
On May 17, 2010, at 15:26:07, Christopher Forsythe wrote:
If the user isn't able to control that, it's annoying.
To the user, specifically.
Right, sorry, I needed to be specific.
So the things that users need to have controlled by admins, like
Start/Stop
of Growl, check for updates, etc etc are all things which are
preferences.
Even the default display should be in the preferences file.
Since this is the case, do admins really need to be able to
configure per
application notifications? Especially since we advocate and
recommend sane
defaults to app devs?
Chris
The answer is yes, many admins feel the need to be able to control
specifically what dialogs, notifications, alerts, popups, etc. appear
in front of the user. Each unexpected alert is at times considered "an
error" by the end user in many environments and can cause trouble for
the admin who has to take a call, close a ticket, 'splain. There's a
school that says "a silent system is the best system." However, some
admins would want to allow Cyberduck to use Growl notifications, but
might want to disallow Mail.app from using Growl notifications. So I
guess what I'm advocating here is a blacklist / whitelist approach
with the relevant preferences being in /Library/Preferences -
something that overrides the user experience for non-admin (Standard,
Managed, Mobile, Network) user accounts. Essentially, Growl would
check the whitelist / blacklist and act appropriately - skipping the
alert if the rule told it to.
For example, I know of one admin who wrote a very nice emergency
notification system that used Growl to display alerts on computers in
case of fire, flood, etc. However, he had to abandon it when he found
that he was getting lots of calls / complaints about Growl alerts from
other apps on the system.
As far as the Adobe thing goes, sure Adobe was lazy and stupid in
distributing Growl without notice or cleanup. However, it does
highlight the point that Growl in and of itself is not a welcome
citizen on many managed networks and as a fan of Growl, I'd like to
see the developers embrace the challenge of changing that perception
by offering management options.
If admins were able to configure per-computer Growl settings (or per
group settings), they would likely evaluate Growl as a gift rather
than view it as a nuisance. A simple whitelist approach limits the
notifications to "blessed" apps. So if you're an admin that wants
Growl, but doesn't necessarily want alerts blooming all over the
screen, prompting unnecessary questions, then your current choices are
to manage each apps preferences individually (hard) or invest a lot of
time and energy into end-user training (also hard and often
fruitless).
On the other hand, if you are an admin that subscribes to the KISS
method of management (keep it simple stupid) then the solution is to
keep Growl off your standard image.
Some end users might find it annoying that the admins might be
managing their alerts settings. These users also might find it
annoying that their network, energy saver and sharing settings are
locked down too. But whether the admin wins or the user wins is
dependent on a discussion that has nothing to do with whether Growl is
manageable. Many admins will shy away from tools that don't allow
manageability as they have waged hard-fought battles to get the rights
to manage the user experience in the first place. Whether the user
wins that fight or the admin wins that fight is really irrelevant. If
the Developers of Growl give admins manageability, then Growl won't be
considered annoyanceware, which is currently is by more than a few in
the Mac Manager community.
I could go on about Sparkle too, since many admins would rather
repackage their own patches and use whatever tool they have at their
disposal rather than let Sparkle be the agent of updating.
Dean
BTW: should you want to implement something like this, I will be happy
to test it thoroughly for you.
A white list is a fine idea. Except that for end users who know what
Growl is would then be calling in.
I think we should have 3 things:
1) Allowed list
2 ) Denied list
3) Overide preference
All of these hidden prefs we document.
However, unless one of the current devs feels like doing this, it'll
require someone submitting a patch. File a ticket on our google code
page, it's a valid concern.
Chris
--
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
.
--
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.
