Sparkle 2.0 Storyboard

Stay with me here. There's a storyboard in front of you. It's got the finished mock-ups on it. You can see all the pictures. Now listen:

Here comes Joe! Hi, Joe. Joe just opened iEye—a Sparkle-2.0-enabled application—for the first time. He's never opened a Sparkle-2.0-enabled application before. We are all in suspense. But nothing happens! Joe has a wonderful first experience with the application and enjoys the welcome screens and filling out his lovely registration information. He quits the app.

Thursday rolls around. Joe launches iEye for the second time. Now it pops up an alert with the Sparkle icon saying:

iEye can use a program called Sparkle to keep itself and other supported applications up to date. Would you like to install Sparkle now?

(think you can improve the wording? please make suggestions)

I don't love "can use a program called Sparkle." How about, "Sparkle lets iEye and other supported applications stay up-to-date. Would you like to install Sparkle now?" -evands

Yes. And a third button for Learn More... that visits the Sparkle site. —Andy Matuschak

I've argued this before (on #macsb primarily), but I think the 'separate entity' approach is incorrect. Half the beauty of sparkle is that it's part of its host app, so there's nothing more to install. --DavidSmith?

Half the ugly, though, is a large amount of repeated code across many apps that doesn't need to be there. Another piece of ugly is that, though the frameworks are effectively all the same, there's no central location to modify anything. To actually check for updates, currently, you have to run every... single... application... and that takes a LOT of time if you have a lot of apps. That's largely why AppFresh? has gained so much popularity, despite its many glaring flaws. Why not do it right? --Groxx

The problem is that AppFresh? and Sparkle get to the end user in two different ways. If someone wants to use AppFresh?, they have to download it themselves. Compare that to, say, SubEthaEdit or Stuffit Expander. If I download these apps I'm definitely not expecting some third party preference pane to come along with it, and I'd be pretty annoyed if it did.
Furthermore, you depend on software developers to distribute your software. The reason why we use Sparkle is because it's professional and non-intrusive--it acts like a part of our applications. You can make the slickest autoupdating framework in the world, but it won't matter if software developers refuse to put it in their apps--and I suspect most would refuse. I know I would never allow my app to install something on the user's system that I didn't write.
My suggestion is this: make Sparkle a standalone app/preference pane, if you want to. But if endusers want to use it, they have to download it themselves--no riding along on third-party apps. Then you could use the Sparkle appcast URLs that are already in applications to check for all updates in a reliable way--and as a bonus, provide the (less reliable) autoupdate functionality found in something like AppFresh?, where you just guess based on an online database. That way endusers get the best of both worlds--reliability and global update checking for Sparkle-enabled apps, and the less reliable AppFresh?-style checking for all other apps. And in the end, the versioning and permissioning nightmare that auto-installing frameworks would entail just goes away. --adamjernst

I think it's worth noting that this is exactly what Growl/Adium do (or can do). When running Adium, it asks you if you want to use Growl, to provide notifications and so forth. You can install it from Adium, or you can go to the website and download it yourself. Some apps include it, and some don't.
I think the important thing in this case would be for the developer to decide if it was worth shipping Sparkle themselves, referencing Sparkle to the user, or just checking to see if Sparkle is installed and using it if so. I don't want Stuffit installing random apps all over the place (just look at the Logitech/APE/Leopard fiasco), but if it tells me that it can install some small updater software, I'd be open to it if it makes everything Just Work. --Dan Udey

As an Adium developer, I can safely say that copying our first launch experience is probably not something you want to do. Too much stuff popping up, and way way too much text for them to read. Even with all that text "wtf is this growl thing" is still one of the more popular support questions we get. --DavidSmith?

As a Last.fm Client developer I think Sparkle should continue to do as it does now, ie offering a framework that checks for updates from within the application. If the user has installed the all-in-one-updater this internal app check should be deactivated. We're working with Growl currently to do the same thing with their notification framework. Users hate the interruption to their work flow when a dialog for an unrelated app pops up, especially on first use. To encourage use of the all-in-one-updater offer a pref-pane for applications to use that allows configuration of Sparkle, with a suggested link to download the daemon -- Max Howell

Joe clicks "Install Sparkle". iEye's Sparkle.framework springs into action and downloads the latest real copy of Sparkle—the framework is only a stub. It installs a preference pane and a daemon. iEye then registers itself with the daemon. Sparkle creates an CFURLAlias of iEye to keep track of it in case it moves.

The daemon then scans the system for Sparkle 1.x-based applications and registers each of them. And that's all that happens! No update-checking happens right now, as we have imposed on the user quite enough for now.

Sparkle2 will "just work" to support all Sparkle 1.x-based applications? If so, will it remove the SUCheckAtStartup item from the User Defaults of these apps? jerrykrinock

Yes. I'll probably support some kind of SUAntiSparkle2Override key, too, for people who've customized it or are using the framework unexpectedly or just hate Sparkle 2. —Andy Matuschak

But the daemon is still brooding in the background. Inevitably, it checks its registered applications for updates. If any of them have been updated, a Sparkle icon appears in the Dock, and Joe sees an interface very much like Apple's Software Update. It has very few features and very little UI. (mockups when I get time)

It may be worth, at this point, drawing a distinction between 'daemon' (a system service, running regardless of logged-in users) and 'agent' (a user service, running while the user is logged in, as the user). I think an agent would be far more appropriate than a daemon for this project.

The Sparkle Update Prompt

The top half of the window is a table view with updated applications displayed. There are check boxes for each determining if they should be updated, and all are checked by default.

A version can be skipped by selecting a row and pressing Delete or by clicking the Skip button at the far right of each row. If an update is skipped, and subsequent updates for that app will be unchecked by default until the user chooses to update it again. If an update to this application is the only available one, the Sparkle update window won't be triggered to display. If the only displayed update is skipped, the update window disappears.

Not sure why we need a Skip button. Just clicking the checkbox should be enough. Also, future updates should be automatically enabled again, unless the user has explicitly deactivated updating for that application in the preferences. Last, I'd suggest adding a lock icon for 'secure' (i.e. signed) updates. --AndreasM

Below the table view of updates is the release notes view. Joe is bored. Same old. Beneath that is a check box for "automatically install all updates in the future". Buttons are "Install Selected Updates" and "Remind Me Later".

Progress is displayed, et cetera. If an application is being updated that's currently running, Sparkle pops up an alert saying "iEye, iBuy, and iFoo are currently running. They will be updated when they exit." The daemon will keep a watchful eye and keep its promise. It is a trustworthy daemon.

The Sparkle Preference Pane

Most users will never want to change Sparkle's default behavior. But Joe is no ordinary user. He goes to the Sparkle preference pane, where he finds a view with two tabs: General Settings, and Applications. Also a big master switch like Time Machine's.

The General tab has a big Check Now button with a timestamp of the last check time. And a popup button with Daily (default), Nightly, and Weekly. And a check box for "automatically install all software updates." Joe is getting bored again. He clicks the Applications tab.

There's a big table of all the registered applications, with columns for icon, name, author, and current version. The last column is for "update action", which is a popup button with choices: [Ask Me (default), Always Install, and Ignore]. The last of these works like the skip button in the update alert.

The look of this preference pane should seem similar to that of Apple's Software Update. Along with the background updating should be a general update interface for all registered applications that is also similar to the Software Update program. It should also produce a log file of all the updates it's made, just the same way that the Software Update app does. Another tab would be added that display's this log.

Registration of Sparkle apps should be like that of Growl's, using physical ticket files stored in Sparkle's Application Suport->Tickets folder. That way we're not dealing with plist files for storing the Sparkle registration information.

More Cases

Joe launches iFoo, another Sparkle-enabled app. He sees nothing! It registers with the daemon behind the scenes.

In case you were curious, had Joe not been connected to the internet when he launched iEye for the second time, it would not have mentioned Sparkle. It would wait until the time was right.