On 21.02.2010, at 00:04, Sean Dougall wrote: > To clarify: What I meant by this was, do v1 users really want to find > out every time a 2.0.x bugfix is released? Obviously many of them > would want to know when 2.0 is available, but I was concerned that a > single appcast would keep spamming them with non-applicable updates > every time a new v2 release comes out.
Yeah, that's a point we're 100% in agreement on, you don't want to spam your users by presenting 1.x users indiscriminately with paid update messages that aren't of use to them. You definitely want to define a clear "breaking off point" where you decide not to send messages to 1.x clients. >> and they activated it, so they've told you they're interested. > > There I'd have to disagree somewhat. As a user, I see Sparkle as a way > of keeping a product I've already bought up-to-date with bugfixes, but > that doesn't mean I'm interested in being offered a new product > (which, to an extent, a paid upgrade is). Which is not to say that you > shouldn't let people know v2 is out there, but I'd feel weird about it > popping up in the app while I'm trying to work. Agreed, you *never* want Sparkle to pop up at inopportune moments, even for free updates, which is why we added a bunch of delegate methods to let us tell Sparkle to push back an update request under certain circumstances. Though, being realistic, there will always be edge cases where you get in the way, but I guess we have no other option than to work on improving that. Sadly we can't read users' minds. Or maybe that's "fortunately" :-) >> I'd be interested in hearing why you think Sparkle isn't the right >> venue here, and what you would do instead? > > Obviously no one solution is going to be best for everybody. In our > case, we have the luxury of mailing list + twitter + word-of-mouth > being perfectly effective among our users, so I would personally > prefer to keep paid upgrades out of the update path and avoid the > appearance of in-app advertising. That sounds like you have a fairly technical audience for your product. Most end users don't use Twitter yet, and while we also have a mailing list, non-technical users aren't really familiar with manually triggering an update. (And why should they? When have you last updated your TV?) We also take care to space our updates far enough apart that they don't get a Sparkle dialog every time they start up the app, and that also means paid updates happen about once every couple years. > I still don't think Sparkle out of > the box is the right tool for the job, but it sounds like you've > managed to solve most if not all of the technical problems to make it > into a viable tool for people who don't have any other real options. Technical problems are easy. It's the usability side that always takes so friggin' long :-) Cheers, -- Uli Kusterer "The Witnesses of TeachText are everywhere..." http://groups.yahoo.com/group/mac-gui-dev/
