When I first made the submission for AppMover, I was just trying to come up with an idea that solves a headache lots of Mac users face when they have two or more Mac systems: They’re never in sync. I’ve forced myself into a habit of tracking my new and changed files with Smart Folders, but that is a losing battle. Every time I change a setting in Keynote on my PowerBook, my iMac is blissfully ignorant of it. AppMover was dreamt up as a way to sync those files that are most troublesome to sync manually, the application preferences and settings. By this I meant search history in Safari, prediction models from Quicksilver, button settings for my Wacom tablet, junk mail filters from Mail, etc. (the features I know I’m changing day to day but have no idea where the associated file is). Once a sync is established, whenever the Macs are close to each other (either by Bonjour or network), they automatically sync. All the files are tagged with Time Machine, so you’ll be protected from accidental “upgrades” (when you sync a bad file and it overwrites the good one).
Ideally, I’d like a simple app that does all this as well as file and folder sync, but I didn’t want to get ahead of myself (feasibility of development is, after all, one of the judging criteria). Now that this idea has gotten past that first hurdle, all bets are off. I think we all know the Mac is ripe for an elegant synchronization app that is both separate from and more pervasive than .Mac Sync. AppMover should be able to take on more responsibility for general purpose syncing. Accommodating this means, at the very least, a name change. So AppMover will give way to Portal.
Portal will be changing a lot for its debut as a Finalist. Names will be changed, features expanded… Lots of stuff. The interface (which was strangely absent from the original idea) will finally start to take shape. Count on a healthy dose of “Wow Factor”. The basic premise stays the same: Files, folders, and applications you choose stay in perfect harmony between Macs, with minimal user interference (but bring on the Core Animation when a sync is initiated manually!).
Features:
From the user point of view, pretty much anything dragged into the interface will be kept in sync, no muss no fuss. Synchronization ‘under the hood’ will be broken into four categories: File specific, Folder specific, Application specific, and Search specific.
File specific sync: Tag files individually (or as groups) to be synced. That way, if a file name is changed, or if the file is moved to another folder, the two systems keep up to date. A file on the desktop of one might be in a nested folder on the other, for instance.
Folder specific sync: All files in the folder get synced to a matching folder on the second system. Moving files in or out of the folder adds or removes them from the sync profile. Folders can be moved or renamed however the user wants, on either system, without breaking the sync profile.
App specific sync: All files associated with a certain app get synced automatically (this would be all the preferences and such). All user files edited in a certain app could also be tagged for a sync (this would include all mail messages, iCal calendars, iChat logs, Keynote presentations, iTunes media, iPhoto media, etc.). Keep both instances of an application in perfect sync by default, but have the option of limiting the sync to just specific albums, mailboxes, etc. Miscellaneous system preferences, like your Keychain, Dock settings, etc. should also be selectable for sync.
Search specific sync: Using the same profile as the folder sync, but with Smart Folders. Any file that matches the search criteria ends up in the folder and gets synced. When the file no longer matches the criteria, it leaves the folder and is no longer synced. Useful for keeping all your project files in sync for just as long as you need them.
Technology:
Core Animation: From what little I’ve seen of this technology, I’m very impressed. Portal should be able to flex some serious graphics muscle if it wants. While normally I’d like Portal to be as passive and transparent as possible, there will be times when the user initiates syncs manually. In those cases, Portal should deliver the goods as far as interface “Wow Factor”. Several schemes should be available. My initial idea would be to have the files being synced (in miniature icon form) fly in from the edges of the screen, converge in a little tornado on top of the Portal window, and then fly offscreen to the one side. At the same time, Portal on the receiving Mac should duplicate the tornado coming in from a side of its screen. Then the tornado dies off and all the files gently get absorbed by the desktop. If an application is being synced, its icon will enjoy the ride from one Mac to another and, if possible, deposit itself onto its twin in the dock. If the tornado isn’t your thing, you might try a wormhole/Stargate version, with a semitransparent “tunnel” passing underneath the desktops of both Macs, with icons being sucked in one end and reappearing on the other (like the Genie minimizing effect used for the Dock, but with more of a fullscreen warping/flexing effect). This might even be a user plugin feature: make your own sync animation. If Core Animation is easy enough, it could happen.
Time Machine: This feature seems like the most common sense. Whenever a sync takes place and a file is overwritten, Time Machine should log the original file. That way, if you messed up your document during the day and the bad file accidentally overwrites the good file at home, you’re not lost. Logging these changes for applications, where the actual files that are being changed are hidden, would be an added feature. That way, some of the benefit of Time Machine will be passed on to apps written before the technology existed. Of course, once new apps start integrating this on their own, Portal will scale back its own backups. No sense burning too much disk space on redundant files.
Sync Services: Mac OS X has built in a decent amount of Sync features that might be easy to exploit for this app. I’m no developer, but it seems like a lot of the backbone of an application like Portal is already built into Cocoa. How easy it will be getting this framework to do what Gemini is designed to do is another question, but at least its not being written from scratch.
