Blog

Thoughts on Auto Save

Back in 2011, with Mac OS X Lion, Apple introduced a new autosaving document model. The concept was like this:

• all changes are to saved to disk as you edit a file (not necessarily at every keystroke, but every few seconds);

• since there would be no unsaved changes, there is no prompt asking you to save changes when closing a document;

• … except for untitled documents where the prompt ask you where you want to save them (with the option to not saved the document).

Also in Lion came Versions, a feature keeping a history of save points for your documents. With it, you can navigate through the older versions of a document in a Time Machine-like UI from the app which opens your document. The version history is used when you want to revert a document to what it was when you last opened it, or to its last explicit save point, in the new autosave model.

It turns out that I quite like the new autosaving document model. I think it makes more sense than the older one. But if you’re accustomed to the old one, I agree that it can be hard to adjust. For my part I’m well accustomed to the new behaviour now.

To me, interrupting the user every time he closes a window to ask whether the changes he just made need to be saved or forever forgotten is the ridiculous thing to do. How many times a user clicked the wrong button and lost hours of work? I know I did a few times. Better save now and let the user revert later if needed. I’m glad it works that way now.

It wasn’t always clear to me now why this document model was adopted. Some said it was to make it more like iOS, and perhaps it’s true to a certain extent. But I think now the more important reason would be to make seemless syncing between devices work as expected. If you wait for the user to explicitly save a document before syncing it to other devices, you’ll end up with conflicts. You need to have a single true version of the document; you can’t have various unsaved states on different devices that’ll conflict with each other when you try to save.

Imagine editing a document on your Mac, then later opening it on your iPad only to find out your recent changes aren’t there because you forgot to hit “save” on your Mac at home where the document is still open. If you do any edit on the iPad you know they’ll conflict with whatever was not saved at home and you’ll have some tedious manual merging to do. You’re stuck. The new document model, by always saving the current edited version to disk, makes conflicts much less likely.

That’s said, while I think the new autosave model is good, there’s a lot of things that could be improved in the surrounding parts.

A problem I see with the new model is that version management isn’t that well done. Currently you have to open the document and navigate through a Time Machine-like UI to revert to an older version. If you just want to make a copy of the old version of a document somewhere, the way to accomplish that is terrible. It’d be much better if the Finder could let you browse previous save points for a document (perhaps in the Get Info window?). It should also let you open those previous versions, copy them elsewhere, and delete the ones you no longer want. The side-by-side view within the app can be convenient at times but is also is a terrible at other times (such as when the app crashes when reading your corrupted document!).

Perhaps another thing that is confusing is that there is actually three modes right now: the old model (save/don’t save/cancel), the autosaving model one with no prompt, and the new autosaving model with a prompt (save/revert changes/cancel).

The optional prompt you can enable in System Preferences for the new model is a concession to those who like the older model. So why not just use the older model when that option is checked? Because the old model sucks with sync, and no one choosing that option wants to make syncing more difficult.

So today, on the same Mac, some apps may use the old model, some other will use the new model. And some apps let you choose between the two with a check box in their preferences. It is rather messy and is making things more complicated for users because not all developers are on board and not all users are happy with the new behaviour.

Here’s what I think should be done to improve the situation:

• Apple should improve version management by adding a version browser to the Finder, so that users don’t have to rely on apps to get to the previous version of a document.

• Apple should improve the in-app conflict resolution UI, perhaps by offering to enter a side-by-side mode (like the Versions browser) when a conflict occurs instead of just asking you which version you want to lose.

• App developers should adopt the new model for consistensy, perhaps with a preference option (such as the one found in Acorn) to choose between the two if deemed necessary¹.

I’m aware that enabling autosave in an app is more work for a developer than just flipping a switch. For one thing, the behaviour when attempting to edit a locked document can be particularily tricky in some cases. But think of it this way: it’ll have to be done eventually anyway, if only because more and more of your users will use iCloud or Dropbox to edit a document from more than one computer and will get caught in the unsaved changes trap. And as time passes more apps will use the new model and it’ll become more and more what the user expects.

And personally, I know I am more likely to like an app that doesn’t nag me with “You have unsaved changes” prompts. I can’t be the only one.

Xcode 6, XLIFF, and straight quotes

It’s a nice thing that Xcode 6 added better localization tools. With any Xcode project, you can now select the project file in the outline on the left and from the Editor menu choose Export for Localization… which will produce XLIFF files for each of the enabled localization. You can then send the files to those who will make the translation.

The export function grabs strings to translate from your Interface Builder and Storyboard files, but also directly from your code if you are using NSLocalizedString to get those strings:

NSLocalizedString(@"Grab Handle to Change Location", @"Tooltip");

It’ll also work with Swift:

NSLocalizedString("Grab Handle to Change Location", comment: "Tooltip")

Once you have the XLIFF files for each localization, translators for each language can edit them with an editor (such as Counterparts Lite), or they can edit the XML content themselves if they are confortable with that. You can then later import any changes made to those translations

But right now there’s a glaring bug in Xcode 6.1 that’ll make strings with straight quotes export as garbage in XLIFF files. So if you have this in your code:

NSLocalizedString(@"He said \"Hello!\"", @"Straight quotes test");

you’ll get incorrect strings when exporting for localization. If you import XLIFF files with straight quotes in your project, expect those to be mangled once you reexport them.

I would suggest the use “curly” quotes instead of "straight" ones. Actually, you should always use curly quotes: they’re prettier an more typographically correct, and your app will look better.

It Better Stands on Its Own

There is much speculation about an Apple wearable thing that might come up at the Apple event scheduled on September 9. Here is some speculation of my own.

There is one thing I’m pretty sure it won’t be: it won’t be an add-on device for an iPhone. Oh, I’m sure it’ll do cool tricks if you do happen to have an iPhone around, but if you can’t use the thing without an iPhone then it’s not a new product category, it’s just a new fancy iPhone accessory.

In other word, the main features must be self-contained within the device.

Displaying iOS notifications, while interesting, relegates the device to an accessory, so it can’t be the main feature. Same thing for a Siri button or a wirst-phone feature that’d use your iPhone as a conduit to the Internet.

So, if the main features have to stand on their own, here are a few novel possibilities based on what we more or less know Apple is working on these days:

1. A key to unlocking and switching on or off things nearby remotely, something that replaces your passwords and credentials when you’re in front of another device. A keychain of some sort.

2. As an extension to the above, a payment device that’d replace a debit or credit card but that is less ackward to wave around than a phone. Perhaps it could also let you give virtual money to someone nearby. A wallet of some sort.

3. A health monitor capable recording data from various sensors (some internal, some external) letting you know when something is anormal and giving some information to first responders in case of an emergency acting like a medical alert bracelet, but with much more data on it.

Note that none of these features requires internet connectivity to work. The wearable device only needs to talk with other devices which are close to you.

Other (secondary) features that’d be technically possible but that are either less impressive or not standalone:

• telling the time (obviously)
• play music
• notifications from your phone (if you have an iPhone on or beside you)
• Siri (again, you need your iPhone close by)
• wirst-phone (really, you need your iPhone close by!)

On thing I don’t expect is a full phone with cellular connectivity that doesn’t need to rely on a separate device (iPhone). It’s cool, in theory. Also it looks like Samsung just announced one (still no release date though), so it does not seem too far-fetched. But oh the poor battery!

If the thing only does Bluetooth LE — and perhaps NFC as some rumors seems to point to — radio signals aren’t going to eat the battery too fast. That’s all that’s needed for the features I mentioned above. That’s all you need to build a new product category.

Mac App Store Icons Messed Up

Today I released minor updates to Gamma Control and Counterparts Lite. After pushing the updates on the Mac App Store, I had the unpleasant surprise to see the two icons had been put on a black iOS-like round rectangle box. It looks ugly, not only because the icons aren’t designed to be in such a box, but also because of the lack of smoothing at the edges.

In truth, it looks like Apple is changing the image’s transparency mask to match what it should be on iOS, which is a perfectly reasonable thing to do for the iOS App Store but shouldn’t apply to icons on the Mac App Store. Browsing the Mac App Store seems to reveal a few more apps released today and yesterday with an out of place black box surrounding the icon.

If you are a developer, you might want to postpone your release until this is fixed to avoid showing your customers to show a hideous icon. I do hope this will solve itself without having to submit a new version of the app.

Note that this only affects the icon shown on the Mac App Store. Everything looks fine on iTunes Connect prior submission, and it doesn’t affect the icon of the app installed on a user’s computer.

(Added as issue #17841429 on Apple’s bug tracker.)