Archive for August, 2007

UI: Computers should be seen, not heard

Tuesday, August 21st, 2007

When I was a child, my father would quote the Victorian era expression “Small children should be seen, not heard” when I became overly boisterous. At that time I was not sure whether or not he meant it. I do however believe it should apply to computers…

Don’t put words in other people’s mouths!

Safari’s URL and form autocompletion really irritate me: they always add their guess to the end of what I’m typing a third of a second later. That means I press enter, only to find incorrect data was added to the field, and then submitted. Others have the same complaint. Nevertheless people do want some form of autocompletion.

For Find It! Keep It! I added an almost identical interface: the same popup window, the same use of up and down keys to choose, the same ability to click or double click on a choice, but crucially, you’re always in control. Nothing is added behind your cursor until you use the up and down keys to choose a selection. Type a new character in, and your selection is cleared.

Don’t just grab something that I was about to use!

Spotlight invariably updates its window the instant before I click the file I want to open, causing me to open the wrong thing.

A different solution is to use colour to show which page contain the search term. Although it does mean more information on the screen, it lets users click on pages as soon as the search term is found. That’s what I’m doing in Find It! Keep It! when searching pages by content.

Don’t jump up and down to get attention!

An application’s icon will bounce automatically when the application opens a modal panel if it is running in the background. It is possible for each application to remove this effect on a per-application basis. The problem then is that either one has to set a preference in each app to override default behaviour, or apps behave inconsistently. Apple could system wide preference for this to alleviate the problem.

Delay informing people about things until it’s relevant!

Software Updaters are another source of interruption that I don’t believe is necessary: as long as I don’t adversely notice the change when I use the tool, I don’t need to know that it’s updated the moment I use it. Web applications change constantly, but no one complains unless they stop working. Desktop applications will, I believe, adopt a similar model. How then, will the user know about the latest improvements? By email! People are in the mood for reading things when reading their email, not when working. Apple’s Software Updater is the worst in this category: it interrupts you and then asks you to drop everything and restart your computer.

Software should not behave like 3 year old children

It is difficult to hold a conversation when someone continually interrupts: one can’t organize one’s thoughts while being bombarded with new information. Using a computer is a similar situation. When the user talks, the computer should just listen.

Solving the evolving File Format problem

Tuesday, August 14th, 2007

Andy Matuschak brought up a really good obstacle to providing an easier upgrade and downgrade path for applications: changing file formats.

Changing file-formats is far from free. It fractures your user base as your users find they cannot share their documents with their friends. It makes it difficult for you to regression test your code. And it dissuades third parties from supporting your file-format, because you’re giving them more work each time you change. Overall changing file-formats should be avoided where possible. How then can you extend your application?

Future proof your file-formats!

I try to keep my file-format forwards compatible: the same file should work with older versions of my software. This makes it easier to find bugs that I may inadvertently have added: I can regression test against an older version of the software.

I use a file-format that lets the Application store but not use the fields it does not understand. There are many such solutions: SQLITE database, Trees, XML, python pickles… The reason to store fields one does not understand is that one can save them back out later.

For example consider an HTML document. Even if your HTML editor does not know what the “blink” tag means, it can remember the fact that that there is a “blink” tag around the text over there. Even if you edit the text within the blink tag, it can make reasonable guesses about grouping. Of course if you delete the text and type it back in, the blink tag will be gone. But most of the time you don’t just lose your formatting because a colleague used a different tool to edit your file. The key idea here is that you can use an extensible hierarchical data format to keep things associated with their attributes.

Keep the conversion code separate!

Sometimes, to simplify the main application’s code, it does makes sense to change file-formats. In that case, write a bidirectional converter. A version field in the file-format specifies (by naming convention) the converter to use so that the App when encountering a file of a different file-format can figure out the chain of conversions it must apply to get something it understands.

Now if you downgrade, you’re in almost the same position as your friend who never upgraded: your application can’t read the new format files. There is however a difference: as part of the upgrade process a bidirectional converter was added. It does not need to be removed on a downgrade. Because the the older version of the application knows how to figure out which converters to call, it will just find them and call them.

Note that because the original file-format is extensible, it’s possible for the bi-directional converter not to throw away any data. Similarly because the oldest version of the app stores the stuff it does not understand and saves it back out again, changes made by a co-worker with an older version of the software should cause little data loss.

Additional benefits of independent converters

Because you have independent converters you can earn bonus points with people who have not yet been able to upgrade. You can give or sell them the tool to convert the files. The tool can even advertise the features they’d get by upgrading.

You benefit because your code is simpler. The application code is simpler because it only knows its native file-format, the converter’s code is simpler because it’s focussed on one task. You also benefit because it’s easier to require a new base OS for your next version without fracturing your user-base.

Of course writing writing a converter is a pain, and a bidirectional one even more of a pain, but as I said in the beginning changing file formats should be avoided. Writing a bidirectional converter forces you to consider more cases, leading to a better upgrade converter. Furthermore you can reduce the pain for third parties by giving or licensing your converter to them.

What about standard file formats?

I think the same idea of independent converters can be applied, although it may not be possible to keep the additional information known to later versions of the file-format in earlier versions of the file format.

A better Software Update mechanism

Monday, August 13th, 2007

I’m using Sparkle to update Find It! Keep It!. It’s a state of the art desktop application update solution. It would however like to see some improvements.

What I don’t like about the current solution

Don’t interrupt me!

Sparkle asks whether you want to update the app when you start it. When someone opens his mouth, it’s not a good time to ask him something: he’s about to say something. Starting an app is the same.

Sparkle can also ask you whether you want to update the app when it’s running. That’s just plain rude: it could be interrupting the user’s thought process, especially as, IIRC, it causes the application’s icon to bounce if you’re using another app.

How am I supposed to know?

There is no way the user can know whether an upgrade will improve his experience, or waste time as he tries to recover his mistake. Asking can only make people feel stupid. Web Applications don’t ask. You get the upgrade, and you may not even notice.

Automatically upgrading software on other people’s computers could be a support nightmare, so it must be very easy to go back to where you were. Sparkle currently doesn’t provide a downgrade path.

Don’t make me wait!

Sparkle downloads the whole app on each update. For people on slower connections it’s noticeable and irritating. It would be better if the user didn’t notice it.

Overall impact

About 60% of my users seem to have disabled Sparkle. That’s a lot given that during the beta-test cycle, upgrades are not optional.

A solution

Transparent upgrades

Updates are small bidirectional binary diffs (created using bsdiff for example) that are downloaded in the background. To minimize user visible lag, they could be downloaded in small sections.

By default upgrades are applied silently at application startup, but the user can require a confirmation step using the Application’s Preference Panel.

In built version selector

The Application’s Preference Panel easily lets users switch back to an older version. It shows the version information for each version that Sparkle currently only shows when checking for a new update. Because each downloaded upgrade is a bidirectional diff, one can always downgrade.

Downgrade Appcasts

The Appcast Sparkle currently uses to inform the Application that an upgrade is available is enhanced so that a developer can correct an “Oops” by retracting a faulty upgrade. Adding this to the appcast protocol would be easy.


A small unchangeable harness is used to launch and monitor the App. If the app crashes on startup before the user could access the preference panel, it retracts any recent unproven upgrades and sends crash logs to the developer, after asking the user. Using a process to monitor another is extensively used for high reliability Telecom Systems: nine nines reliability (that’s 30ms downtime a year).

Growl and Email

If Growl is installed, it can be used to inform the user of the upgrade.

Generally however I think email is the most appropriate forum to inform the user of updates: one is more inclined to read information if one is not busy doing something else. Notice that even users who worry about providing their email addresses to the software developer can be catered for: the app itself can email the user with the information currently in the appcast when an upgrade has been downloaded.

Why I’m hoping Sparkle will implement this

I’m hoping the current Sparkle improvement discussion will consider and adopt this idea: Sparkle is already a standard, with tools like AppFresh supporting it.