One annoying thing about desktop UIs that has also appeared on touchscreen devices is the “verb then object” style of interaction, or what I call “ink dipping”. You pick a tool from some globally-positioned area (like a toolbar or palette), then move to where you actually want to use that tool – like having to periodically re-dip your pen in an inkwell. It requires a lot of unnecessary hand-movement, and breaks the idea of “direct interaction” to a certain degree.

On a touchscreen, you often have a simplified interface, with very few options, commands or tools. I was thinking about how to improve interaction in canvas-based applications (drawing, painting, charts, diagrams, etc), and it occurred to me that you often have fewer commonly-used tools than you have fingers. So, I created a UI concept/prototype that I call Finger Tools (or perhaps Touch Tools, or the Tool Glove, or some other such thing).

The Finger Tools concept is that your fingers are your tool-palette, so that useful tools and commands are literally always at your fingertips.

Here’s a video showing how it works, which you can also watch on YouTube:

Finger Tools are triggered by touch-holding for a period, or immediately by multi-touch interaction. That’s just my current testing setup; you could of course change the triggering mechanism to suit other situations. There are a couple of interesting points about this interface:

• Finger Tools are naturally ambidextrous, since tools trigger in priority order regardless of finger-position. Just use whichever hand you prefer.
• You can swap tools to ease manipulation. If you prefer (as I do) to use your index finger when dragging a tool to your target area, but that tool is attached to another finger, you can simply lift and then replace both fingers to swap tools between them. This is also a natural consequence of tools appearing in priority order.

Neither of the above features required any additional code; they’re inherent and deliberate benefits of the design.

There are still some rough areas, but I think it’s a promising concept. I plan to continue to develop it.

• Added the ability to put the Master after the Detail instead of before it (based on an idea by Marco Pifferi). It works for both orientations (i.e. Master to the left or right of Detail in landscape, and Master above or below Detail in portrait), and includes an animated toggling action for your convenience.

  Great for “list-below” portrait UIs (like Osfoora HD), or for making your Master-Detail interfaces easier to use for left-handed people!

• Fixed an exception raised when the delegate doesn’t add the popover’s associated UIBarButtonItem to a suitable bar, making the popover support now entirely optional (as it should be). Thanks to @pcwiz for reporting it.

There’s a new demo video embedded below, which you can also view on YouTube. It’s easier to see what’s going on if you watch it in HD.

If you make use of MGSplitViewController, a Paypal donation (or something from my Amazon.co.uk Wishlist) would be very much appreciated. Appropriate links can be found here.

I was made aware today of a glowing review of Favorites, and to celebrate I thought I’d give away some free copies. The promo codes below are valid for the US App Store (Apple only issues promo codes for the US store right now; as soon as that changes I’ll gladly issue some codes for other countries).

If you use a promo code, it would probably be helpful if you left a comment saying so, then I can cross it off the list. If all the codes have been used, remember that you can still buy a copy of Favorites for just $1.99 (or equivalent). I think it’s great value for money, and it all goes towards supporting nifty new apps, source code and so forth. It also comes with a free warm, fuzzy, righteous feeling (whilst supplies last).

I spent a lot of time on the user experience of Favorites, and I really hope you’ll enjoy using it. If you’re interested, you can read about what’s new in Favorites 1.1 (Retina Display support, multi-tasking, accessibility and more). If you’d like some code instead, you might be interested in MGImageUtilities, which provides image-scaling/cropping and tinting, ideal for support Retina Display devices in your own apps.

Without further ado, here are the promo codes; the scored-out/dimmed ones have already been claimed!

Update: all of the current batch of codes have been used – that was quick! Sorry if you missed out this time; if you’d still like to try Favorites, you could always buy a copy (for just $1.99)!

1. 9JF76Y6LMPJY
2. MNXTLJN4FL6N
3. 9J7KL69MFA34
4. ERNJJTLFMA6E
5. 4TRXFY677EJ4
6. EL9FKL34HYP3
7. RKYN36PRJY77
8. 3FKNHTL9Y4AR
9. N9HFTJEXNLRP
10. EYKL76TRTWKM
11. TJRHMPKH3TT9
12. FP73TYAWXFM7
13. Y4EFF3PJPMRX
14. Y9EP3F37J3F3
15. TL46FWLEJLHJ
16. 99KMJ4XLYLY6
17. AT4M6RTHXK9W
18. R4AWFKHEJLJ6
19. 99N4REFNMNXP
20. 9YXTRKM6JTWJ
21. YY73P44LF7XX
22. 67APK67FWMTL
23. FRXWM7XFR4JY
24. 3W3AELT9M6W9
25. YX6FERYT4LYY
26. XEJHA64HHNRK
27. 3RAMMNYAMMNY
28. WM3K9NALHRYY
29. PPTTH3H6676M
30. ANR6J74H7EAT

Remember that you can keep up to date by following me (@mattgemmell) on Twitter, or subscribing to this blog.

Enjoy using Favorites!

Here’s a demonstration video hosted on YouTube. It’s better if you watch it in full HD.

Donations

I wrote MGSplitViewController for my own use, but I’m making it available (as usual) for the benefit of the iOS developer community, because I care about this community and about the platform.

If you make use of MGSplitViewController, a Paypal donation (or something from my Amazon.co.uk Wishlist) would be very much appreciated. Appropriate links can be found here.

It’s taken a fair bit of work to refine the code to a flexible, reusable state, and I hope you’ll find it useful in your own projects. It’s my goal that it should save you many hours or days of work.

Features

Please note that, since split-views are commonly used for “Master-Detail” interfaces, I call the first sub-view the “master” and the second sub-view the “detail”.

• By default, MGSplitViewController mimics the appearance and (complete) behaviour of UISplitViewController, including its delegate API. It accepts two UIViewControllers (or subclasses thereof).
• Allows toggling the visibility of the master view in either interface-orientation; i.e. you can have master-detail or detail-only in either landscape and/or portrait orientations (independently, and/or interactively).
• Allows choosing whether the split orientation is vertical (i.e. left/right, like UISplitViewController), or horizontal (master above, and detail below). You can toggle between modes interactively, with animation.
• Allows choosing whether the master view is before (above, or to left of) the detail view, or after it (below, or to the right).
• Allows you to choose (and change) the position of the split, i.e. the relative sizes of the master and detail views.
• Allows you to enable dragging of the split/divider between the master and detail views, with optional constraining via a delegate method.
• Allows you to choose the width of the split between the master and detail views.
• Preset “divider styles“: one for non-draggable UISplitViewController-like dividers, and one for draggable, thicker style with a grip-strip.
• Allows you to substitute your own divider-view (an MGSplitDividerView subclass), used to draw the split between the master and detail views.

Getting the Code

MGSplitViewController is hosted on github, for ease of sharing; you can get the code here.

If you find it useful, it’d be much appreciated if you leave a comment to that effect here, and (ahem) note the Donations section above. Relax, that’s the last time I’ll mention it.

How to use

The “MGSplitViewController.h” header file (and the sample project) should be self-explanatory. It’s recommended that you use the project as a reference.

Interface Builder support

At time of writing, MGSplitViewController cannot be quite as elegantly visually configured like UISplitViewController using Interface Builder.

You can, however, (and it is recommended that you do) create an instance of it in a xib, and connect the masterViewController and detailViewController outlets to the required view-controllers.

License and Warranty

The license for the code is included with the project; it’s basically a BSD license with attribution.

You’re welcome to use it in commercial, closed-source, open source, free or any other kind of software, as long as you credit me appropriately. If you require a different open source license, please contact me (details below). If you need a license without the attribution requirement, a fee will be payable.

The MGSplitViewController code comes with no warranty of any kind. I hope it’ll be useful to you (it certainly is to me), but I make no guarantees regarding its functionality or otherwise.

Support / Contact / Bugs / Features

I can’t answer any questions about how to use the code, but I always welcome emails telling me that you’re using it, or just saying thanks.

If you create an app which uses the code, I’d also love to hear about it. You can find my contact details here.

Likewise, if you want to submit a feature request or bug report, feel free to get in touch. Better yet, fork the code and implement the feature/fix yourself, then submit a pull request.

You can keep up to date with what I’m working on by following me (@mattgemmell) on Twitter, and you can see my apps (or enquire about hiring me for your projects) at my business site, Instinctive Code.

Enjoy the code!

I’m very pleased with the Trackpad so far; it addresses the two major problems I’ve had with trackpads in the past: slow scrolling, and awkward dragging/text-selection.

Part 1:

(Or view it on youtube.)

Part 2:

(Or view it on youtube.)

And here’s another (silent) video showing how Magic Trackpad can do “pick up and move” mouse-like multi-stage drags, making it usable on any size of screen:

(Or view it on youtube.)

If you like stuff like this, you might want to keep up to date my following me (@mattgemmell) on Twitter.

I’d like to start by mentioning three very important new features (“tent-pegs”, if you will).

Multi-tasking

First up, Favorites has been compiled against the iOS 4 SDK, so it will participate in “multi-tasking”, i.e. it won’t need to launch from scratch each time you use it, and you can flip back and forth to it using the app switcher on iOS 4 (on supported devices, namely iPhone 3GS or iPhone 4).

That’s a minor thing in terms of effort on my part, but makes an enormous difference to actual day-to-day use.

Retina Display

Second, Favorites fully supports the new Retina Display on iPhone 4. All your contacts’ photos will be shown at the best possible resolution, and all of Favorites’ graphics, icons and drawing code have been updated appropriately.

It looks very, very nice on an iPhone 4; if you have one, you should give it a try. Here’s a (slightly scaled down!) preview:

Accessibility via VoiceOver

Thirdly, and this is the one I’m most proud of by a mile, Favorites is now fully accessible to blind and visually impaired users via VoiceOver, the accessibility technology built into iOS. All functionality of the app should be accessible, and I think it works pretty well.

I made a video discussing some of the new accessibility support; you can watch it on YouTube, and it’s also embedded below – it’s best if you watch it full-screen.

If you’re a visually impaired user and would like to provide feedback on Favorites’ accessibility support, get in touch via the contact page at Instinctive Code.

Other New Features

• New style of display for names, including larger, brighter text, and more sensible clipping of long names.
• During initial launch (which will be very rare on multi-tasking-capable devices running iOS 4), all contacts will show their names until their pictures have loaded.
• All of the Favorites settings which were previously in Settings.app are now also in Favorites itself.
• Wallpaper of your choice can now be shown behind the grid of favorites (this setting is only available inside Favorites itself, not in Settings.app).

Improvements

• Performance optimizations, particularly when dragging favorites around.
• Increased visual contrast for labels, button-borders, lists of phone-numbers/email-addresses, and more.
• Made the overlay action-button highlight colours more vivid and distinct.
• Favorites without pictures will now always show the person’s name, for easy identification.
• The label-editing view now opens automatically if a custom label is tapped and still has the default value.
• The info (“i”) button on the main screen is now easier to hit.
• Fixed an issue where contacts’ images could be incorrectly rotated on iOS 4 (often by ninety degrees counter-clockwise).

I really hope you’ll enjoy this new version of Favorites; Lauren and I (and thousands of others, I might add) use it every day. Every feature is there for a good reason (especially the absent features, like multiple pages of contacts). I find it a very quick, efficient and understandable way to contact my most frequently needed family members, friends and colleagues, and I don’t feel like I need to fight with Favorites as I sometimes do with the Phone app.

You can find out more at the Instinctive Code site or you can go directly to Favorites on the App Store. (Oh, and if you do enjoy it, feel free to share your thoughts via a review on the App Store. :)

If you need support with Favorites or want to request a feature or send feedback, you can either visit the support site at GetSatisfaction (preferred), or get in touch directly via the Instinctive Code site linked above.

Remember that you can also keep up to date by following me (mattgemmell) on Twitter.

There are three primary problems I face when talking about multi-touch gestures in documents:

1. Elaborateness. To visually describe a gesture, it’s fairly common to see actual life-like drawings of fingers and hands; that’s far too much trouble to sketch, and takes up too much room when reproduced. It also doesn’t scale to small sizes.
2. Verbosity. To instead textually describe a gesture, disproportionately many words are required: “double-tap-and-hold the object then drag to the right”. That’s tiring, and again takes up far too much room.
3. Ambiguity. There’s no absolutely standard mapping of terminology to gestures, so we’re faced with deciding whether we really want “swipe”, “flick” or something else, and whether the term will be understood later.

Such situations are usually helped by creating a formal terminology or notation of some kind, and indeed we all find ourselves doing so automatically and organically in our own notes. My own notation has developed over the course of a few months, and has stabilised sufficiently to be worth sharing; I find it very useful. Touch Notation’s purpose is to help me talk about and design features and interactions for touch-screen (and usually multi-touch) software.

That’s not all it’s useful for, though – I also use it to display gestural input in a concise, reference-suitable way. This usage is analogous to lists of keyboard shortcuts on the desktop, which make use of standard modifier-key symbols like Shift, Alt, Ctrl etc.

Touch Notation lets me make gestural-input “cheat sheets” for touch-screen apps just as easily as I can make lists of keyboard shortcuts for desktop apps. The goal is to provide one possible way of talking precisely and accurately (I hesitate to quite say “scientifically”) about touch-screen interaction. I thought it might be of interest to you too, so I’ve decided to share it.

Design Priorities

When developing the notation, my priorities were:

• It should be (relatively) easy to sketch quickly, and definitely easier than textual descriptions or finger-drawings.
• It should be scaleable, so it can be reproduced at any size (particularly at small sizes).
• Each symbol should be unambiguous within the set.
• We should prefer using the simplest, strongest forms for the most common gestures.
• All symbols should fit within constant vertical space, and have similar vertical visual weight.

These are simple, utilitarian and common-sense constraints, with an emphasis on making something that’s usable rather than conceptually perfect (which is almost always the right approach for anything).

Fingers vs Gestures

Before I list the symbols, I want to briefly mention the number of fingers issue. I’ve seen plenty of sketches and icons where, for example, a two-finger swipe-right is represented as two right-pointing arrows, one above the other. That’s fine in itself, but it completely breaks scaleability at small sizes – particularly if you’re requiring a four-finger swipe for some reason.

I wanted to avoid that problem with Touch Notation, so my approach was to separate the number of fingers from the gesture. After all, a tap is conceptually the same “gesture” whether you’re tapping with one finger or with two. I specify the number of fingers first (which is optional for the most common case of only one finger), then the actual gesture (with a gap between the two sections).

There are a few alternate notations I’ve experimented with for showing the number of fingers:

• Number Only. This is the one I actually use on a day-to-day basis, because it’s as simple as writing/typing a number.

• Number and Symbol. As with Number Only, but followed by a “Finger” symbol (shown below in the full list of symbols). Since the Finger symbol is a sort of vertical lozenge shape, you’d likely want to distinguish this from (say) the numeral 1 by using colour or some such thing.

• Multiple Symbols. No number, and instead repeating the Finger symbol the appropriate number of times.

It really depends what you find most useful or pleasing. There’s actually less visual ambiguity from the Finger symbol than you might think, since (for example) confusing it for the numeral 1 doesn’t change its meaning in isolation, and in Number and Symbol style you’re unlikely to think it’s an additional numeral 1 after the actual number because it’s very uncommon indeed to require a double-digits number of fingers to perform a gesture!

Personally, I find the Number Only style to be the easiest to write, and least visually ambiguous at smaller sizes. I’ll be using it in all the examples below.

Touch Notation Symbols

Here’s the full set of symbols, and their meanings.

Tap

A standard tap (and release).

Tap and Hold

A tap and hold for a moment (without releasing). This gesture is sometimes also called a long tap.

I deliberated for a while about whether this symbol should actually be Tap, and the solid circle be Tap and Hold (the hollow area representing releasing the tap, in that case), but I decided against it since Tap is by far the most common gesture and I wanted it to have as strong and simple a form as possible.

Swipe

A swipe or flick across the screen, usually with no particular origin. The arrow is rotated to indicate the actual direction of the swipe.

Rotate

A rotation gesture, involving at least two fingers.

Pinch Out

An expansion/pinch-out gesture, involving at least two (and usually exactly two) fingers.

It’s worth noting that the Pinch Out/In symbols are horizontal reflections of the fairly-standard “Enter/Exit Full Screen” icons used on Mac OS X and elsewhere. The context of use will remove any ambiguity, and the symbols are too meaningful to pass up on that basis alone.

Pinch In

A pinch (inwards) gesture, involving at least two (and usually exactly two) fingers.

Tap and Drag

A tap and then drag, without releasing and without any explicit pause between tapping and dragging. This is distinct from a Swipe in that a Tap and Drag usually has a specific origin point: the object you’re dragging.

Tap, Hold and Drag

A tap, hold for a moment, and then drag (commonly involving a transition in object-state after the hold period has elapsed).

Finger

The symbol for a finger, which can optionally be used when specifying the number of fingers required for a gesture (as described above).

Examples

Here are a few examples of using Touch Notation to encode various gestures. When I’m creating formal documents using Touch Notation, I tend to use black for the number of fingers and blue for the entire gestural part, just to give a subtle sense of energy and motion to the gesture. You’ll find that the gesture instructions in tutorials in the iPad versions of the iWork apps do the same thing.

• Tap (with 1 finger)

• Double-tap with 3 fingers

• Swipe right with 2 fingers

I find that the best way to read these gestures is to first read the black number, prepare that number of fingers, then follow along with the blue symbols of the gesture: “with this number of fingers, do that“.

Quantity Modifiers

I sometimes want to specify that, say, the user will tap and hold for two seconds, or will rotate for 45 degrees. I use leading or trailing numbers to indicate these situations, with the position of the number depending on the actual affinity of the value to the symbol. There are a couple of examples below.

• Tap and Hold for 2 seconds, then drag

• Tap and Hold (for some default period), then drag for 2 seconds

Sequential and Split Input

By default, since we’re dealing with multi-touch gestures, two consecutive tap symbols (for example) indicate performing two taps quickly, i.e. a double-tap. Sometimes, however, I want to express that the user should tap, wait a moment, then tap again – as two sequential gestures. I use the comma for this, since it has a fairly standard meaning of indicating a brief pause.

• Double Tap

• Tap, then Tap again

In touch-screen gestures, there’s also the (not so well-known) concept of a split tap; this is where you’re performing one action with one hand, and then (simultaneously) perform an action with the other hand, as a single gesture.

This is commonly used in VoiceOver, where for example the user can roll a finger over the keyboard until they hear that they’re arrived at the correct key, then tap a finger of their other hand anywhere on screen to enter that key. Split taps in VoiceOver allow for much easier text-entry where precision is only important for one hand.

I think the general concept of split input is interesting and useful, so I included it in the notation: I use a forward-slash to indicate the split. I don’t consider this to create ambiguity, since I only ever encode one gesture in a notation sequence, so I wouldn’t be using a forward-slash to mean “or”, as it can in English.

• Tap and Hold, then Drag, and then Tap elsewhere with another finger

Download your own set of Touch Notation symbols

I find this notation useful, and you’re welcome to use it too. If you use it anywhere other than in-house, I’d appreciate attribution. I’m offering a Photoshop (.psd) file containing each symbol as a Shape Layer (with all symbols at their original relative sizes), a Photoshop Custom Shapes (.csh) file so you can use Touch Notation in any Photoshop document, and also the original Illustrator (.ai) file I created the symbols in.

You can download Touch Notation here.

License info is included with the download; it’s a Creative Commons Attribution-ShareAlike license.

Oliver Toscan also made an OmniGraffle Stencil of the Touch Notation symbols; you can download it here.

Final Thoughts

I’ve found Touch Notation to be really useful in my own work; I just keep a quick symbol-reference around (though I rarely need to refer to it now) for when I’m sketching, and I’ll occasionally make formal lists of gestures for features electronically using the templates. I find that it has just the right balance of simplicity and expressiveness that I actually do use it.

I hope you find a use for it in your workflow, or at the very least get some value from comparing it to your own notation style; I always welcome any feedback you may have. If you’re feeling grateful/generous, feel free to take a look at my Amazon Wishlist, or the Paypal Donate link on my Cocoa Source Code page.

Remember that you can always keep up to date with what I’m doing by following me (mattgemmell) on Twitter. Now, back to work.

I use these in my visual speed-dial app, Favorites for iPhone, and I thought you might find them handy too.

UIImage+ProportionalFill

This category lets you resize an arbitrary image to fit into a specified physical size, using one of four resizing methods:

• Scale: scales the image proportionally to fit entirely into the required size, like UIViewContentModeScaleAspectFit.
• Crop: scales the image proportionally to completely fill the required size, cropping towards its center. This is the most useful method, and works like UIViewContentModeScaleAspectFill.
• Start: as for Crop, but crops towards the “start” of the image (the top or left, depending on relative aspect ratios).
• End: as for Crop, but crops towards the “end” of the image (the bottom or right, depending on relative aspect ratios).

This is very useful for caching on-screen-sized versions of images, and generating appropriate images for use on a Retina Display. I use it to appropriately resize photos (and many other things) throughout Favorites:

The category will do the right thing based on the image’s orientation metadata (like in photos taken with the iPhone’s camera, for example), and the scale factor of the device’s main screen (i.e. the resulting image will look as sharp as possible on high-resolution devices like an iPhone 4).

UIImage+Tint

This category takes an image (presumably flat and solid-coloured, like a toolbar icon), and fills its non-transparent pixels with a given colour. You can optionally also specify a fractional opacity at which to composite the original image over the colour-filled region, to give a tinting effect.

This is very useful for generating multiple different-coloured versions of the same image, for example ‘disabled’ or ‘highlighted’ states of the same basic image, without having to make (or update later!) multiple different-coloured bitmap image files. I use it to make the blue and grey versions of the badges in Favorites, for use in the editing UI:

Download the code

You can get MGImageUtilities on github. If you don’t know how to use git, just click the “Download Source” button near the top-right of the github page to download a local copy of the code as a zip or tar archive.

The categories are included in a demo app (for iPhone) which shows how to use them. Here’s a screenshot of the app running:

The license for the code is included with the project; it’s my usual BSD-like license with attribution.

I can’t answer any questions about how to use the code, but I always welcome emails telling me that you’re using it or just saying thanks. If you’re feeling grateful/generous, feel free to take a look at my Amazon Wishlist, or the Paypal Donate link on my Cocoa Source Code page.

Remember that you can always keep up to date with what I’m doing by following me (mattgemmell) on Twitter. I hope you find the code useful!

The entire workshop was recorded (both audio and video). I wore a mic, and there were several microphones and cameras around the room to capture the discussion which formed an essential part of the workshop. The workshop videos are now available here; they’re free to attendees, or you can buy them (4.5 hours of content) for $49.99. Whilst I do get some royalties, the main proceeds go to the Mac Developer Network to help support more developer podcasts, training materials and conferences in future.

You can read a synopsis of the workshop on the video page; we covered a lot of ground, and had some excellent discussion. It was split into two main parts: an initial 1-hour lecture on iPad application design with follow-up discussion, then a series of UI/UX/design questions submitted by attendees before the workshop, which we discussed as a group.

We discussed plenty of interesting material, and I think the videos represent the workshop well (I’ve watched the entire thing within the past few days). I hope you’ll enjoy them. Many thanks of course to Scotty, Dave and all the MDN/NSConference staff for making the event possible.

As usual, though, lots of companies get it subtly wrong, thinking that adding social functionality or a community aspect is enough. Social features aren’t a silver bullet; they’re actually sort of besides the point.

Games which automatically tweet your achievements are an example of such a ham-fisted, confused approach. That kind of thing irritates and alienates those you’re trying to attract, and indeed damages the reputation of your existing customers amongst their friends or peers. Sure, it gets eyeballs for a brief moment, but the fall-off and collateral damage are horrendous. People don’t share things that way; it’s not organic and it reeks of necktie-wearing sleazy marketeering.

Building in social features for their own sake isn’t a route to massive success. Anyone who tries to tell you that taking an arbitrary app and adding Twitter or Facebook integration (or adding a forum to your website, or adding a StumbleUpon or Digg link, or Reputations, or Medals, or global high scores) will automatically make your customer base mushroom, is guilty of either stupidity or downright dishonesty. It doesn’t work that way, because people don’t work that way.

Here’s the reality: people don’t just share things because they have the ability to do so. People share things they want others to experience. It’s about the thing, not about the sharing. I’m not sure how to make that more obvious.

You don’t succeed at social/viral marketing just because you make it a little easier to share, and nor do you succeed based on the raw, native appeal of the experience. Rather, it’s about shareability.

Shareability is the degree to which you want someone else to have the same response to a thing that you had. One company that understands this point is Apple. They don’t just make things that you want to have; they make things you want others to have too. Ditto for Nintendo, particularly with the Wii. And the real kicker is that their stuff is particularly easy for other people to experience, because it’s easier to use in the first place. So, it’s an easy decision to share it.

That’s why focusing on social features is a skewed approach; you’re targeting a possible means to an end, rather than the end itself. It’s a classic error; exactly the kind of strategy that comes from ponderous corporations, last-century thinking, and/or click-counting cynicism.

The problem is that you’re supplying the “how” for sharing, and neglecting the “why”. What you should be doing is spending all that energy (and every penny of that budget) designing an experience that doesn’t just benefit from the participation of others, nor even that requires others, but rather that your users will actually want others to enjoy. That’s the critical point. Write it down somewhere.

At this point, marketeers will talk about reducing barriers to sharing (they’ll likely use fashionable words like “friction” too), and how important that is. They’re wrong; it’s really not that important, because your customers will find a way. Seriously, do you doubt that for even a second?

Sharing doesn’t happen because you create the mechanism for it; it happens because you create the motivation. Indeed, when the users wants to share something, they will find a way to do so even if you haven’t provided one. So spend time on motivation, not mechanism. Don’t give money to people who claim to be able to “social-up” your arbitrary product; you’re doing it wrong.

If you want your customers to do your marketing, you need to be thinking about more than high-scores or ad-hoc network games or multiple user accounts. For real people, the key sharing motivator is joy; the natural human desire to share joy with people we care about. Apple has this down. Do you?

It’s not enough to be social; you need to be shareable.