[Sparkle] Thinking about unifying Sparkle...

[Jerry Krinock]

On 2007 Aug, 04, at 18:40, Andy Matuschak wrote:

> The user can roll back to any version still in the appcast through  
> the prefpane UI.

An unstated but desirable feature of the above is that the developer  
maintains control over the appcast and hence what old versions are  
still available.  I don't want users to have a selection of old  
versions on their drives.

> 1. What kind of interface is appropriate for notifying the user of  
> updates? ...
> 	a. Don't do anything to notify the user.
> 	b. Just basic notifications, like Growl...
> 	c. When you start the app, it says "Hey, this is a new version!...  
> This is just as obtrusive as the current system, really. So  
> probably not.

No, I think that 1(b) is most obtrusive, because it will happen at  
random times.  (How many users remember to squelch Growl as they are  
rushing to connect their Mac to a projector and begin a presentation  
that they just finished.)  I do not agree with John Gruber that  
launch time is a bad time to update.  My reason is that the user's  
attention is focused on the app at that time, and their mind will  
already be open to whether or not there is an important bug fix or  
new feature that they want immediately.  For large apps though, it  
would be nice if the new version were already downloaded and ready to  
go.

I would suggest that (a) be the default and (c) be available as a  
preference.  At this time, I don't want anybody ever using an old  
version of Bookdog for any reason, but someday when I start charging  
money for updates I'll have to allow (c).  I suppose I'll have to  
learn what a "poset" is too.

> 2. How does the prefpane get installed?

I think your option 2(a) is best.  Regarding the issue that...

> if a user says "no", he doesn't really have a way to install it later.

Well, you could provide an action for another menu item...
         Check For Updates (Sparkle Updater)
         Upgrade To Sparkle System-Wide Updater
That second menu item simply targets the first-launch new-user  
introduction action again, so you've got no additional code, although  
another "feature" to document :(   Looking at that first menu item,  
the reason why I added "(Sparkle Updater)" to the "Check For Updates"  
item is because, at this time, unless they read the credits, most of  
my users have no idea that I'm using a framework called "Sparkle".   
(They probably think that I'm as smart as you!)  So they need this  
label to give them a clue as to what the second item might do.

> The other problem with this is that even though Sparkle is system- 
> wide under this mechanism, every app's still got to ship with and  
> contain a copy of it for it to install itself. Kinda lame.

Well, with a little more work, developers who want to trim the fat  
from their dmg can host the Sparkle System-Wide Updater as a separate  
download, downloaded as needed.

>

A few more comments:

* The proposed Sparkle System-Wide Updater is going to have to be  
solid and updates of itself must be backward compatible.  I don't  
worry about Sparkle now, because I have built, tested and shipped it  
in my package.  When it becomes a system component, I'll have this  
slight worry that I'm going to wake up one morning and find that an  
update of Sparkle System-Wide Updater broke my app.

* Are people still using things like Little Snitch?  If so, they'll  
have to be warned when this thing goes out looking for updates at  
random times.

* Apple's model (Software Update, iTunes podcast updates) is that the  
user has no control, and not even any view, of the time of day when  
"check for updates" happens.  So every now and then my son will be  
playing some online game, and he comes to me complaining that "My  
ping is up to 999.  Your %$#@! Mac must be downloading podcasts  
again!"  We're living with it, and apparently this is good enough for  
Apple, but realize that some people might like control over or at  
least visibility of the scheduled "check" time.

* Finally, in case anyone is interested in further reading, the 1- 
sentence comment by John Gruber which started this was made in  
reference to the following blog post by Chris Hanson.

http://chanson.livejournal.com/173526.html