[Sparkle] Thinking about unifying Sparkle...

[Andy Matuschak]

I'm trying to think a bit about Sparkle's future. I'm hoping you all  
can lend me a hand.

John Gruber made an excellent point about Sparkle in his Linked List  
last week: when it has an update available, it prompts you to install  
it at pretty much the least convenient time. You've just launched the  
application and want to use it for something! The fully automated  
updates mitigate this somewhat, but almost nobody uses them, and then  
the user still gets a prompt to restart the app maybe thirty seconds  
later.

I envision a system-wide Sparkle that constantly keeps the system up- 
to-date, controlled by a prefpane. All updates must be signed, and new  
updates are installed automatically as they're acquired (this behavior  
being perhaps configurable). If an update is installed for a program  
that's running, the system will ask the user if he'd like to restart  
it. The user can roll back to any version still in the appcast through  
the prefpane UI.

Now, I have a couple problems with this idea:

1. What kind of interface is appropriate for notifying the user of  
updates? A lot of the time, they don't care at all that something's  
been updated—a tiny bug fix, a small new feature, whatever. I don't  
want to be intrusive. Here are the options as I see them:

	a. Don't do anything to notify the user.
	b. Just basic notifications, like Growl, in the upper-right when an  
update's installed. If you click a bubble, you see the release notes.  
This is hardly elegant. Maybe something a little more... Delicious?
	c. When you start the app, it says "Hey, this is a new version! Wanna  
see what's new?" and offers to show release notes. This is just as  
obtrusive as the current system, really. So probably not.

2. How does the prefpane get installed? Sparkle is so effective and  
ubiquitous now because users don't really have a choice: the app comes  
with Sparkle, and by golly, it's going to keep things up to date! If I  
switched to Growl's distribution method, I don't think nearly as many  
updates would actually get executed. Ideas:

	a. When an app that supports Sparkle is opened for the first time, it  
introduces Sparkle and offers to install it. This is rather obtrusive  
and inelegant, though it only occurs a maximum of once for the whole  
system. Also, if a user says "no", he doesn't really have a way to  
install it later. That's an issue.
	b. Option (a) but do it when the app quits for the first time. Then  
it's not so much in the way of actually doing things but it still  
generates the "argh no I said go away why are you doing things" anger  
response.
	c. Just install it. It's not like it's going to kill the user. The  
problem with this is that they may wonder how it got there or why  
notifications of app updates are appearing. Furthermore, they'll have  
no idea the prefpane exists.
	d. Option (c) with some kind of explanatory dialog on first open /  
quit.

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.

I could really use feedback on this, guys. Let's get creative!  
Especially on problem #1. I'm probably going to end up rewriting  
pretty much everything in the process of making it system-wide; I'll  
separate all the components so it'll be easier to support plugins /  
prefpanes / whatever, too. I'll try to do binary updates, and I'll  
merge in Sparkle+ stuff. It'll be great. If Caltech ever gives me a  
chance to breathe.

Wheezingly yours,
Andy Matuschak

PS: Great coats, sparkle.andymatuschak.org couldn't be uglier. Ideas?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.andymatuschak.org/private.cgi/sparkle-andymatuschak.org/attachments/20070804/3e10eb6d/attachment.htm