But now you need people to buy it. You release a demo version of your software which allows your potential customers to get a feel for the app and decide whether it’s right for them, or not. And in doing so, you screw up the entire thing.

Where demos suck

It amazes me how many software companies get demo versions of their applications wrong. Demos aren’t a trial period for you of your users, but rather a trial period for your users of you and your software. And if you want to sell your app, you’d better make a good impression.

But time and time again, demo versions of applications aren’t done properly, and rather provide more friction for making sales than acting as a way of convincing your users that your software is worth them buying. Common areas where application demos fall down are:

1. You have to register an account to download the demo.
2. The emphasis is placed on purchasing the app rather than downloading it.
3. The demo places a crippling restriction on the software that doesn’t let you get a proper feel for it. For example, restricting major features.
4. There is a time limit on the demo which pressures users into purchasing the full version.
5. An annoying window prompting you to buy the app is displayed at frequent intervals.

All of these elements create a negative experience of you and your software, right from the very start. But what is it about some of these irritations that make such demos a bad experience for your users, and what are the alternatives?

1. Account registration

Everyone hates account registration. I – like most other people – already have too many online accounts, and to be quite honest, I don’t want any more.

But where this is even more of a problem for people who want to try out your apps before they buy is that you’re already putting rope around their neck. They may just want to try out your app but you are already asking them to make a partial commitment by signing up to try out the demo.

An example of this is with the FileMaker Pro trial download. Before you get a copy of the software to try out, you have to fill in a form, providing your name, address, operating system, and other market research questions such as how you heard about the product. This will be a huge turnoff for any potential customers because they will be less inclined to go through this entire process, just to see whether the application is something they’re interested in or not.

The solution to this problem is simple: don’t do it. On the main page for your app, place a prominent “Download” link which allows people to download your demo in one-click, no strings attached. This way they can see whether your software is relevant to them, without them feeling as if they’re being tied to anything.

2. Emphasis on buy, not try

Another problem with demo software is that the emphasis of the product is immediately placed on buying the software, not offering users to try it first. This ties in with making the users register to download the demo version first, or nagging for them to hand over their credit card details and is again, annoying because it ties them down and makes them feel that they are making a commitment rather than just trying out the software in their own time.

A good example of this being done well is on the Agile Web Solutions downloads page; it is clear that the focus of the section is downloading a demo version of the software to try out first, and not immediately placed on buying it, as shown by the prominence and alternate colour of the “Download Now” button compared to the “Buy It” button.

3. Crippling restrictions

Of course, some form of restriction needs to be placed on your demo applications so that people who have a genuine need or interest for your app can’t use it forever for free.

However, these crippling kinds of restrictions include things like restricting major features from the demo version, which is often counter-productive, because it doesn’t actually let your users see whether your software is right for them, since they don’t have access to certain features, which might be the main reason that they would be interested in using the full version.

Instead of imposing restrictions such as this on your demos, where possible it is better to provide some other restriction that allows your users to get a feel for the application, but perhaps provides an upper bound on their use of it. A good example of this is with LittleSnapper, which limits the number of images in your library in the demo version to 30, but so long as you have 30 or less images in your library you get access to all the other features available in the full version of the app.

From a business perspective, you want to make sure that the restriction you place means that people who are genuinely interested in using your software can’t do so forever without paying, but which doesn’t provide a barrier for those who aren’t yet sure to see whether the app is right for them.

4. Time restrictions

This is probably one of my main annoyances with demo applications – where time limits are imposed  on the use of the demo. The reason I find this such a turnoff is that it it similar to being sold something by a salesman on commission: there is constant pressure on you to purchase the full version rather than doing it in your own time.

Again, this seems attractive from the business side of software, and sometimes this may be appropriate, as there is no other justifiable alternative as a restriction on the demo, but this should only be used as a last resort.

And as Matt Gemmell suggested on one of the World According to Gemmell segments on the MDN show, if you are going to impose a time limit as a restriction, make sure that the time limit only applies to the days that the software is actually used. For example, if you impose a 30-day time limit and the user first uses the demo on the 1^st of the month, but doesn’t use it on the 2^nd, 3^rd or 4^th and comes back and uses it on the 5^th, only count that as 2 days of use, not 5.

5. Prompts to buy

This is probably my biggest annoyance of application demos: where they constantly nag you to purchase the full copy; be that on launch, on exit, or even just during use of the application, it’s a definite no and will not get me – and most other people, I imagine – on your good side.

As I mentioned earlier, application demos are a way for your users to decide whether your software is right for them, and whether it is worth their time (and money). But this is another really annoying feature of demos because it is again pressuring users to purchase your software, rather than letting them decide first whether it is right for them or not.

In this process, it provides your users with a negative experience, and pushes them in the opposite direction to buying your software.

Final word

Application demos are a way for the user to decide whether your software is right for them. It’s your one shot to impress them and convince them that your software is worth investing their time – in learning how to use the software – and money.

Although it might seem like a convenient excuse to offload a whole load of marketing onto your potential customers and pressuring them to make a purchase, this reflects badly on you, and if you offer multiple products they are unlikely to try out others if you create a bad first impression.

The key is to provide a user-friendly experience which portrays you and your software in a positive light; if the software is presented in this enticing manner and people have a genuine need or interest in your software then you are going to make some sales.

As developers, it is hard for us to detach ourselves from what we do and cater to the user. We live on the other side of the fence and are often restrained from making the right decisions because of the way we think, and usually need an objective opinion. We have the curse of knowledge by being so deeply focused in on our software, and what seems intuitive and easy for us is unlikely going to be the same for the people who use our creations.

Thinking from the user’s perspective

The amazing thing about a lot of usability and application design is that most decisions come down to simple thought of how your software is going to be used, and to anticipate and accommodate the user’s various needs. It’s about thinking “I shouldn’t put that text field there because the relation to that other form is confusing” or “I should relabel that button because the current label is misleading”.

As software developers, our main subjects are not computers (even though we do instruct them on what to do) but rather people. We have to be psychologists to some degree and accommodate their needs – our software of which is an end to a means.

The reality

As Matt stated on an earlier MDN show podcast, users want to spend as little time in an application as possible, so that they can get on with their lives. But because we have an affinity with the software we produce it is often hard to detach ourselves from the way we go about our business and think in this way.

Of course this doesn’t mean that we shouldn’t design and architect our applications in a maintainable way, and doesn’t mean that we should write crap code that looks like something the dog threw up. However bear in mind that the user doesn’t actually see any of this. To paraphrase Gemmell again, all the user sees of our applications is the interface.

At the end of the day, users couldn’t care less whether you have a PHP backend or the UI implemented using Rails; they have such a different perspective of what we create. What they care about is how your software solves their problem and how it makes their life easier by doing so.

The first day of NSConference 2010 kicked off with two workshops – Concurrency Programming on Snow Leopard by Drew McCormack, and The World According to Gemmell, by the Legend himself, of which I was an attendee.

The session started with a discussion about a certain recently released Apple product which was very interesting and allowed us to present our thoughts on the device. We covered such areas as the human psychology behind it, the display of “real” objects as the interface and the much more emphasised touch interaction including two-handed UI, as well as getting “wanky” about the emotional connection with the device.

Andy had also created a great model of the device, that was the exact dimensions (although the back didn’t slope like the real thing) and half the weight of an actual iPad. This was really useful in the talk from Matt, when he was explaining such things as how people would hold the device.

We also discussed the changing seeds of user interfaces and the switch away from clutter-based interfaces, such as inspector panels which ‘can edit anything that has ever lived’.

Our workshop

A few weeks ago Matt sent an email round to all the workshop attendees asking whether we had any UX topics that we wanted to discuss that could form the basis of the workshop. This was a great structure and in the session we got through 7 or 8 discrete topics, from such topics as the evolution of your app and removing features to when the best time to release your 1.0 is.

Although Gemmell said that he had put the slides together quickly and a bit haphazardly (and Scotty had been fiddling around with the slide animations*), the slides were well arranged, and contained only a few – although thought-provoking – bullet points for each topic, and allowed us to really discuss the ins and outs and how one would go about dealing with these problems. The workshop dynamic really helped this section and the group discussion bit was great as we could all have our opinions heard and commented on, with Matt being the suspiciously-bearded ringleader of the event.

Workshop dynamic

Matt’s talk was arranged as a workshop and consisted of around 30 people. The tables had also been arranged into groups of about 5 or 6 and all of this combined made a great, much more personal dynamic for the session, because as Matt himself put it, we were all participants and it was our workshop, not just his.

It was a great social occasion to this end, and allowed for group collaboration which was a real strength of the workshop and made it a really enjoyable event.

Final thoughts

A brilliant first day to NSConference and a great thought experiment with lots of things to take away and think about. As I mentioned when speaking to Matt in one of the breaks, the Mac/iPhone/iPad platforms are so brilliant partially due to the fusion and interwoven nature of code and design, the latter of which is given a lot of thought in most instances, which made the workshop a very topical and interesting one indeed.

The Mac conference (Monday 1st Jan – Tuesday 2nd Jan) has a lot to live up to but a great start to what I’m sure will be a great conference.

A flawed design

It’s a pretty common design in applications even today, although flawed. The problem is that it is often linked with a permanent, destructive action, and doesn’t take two important behaviours into account:

1. People don’t read
2. Humans being humans, we all make mistakes

It also offloads the responsibility of managing data – which often is important – to the user, and forces them to make a choice about what they want to do, a choice which often cannot be undone. But hang on, why should an action that I want to perform be completely, irreversibly destructive anyway? We have the Recycle Bin to provide a safety net for accidental deletion in the filesystem, so why shouldn’t closing a Word document without saving or unsubscribing from an RSS feed be reversible too?

Alongside this, the dialog is irritating in most situations:

1. “Why are you asking me this?! I clicked on the button because I wanted to perform the action… duh” – when we’re in a hurry and just want to delete something, we have to then go through another modal dialog to accomplish the action.
2. “Shiii- I needed that and I just clicked on Delete” – due to the fundamental flaw in nature of the design, it’s easy to accidentally go ahead with the action anyway.

A better design

I like the design that Gmail have implemented when you want to delete a message: the message is soft-deleted and a bar is displayed prominently notifying the user that a potentially destructive action has just taken place, but that it isn’t permanent and can be quickly undone by clicking the Undo button.

This is a great design because it caters for most use cases: if you want to quickly go through and delete messages, you can do without being inhibited by modal dialogs. However if you accidentally delete something that you don’t want to, the action can be easily reversed.

But people don’t like repetitive, boring tasks. And one of the areas where this is done especially poorly is when performing batch operations on large sets of data, where the user has to go through several stages to accomplish a task – each time for every item they want to perform the operation(s) on.

Dealing with multiple items

It really does amaze me how badly this is done with lots of services that are on offer, most of which play with large quantities of data – manipulating all of this can be something of a nightmare.

A great example of this is on Facebook. In the settings, there are a list of applications that you have granted privileges to – 85 in my case. What I want to do now is remove a load of these from this list. The procedure to do this is:

1. Click on the X in the right-hand corner.
2. Click on “Remove” in the are you sure..? dialog box (as a side note, the “Remove” button shouldn’t be the default option since it is a destructive action)
   
3. Click on OK in the confirmation dialog
   

For those who are mathematically inclined, you probably have guessed that to remove all 85 applications from the list takes 255 clicks (perhaps more taking into account accidental/mis-clicking). And guess what? There is no way of removing privileges from multiple applications at once.

This is when people don’t like clicking – when they have to perform batch operations by clicking the same things over and over again to do the same job on lots of items.

Solving the Problem

I feel that iTunes solves this problem very well when editing multiple items at once in the “Get Info” panel. The panel is generic and works with different kinds of media, and allows batch editing of all properties that are shared by items in the current selection, something which is very useful especially when dealing with large media libraries. This means that the user can change a load of common properties of items in their media library in one fell swoop, then go through and change the unique properties, such as song name afterwards.

Final word

When designing an interface that deals with lots of data, make sure you have a way of changing or removing multiple items at once, rather than the user having to repeat several actions for each item – something which becomes tedious very quickly, and means they have to waste more time dealing with fairly minor actions, rather than the main focus of your application.

It’s a fair enough dialog, I have been using free software which someone put their own time into and I’m appreciative, and might think of donating to the developer(s) who wrote it.

However, two fatal mistakes have been made here:

1. The “don’t show again” checkbox is unchecked by default:
   
2. The donate button is the default option:
   

From a business or financial perspective, that sounds brilliant. Prompt the user to give you money every time they close your app, because they’re probably going to forget to check the “don’t show again” box, and fortunately for you, if they happen to accidentally hit enter then they’re going to be taken straight to the donate page.

But in terms of establishing goodwill with your customers, it’s a horrible decision – the dialog is annoying, and this is only going to be a lingering annoyance if you repeatedly forget to check the “don’t show again” option – something fairly likely since it’s on application terminate when you generally want or need to get out of the application quickly.

You should always make sure that options such as this are safe and off by default – that is, that without any user intervention if they are prompted once for something that is an extra and something annoying, the option to turn it off is set to yes by default. By default, no stupid emails when registering for an online account, no annoying popup boxes or dialogs.

Be subtle

Of course it’s reasonable to have some form of link to donate to a product, or buy a full version or something similar. But if you’re going to have one be subtle about it. Put it in the about box or discreetly as a menu item, so that if users want to find out more they can do, but it’s not always glaring and in-your-face. I quite like how Viewfinder by Connected Flow does this on their demo version:

Granted it’s always there, but it’s a discreet message and in a small font, which isn’t particularly distracting and at the least doesn’t get in the user’s way.

Overall a winner

At the end of the day, if your app isn’t annoying and persistent about money, the good experience you give your customers will make them more likely to donate to your project. And if your product is commercial then you’ll give your users a better experience and mean that others are likely to purchase it based on the good things that people say about it.

After downloading the new Chrome beta for Mac OS X the first thing that struck me was how well it blended into the native Mac UI. The window takes on the standard OS X window appearance whilst working into it with the tabs which are built into the title bar. This wasn’t simply a port of the Windows version, it’s evident that time and effort has gone into making the app as Mac OS-native as possible, with the Preferences window and the keyboard shortcuts and so forth.

But the truth is that many software developers think they can invent a better UI than already exists.

One of the worst applications for OS X in terms of UI that I’ve come across recently has been the Paragon Talking Concise Oxford English Dictionary and Thesaurus. Reviewed by Mac Format, the actual functionality of the app seemed to be fairly average. But worse still, as concluded in the final rating was the “often awkward interface”. I don’t know about awkward, but I’d also add in damn-right ugly:

What I don’t understand is why the developers did this – what was so bad about the native OS X UI? It’s the classic example of reinventing the wheel when it didn’t need it, but which in this case was damaging since the reinvented UI looks pretty grim.

Especially if you’re porting your application, don’t make your application look identical on multiple platforms. Take the time to port it to the platform so that it fits in with that platform’s appearance and behaviour.

Creating your own UI or using that of another platform can distract users away from the actual functionality of the app because it looks alien compared to other applications on the platform; if it is behaviourally different then this also makes the app harder to use because then they have to deal with behaviours that they’re not used to.

If you want some custom control, then build into the existing UI and make it fit in.

Otherwise, the learning curve of using the new UI – which comes as cliff-like – is the main learning focus rather than learning to use the actual functionality of the app, the functionality being the reason why people buy the app in the first place, right?

Which can be changed to:

(Dependent on your level of stalkiness).

Being a moody teenager myself, I am, naturally in contact with.. A lot of moody teenagers. And there has been almost outrage over the new changes; groups with such titles as “i HATE THE NEW FACEBOOK!” rallying troops with motivational speeches including “i HATE HOW FACEBOOK HAS BECOME MORE CONFUSiNG, THEY ARE ADDiNG TOO MANY FEATUrES, PEOPLe CAN SEE YOUR EVERYMOVE…NOT A GOOD LOOK!!!!” have sprung up thick and fast (you’d perhaps be misguided that International Caps Lock Day is infact the twenty-third of October).

Although I find this very amusing, I can sympathise.

Of course changes have to be made to Facebook, otherwise it would remain like a stagnant pool for 10 years. And I’m sure they’re responding to user feedback and I’m sure in the long run it will improve the whole Facebook experience (although this particular update seems like a bit of candy to satisfy the kids).

But the way they’ve gone about it is terrible.

What is this? What can it do for me? Why the hell would I even want this?

were several questions that came through my mind, and where were the answers? Where was the explanation of how or why to use this? Nowhere. Users have basically been thrown into the deep end – accustomed to the “old” Facebook layout, this change has been sprung upon the site, and they don’t know what to do with it, how it works (initially) or why they would want to use this.

And this is not new. This has occurred several times with Facebook.

Joel Spolsky summarised this quite well on Episode #51 of the Stack Overflow podcast:

Spolsky: They’re gonna start, I mean, every time I changed a font, I could change a font on “Joel on Software” and get, you know, 30 angry emails, and then change it back and get another 30 angry emails, 25 of them from the same people that were upset the first time I changed them “ I just finally got used to that font that you changed”. And have to change it all over again.

And it’s because people don’t like to be somewhere they’re uncomfortable. They want to be familiar with their surroundings and know what to do and how to do it.

Not just cainophobia

By now you’ve probably come to the conclusion that users simply don’t like change. But this is an important thing to note. This is why designing UIs which are familiar to users is so important – UIs which reflect their mental model, which are consistent with other applications on the platform, which have workflows which are common and canonical are so important. Because if they aren’t, then you’re throwing your users into the deep end, and their experience will be so much worse.

And if it isn’t, make sure that an explanation is near – all you need is a small question mark icon, or a line of text which explains what something is, or perhaps a tooltip, such as those on Stack Overflow:

which will give your users confidence in what they’re doing and help them to do what they want to do.

And people like to complain about software. People moan about the price, the poor documentation (often with good reason) and the lack of enough features. But indecisiveness is engraved in our genes, too, since people moan when their software doesn’t work, then moan when they have to update it, or install the latest patch to make it work.

I admit that I have some sympathy, since the majority of most software updates are done poorly, and are something of an annoyance. User experience isn’t just about the software itself – it also encompasses the delivery and after-service of the product, and both of these are often implemented badly, with little consideration about the people who are going to use them.

A good software update process should be:

1. Unobtrusive
2. As frictionless as possible

But a lot of software updating mechanisms are bad. Here are the key offenders:

1. Timing

I think Joel Spolsky proposed this very well in his discussion with Jeff Atwood in episode #62 of the Stack Overflow podcast:

Spolsky: Well one thing that always bugged me about Firefox is that, my Firefox window is sitting there all day long, doing absolutely nothing, except for those few minutes of the day when I’m using it; and sometimes I really need to use it, so I launch Firefox, and at that exact moment it says “This would be the perfect time to do an upgrade!”

Atwood: Yes.

Spolsky: So it’s kind of weird. Like, why is it at startup it does the upgrade? How about at exit or at idle time or something – some time when I’m not using it. It picks the only time when it’s annoying, to do the upgrade.

I think this is perhaps the biggest bug-bears of software updates. Applications always seem to want to update themselves at the most inconvenient times. This principle of only updating at startup is actually proposed as the standard for Mac applications in the Apple Human Interface Guidelines (an article which provides guidance on developing software for OS X):

To provide a convenient application-update experience, follow these steps:

1. When your application fully launches the first time after installation, start a separate thread that checks for updates.
2. If a newer version is available, keep track of this fact in your application. Do not notify the user at this time.
   The next time your application launches, check the state of update availability you determined in step 2. If a newer version is available, immediately notify the user.
3. If a newer version is not available, start a separate thread to check for updates and keep track of the results in your application. Do not notify the user at this time.

Although I’ve expressed fairly positive feelings about the Apple Human Interface Guidelines I still don’t agree with this.

Apple’s argument for this method is to “avoid startling the user with unexpected and intrusive update notifications that occur outside the context of your running application” and to provide “an update notification consistently and immediately at launch time”. Although I can see where Apple are coming from to a degree, I think they’ve got it wrong. As Joel says, the best time to do an upgrade would be when the application is idle, and waiting until application startup to do the upgrade is in itself often an annoying interruption.

2. Restarting

One of the most irritating dialog boxes (perhaps of all time) is the “Please restart your computer to finish installing updates” dialog box:

It’s annoying because it’s obtrusive. People generally don’t want to quit all of their running applications, restart and then spend more time getting back into the flow of what they were doing again.

A well-designed software update process should work in such a way that the update does what it can do without restarting, then perform the required tasks when the user organically decides to restart at their convenience. If the application can update itself without restarting the entire operating system, even better. And reminding the user every 5 minutes or placing an annoying icon in the task bar can be somewhat irritating too.

3. Preserving Configuration

Although a fan of the Opera browser, when upgrading from the Opera 10 Beta to the Release Candidate, it decided to use my settings for the last stable version of Opera installed (9.64) and not the Beta, which I’d been using for a couple of months. The end result was that I lost a load of bookmarks and feeds which I had subscribed to during the period I was using the Beta. Let’s say I wasn’t too happy.

Preserving the configuration from the last version is a really important part of a good software update and helps to ensure that it is a seamless, frictionless transition. It also makes your users more willing to update if they know that their data is safe.

4. Automatic Updates

I have mixed feelings about automatic updates. On the one hand, they are really convenient, because they are silent and work in the background; however, you have to also “trust” the application at some level to be happy with it updating itself when necessary.

Also, you may not always want every update – patches and updates to improve security obviously have their attraction and are important and should be installed. However if it is an update to add some extra functionality or some plugin that I don’t need (for example Windows Vista Ultimate Extras), I wouldn’t necessarily install it.

A good way to provide a workaround is to categorise updates and provide different user-configurable automatic update settings for different categories – for example, I’d be happy to allow certain applications to automatically update themselves with security patches, but if there was an update that wasn’t strictly urgent or some kind of fix, then ask me whether I want to install it. This also removes some of the intrusiveness that most updates have. However, this method can be sketchy ground with some users, especially if enabled by default.

Final Thoughts

I don’t think software updating is taken into as much consideration as it should be. The application itself is not the only part of the experience that the user wants to be as frictionless as possible, and developing software which offers a good experience to the user also means taking both the preamble and the after-party into account.

Personally, for any document of considerable length which I will undoubtedly spend a fair amount of time reading, I prefer to have a physical copy to read than simply read on-screen:

Although at a modestly-sized 394-pages long (those pages are printed double-sided), I would highly recommend that any Mac developer or designer for the Mac platform read the Guidelines, if not in their entirety because they are such a valuable resource when designing applications.

The Human Interface Guidelines are split into several parts:

1. Application Design and Fundamentals: This section analyses what makes an effective interface which is both easy to use and attractive.
2. The Macintosh Experience: This section explains the design and environment of OS X and presents the integrated technologies that can be used by applications.
3. The Aqua Interface: This section is all about the Aqua Interface – the OS X user interface and behaviour of certain components such as windows and menus. It goes into considerable depth on a number of topics, such as icons, pointers and the controls provided by the Interface.

Déjà Vu

I am a strong advocate of consistency in applications across a platform, which is probably the biggest emphasis of the Human Interface Guidelines. This is so beneficial because in turn it leads to ease of use for users due to familiarity from other Mac applications. This is a massive plus, because it makes the application more intuitive and shallows the learning curve, which will make users more satisfied and provide them with a more painless, more enjoyable experience.

This main advantage, of course, stems other advantages from it, most of which are documented in the Introduction section:

• Users will be more at ease with your application because they have encountered similar workflows before, and so will learn how to use it faster and be able to accomplish tasks quicker.
• Documentation is easier because less has to be explained to the user.
• Application support is easier for the same reason.
• Users with disabilities will find it easier to use your application (there is a section about Universal Access in the Human Interface Design section).

At almost 400 pages long, the Guidelines are also very detailed, with information on some subjects which at first glance seem trivial. For example, the other day I was having a discussion about document icons (icons which show the user what application a document is associated with) on OS X and a contender’s suitability – and, low and behold, there is a detailed explanation about the role of Document Icons and how they should be designed, which I referred to:

Traditionally, a document icon looks like a piece of paper with its top-right corner folded down. As previously suggested, document icons should make it obvious which application they are associated with. Preview documents, for example, include a graphic of the media (the pictures) used in the application icon. For simplicity and to avoid confusing the document with the application itself, the viewing tool is not repeated in the document icon.

Document icons are presented as if they are hovering on the desktop, with the shadow behind the document. For more information, see “Icon Perspectives and Materials.”

When you want to put an identifying badge over a document icon, treat the badge as an integrated element within the document instead of putting it over the top of the base image and breaking out of the overall document shape.

There are also accompanying images to explain this.

Of course, there may be some debate about some of the items listed in the guidelines – and after all, as the name states, they are “guidelines” and not truly definitive. For example, in Updating Installed Applications in the section on Software Updates, the proposed method is as follows:

To provide a convenient application-update experience, follow these steps:

1. When your application fully launches the first time after installation, start a separate thread that checks for updates.
2. If a newer version is available, keep track of this fact in your application. Do not notify the user at this time.
3. The next time your application launches, check the state of update availability you determined in step 2. If a newer version is available, immediately notify the user.
   If a newer version is not available, start a separate thread to check for updates and keep track of the results in your application. Do not notify the user at this time.

Although I can see some of the advantages to this method, I am not in complete agreement – for example, what if the user rarely shuts down their computer and puts it to sleep? What if certain applications aren’t launched on a daily basis to check for/apply the updates? If the application is idle, why wait until the next application launch to perform an update when the user actually needs to use it? But although debatable, this depth of explanation also provides the consistency with other Mac software, and if adopted by applications, makes the whole user experience more seamless to the end user.

To Conclude

You can’t, of course, take everything the Guidelines state as gospel. All applications are different and there may be some cases where some of the proposed methods just don’t work, or don’t apply.

However, as guidelines on how to design great software for the Mac platform, I think the document is a very useful one. The level of detail that they go into is what makes the Human Interface Guidelines such a valuable resource – there really is an insistent emphasis on consistency and design so that the user is put first and helps to make the whole OS X experience more seamless and intuitive. And it is this collaborative effort and symbiosis by both Apple and Mac developers which make the platform a great experience.