Developer confirmation for using Mist

[GoogleCodeExporter]

Provide a way to let developers know that Mist is available in the 1.3 sdk, and 
report to the framework that they know it is available. The reason that this is 
wanted is so that developers need to know about Mist and how they want to use 
it.

This needs discussion.

Suggestions for text:

20:07 < sholt> "Hi, you haven't decided if you want your application to display 
mist notifications - a way to display notifications to users without growl.app 
installed on their 
               system. click here for more info."
20:07 < Catfish_Man> Something like: [title: Don't ship this yet!] Hi, it looks 
like you've just updated your app to Growl 1.3. That's great, but make sure to 
set 
                     GrowlUseDefaultConfigurationUI in your Info.plist to make sure that your users still have a way to disable notifications if they want to
20:07 < sholt> actually - I kinda like that.  The correct default option is no 
default option.
20:07 < sholt> like sending the recovery key to apple for FDE
20:07 < sholt> in lion
20:08 < Catfish_Man> actually my text isn't that good because it doesn't 
explain what to set it to or why
20:08 < Catfish_Man> but you get the idea :)
20:09 < sholt> yeah, basically, "this is a new thing and you need to decide how 
to use it"

Original issue reported on code.google.com by ch...@growl.info on 6 Nov 2011 at 3:11

[GoogleCodeExporter]

the suggestion on sholt and cfm's behalf is a complete NON-SOLUTION, what 
they're actually asking for is mist to be opt-in. 

Original comment by rarich...@gmail.com on 6 Nov 2011 at 2:00

[GoogleCodeExporter]

Not exactly the same, but effectively the same as opt-in. I told sholt that I'd 
file it and we'd discuss it.

Original comment by ch...@growl.info on 6 Nov 2011 at 2:43

[GoogleCodeExporter]

FWIW, we're already getting user complaints over mist since our Adium 1.5b3 
release.

I'm not saying that to argue about mist itself, but rather to point out that 
for users that do not have growl installed (or, even, people who have never 
heard of growl), these notifications are coming from Adium and we get blamed 
for "changing" their notification settings.

The fact is developers do not track your development progress that closely, and 
this is a huge change in how growl behaves. We need education and outreach to 
developers from you with this feature, because for people without growl.app 
(previously growl.prefpane) installed, any changes in behavior are changes in 
the app itself.  Developers need to be informed that this is a risk (with the 
cost of extra support for users that do not understand notifications or growl) 
they must accept.

Original comment by stephen.holt@gmail.com on 6 Nov 2011 at 5:24

[GoogleCodeExporter]

This hasn't been forgotten, I'm still thinking on it.

The problem is that without this, it's either we enable it and developers get 
it that didn't read the docs, or we disable it and developers never see it that 
never read the docs. That's their fault but it's also our problem.

With this, developers who did or didn't read the docs still have to opt in or 
opt out of Mist. So it forces them to read the docs basically.

Those users who complained are a symptom of the problem possibly, but also a 
symptom that they don't know how to go look at the Adium event system. I don't 
know if they entirely count as reasoning here and may just be a red herring, 
but they are still worth considering. Users who are used to not having Growl 
installed on their system to just disable notifications are now going to have 
to figure that out, which is where I think sholt's initial problem with this 
came about. Regardless, we have to think about both the end user and the 
application developer, who is also our end user.

I'm not opposed to what was proposed here (say that five times fast). Basically 
the gist is that if an application developer adds the framework in, it needs to 
inform the application developer that there is a change in the framework.

However, there's another problem. Say a developer doesn't test their support, 
they just update the framework. Now they ship to end users. End users now run 
into this problem. That's an issue. So do we add another global defaults 
setting to disable the opt-in/opt-out choose notifier? The problem kind of 
builds on itself.

We'd also need to take into account our use of the framework in Growl Version 
Detective, so we would have 2 slightly different frameworks to contend with. 
One for GVD, and one for everyone else. Something to keep in mind.

Thoughts?

Original comment by ch...@growl.info on 13 Nov 2011 at 6:02

[GoogleCodeExporter]

Releasing the 1.3.1 sdk, moving this to the next milestone.

Original comment by ch...@growl.info on 26 Nov 2011 at 6:32

• Changed state: WaitingOnUser
• Added labels: Milestone-1.3.2
• Removed labels: Milestone-1.3.1

[GoogleCodeExporter]

Original comment by rarich...@gmail.com on 19 Oct 2012 at 2:31

• Added labels: Milestone-2.1
• Removed labels: Milestone-1.3.2