Category: I-phone

The recently released Mac OS X 10.7 “Lion” (read my review of it at The Guardian) introduces Mission Control, an amalgamation of some of the functionality of Spaces and Exposé. Whilst it’s genuinely useful once you’re accustomed to it, it does hide away some of the previous functionality you might have relied on. This brief article describes how to restore some of the Spaces behaviour from Snow Leopard.

There are three main aspects of Snow Leopard’s Spaces behaviour that I use frequently:

1. Creating multiple Spaces (four, in my case) for various purposes.
2. Assigning certain apps to always open on a specified Space (and certain other apps to open on all Spaces).
3. Switching directly to a given Space using a keyboard shortcut.

All of this functionality remains available on Lion, but some of the settings have changed location. Let’s deal with the above points in order.

Creating multiple Spaces

On Lion, Spaces tend to instead be called Desktops, but I’ll continue to use the term Spaces in this article. To make more, enter Mission Control and hover your mouse over the top-right of the screen (or hold the option/alt key). You’ll see a “+” button, and you can click it to create a new Space.

You can also hover over any Space you’ve created (or again hold the option/alt key) to see a delete button, which you can use to delete that Space. You can only delete Spaces you’ve manually created.

Assigning apps to Spaces

Somewhat unusually, on Lion you assign apps to Spaces using the Dock. First, switch to the Space you want to assign an app to. Make sure the app is either running (and thus visible in the Dock) or has been added to the Dock. Then, right-click on its Dock icon and choose the “Options” submenu. You’ll see an “Assign To” section, where you can pin this app to either the current desktop (Space) or to all desktops.

The “None” option means that the app will simply open on whatever the current Space is when it’s launched.

Keyboard shortcuts for switching Spaces

You can still switch directly to a specific Space using the keyboard, but the setting is now in the Keyboard pane in System Preferences. Open that preference pane, then select “Mission Control” from the list in the “Keyboard Shortcuts” tab.

You can choose shortcuts for switching left and right by one Space, and for going directly to a specific numbered Space.

Hopefully these tips will make Lion’s implementation of multiple desktops a little more familiar.

I’ve also been tweeting extensively about Lion recently; you may want to follow me (@mattgemmell) on Twitter.

If you’re a developer of either Mac or iOS apps that use networking, there’s a new feature in the Developer Tools for Mac OS X 10.7 “Lion” (read my review of it at The Guardian) which will be useful to you. This brief article describes how it works.

In the Finder, take a look in the Utilities folder (Go menu, Utilities – or press Command Shift U). You should see a folder called “Network Link Conditioner”, which contains a preference pane for System Preferences.

I assume that this folder is installed by the (free) Developer Tools, because I didn’t find it on two other Lion-running Macs which didn’t have the Developer Tools installed. Double-click the prefpane file and authenticate to allow it to be installed. You’ll then see the pane in System Preferences.

You can choose from various different types of network conditions using the Profile popup menu.

You can also add profiles of your own by clicking Manage Profiles, either from scratch or via duplicating an existing profile.

Extremely handy for simulating less than optimal network conditions while testing an app. Just don’t forget to switch it off afterwards!

If you’re interested in more tips about OS X Lion, I’ve been tweeting extensively about it recently; you may want to follow me (@mattgemmell) on Twitter.

If you often need to search for certain patterns of text rather than exact, unchanging pieces of text, there’s a new feature in Mac OS X 10.7 “Lion” (read my review of it at The Guardian) which will be useful to you. This brief article describes how it works.

If you have Lion and want to follow along, you should launch the TextEdit application and type some text into a new document. Here’s the sample document I’ll be using:

Trigger the Find function by pressing Command-F, or by choosing “Find…” from the Find submenu of the Edit menu. A find bar will become visible at the top of your document. Click the magnifying glass in the find bar, and a menu will appear.

Choose the “Insert Pattern” option, and you’ll see a further popup menu listing several common patterns of text. Choose whichever patterns you like. In my example, I want to just get the raw email address from the document, so I’ve used the “Any” and “Email Address” patterns in that order, to grab both the text before each address, and the address itself. Any patterns you insert will automatically be colour-coded.

Next, make sure the Replace checkbox is checked, and you’ll see an extra field appear below the find bar, letting you enter text to replace the found patterns with. The “Insert Pattern” command works here too, and produces a slightly different set of options.

Notice how the colour of the replacement patterns in the menu match the colours of the pattern tokens in the find field. This is because, if you use one of those patterns in the replacement field, the actual text that matched that pattern will be inserted into the document. This is what makes pattern-based find and replace so useful and powerful.

In my example, I chose to replace the entire found text with just the email address that it contained, plus a line-break character – so that the end result would be a document containing just the email addresses, with one on each line.

You can experiment with the other patterns to see what’s possible. If you discover that your needs are more advanced than the patterns will allow, it’s worth knowing that these patterns are actually examples of a technology called regular expressions, and that many text editors on the Mac support them.

To learn more, you might want to read a tutorial on regular expressions, and then to find a text editor app that will let you use regular expressions natively (such as BBEdit). You could also search for info on grep, which lets you use regular expressions on the Unix command line.

Lastly, if you’re a Mac developer and you want to make use of this functionality in your own apps, here’s the relevant API documentation.

If you’re interested in more tips about OS X Lion, I’ve been tweeting extensively about it recently; you may want to follow me (@mattgemmell) on Twitter.

The recently released Mac OS X 10.7 “Lion” (read my review of it at The Guardian) adds a useful feature to the Spotlight menu, allowing inline Quick Look previews of the search results via both mouse and keyboard. This brief article describes how it works.

When you’ve entered a query into the Spotlight menu (you can trigger the menu by pressing Command-Space) and you’re viewing the list of results, you can trigger a Quick Look preview by either:

• Hovering the mouse pointer over any result, or;
• Holding the Command key for a moment.

Here’s what it looks like:

The preview popover will follow the selection in the menu, resizing itself appropriately, so you can easily trigger the preview then use the up- and down-arrow keys to skim through the results and find the item you’re looking for.

As an additional touch, when the preview popover is visible, holding the Command key will cause the content of the preview to shrink slightly, revealing a status display along its bottom edge. The display will continuously cycle between the full name and the location of the item (for examples, files will show their path, and emails will show their mailbox).

Yet another useful little improvement in the new version of OS X.

I’ve also been tweeting extensively about Lion recently; you may want to follow me (@mattgemmell) on Twitter.

The Financial Times recently launched their new web app, replacing their dedicated iPad app. It’s been widely speculated that this was in response to Apple’s (since relaxed) policy of not allowing publishers to offer cheaper subscriptions outside the App Store than they do within the Store itself, preventing those publishers from offsetting Apple’s margin-destroying 30% cut.

I contributed some thoughts on the relative advantages of both approaches (native app vs web app) to the lead news piece in the new issue of .Net magazine, and I’d like to talk a little more about the distinction between native and web apps from the user’s perspective.

The first thing to state is that this article isn’t about web technologies themselves. HTML5, CSS, JavaScript and so forth are all excellent technologies, and we all use web apps every day; the web is a thoroughly proven platform. Instead, this is about mobile devices, and our relationship with them.

When deciding how to build and deploy an app, web technologies provide many temptations:

• Working on every platform (inasmuch as that’s ever been true for web sites/apps; i.e. pretty much, but not completely, and with some effort).
• Being immediately updatable without waiting for approval.
• Having complete control of monetisation, including advertising.
• Being able to do all the tracking and data-gathering you want.
• Being insulated to some degree from the minutiae of rendering.

These advantages are tempting, and it’s easy to understand why we’ve see a proliferation of mobile web apps. There are, of course, disadvantages too, compared to native applications – but even this simple distinction is somewhat misleading. In fact, there are perhaps four different categories of app:

1. Web apps, explicitly running in a general-purpose browser.
2. Web apps, running in a dedicated browser and launched from a Home screen (appearing at first to be native apps).
3. Web apps, running within a web view inside a native app shell.
4. Fully native applications, without an HTML/CSS user interface.

These fall into two neat categories. Category A (types 1 and 2) run within a browser, and category B (types 3 and 4) run within, or are, native apps.

There are three primary problems with web apps as an alternative to native apps. Let’s talk about them individually.

Frames of Interaction

This issue applies to type 1 apps: true web apps, running explicitly within a browser.

The core of the problem is that computing devices are already task-compromised. We can perform tasks on devices, but we’re almost always making a compromise or allowance for the device. This isn’t just about the glib “my paperback’s battery never runs out” type of remark; it’s about the hindrances that come from apps being virtual entities within unrelated, unspecialised physical devices.

Yes, devices bring many unique and almost magical advantages (a thousand paperbacks within the physical size of one), but not without corresponding problems.

Here, for example, is a desktop calculator.

A calculator (photo by Paul Downey.)

It’s a tangible physical device, recognisable to most people (for now, at least), and with a single primary domain of functionality. We understand the discrete set of tasks we can perform with this device, and while using it we’re (by necessity) focused entirely on those tasks.

As a dedicated piece of hardware, it has one frame of interaction. You’re interacting directly.

Now, here’s a calculator app running (essentially full-screen) on a smartphone.

A calculator app, running on a phone.

Very similar, at first glance, to the dedicated hardware above – until your eye strays to what surrounds the calculator. We have a status bar, with signal strength, cellular carrier identification, network attachment indicators, the current time, and a battery charge indicator. Above that, we have a speaker and a camera. Below, a Home button. Surrounding the device, various other hardware buttons and ports.

None of those other things pertain to the calculator, because they’re part of the actual, underlying device – the smartphone. We have a second frame, surrounding and enclosing our primary area of focus.

Apps, by virtue of running on devices which we’re physically interacting with, have two frames of interaction: the app, and the device. You’re reaching through a window to do whatever you’re doing.

Finally, here’s a calculator web app, on the same device:

A calculator web app, running in a web browser, on a phone.

The calculator web app is running in the frontmost tab of a web browser app, which in turn is running on a smartphone. The device’s screen is no longer task-dedicated, but instead is conceptually split into the “content” (in this case, our task-specific web app), and the “chrome” – the actual interface of the web browser. The browser has an address bar, a search field, navigation and bookmarking controls, tab-switching UI and more – none of which has any meaningful or intrinsic relationship to the actual calculator we’re using.

A web app (frame 1) running within a browser app (frame 2) on a smartphone device (frame 3) has three frames of interaction. You’re reaching through a window, then putting your hands into a box, to perform your task.

Chrome has a cost (“chrome” in the generic sense; no disparagement of Google’s excellent browser is intended). The more interface you have visible, the higher the cognitive load on the user. When parts of that interface belong to entirely different, unrelated frames (or levels) of interaction, the load is high.

We can cope with a surprisingly high degree of interaction frames, but we’re not optimised for it. Try running an operating system within a virtual machine, and tell me you’ve never made an error of input scope, sending a command to the host instead of the guest system or vice versa. Web apps within browsers are essentially the same situation.

The nesting of interaction frames is uncomfortable in itself, but browsers also introduce an additional dimension (pun most definitely intended) of difficulty.

Separation of Concerns

This issue also corresponds to type 1, true web apps running in a browser.

Arguably (albeit humorously) excluding women, humans are designed to focus the majority of our attention on a single task at a time. Interfaces which permit and even encourage this separation of concerns reduce our stress level, and facilitate concentration. Many mobile devices use an interface design which enforces a “one app at a time” interaction model.

Even on devices like desktop computers, where history, experience, screen size and other factors make such a mandatory approach undesirable, there’s considerable effort being expended constantly on ways to reduce the number of things we have to focus on (and a thriving third-party software market offering solutions).

Our operating systems have become very proficient at allowing us to focus on one thing at a time. The concept of the frontmost application, for example, complete with a corresponding inactive state and appearance for non-frontmost windows, is ubiquitous. Window-management methods and technologies are myriad. Full-screen modes, the ability to minimise windows or completely hide running applications, virtual desktops and more all speak volumes about our wish to focus on single tasks.

The logical extension of task focus is task separation; the putting of things into places, for dedicated access and retrieval on a deliberate, controlled, organised basis. We all do it (to a greater or lesser extent) in our own homes, by assigning a particular cupboard to cleaning products, and a specific closet to towels or bed linen. A place for everything, and everything in its place.

This is critically important on computing devices, because doing a task electronically usually begins with a huge compromise: you’re using the same tool for every job. Consider these tasks, in their analogue, real-world forms:

• Writing a letter
• Reading a book
• Watching a movie
• Playing a game

All discrete tasks, with appropriate venues, tools/media, and styles of interaction. Now consider the digital equivalents – in every case, it’s a person sitting at a computer, or tapping on a device. There are many enormous advantages, of course; for example:

• Spell-checking of your letter, and sending it electronically.
• Immediate availability of your book, and the ability to look up words, or search the text.
• Watching movies anywhere you like, and being able to pause for a bathroom break.
• The many wonders of videogames, including online play with distant friends.

All well and good, and indeed wonderful. But we give up task-specific hardware, which our brains like so much. We introduce frames of interaction, and so we must then invent our many ways to re-separate those concerns within the virtual environment.

Now, consider modern web browsers. Multiple, independent web pages or apps, each in a tab or window of its own, but all gathered into a single app. Each page or web app is a third frame of interaction, beyond the browser itself and the device it runs on. Apps within an app; a computing environment within another. Suddenly our coping mechanisms of app-switching and so forth no longer work, or at best become poor imitations.

If your app is running within a web browser, it’s automatically victim to a second-order version of the fundamental compromise of computing devices: the violation of one tool per task.

No matter how commonplace and mundane computers have become, we still exist in a physical world – and our experience continues to teach us that the best tools are dedicated. Fundamentally, multi-purpose tends to mean multi-compromise. Indeed, in this case the compromise is almost fractal.

In some particularly egregious cases, such as sites which embed chat functionality into their pages alongside their main purpose, you have a fourth frame of interaction to deal with: the multiple “mini-apps”, within the web page, within the browser, running on the device. Our capacity for wilful focus, and our tolerance, has a limit. If your app approaches that limit more closely than another, you’ll lose users.

These are the disadvantages of engineer thinking about how to design an app, i.e. thinking mainly about technical feasibility rather than how the user feels.

We’re all guilty of ignoring the fact that the browser is not the same as the device itself. It’s another level in the hierarchy, and you can’t pretend otherwise.

System Integration

This issue applies to web apps in types 1 and 2, i.e. those that run within a generic browser application. To some extent, and depending on implementation, it may also apply to type 3 apps; web apps which run inside a dedicated native application wrapper.

With computing devices, the platform is king. Not the hardware (though Apple makes a tidy income from it), and certainly not the operating system itself (which is just a facilitating commodity). It’s all about what we like to call the ecosystem: the degree of external investment in the platform, in the form of everything from apps to compatible peripherals. The health of the ecosystem is the herald of a platform’s fortune.

It follows logically, then, that a platform provider will commercially want to tie customers to the platform as securely as possible. This means unique selling points, exclusive features, and native applications. The primary advantage of native applications (for both customers and developers) is integration with the platform. All those little things we take for granted, and miss when they’re not present. There are hundreds of examples, including:

• Having access to standard contact lists and calendars
• Participating in centralised notification systems
• Having data which is accessible through system-wide search facilities
• Responding to appropriate dedicated hardware controls, like music playback or volume buttons

The list goes on. These niceties are conveniences, but they’re also privileges – and the price of privilege here is to be native. Users want and to some extent expect these pieces of functionality, and native apps are the only type of apps with the ability to implement them. Web apps (for the most part) are forever locked out, because their domain is that of the browser, not the device which lives one frame of interaction above. This separation is self-imposed, and is often for very good reasons of security. A purgatory of choice.

Single-Site Browsers may initially look (to the user) like they’re dedicated apps, but it quickly becomes clear that they’re not, and that their sphere of influence is severely limited. App-wrappers (native apps which embed, for example, a WebKit view which runs a web app) are slightly better off; there are ways to bridge the two worlds of the web and the surrounding app, offering at least the potential for integration. But native apps, inevitably, need do far less work to integrate themselves with the user’s chosen environment.

We’ve already discussed the advantages of web apps, but the disadvantages are by now also manifest. It’s not just about technology, and certainly not just about economics. There’s psychology to consider, specifically psychological distance.

Apps feel designed. They feel tailored, and special. They’re lean-back, on-the-go, crafted, targeted things. The immediate extension of these properties is how at home they feel. We’ve all been pointing our fingers and hissing for years at the app that just wasn’t at home on our platform. An intruder in our midst, often from that worst of all possible worlds, cross-platform.

I said it wasn’t all about economics, but it’s also a bit about economics. Native apps are the fortune of an ecosystem, and thus of a platform. For that reason, native apps tend to get free marketing, both at the user level and at the platform-provider level – and that’s never been more important than on mobile devices. Apple’s walled garden is the sleek toyshop that’s already in your customer’s pocket, and they’re willing to put your app in the window once in a while if it’s good enough.

They’ll dip into your wallet for the privilege, of course, but it doesn’t change the fact that your vegetables are in the supermarket and your novel is in the bookshop. Do you really want to be left outside? Consider very carefully what you actually get for that thirty percent.

Conclusion

Each project must weigh up the relative merits of native and web apps for itself, but the inescapable fact is that when deploying on the web, from the user’s perspective, you’re probably starting with a disadvantage. There’s cognitive load associated with your app being a bookmark instead of an experience, and there’s an implicit trivialisation which occurs in the user’s mind. It’s unfair, but it’s a reality.

Many of the arguments I’ve seen that are pro-web tend to be technological arguments, and they’re maybe mostly true as far as they go. But consumers don’t buy based on quickness of updates, newness of technology, or whether their vendor is “in control” of the development process. Platform-agnosticism is part of your politics, not your customers’ buying decision. Users couldn’t care less, particularly non-technical users.

Instead, people want an experience that’s delightful, and tailored to what they want to do. Something dedicated, and designed. Something specific, and something special – and something that works with what they already have, without effort or aggravation. They want to hit a button and be subscribed, and wake up to a new issue waiting for them while the coffee machine is bubbling away.

You can do those things on the web, and you can even do them well. But when your goal is to make a mobile app that will delight, each technology path giveth just as it taketh away.

Be very sure you’re making your decision for the right reasons, and not beginning with an unnecessary compromise.

The standard and thus ubiquitous save sheets (document-modal dialogs) in Mac OS X have for years supported keyboard shortcuts for triggering the main buttons. With the release of Mac OS X 10.7 “Lion” yesterday (read my review of it at The Guardian), there are a few changes to those shortcuts. This brief article describes them.

Here’s how the standard save sheet (provided by the NSDocument architecture) looks on Snow Leopard:

The buttons can be triggered via the keyboard as follows:

• Save can be triggered with the Return key.
• Cancel can be triggered with either the Escape (Esc) key, or by pressing Command-Period (Command-fullstop).
• Don’t Save can be triggered with Command-D.

Things are slightly different in Lion. Here’s the new (combined) save sheet, as used by TextEdit:

The new keyboard shortcuts are more logical, more convenient, and safer.

• Save can be triggered with either the Return key, or by pressing Command-S.
• Cancel can be triggered with either the Escape (Esc) key, or by pressing Command-Period (Command-fullstop).
• Don’t Save can be triggered with Command-Backspace (the ‘delete’ key above the Return key).

Since the user will probably associate Command-S with saving (it triggers the Save menu command, after all), it makes sense to also assign that shortcut to the Save button within the sheet. However, that creates a problem: the previously-standard Command-D shortcut for “Don’t Save” puts two opposing commands on adjacent keys (since S and D are adjacent on a QWERTY keyboard).

It would be unacceptable to invite the inevitable physical slips this would cause, so “Don’t Save” is now triggered by Command-Backspace (which is an excellent shortcut, since not saving means your document’s contents will be deleted, in a sense, and hitting Command-Backspace is slightly more difficult than hitting Command-D).

Here’s hoping that apps which roll their own save dialogs/sheets will adopt Command-Backspace for “Don’t Save” soon. As I’ve said before at conferences and elsewhere, dangerous actions should be a little harder to perform than safe ones.

(I’ve also been tweeting extensively about Lion recently; you may want to follow me (@mattgemmell) on Twitter.)

Mac OS X 10.7 “Lion” was released yesterday (read my review of it at The Guardian), and one of the standard apps that has been most significantly updated is Mail.

Besides the visual overhaul, Mail also now supports a feature I’ve always enjoyed in Outlook: multiple different colours of flag with which to mark a message for follow-up. There are seven colours, and by default the flags are simply named after the colours (Red, Orange, etc). I prefer my flags to have more useful names, and thankfully you can change them. This brief article explains how.

You can set a flag (only one per message) when there’s a message selected in the message list. Simply choose a flag from the flag popup-menu in the toolbar (or from the Flag submenu of the Message menu on the main menubar), and your flag is applied.

To change the name of a flag, you first have to apply it to at least one message. The reason is that doing so causes a “Flagged” section to be visible in the Reminders area of the mailboxes list (you may have to show the mailboxes list too). You’ll see a smart mailbox named after each flag, which contains any suitably flagged messages.

Like most other mailboxes, these smart mailboxes can be renamed. Just right-click on the one you want to rename, and choose “Rename Mailbox…” from the contextual menu. Type the new name, and press Return.

Repeat the process for any other flags you’ve used, and you now have much more useful flag names.

The new names are remembered between launches of Mail, and also appear in the flag popup-menu on the toolbar, and in the Flag submenu of the Message menu.

That’s all there is to it. Enjoy!

(I’ve also been tweeting extensively about Lion recently; you may want to follow me (@mattgemmell) on Twitter.)

Just a quick note that I wrote The Guardian’s review of Mac OS X 10.7 Lion.

I feel terribly legitimate as a journalist now. (Remember that I continue to write for Tap! magazine each month too!)

I received an email recently with the subject:

"I wonder whether I might be able to ask you a question…"

It struck me as such a perfect example of a self-limiting email habit that I did actually read it. It was, of course, from a lovely person, who was extremely polite and who (as I eventually determined) had a technical query. If you’re that person, I hope you take this constructively, as intended.

I call this kind of email courtesy suicide, because the over-application of (what you think of as) courtesy will actually result in you not getting a reply. You’ve done two terrible things even before I consider reading your email:

1. Your subject doesn’t tell me what you want.

   I maintain a very popular blog (you’re reading it). I write for publications, including an actual paper magazine. I share a lot of code with the development community. I’m a speaker at conferences. I’m a freelance UX/UI/accessibility consultant and developer. Unsurprisingly, I get a lot of email.

   Please, please, help me to categorise it by using a subject which summarises the contents and purpose of the message.

2. You’ve made me work hard to understand you.

   Your email’s subject was hard to understand; this doesn’t bode well for the rest of the message, and my motivation to read it is already almost zero.

   You are sending me email. You should do the work beforehand to summarise and be succinct, to make the task of reading it as easy as possible. If you cannot be succinct, please don’t communicate with people. You’re a time-sink, and you’re getting in the way of better things.

Since this particular email was from a developer, and developers make up the bulk of my readership here, let me run through my mental parse-tree for the aforementioned email’s subject. It’s as follows, with my own thoughts as comments (i.e. beginning with “//”).

I wonder {

    whether I might {

        be able to {

            ask you a question… // You just did, despite lack of question mark.
                                  // It wasn’t a positive experience for me.

        } // You doubt your ability to ask a question?

    } // Is there some doubt as to whether you want to ask?

} // I see. Keep wondering. Let me know how that turns out. Or don’t.

It’s only 3 PM, and already I feel tired after reading your subject line. The email itself continues in this oh-so-courteous-and-circumspect way for several paragraphs, only reaching the actual topic about half-way through. For the record, the correct subject in this instance would be something like ”Question about performance of real-time data storage/retrieval in Cocoa”.

That subject may pique my interest, and it will certainly gain you some subconscious points as my brain breathes a sigh of relief at how easy it was to parse and categorise the message.

When writing email (or any other communication), by all means be courteous – but understand that the primary form of courtesy is to be considerate of others’ time. Excessive verbiage isn’t courtesy; it’s just waffling. Get to the bloody point.

It’s time that’s the limited resource. If you want me to give you mine, it’s best not to start by stealing some of it.

(If you enjoy a high wit-to-words ratio, you may enjoy following me, @mattgemmell, on Twitter.)

Solid-state drives (SSDs) are becoming commonplace, and the first time you use one as a boot drive, you realise why – they’re faster than hard drives to a ridiculous degree. The downside is they’re currently still very expensive compared to hard drives, such that only smaller capacities are currently affordable. Macs are now being offered with what I call ”mixed drive” configurations, including both a (small; often 256 GB) SSD and an HDD, and many people wonder how to make the most of this setup.

I have two SSD-equipped machines here, including a mixed-drive iMac, and have recently configured it in what I believe is a good compromise setup to take advantage of SSD speed without sacrificing the roomy storage of a hard drive (or causing excessive wear to the SSD). This is just one possible setup, but I hope it’s useful to you.

The basic approach here is to have the OS on the SSD (the default setup on mixed-drive Macs), and to move certain folders onto the hard drive, providing links to those folders in the places they used to be. Before beginning, let me try to pre-empt two possible comments:

“You can tell iTunes (etc) to keep its data elsewhere!”

Indeed you can (usually by holding the alt/option key whilst launching the app), but you’ll have to do it for each and every app that has such a capability – and some apps won’t let you. The method I’m about to describe, however, will just work, without changing any settings.

“You can put the home folder on the hard drive, and use the Accounts pane to point to it!”

That’s also true (unlock the Accounts pane, then right-click on your account in the list), but you’re losing the speed benefit of having certain parts of your home folder on the SSD (such as caches, preferences, your development projects and so forth).

It’s your choice if you want to use one of the above limited expedients, but I feel that you can find a better balance by doing just a little bit of extra work.

Copying and Linking folders on the HDD

With that all said, let’s offload some folders to the hard drive. It’s extremely easy to do, even though there’s a tiny, tiny bit of typing on the Terminal involved. If you’re scared of that, by all means run away now and get a friend to help. Also, make sure you have an up-to-date backup of your boot drive before beginning; that’s just common sense.

We’re really just going to be repeating the same process over and over, once for each folder that you want to live on the HDD instead of the SDD. The process is simply this:

1. In the Finder, copy the folder from the SSD to the HDD. Check that it was copied successfully.
2. In Terminal, cd to the location of the original folder (on the SSD), and delete it via sudo rm -rf foldername.
3. In Terminal, still in the location of the original folder you just deleted, make a link to the copy of the folder on the HDD, via ln -s /Volumes/HDDname/path/to/foldername.

(In steps 2 and 3 above, you should of course substitute the actual names and paths of the relevant folders and volume instead of ‘foldername’, ‘HDDname’, and ‘path/to/foldername’. Hopefully that’s obvious. For the ln command, think of the syntax as being “put a link here, that points to there”.)

That’s it. You’ll probably want to put all these copied folders somewhere sensible on the HDD; I created a folder called “matt” at the root of the HDD, and copied my folders into there – you can see a picture of it below. I’ve heard that you should not create a “Users” folder at the root of a non-boot disk, however.

You should also note that, if you’ve copied and linked one of the “special” folders in your home directory (such as Pictures), the new folder/link won’t have the special icon that the Finder usually provides. That’s normal, and completely harmless. You may also need to re-add the folder to the Finder’s sidebar.

There’s nothing else to it, except to decide which folders to actually offload.

Choosing which folders to put on the HDD

This is a personal decision, but generally you’ll want to offload folders that fit any of these criteria:

1. Are very large. Your SSD is small, and it shouldn’t be bursting at the seams.
2. Will change extremely often, particularly if they contain large files. SSDs are notably subject to wear, especially if they don’t support TRIM.
3. Contain files which aren’t involved in performance-critical work.

Try to keep in mind that the HDD is perfectly good enough for almost everything, and that we’ve been using HDDs for years. It’s not the poor cousin, and it hasn’t suddenly acquired the performance characteristics of a floppy disk drive. This is just about balance, and sensible optimisations to help get the most from the new SSD.

In my own case, I offloaded several of the folders in my home directory onto the HDD, as shown in the screenshot below.

Note that the Dropbox folder is created by the utility of the same name, and that the Backups folder is one I created for my own use.

In addition to those, as shown in the picture, I offloaded Downloads, Movies and Pictures. I don’t keep things permanently in my Downloads folder yet its contents change constantly, so it was an excellent candidate for offloading. I also don’t heavily use iPhoto or Aperture, and keep my graphic work files in my Documents folder, so I could offload Pictures. I don’t do any video editing, and have a large Movies folder, so I offloaded it too.

I did not offload the Music folder, but I did offload the actual media files (and mobile apps) that iTunes uses, as shown in the picture of my Music folder’s contents below.

Note that on your Mac, the “iTunes Music” folder may instead be called “iTunes Media”. The reason I didn’t offload the entire Music folder was to keep my GarageBand files on the SSD for performance, and nor did I offload the entire parent iTunes folder so that I could keep iTunes’ library and metadata files on the SSD for the same reason.

You may find that you’ll want to keep some of those folders on the SSD, and equally you may find that you want to offload additional folders to the HDD. For example, I also put my Virtual Machines folder on the HDD, and you might also want to put your Steam games there (they live in ~/Library/Application Support/Steam).

Just follow the same process as above, and you should be fine. It takes only a few minutes, and it should ensure that you get the maximum benefit from the SSD without being unduly hindered by its comparatively small capacity.

If you enjoyed this article, you may want to follow me (@mattgemmell) on Twitter, where I always announce new articles and projects. You may also want to read my biography, or hire me for your iPad, iPhone or Mac OS X app projects.

This article gives an ordered checklist of things to do (or think about) if you’re manually migrating to a new Mac. When I say “manually”, I mean not using Migration Assistant, or restoring from a clone or other backup. This is the first in a series of ‘Guide’ articles, giving advice for common and/or interesting situations you might encounter when using your Mac.

This checklist is for situations where you want to start fresh with a clean installation of OS X and just your essential apps and files, which can provide a general speed boost and may also be a useful preparation for a major new version of OS X (at time of writing, 10.7 Lion is just a few weeks away from release). You may find this approach particularly advantageous if you’re moving from a single-drive HDD-only machine to a dual-drive, SSD plus HDD setup. I’ve written a separate guide with some specifics on a good SSD plus HDD configuration which may be of interest.

Your situation and preferences will differ, but this should be of interest at least as a possible approach and a checklist of things to think about when making the move. I’ve written the checklist in what I believe to be a sensible order, letting you finish up with the old machine and move the new machine into place as we go. This guide assumes you have both the old and new machines in the same location, both powered up and running, and that you have at least a factory installation of Mac OS X on the new Mac.

Just a small warning to my regular readers: this isn’t a breezy, opinionated, entertaining article you can read with your coffee; you’ll probably only ever want to read this if you’re actually migrating to a new Mac. By all means plough ahead anyway if you want to, of course.

Things to have

If you’re extremely organised and are reading this before you’re ready to begin (or perhaps even before your new machine has arrived), you might want to make sure you have:

• An ethernet cable. Regular is fine; it doesn’t have to be crossover. Make sure it can reach between your old Mac and the new one, as you’ll at least temporarily have both sitting in close proximity.
• A multi-socket extension cord or cube, if you’ve run out of power sockets.
• A paper notepad and pen. There are always a few things it’ll be easier to scribble down and re-type.

If you’re going to be using Time Machine with the new Mac (and you should), I advise considering a Firewire 800 drive. It’s noticeably faster than USB2, and Time Machine can really drive you to distraction if the hourly backups are slow. If your Mac won’t arrive for a day or two, consider ordering one now.

When you have your Mac and the items listed above, let’s proceed.

Backup the old Mac

Hopefully, you already have a backup schedule, and you’re up to date. Even if you’re retiring the old Mac and keeping its contents intact, you’ll still want a full backup – the original copy doesn’t count as a backup, naturally. Furthermore, if you need to dip into your old files to get something you missed, it’ll be easier to do that from an external drive or from the cloud than to set up the old Mac again.

Time Machine is fine, but I also always keep a full clone of the internal drives; the app I use for this is SuperDuper. So, checklist points:

• Allow a full sync to your cloud services to occur on the old Mac. MobileMe, Dropbox, Google Calendar; whatever you use.
• Take a full backup of the internal hard drives, ideally bootable clones.

Initial setup of new Mac

• Make the most basic System Preferences settings that you need to be able to use the machine relatively comfortably, perhaps including:
  • Mouse or trackpad behaviour. Tap to click? Secondary click/tap? You’ll know what’s missing within the first couple of minutes.
  • Dock behaviour.
  • Full Keyboard Access, if your brain/fingers depend on it.

Most of the rest can wait for later. The only other really critical thing at this point is networking:

• Get onto your wi-fi network.
• Ensure your ethernet interface is a higher priority than the AirPort hardware.
• Set up the machine’s network name to suit your preferred naming scheme.
• Enable file sharing and perhaps screen sharing, at least temporarily.

Copy essential files

This is a clean build, so take this opportunity to be selective and trim down some of the clutter from the old Mac that you don’t need. The new build should have everything you need, and nothing you don’t; lean and fast. You’ll want to consider the folders below, and copy their contents into the same place in your account on the new Mac.

I recommend you directly connect the two machines via ethernet for the best transfer speed; use any old ethernet cable, and both Macs will auto-sense that they need to operate in crossover mode. You should also ensure that, when the ethernet cable is connected to both Macs, that Ethernet appears before AirPort (or Wi-Fi) in the list in the Network pane of System Preferences. This will mean that your Mac will prioritise that interface for copying the files. Mount your home directory from the new Mac (if you’ve enabled File Sharing on it) on the old Mac, and copy in batches. You may want:

• Documents folder.
  • Perhaps including any virtual machines you use.
• Music folder, for your iTunes library and GarageBand compositions.
• Pictures folder, if you have important photos and/or graphic work. Your iPhoto and Aperture libraries also live here.
• Remember to pick any anything on your Desktop.
• Movies, if you have a video or TV library. Your iMovie projects are here too.
• Depending on how you use it, you may want to copy some of the contents of your Downloads folder.
• Other home-level folders you may have:
  • Applications?
  • bin?
  • Development/Code, if you keep it there?
  • Anything application-specific that you need.
• Consider invisible files and folders. You can ignore most of it, but do strongly consider:
  • .ssh folder, for your keys.
  • configuration (and history) files pertaining to your preferred shell, such as .bash_profile and .bash_history.
  • any local repositories you may have, either for source control, command-line software installation, or such.
  • You can copy these files on the Terminal if you have the new Mac mounted; its mounted volumes are reachable in /Volumes.

If you have the patience, I also recommend taking a copy of your Library folder (from your home directory on the old Mac), and putting it on your new Mac – not in your new home directory, however. Just keep it someplace, as something to refer to and cherry-pick settings and configurations from as you go. Keep your lean, clean new Library folder, but have the old one around for a while – you’ll be amazed all the little things in there that you’ll probably want to grab, such as fonts, desktop pictures, sounds, Growl and Adium themes, and lots of other bits and pieces.

If you have a repository of your purchased serial numbers or licenses for apps which isn’t already included in the list above (or isn’t in your email), be sure to copy it over also.

Finally, you may want to take screenshots (or notes, either electronic or on paper) of relevant settings from the old machine that you’ll want to configure on the new one. There should be relatively few of these, but you may want to take special note of:

• Any special network settings you’re using, such as a fixed IP or custom DNS servers.
• Time Machine exclusions.
• Spotlight Privacy exclusions.
• Printers and Scanners, particularly for sharing.
• Any keyboard shortcuts you’ve added in the Keyboard pane of System Preferences.
• Settings pertaining to any third-party System Preferences panes you’ve installed. You’ll also want a list of such panes.
• Login items from the Accounts pane in System Preferences. A list of these can remind you what to install on the new Mac.
• Any custom status items you have installed in the menubar, and a note of which apps provide them.
• A screenshot of the contents of the Recent Items submenu in the Apple menu. It’ll make it easier to remember what apps are essential to reinstall on the new machine.

If you’re particularly fastidious and/or obsessive, you may also want to take screenshots of:

• The contents of your Dock, making note of the identity of any anonymous-looking folders and Stacks.
• The arrangement of files on your Desktop.

You’ll also probably want a copy of your user account photo/icon, unless you took a new one via the FaceTime camera on your new Mac during setup.

These should help you make yourself at home more quickly on the new machine.

It’s much easier to screenshot these than to try to extract them from mysterious configuration files later. Finally, unmount any shared volumes from the new Mac and disconnect the ethernet cable.

Prepare to wind down the old Mac

We’re nearly ready to switch off the old Mac, or at least move the new Mac into place to start building it into our primary machine. Some quick housekeeping tasks:

• If you’re retiring the old Mac, consider deactivating any automated backup systems, like Time Machine or scheduled clones.
• Consider de-authorising the machine for iTunes if you’re not going to have it running. You have a 5-machine limit per account, and you’ll need a slot for the new machine.

You can now shutdown your old Mac, disconnect peripherals, move the old Mac away, and prepare to move your new Mac into place. Take the opportunity to route power and connection cables even if you’re not actually setting up peripherals yet (we’ll do that later). If necessary, power the new Mac back on.

Continue setup of new Mac

Let’s proceed with setting up the new Mac. You can probably spend most of a day tweaking various settings, but for now, focus on the basics:

• Configure your cloud sync accounts (MobileMe etc) and allow them to proceed with an initial full sync.
• Configure your iTunes account, and authorise the computer. You have already copied your iTunes library; ensure it’s found.
• Configure sharing options to your liking.

Boot Camp partition

If you ever plan to use Boot Camp, now is the best and safest time to use Boot Camp Assistant to create a suitable partition. It’s non-destructive to existing partitions, and your machine is in a pristine state, so it’ll take only moments. You can create the partition and then quit Boot Camp Assistant, and go back later to actually install Windows. If your new Mac has multiple internal drives, Boot Camp Assistant will allow you to choose which one to partition for Windows.

The size is a personal decision; you’ll probably want a minimum of 60 GB or so unless you have an ultra-minimal need. For Windows 7 and a few big games and heavy apps, 100 GB is a good guideline size. If you’re a hardcore gamer planning to put a huge Steam library on it, you’ll want even more.

Connect and configure peripherals

It’s time to hook everything up to the new Mac. In the root of the boot drive you’ll find a folder (actually, an alias to a folder) containing various user guides, including one introducing you to your new machine. The guide is a fully resizable/scaleable PDF, and it includes diagrams of the various ports and connectors on your Mac. If you have a desktop Mac, it’s handy to zoom into those port diagrams and take a screenshot, so you have a reference card for when you’re fumbling behind the machine to find the right socket for a cable. I usually name the file “ports”, and put it in my Pictures folder; you can then pull it up by entering “ports” into Spotlight whenever you need it.

• Attach, power on and/or mount all relevant peripherals and drives.
• If you have network-attached devices, make sure they’re visible.
• Consider whether you need to re-share local devices to the network, like printers or scanners.
• Sync your iOS devices to the new Mac, allowing them to be backed up.

Install applications and utilities

This is the part that almost put you off making a clean, manual migration – installing your apps. My advice is to take a look at the screenshots of both your Dock and your Recent Items menu from the old Mac (you did take those, didn’t you?), and of course your status items. What constitutes an “essential” app will be different for everyone, but for my usual readership of developers and designers, you may wish to consider:

• Developer tools, such as your IDE and your favourite text editor(s) like BBEdit or TextMate.
• Graphic design tools, such as Adobe Creative Suite applications or otherwise.
• Your chosen virtualisation software, such as VMware Fusion or Parallels.
• Media-management applications, like Aperture or Lightroom.
• Productivity applications, such as iWork, Microsoft Office and the various Omni Group apps.
• Social media and messaging applications, like your email, IM and IRC apps, and Skype.
• Utilities like Growl, Printopia, Dropbox, Little Snitch, SuperDuper, VLC and so forth.
• Codecs, plugins and helpers, like Perian or Adobe Flash (boo!)
• Additional web browsers, like Chrome or Firefox.
• Steam, if you’re a gamer.
• Your preferred peer-to-peer networking applications.

Remember that if you’ve purchased software on the Mac App Store, you can re-download it to your new machine using the Purchased tab in the App Store app.

Once you’ve installed and re-registered everything, you’ll want to check for updates. Most apps will have their own internal update checking mechanism, but you’ll also want to check via:

• Software Update, in the Apple menu
• The Updates tab in the Mac App Store app
• Microsoft AutoUpdate, for Office
• Adobe Update Manager, for Creative Suite

That’s the most arduous part over.

Configure backups

Time to create a robust backup strategy. We’re professionals, and this isn’t optional. My recommendation is to have at least two forms of backup:

• Daily clones of the entire contents of your Mac’s internal drive(s).
• Hourly incremental backups via Time Machine.

For cloning, I use SuperDuper as mentioned previously, and a USB2 drive is more than sufficient. Make sure to set SuperDuper to Smart Update the clones, which means it’ll copy on what’s changed to create an up-to-date clone, not re-copying everything each time. You can of course use a Time Capsule or other NAS instead, in whatever disk configuration you prefer. For Time Machine, as previously stated, I strongly recommend a Firewire 800 drive instead of USB2.

If you’ve purchased or erased a large drive to use for backups, consider taking this opportunity to partition it. Some thoughts:

• Time Machine volumes should be as large as you can provide. TM gets slow when it has little free space, and more space means more backup versions being saved.
• Clone volumes should be no larger than the maximum capacity of the volume they’re cloning, naturally.
• It’s always very handy to have one or two smaller partitions for miscellaneous use. A 20 GB partition is very handy for running other versions of Mac OS X, for example.

Configure your clone(s) and schedule them to run when you won’t be using your machine heavily. Overnight is ideal, but dinnertime might be fine too. Consider leaving the machine on overnight at least for the initial full clone, which will be time-consuming. Set a reminder for the next morning to check that the clone(s) successfully completed, and at least weekly try to boot from them or otherwise check their integrity.

You should now connect and configure your Time Machine backups. For minimal intrusion each hour, and given that you have a nightly full clone anyway, you may wish to make some exclusions in the Time Machine options sheet. The specific exclusions are up to you, but you may want to consider some of the following:

• All volumes of your backup and cloning drives. These should be excluded automatically.
• /Applications (changes here will often be large, and will be caught by the nightly clone)
• ~/Library/Caches (frequent changes, which aren’t essential to keep)
• /Developer (trivial to recreate)
• ~/Downloads (very frequent changes, and often containing very temporary items)
• ~/Dropbox (this is already backed up in the cloud, by the very nature of how it works)
• ~/Library/FileSync (can have very frequent changes)
• ~/Music/iTunes/iTunes Music [sometimes “iTunes Media” instead] (caught by clone, and probably already on multiple devices)
• ~/Library/Logs (frequent changes, not usually essential)
• ~/Library/Mail (sometimes used for local caches of mail by some clients; presumably already online)
• ~/Documents/Microsoft User Data (can change frequently, and in large chunks, if you use Outlook or Entourage)
• ~/Movies (changes are often large, but you shouldn’t exclude it if you work in iMovie)
• ~/Documents/Virtual Machines [or wherever you keep VMs] (changes can be very large, depending on virtual disk schemes used)
• ~/Library/Application Support/Steam (the downloaded games are stored here, which can be very large indeed)

You may also want to consider online backups, or rotating your backup drives and storing non-active ones off-site. Be sure to pay attention to your workplace policy regarding the storage of data outside business premises if you do.

Lastly, be sure to exclude your clone (and probably Time Machine) volumes from Spotlight, using the Spotlight pane in System Preferences.

Install Windows on the Boot Camp partition

You can do this at any time, so feel free to leave it until later. When you do proceed, you’ll need:

• The Boot Camp installation instructions, either printed on paper (via Boot Camp Assistant) or electronically on another Mac or device.
• The installation media for a legal copy of Windows.
• Your Windows license key.
• Either the original Mac OS X installation DVD which came with your specific Mac, or a blank CD onto which Boot Camp Assistant will place some drivers.
• At least half an hour (often nearer an hour) of time without needing access to OS X on the machine.

Use Boot Camp Assistant to begin the Windows installation process, then follow the Windows setup instructions. Be very sure to follow the step regarding formatting the Boot Camp partition; it’s the only step which isn’t abundantly obvious from the on-screen instructions. In essence: tell the Windows setup wizard to format the “BOOTCAMP” partition; the default settings for that are fine.

Once Windows is installed, you’ll want to:

• Install the Boot Camp drivers from either your Mac OS X disc or the disc you burned from Boot Camp Assistant.
• Configure the screen-size, mouse/trackpad options etc appropriately (after the drivers have been installed).
• Allow Windows to update itself appropriately.
• Install some anti-virus/anti-malware software. Microsoft has a free one, for example.
• Configure Windows to your liking, including installing any apps or games you need.

Security

Common-sense tips:

• Ensure you’re using a strong password.
• Ensure auto-login is disabled.
• Configure File Vault, screen savers, password locking and the firewall to your taste.
• Consider installing remote monitoring software in case of theft. If this is a lab/classroom machine or similar, consider Apple Remote Desktop.
• Consider physical security. Do you need a Kensington lock cable, or similar system?

Health and safety

If this machine has a different form-factor and/or input devices than your previous Mac, consider ergonomics:

• Does your seat need to be adjusted?
• Do you need a wrist-rest of some kind, or to get rid of one?
• Is your line of sight to the screen still sensible?
• Does the machine need to be elevated to provide a comfortable viewing angle?
• Is the new total load on your desk within tolerances?

Also be sure to consider electrical safety:

• Is the Mac plugged into a surge-protected power brick?
• Do the premises have a master circuit-breaker or similar device?
• If the machine is not a laptop and/or requires to be permanently on, do you need an Uninterruptible Power Supply unit?

Warranty

If you purchased AppleCare cover, double-check that the machine is registered and that your coverage is active; you can do so on the Apple site using your Apple ID. Keep a copy of the Mac’s serial number (it’ll in About This Mac in the Apple menu if you click the OS X version number twice, and it’ll be on labels attached to the shipping box, and likely engraved or printed on the casing somewhere unobtrusive too). If you have a different warranty/coverage provider, ensure that they know about the new machine.

Insurance

Ensure that your new Mac is covered on your contents insurance for the premises. Make sure the monetary value and starting date are correct. Check if you need to pay an increased premium, and if so then ensure it’s paid.

Accounting

If the machine is for business use, make sure it’s logged as a capital expenditure in the appropriate tax year, so you can claim back a portion of the cost as a deduction. Consult your own local tax laws and a professional to help you with that if you’re unsure.

You’re done!

That should pretty much be it. Keep the old Mac around for a little while, and keep the box for the new one for a little while longer. If you’re storing the box somewhere that’s not easy to get to, first remove the installation and hardware test DVDs, and keep them near your desk. If you’ve upgraded the RAM on your Mac such that you no longer require the factory-installed chips, it can be wise to keep them around for a little while too, just in case.

Now go and enjoy the new machine.

If you enjoyed this article, you may want to follow me (@mattgemmell) on Twitter, where I always announce new articles and projects. You may also want to read my biography, or hire me for your iPad, iPhone or Mac OS X app projects.

There’s a widespread mistaken belief that ideas are the currency of creative people. The reality is, that particular currency is worthless.

An idea is the germ of something. Maybe it’s a painting, or a novel, or even a piece of software – but the idea without the execution is nothing. Indeed, having ideas is a natural state. Innovating is a natural occurrence. We’re faced with problems (existing, or entirely new), and we conceive of potential solutions. It’s how we deal with the world around us, and why we’ve reached this height of evolution.

But the ideas weren’t what mattered; it was the execution. The development of an idea (into a concept, or a prototype, or a finished piece of work) requires both skill and dedication. The real act of creation occurs after the idea state. Only in this act of creation can legitimacy be found. Real artists, as they say, ship.

People who make things, or Makers, contribute something to the universe. Makers are people like writers, musicians, artists, architects, software engineers, carpenters, and the chap at the coffee shop who makes your morning latte. He has a skill, and he applies it to create something that makes your day a little bit better.

There’s another type of person – I call these people Takers. Takers participate in the economy as money-handlers, exchanging currency on the back of others’ creations. They lend, and sell, and negotiate and manage. You can argue that these things are in themselves skills, and that’s true – but none are anything I’d aspire to as my productive output. They’re inherently ancillary occupations. They’re just not enough – for a Maker, at least. The question of sufficiency rarely occurs to the Taker.

There’s no rule that says you can’t be both; indeed, many who are Takers by necessity find a degree of personal salvation in also being Makers, even if it has to be in their evenings or weekends, in the upstairs office or out in the garage. For some, it can make daily life as a Taker bearable. For others, though, being a Taker is not only enough, but is all they aspire to.

If you’re making money from other people’s ideas, without creating anything, you’re accruing a debt. You’re a sinkhole in the system, into which value flows without any commensurate output. That’s not entrepreneurship, and if you even think it’s a business, then I have a queasy feeling about you. I imagine that your handshake is probably slippery.

Whilst there’s art in the development of an idea, and legitimacy in its execution, the ideas themselves are commonplace. Each idea is independently re-conceived every day. We’ve all had an idea, then found that we weren’t the first – the majority of all ideas are like that. The very concept of being the “first” to have an idea is highly questionable.

Our legal system does have to offer some protection of intellectual property as an incentive towards commercialisation, for the good of the economy. It’s important to realise, though, that the logical purpose of such protection is to enable and provide a return on investment; i.e. on the injected capital of invention. For software user interface or interaction concepts, it’s dubious what exactly the up-front investment actually is, much less the notional cost of development of the idea. With patented algorithms and interactions, there’s often so little difference between the concept itself, and the mechanics of its implementation, that they are virtually one and the same. The entire existence, much less the legitimacy, of the idea is in its execution. The product is the idea.

If you’re simply a commerce-enabler, then fundamentally you’re a Taker. That’s all well and good, and necessary, but you’re in an entirely different category of economics than the Makers, who actually create things. Your break room is down the hall. Your keys unlock a different set of doors.

If you want to contribute and innovate, do so within your commerce-enabling, ancillary, infrastructural field, and good luck to you. To attempt to pass yourself off as a Maker by selling someone else’s idea without doing any execution yourself is tantamount to intellectual fraud. At best, it’s the sleazy, greasy underside of Western capitalism. It’s not something I’d ever want my name associated with, or for my family to know about. I’d feel ashamed.

I use the services of Takers to the extent that it’s necessary, and accept the tacit crassness and unseemliness of the interaction as a cultural cost. I don’t think that it always has to, or will, be like this, but I accept it for now. When, however, I’m choosing who to spend time with, or seek inspiration from, or learn from, or adopt as a role model, I’m exclusively looking at Makers. The fire and water, rather than the mere pipework. The lightning, not the rod. Surround yourself with Makers.

Choose someone you admire or otherwise care about. Given knowledge of your motives, would they be genuinely proud of you in your work? That’s the test. What are you creating?

Are you a Maker, or only a Taker?

As I mentioned previously, NSConference 2011 was an incredible experience. I was fortunate to be invited once again as a speaker, and I’m happy to say that the session videos are now available.

My presentation was entitled “Making Really Annoying iOS Apps”, and it’s included in the video pack you can buy here (which includes our slides too). If you were at the conference, you should have received an email letting you download them for free.

Thanks to everyone who made NSConference 2011 such a success, and I hope to see you again next year! If you’d like to keep up to date in the meantime, I’m @mattgemmell on Twitter.

It’s been observed that there tends to be a strong correlation between obsessive/compulsive behaviour and technical proficiency as a software engineer. I wouldn’t argue with that. I try very hard to buck the trend of geeks being poorly-dressed, socially inept and having questionable personal hygiene habits, but I can’t deny that I do suffer from a little OCD (albeit not clinically). Icons on my desktop are, like Goldilocks’ porridge, just right – neither too big nor too small. And you’d better believe that they’re set to snap to grid.

I’ve noticed a further manifestation of this compulsive behaviour as regards installing software on my machines, and I’ve called it the Critical Customisation Cost (CCC, henceforth) of software. Put simply, there’s a cost (not just financial, but rather psychological and emotional) associated with installing third-party software on a computing device, and there’s an associated threshold above which the CCC is so high that it outweighs the benefit of the functionality offered by the software.

Geeks are known to love configuring and customising their devices, but perhaps paradoxically they can also be reluctant to do so because of a compulsion to not deviate too far from a “clean” (and thus presumably safe, fast, efficient, known and well-tested) configuration. If your app’s overall CCC is above a given geek’s tolerance threshold, they’re going to remove it from their machine soon after trying it.

My own CCC Threshold is something I struggle with daily. It’s surprisingly low; I desperately want to stick to the default setup on a new system, with just a minimal set of additional apps. I’m going to discuss some of the symptoms of this condition, and what tends to raise and lower the CCC of a given app, but if you can’t be bothered reading all that then I can offer you an executive summary: I’m incredibly clever and handsome, and you should give me money. If you’re not going to read the whole article, I feel entirely justified in misrepresenting its content.

Symptoms

I doubt that I’m alone in suffering from this condition. Perhaps you’ll recognise yourself in a few of these symptoms.

• Making unreasonable effort to live with default options and preferences.
• Returning to one of the factory-installed desktop wallpapers after only briefly trying a custom one, and repeating this process every two months.
• Automatically assessing a new piece of utility software based on whether you want to install it on all your machines, and learn it, and deal with the heartache of temporarily not having it when you get new hardware.
• Paradoxically (since that’s not the default behaviour) hiding the Dock because you can barely stomach its constantly-changing contents.
• Balking at an app because its menubar (status bar) icon isn’t monochrome, or generally homogeneous with the system-supplied icons (or, even worse, is confusingly similar to one of the standard ones).
• Irrationally quitting low-load, low-memory-usage apps when you won’t be using them for a short while, because that’s how you were raised.

That’s how you know you have it, but the details of how you assess a given app’s CCC are probably specific to you. I can only share the factors that increase or decrease the perceived cost of an app for me, as follows.

Things that increase the CCC of 3rd-party software:

Any of these factors will push a given piece of software ever closer to my CCC Threshold, and ultimate rejection.

• Having an installer. Depending on the app type (i.e. if it doesn’t seem reasonable for you to need an installer), this can be an instant Threshold-breaker.
• Adding a menubar icon.
• Adding a login item (not constantly visible, but nonetheless like a splinter in my brain).
• Being a utility-like app (i.e. not an app I’ll often have frontmost, but will instead use via ancillary UI or shortcuts) which is nevertheless in the app switcher all the time (this is nigh-guaranteed to break the Threshold).
• Auto-adding an icon to the Dock upon installation (instant Threshold-breaker; you’re gone, but update I do make allowances for Mac App Store apps here, albeit grudgingly).
• Adding anything onto my Desktop without asking me first, or even defaulting to doing so when you do ask me (this is also an instant Threshold breaker).
• Trying to actually replace a core part of the standard desktop experience (your file-browser/Finder replacement had better be amazing if it’s staying on my machine).
• Doing anything that feels like it uses hackery-pokery, or fragile/undocumented APIs, or that injects itself into system functionality. I’ve never found an Open/Save panel enhancement that I’ve been able to keep around, for example.
• Cosmetically altering the system. It’s unlikely I can live with that.
• Doing things substantially differently than is standard on the platform, especially with regard to UI conventions and/or widget appearance.
• Seeming to be something that will run periodically regardless of whether I’ve initiated it. I only tolerate Time Machine due to its obvious benefits. I balk at third-party scheduled sync solutions, folder-watchers, virus checkers and so forth for that very reason. And yes, I’m aware that all these can be and often are event-based anyway these days; nonetheless, the gut feeling remains.

Things that decrease the CCC:

• Letting me swap an always-in-the-app-switcher standard app for a small, unobtrusive menubar icon (e.g. Notify, instead of Mail).
• Letting me swap a system-supplied app for one with a more focused, efficient user experience but which accesses the same data (via an official API). Examples would be address book apps, calendars, etc.
• Being simply an interface to a remote data store, so I know I can access the data in other ways and from anywhere.
• Being a web app, for similar reasons to the previous point.

These rules change on a weekly basis as the mood suits me, but generally they’re indicative of how I’ll feel about a particular piece of software.

If your app’s Critical Customisation Cost reached my particular (low) tolerance Threshold, I can’t keep it around – it’ll drive me crazy. Does that mean that I, myself, am a little bit crazy? Yes, no doubt it does – but being unhealthily detail-oriented, rule-focused and meticulous does have its compensations in this line of work.

Last week I attended NSConference 2011, in Reading, England. NSConf (Twitter tag: #nsconf) has been a yearly event for me since it began in 2009, and this year’s was not only the best so far, but probably the best conference I’ve ever attended, on any topic.

It would be difficult not to enjoy the conference given the stellar line-up of speakers (disclosure: including yours truly), but this year there was really a sense of an event that had found its pace and natural rhythm; NSConf has clearly matured. I’ve been thinking about it for a few days to try and pin down what worked so well.

It was a combination of several factors:

• The universally high quality of the main presentations. Many of the speakers are old hands at conference/public speaking, but a few were relatively new to it, and held their own admirably. There wasn’t a single dud session, and I learned a huge amount.

• Ideal session length. Keynotes (each day) were 45 minutes, and all other sessions were 30 minutes, followed by 30-minute breaks (with post-session questions pushed into the breaks). You can say a considerable amount on a topic in 30 minutes, but it’s short enough to require effort and preparation to keep the presentation tight and coherent.

  Equally, having a full half hour between sessions not only allowed time to recharge, but also gave an opportunity to really discuss what we’d just heard. This 30-30 format felt like the perfect rhythm for a technical conference.

• Single-track. NSConference has one track, with sessions on diverse topics that are nevertheless short enough that no-one gets bored or feels they’re not spending their time optimally. Everyone has the same experience, and everyone can talk about what’s been presented that day. No compromises are necessary.

• Blitz talks were also excellent, and well-pitched. These were 15 minutes long, and took place during the 30-minute breaks between primary sessions. The topics were even more eclectic here, and gave an excellent chance for those who speak less often to address a smaller audience on a subject of interest to them. The personality of the conference really came across in these talks, and I loved every one I attended.

  On a personal note, I was especially pleased that my long-time friend Neil Inglis presented one of the blitz talks himself (an excellent session on incorporating advertising and affiliate links into your apps, which he absolutely nailed), and I hope he’ll consider doing so again in future.

• A balance between technical and UX material. This year’s conference really illustrated how UX and design matters have become first-class topics in our industry (particularly on the platforms we work with). We had design/concept/UX-focused talks from Mike Lee, Dave Wiskus, Cathy Shive, Aral Balkan (talk about a blockbuster line-up) and myself, and the audience were every bit as engaged as in the more technical sessions.

• A full-spectrum, end-to-end approach to software development – not just the technical (or UX) side – with best-in-class presenters. DeVoe on marketing. Hoctor on business. Jalkut on customer support. No-one needs to ask these guys for any credentials.

  Then throw in Dann waxing philosophical on method naming, Addey on VoiceOver (with audience participation), Kusterer on parsing, Lee on cryptographic storage, McCormack on Core Animation, Wheeler on Instruments, Zarra on asset caching and more… these are the all-stars you would wish for on each of these topics, and that’s the calibre of speakers that NSConf attracts.

  It was the fucking developer version of Live Aid.

• The social aspect of the conference was extremely effective. I’ve already mentioned the session-to-break ratio, but the venue itself (and its comparative isolation) made sure that everyone was together for meals, and critically during the evenings. It’s difficult to overstate how conducive the setup was to meeting colleagues and making friends.

• The labs. Whilst people were initially unsure what these would entail, the labs worked out extremely well. I ran the Design lab with Mike Lee and Dave Wiskus, and the format was that attendees would book a 20-minute slot, and arrive with something they wanted to talk about – often an design or idea, or even a running app – and some questions or problems. We’d sit down, one on one, and find solutions to those problems.

  People seemed to go away from the labs energised and excited, and often with a new perspective not just on the problems they’d brought but also on the focus of their app itself. It was a very rewarding experience for me, and I’m considering expanding my professional services in that direction too, on the strength of my NSConf experience.

Two of my esteemed colleagues from Tap! magazine, Chris Phin (editor) and Craig Grannell (contributing editor for games) also showed up on the Tuesday night to socialise and share some copies of the magazine, which was a very pleasant surprise. They’re fantastic chaps, and they care every bit as much about the Mac/iOS developer community as I do.

The main value of a technical conference for me isn’t the factual content or even the opportunity to socialise with my peers and learn about their interesting work, but rather the feeling you take away when you leave. NSConference for me has always been an opportunity to recharge my inspiration and excitement for doing what I do, and I’ve never left an event with such a buzz as I felt this year.

NSConference has unarguably hit its stride, and stands as the conference to beat in our industry. Huge congratulations should go to Scotty, Dave, Claire, Matt and everyone else for pulling it off.

I’m certain that next year’s event will sell out even more rapidly than it did this year, and I’ll be doing everything possible to make sure one of the tickets is mine.