Matt Gemmell

MGTileMenu

2012-05-14T09:00:00+01:00

I’m pleased to announce the release of MGTileMenu, an open source iOS GUI component providing a pop-up tile-based contextual menu. It’s designed for iOS 5, and uses ARC. It supports Retina and non-Retina devices, and works with VoiceOver. MGTileMenu is designed for use on iPad, but it will also work on iPhone and iPod touch.

MGTileMenu is released under an attribution license for free, and can also be licensed without the attribution requirement for a modest fee. MGTileMenu has no external dependencies. Here’s how it looks, at full Retina resolution:

MGTileMenu

Tile menus show five icon-tiles per ‘page’, with a sixth page-switching tile (“…”) used to switch to successive pages of tiles. You can have any number of pages of tiles. Here’s a demo movie of it in action:

Demo video of MGTileMenu

(Watch it on YouTube)

The placement of the page-switching tile depends on whether MGTileMenu is configured to be right-handed (the default) or left-handed, and will leave a gap for your finger in each case.

You can extensively configure MGTileMenu’s behaviour and appearance. There’s a delegate protocol to supply tile icons, and to customise tile backgrounds (with images, gradients or flat colours).

Emoticons menu

MGTileMenu also posts various notifications which may be useful. Naturally, it uses Core Animation extensively for a pleasant interaction experience.

MGTileMenu is designed with convenience in mind. Its default appearance and behaviour have been configured to suit most situations, and it will try to behave intelligently to minimise the work you have to do when using it (for example, it will sanity-check and adjust the position you tell it to display at, to ensure it’s fully visible, and will move to remain visible when the device rotates).

The controller’s own properties and methods, and the delegate protocol, have similarly been designed for maximum convenience. You should find MGTileMenu very easy to integrate and use, with minimal additional effort.

MGTileMenu includes a demo application, showing how to create and configure an example menu. In the demo application, you trigger a tile menu by double-tapping anywhere, but you’re naturally free to trigger MGTileMenu however you wish in your own code.

License and donations

MGTileMenu is released under its own attribution license (which is included with the source code). I’ve created and released this component, like all my other code, for the benefit of the iOS and Mac development community that I’m proud to be a part of.

I hope you’ll choose to support future code releases (and this blog) by making a donation, or buying a non-attribution license for the code.

If you find the code useful, you have the option of making a donation to support my work, which would be very much appreciated. You can do so via the button below, or directly to my PayPal email address (matt.gemmell at Gmail). I’d very much appreciate it, and it will go fully back into supporting future articles and code releases.

If you don’t want to (or cannot) provide attribution in your app, you can purchase a non-attribution license via my online license store.

Thanks for your support!

Downloading the code

You can get MGTileMenu on github.

Support, bugs and feature requests

There is absolutely no support offered with this component. You’re on your own! If you want to submit a feature request, please do so via the issue tracker on github.

If you want to submit a bug report, please also do so via the issue tracker, including a diagnosis of the problem and a suggested fix (in code). If you’re using MGTileMenu, you’re a developer - so I expect you to do your homework and provide a fix along with each bug report. You can also submit pull requests or patches.

Please don’t submit bug reports without a diagnosis and a fix!

Designing MGTileMenu

MGTileMenu was created as a way to show options or tools contextually, wherever your hand might be on the iPad’s screen. It’s for use in an app that I’m working on, and I thought it was worth releasing as a useful component.

I’d already experimented with a contextual tool interface that associates tools separately to each finger, but I wanted something much more conventional, less intimidating, and physically easier to operate/

My initial sketch of the tile idea in my notebook is below.

Initial sketch

As you can see, the final control follows the sketch very closely. With only that single sketch and a couple of notes, I started creating a mockup in Photoshop. This is the first version:

First mockup

The tiles are exactly the same size as app icons on the iPad’s Home screen, which provides a sensible consistency and presumably capitalises on Apple’s own research and testing. Believe it or not, the identical size was actually a happy coincidence: the first rounded-rectangle I drew by eye in Photoshop turned out to match iPad app icons to the pixel.

Having made the mockup, I felt there was something visually missing; the tiles needed something to unify them. A bezel seemed like a reasonable choice, so I started experimenting with the concept.

Round bezel with struts

The round bezel looked fragile to me, and didn’t really reflect the grid-based layout of the tiles (it made me want to pull the corner-tiles inwards, breaking the visual stability of the menu). The ‘spokes’ (radial lines) also looked too busy, and created a strange association between the tiles and the Close button. The lines had to go.

Encompassing bezel

My next try was a round-cornered bezel that I was much happier with, fully encompassing all of the tiles. It wasn’t bad, but it looked heavy and a bit static and boring. I wanted the menu to appear more dynamic, to match the Core Animation features I planned to add.

Final design

Trimming down the size of the bezel provided me with the final look. It still unifies the tiles and provides a ground for the Close button, but the fact that the tiles overhang the bezel’s edges looks more interesting and funky, to my eye.

I implemented the control to match the final concept. Here’s a screenshot of an actual MGTileMenu in action, using its default tile-background appearance:

Tile menu default appearance

And here’s a tile menu with some more colourful backgrounds, and one fewer tile.

MGTileMenu, page 2

I’m really pleased with how the appearance turned out; I think it’s a nifty, flexible, inviting control. The next step was to think about the interaction and animation.

Interaction design

I was very keen on the idea of making at least a nod towards the user’s preferred handedness. I placed my hands on the iPad’s screen and saw that we naturally tend to angle our wrists inwards, thus causing our pointing finger to have a diagonal rather than vertical profile against the screen.

A one-tile gap thus didn’t seem like enough, since in most cases the user’s finger would still partially obscure either the lower-left (for left-handed people) or lower-right (right-handed) tile. I decided on a two-tile gap, to give more room.

Configurable Handedness

The gap also has the pleasant effect of reducing the number of tiles visible, which I hope will nudge developers towards having fewer options available in their apps that use the control.

I chose not to automatically mirror the order of tiles when left-handed mode is enabled, because I’m not convinced there’s an absolute correlation between reading/comprehension order and handedness. The delegate object for the control can still readily flip the order of tiles depending on the user’s handedness if so desired.

So much for how the tile menu looks. The appearance and intended use of the control immediately implied several places where I’d want to incorporate some animation:

When the menu appears or disappears.
When the user switches between pages of tiles.

Appearance and disappearance of the menu itself were simple and obvious enough: a zoom-up and fade-in to appear, and a zoom-down and fade-out to disappear. The interesting question was how to transition from one page to another, given that it would involve changing all of the tiles simultaneously.

Given that the tiles overhang the bezel, creating a dynamic tension around the control, I decided to make the tiles congregate in the centre of the bezel when the user switches pages. The tiles would fly into the middle, change into suitable tiles for the next page, and then return to their positions.

A naïve implementation of the animation would move all the tiles in sync, which gives an unpleasantly robotic effect. I’ve slowed the animation down so you can see it in this short video.

Uniform tile movement

(Watch it on YouTube)

By adding an offset to the beginning of each tile’s animation, we get a much more pleasant flocking sort of effect, shown here slowed down once again:

Staggered tile movement

(Watch it on YouTube)

The tile-switching animation is a simple cross-fade, to avoid a jarring sudden change into a different tile.

The videos above show the final animation order, but initially the tiles moved in their programmatic, logical order of left-to-right, top-to-bottom.

Tile index order

That gave a haphazard, disordered impression (particularly the wrap from the end of the top row to the beginning of the second row). I felt it would be more logical if the animation proceeded from the page-switching tile, since that’s what the user taps to initiate the transformation in the first place. Thus, the final animation runs clockwise, starting with the middle-left tile (just above the switching tile). The animation order is horizontally flipped if the menu is in left-handed mode.

Tile animation order

It took a little more work for me to implement, but it’s a much nicer experience for the user.

The delegate API (and MGTileMenu’s own code generally) still indexes the tiles on a left-to-right, top-to-bottom basis internally, because I felt that it’ll require less mental acrobatics for the developers who make use of the control.

Final thoughts

I’ve enjoyed creating MGTileMenu, and I really hope you’ll find it useful - a lot of love has gone into the design and the code. Please do consider supporting this blog and my future code releases with a donation or a non-attribution license.

I plan to write another article soon, detailing the other side of MGTileMenu’s development: the API, and why I designed it the way I did. After all, APIs are UX for developers.

To keep up to date, you should follow me (@mattgemmell) on Twitter. Enjoy MGTileMenu!

iPad productivity apps

2012-05-02T15:00:00+01:00

I’m very invested in the iPad as a laptop replacement, and I endeavour to make it my main machine when I’m away from my desk (at which I currently use an iMac). I travel regularly, often to speak at events, and I try to embrace simplicity and to work away from my office as much as I can.

To that end, I’ve compiled a list of my essential iPad applications for productivity, that I use regularly when:

Planning and thinking about projects (in my case, often software).
Writing (for this blog, for Tap! magazine, and others).
Creating documentation and reports (for clients, based on my User Experience and Accessibility consulting services).
Creating and refining presentations for my speaking engagements.

Since I have my iPhone with me at all times, I try to keep only essential “big screen” apps on my iPad. For example, I keep my various apps for package-tracking, flight information, reminders etc strictly on the phone.

Home screen

I have, naturally, allowed a few extras and alternates to creep onto my iPad, but I at least don’t allow myself to exceed one screenful (including folders) of apps on the larger device.

(Incidentally, I’ve been asked a few times where I got my wallpaper: it’s one of the default ones included with iOS 5.)

Essentials

There are some apps that no device is complete without. These are my choices, though I’m always ready to jump ship to newer, better ones.

Browsing

I use Safari. I’ve not had cause to look elsewhere.

Email

For email, I use the built-in Mail app, set up to use my Gmail account and to receive email via push (if you set up the Gmail account as an Exchange account, it’ll work). I find Mail to do just enough to meet my needs, and to have a very low-friction workflow for powering through bulging inboxes.

Twitter

For Twitter, there’s only one choice: Tweetbot. It’s clean and elegant, has an iPhone counterpart, and natively syncs which tweets you’ve already read.

Tweetbot

Tapbots have put so much work into the interaction design that I’ve come to associate the service with the app. Judging from the characteristic notification sounds coming from the audience at recent speaking events, this is a deservedly widespread phenomenon.

Feeds

For the feed-reading experience, I prefer Reeder, though some of the interaction design is questionable, and it doesn’t allow you to add feeds. For that, I use Mr. Reader instead.

Reeder

I should probably simplify here, and just go with Mr. Reader full-time.

Calendars

I find the built-in Calendar app very unpleasant to look at, and I much prefer Calvetica.

Calvetica

It’s clean, no-nonsense and high-contrast, and it even compliments you.

Geeky things

Sometimes, I need to get into my web server remotely, or to edit some code with syntax highlighting (often to prepare a slide or example, but sometimes for an actual dev project). I keep a few dev/geek apps around for that purpose.

SSH

My SSH client of choice is Prompt, by Panic.

Prompt (SSH)

It’s stripped-down yet capable, and has a good typing experience and support for favourite servers.

Code editing

I use Textastic as a code editor, because it’s full-featured without being too busy, and has excellent syntax highlighting.

Textastic

I’m sure I don’t use even 10% of Textastic’s features, but it’s reassuring to have a capable code-focused editor on board.

Presenting and report-writing

I have the luxury of not needing to exist in a Microsoft ecosystem, so I gratefully stick with Apple’s iWork applications for Office-like purposes, with a few third-party extras to help out.

Presentations

It’s Keynote all the way. With its support for presenter notes, remote control from the iPhone, and video-out to actually run the presentation too (complete with virtual laser pointer), this really is my ideal speaker’s workhorse.

Keynote

You may need to prep your custom theme in a document on Keynote for Mac first, but once you’ve synced it to your iPad it’s relatively plain sailing. I’ve spent a lot of hours on planes gleefully playing with it.

Reading, reference and file transfer

I use ReaddleDocs for everything from shifting files between servers and services, downloading and unpacking archived files, and reading weighty textbooks and reference materials. It’s an incredibly versatile app to have in your mobile toolkit.

ReaddleDocs

I’m constantly discovering new things it can do, and the user interface is pleasant and usable.

Document creation

For page-layout or word-processor type work, including the creation of complex and attractive reports, I don’t think there’s a better iOS app than Pages.

Pages

It’s a well-deserving poster-child for the iPad as a serious work tool, and it has some clever adaptions for text-navigation that I wish were system-wide. It can also capably export to the formats you’ll want to send to clients.

Diagramming, charting and data

If I want to work with data, and derive charts therefrom, I naturally use Numbers, but sometimes you need to do more free-form diagramming.

For that purpose, there’s only one sensible option: OmniGraffle.

OmniGraffle

It’s a pro-level app with a price tag to match, and it’s invaluable.

Graphs (without data)

Sometimes you just need a rough graph to illustrate a point, without necessarily wanting to mess around with underlying data to generate it. Similarly, sometimes your spreadsheet doesn’t provide sufficient tools to suitable annotate a given graph, and it would be too cumbersome to take the graph into a general-purpose drawing tool to enhance it.

Thankfully, there’s an app for that very purpose: OmniGraphSketcher.

OmniGraphSketcher

OGS lets you mark-up and annotate graphs (and create them) as you’d like, without worrying about data or spreadsheets. It’s a wonderful tool for quick-and-dirty illustrative graphs for documents and presentations.

Photo cropping and basic editing

I use iPhoto for this, though I do so under some protest since the user experience is terrible.

iPhoto

Nonetheless, its feature-set is a decent balance of image-editing and photo-beautification, so it’ll do for now.

Creativity

I love the way that the iPad adds breathing space to my thinking, and lets me take my work into unusual environments. I do two main things in these situations: write, and sketch, and I have excellent apps for each.

Writing

I always write using the Markdown format, because it’s compact, readable, understandable and portable (since it’s just plain text). I’m constantly on the lookout for the perfect Markdown-savvy iPad text editor, and whilst none are a perfect match for me, one comes very close: Elements.

Elements

The typography and feature-set are great, and I find it relaxing to work in. I’d like it if a word-count (and/or character-count) was visible at all times, and it would be nice if there was some subdued Markdown syntax highlighting, but I can live without those.

Sketching

I like to sketch down not only UX ideas and concepts, but also illustrations for my reports and presentations. I have no drawing ability to speak of, but somehow Paper still makes my crude scribblings strangely beautiful.

Paper

The UX needs some work (the undo feature is particularly vexing), but for getting gorgeous, elemental output with minimal effort, I’ve yet to find better. I usually use an Adonit Jot stylus with Paper.

Final thoughts

The oft-repeated fallacy that the iPad isn’t a tool for productivity and creation has no credibility whatsoever. Anyone trotting out that old chestnut is either labouring under some astonishingly wrong-headed preconceptions, or is making excuses for their own failings.

I manage to be very productive indeed with the iPad, and I don’t have to jump through many hoops to do so. With the right set of applications (and more are becoming available on iOS every day), you can get real work done - effectively, pleasantly, and regardless of where you happen to be.

I’m @mattgemmell on Twitter.

Footnote: If you’re going to be travelling with your iPad too, make sure you keep it passcode-locked, and with your contact info on the lock screen. Here’s my template image for Retina Display iPads.

Familiar is not a design

2012-05-01T20:00:00+01:00

With a not-uncommon sense of despair, I recently read an article on a hack for jailbroken iPads, allowing desktop-like layered window management.

The hack is called Quasar, and was created by Pedro Franceschi. It’s unquestionably an impressive technical achievement, and on those grounds he’s to be congratulated.

Quasar looks like this:

Quasar jailbreak hack for iPad window management

Self-evidently, it brings desktop-style, manual layered window management to (jailbroken versions of) iOS. Hopefully just as self-evidently, that’s a terrible idea.

On simultaneous multi-tasking

The comments on the linked article are positive overall, indicating that (amongst the tech-savvy, early adopter sort of audience that The Verge attracts), there’s a desire for some form of simultaneous multi-tasking support on iOS (that is, to have more than one app visible at the same time, in some form).

So far, fair enough. Many of us have felt some friction at iOS’ resolutely “one at a time” app interaction model. When writing, for example, we’ll commonly want to refer to another document or to the web. Some writing tools embed reference facilities or mini-browsers for that purpose, but such functionality also acknowledges that there’s an unfulfilled need - at least for some percentage of users.

Quasar, in common with many hacks and engineer-generated solutions to user problems, addresses the deficiency in precisely the wrong way.

Windows Snap

An alternate, considered solution to the issue is Windows Snap, also available with the Metro interface on upcoming Windows 8 RT tablet devices. Snap allows a second app to be shown in a narrow (320 pixels wide) bar on one side of the screen.

Windows 8 Metro multi tasking

This isn’t an arbitrary, forced construct. Snapped status is a defined, discrete application state on Windows, with notifications when the app enters or exits that state, and relevant UX guidelines to suit the situation.

Snap is only one possible implementation, but it’s a judicious, sensible, pragmatic solution.

Experiences should be designed

The core problem with the Quasar model is that it’s not designed for the needs of the device or its users. It’s the desktop windowing model, designed (or perhaps more truthfully, evolved for better or worse) for lean-forward, stationary, pointer-driven, large-screened and comparatively high-performance devices. Everything that, relatively speaking, a tablet is not.

Unconsidered design (or lack of design) tends to simply gravitate towards the familiar, which is a natural instinct when we’re lost in some way. The desktop windowing metaphor is familiar from older computing devices… and that’s all. Its suitability to the iPad’s form factor, usage scenarios, and current app interaction models was not considered. It introduces additional frames of interaction and cognitive load, and disregards the interaction heritage and environment of the platform.

Quasar was not designed, but rather only implemented. It’s the classic outcome of closed, engineer-based thinking.

Experiences should be designed. If your interface will be used by humans, you need to design it for humans. Familiarity may well be a factor to consider in that design, but it’s by no means the only one - and it’s almost always trumped by context.

Context matters

With touch-screen mobile devices particularly, context is key. Not just the physical context (Am I moving? Sitting down? Do I have only one hand free because I’m holding the device?), but also the interaction context (Am I in a hurry? Am I likely to be at leisure to browse or read? What’s my goal?) and the user’s mental model of what’s going on.

Falling back on what’s familiar from some unrelated context, regardless of its suitability to the current situation, is user-hostile and antisocial. It’s a demo or an academically curious proof-of-concept (which I readily acknowledge that Quasar is), rather than anything we’d call a solution.

“Because I can” isn’t a design, and nor is “it’s familiar”. Assessment of context and suitability is always required.

Design for humans

Quasar is a clever demo, and its unsuitability for the iPad can’t do much practical damage because it’s only for jailbroken devices - a tiny niche of tech-savvy tinkerers that will be forever unknown to the vast majority of people.

But knee-jerk design decisions are worryingly commonplace, and pose substantially more risk to software users. Familiarity is only one factor, and it’s often a deceptive one. Consider the entire scenario and context, and take the time to truly design your user’s experience.

I’m @mattgemmell on Twitter.

Misogyny

2012-04-20T15:00:00+01:00

I’ve previously written at some length about the evils of religion, but they pale against a far greater, more pernicious, more widespread blight on society. Religion itself, as always, continues to support and propagate this greater cruelty. And unlike religion, sadly, it’s not being rapidly abandoned by the more civilised countries and enlightened people.

Do you know the word “misandry”? You probably don’t, or you didn’t until you just looked it up. It’s a relatively modern word; about 70 years old. It means a hatred of men.

You do, however, almost certainly know the word misogyny. It’s an older word; something of the order of a few centuries. The hatred of women. The modern ‘misandry’ is modelled on the pattern of the older ‘misogyny’. The etymology is both factually true and deeply symbolic.

Confidence

All of our societies are rife with sexism, which is founded on misogyny. It’s the great, omnipresent crime of the ages, and its victims are fully half of the population. The shame we ought to feel should be absolute.

Men can be blind to many facets of sexism. I’ve been blind in some ways myself. We’re quick to classify positive attributes as inherently male, but when challenged about gender disparity and inequality, we reverse the process, claiming that individual women simply lack drive, negotiating skills, or confidence.

Confidence is environmental. It’s easy to be confident when you’re called “Sir” from adolescence, when you hear about the best man for the job, and when summoning courage or stoicism is to “man up”. How cartoonish when considered from a distance, but how compelling to young (male) ears. The greatest hero (never heroine) of the moment is literally “The Man”.

Confidence is a little trickier to muster when you’re pre-judged due to the incidental fact of being female, or when your viewpoint can be dismissed as down to uncontrolled emotion, or timidity, or hormones. When perceptions of your physical power become an albatross around your neck, and when the default compliment is not about your abilities, but rather your appearance.

Confidence is bred from privilege and security, two things which women lack - in both cases, sadly, due to men. It’s difficult for men to understand a woman’s perspective on threatening language or behaviour, on lewd remarks, or even on the prospect of walking home alone, along a dark street. The world is actually two radically different places, yet we see only one.

Our selective generalisation is something that often strikes me. A positive or praiseworthy act by one man is implicitly claimed by all; it’s the essence of our socially-conditioned entitlement. Yet the acts most quickly stereotyped for women are those that are foolish, or poorly considered, or accidentally amusing.

Women are very aware of it. Their implicit ambassadorship is the bane of every woman who stalls a car, feeling the real or imagined weight of male derision turning towards her. The assumption (very often, sadly correct) that any error will be generalised across one’s entire gender, and will only serve to confirm and reinforce preexisting biases. A pressure that men rarely face.

Social conditioning

Sexism and misogyny have always been with us. We have always sought to control women, to limit their liberties, and even in more enlightened societies to reinforce certain double-standards in terms of how we expect women to behave.

We’ve made some progress in the last couple of generations, such that we now feel not only nostalgia but disbelief when seeing the blatant sexism of Mad Men’s world, or the portrayal of women in vintage ads. We’ve attempted to enshrine equality in law, if not always in practice. We’ve begun to address the overt, but not so much the covert.

Our society still inflicts a thousand paper-cuts on a woman’s confidence. Unnecessarily gender-specific, gender-illuminating or gender-characterising remarks. Social assumptions about who is paying the bill, or who is to be spoken to as an authority figure, or (more subtly) whose ego is to be primarily accommodated during an interaction.

Saddest of all, we see the horror of social conditioning on women themselves; female misogyny.

For goodness’ sake, woman!
Stupid woman.
Ugh. I hate offices full of women.
I bet the driver is a woman.
Women need to learn some responsibility.

Whilst these phrases have been spoken countless hundreds of thousands, or millions, of times by men, I’ve heard all of them in person spoken by women. The last one is particularly troubling, since the context was of course that of reproduction, abortion and so forth; an area in which women’s liberties are being more openly assailed than ever, even in the developed world.

It’s impossible not to feel a deep guilt and dread when seeing an anti-female stance espoused by a woman. It’s the same as when a homosexual person feels guilty about their natural state due to religion’s febrile influence - a shocking psychological assault that has no place in civilised society.

Whilst we must account for teenage foolishness and deliberate controversy-stirring, it’s difficult not to feel horrified, for example, at unsettling remarks from young women, saying they’d allow Chris Brown to beat them.

Caution: the links in the next paragraph are not safe for work (NSFW), or indeed for decent, reasonable people in any circumstance.

Taken to its disgusting extreme, we can even find enclaves of people who are ‘enthusiasts’ of not only (NSFW) misogyny itself, but even (NSFW) beating women and (NSFW) raping women.

There are few words that can address the existence of such ‘communities’, or a society which can tolerate them in any form, regardless of law.

Reproductive rights

We’ve been making a concerted effort to control women’s bodies since time immemorial. Whilst we’re now at a point where you’d expect us to have moved beyond these primitive, fear-based motivations, there actually seems to be a resurgence of this unique brand of injustice. The US Republican party is waging an all-out war against women, with reproductive rights at its centre.

My own wife utterly dreads the possibility of being called to travel on business to the USA, in the current climate. From TSA fondling, to legal powers of unjustified strip-search, faux-terror laws permitting criminal periods of detainment, to the horrendous and knuckle-dragging limitations that some States would place on her fellow women, she would almost rather visit a country governed by Sharia law.

And who can forget the grotesque Rush Limbaugh’s well-publicised remarks that if student Sandra Fluke wanted free contraception, she should publish videos of herself having sex? There is a cancer there, and it’s not limited to America.

It seems trivially true to me that:

My rights as a person end where yours begin.
Your rights always include the domain of your own body.
A current person takes precedence over a future or otherwise hypothetical person, with the boundary moderated solely by the best available science of the time (and never, ever by religious or other pseudomoral ‘frameworks’).

So many self-identified Christians (particularly, but by no means limited to, Catholics), Muslims and others impose brutal restrictions on women’s behaviour, rights and roles, much of it seemingly founded on a bizarre and outdated belief that a woman’s ability to bear young corresponds to a responsibility.

Let me make this perfectly clear: a woman has no duty of reproduction. Not personally, and not socially. She has a right (in sound mind) to determine the outcome of a pregnancy, and a wish to not carry to term does not - and cannot - constitute a failure in judgement, or a lack of ‘womanhood’. The very association is contemptible, reducing women to little more than offspring-producing automatons.

There’s no population shortage here (quite the contrary, in fact), which is just about the only scenario where I could conceive of legal meddling in a woman’s dominion over her body and its functions. Yet we continue to meddle with the very thing that we have least authority and connection with, as witnessed by the shameful ludicrousness of an Israeli gynaecological conference with no women speakers (women are, however, “allowed in the audience, in a section separate from men” - how terribly progressive and tolerant).

Women in technology

My own industry (more or less) is that of technology. I’m at least partly a software developer, and I’m involved in the technology sector and its various offshoots. Our industry has a poor reputation for gender equality, and the treatment of women - and it’s probably deserved.

We’re insular, and we have a skewed view of women which is self-perpetuating. Ours is the industry where the comments on a technical interview focus more on the female interviewer than the content, where female drinks-serving staff at programming events are characterised as “perks”, and where event organisers fail to address the negative impact of having “booth babes”. We’re also closely related to (and have a continuous intake of new talent from) the vast pool of young, male video-game players who treat women appallingly when playing online.

Yes, you can point to yourself and say that you’re not like that. You can talk about the social issues. You can say that your own personal experience has been different, and that some of your best friends and colleagues and mentors are female. I can do that too. That’s fine. That’s not the point. It’s not like that generally, or enough.

It’s at this point that the “women don’t choose to go into technology or programming” argument is usually trotted out, as if that’s somehow an independent and self-justified phenomenon, rather than a symptom of the problem. There’s no inherent unsuitability, nor any lack of interest. Social context gives rise to damaging expectations and gender roles, which quickly leads to peer pressure being a factor in the gender imbalance amongst developers.

Men don’t have to validate their presence, interest or (to the same degree, at least) aptitude in this industry. We are expected to be “more technical”. People even wheel out ridiculously irrelevant studies about brain activity to provide some kind of faux-biological context - as if software engineering was some genius-level discipline requiring every ounce of a notional neurological advantage. What drivel. The gender imbalance is a social and societal phenomenon.

The proof is all around, even without resorting to common sense. There are any number of positive female role models, both past and present. They’re successful because of who they are, and the work they put in - and neither because of nor despite the incidental fact of their gender. Indeed, being treated as a student, rather than a ‘girl’, is very important in building confidence, as any reasonable person would immediately intuit.

We still have a lot of work to do. I attend technical conferences periodically, and the gender imbalance is a travesty. Not just “unequal”, or “not ideal” - it’s shocking. Further, there are assumptions made about women who are present at conferences. They must be someone’s girlfriend, or in some ancillary or “soft” discipline vaguely related to software development, like the visual arts. That’s a prejudiced assumption.

My wife sometimes attends conferences with me. Every time, with the best of intentions, someone will strike up a conversation with her, and offer some variant of the following:

This must be really boring for you!
What’s it like to be around all these geeks?
So what is it you do for a living?
Don’t worry, not all the talks are going to be that technical!

I tend to stay quiet, and I confess to enjoying hearing her very graciously tell the person that, actually, she holds an Honours degree in Computing Science, and is a software engineer for Amazon. She manages a team of engineers, and has direct expertise in the sorts of very serious and grown-up things you’d expect an Amazon software engineer to have. She has experience in more technologies than I do. She’s been responsible for more revenue than I ever have, or almost certainly ever will. And she’s a girl! Some people have the good grace to blush.

It’s not the questions or remarks that are the actual problem (as I said, they’re universally meant considerately and generously, and we’re both very grateful for the effort people make), but rather the automatic assumption. A juxtaposition of gradual enlightenment and entrenched attitudes.

We watched the original Star Trek episode ”Who Mourns For Adonais?” the other night, and it was the perfect combination of socially-sexist and progressive attitudes. In the episode, Kirk wryly laments that he’ll no doubt lose a very promising female Lieutenant when she inevitably decides to leave Starfleet to have a family - this is treated as an automatic, unquestionable course of events. Coupled with the short skirts and soft-focus close-up shots, the bridge of the Enterprise is at that moment very clearly a television sound-stage in the 1960s; not the future, but a past we can only half-imagine.

Later in the same episode, however, with Kirk trapped on the planet, Uhura is wiring up and soldering a communications circuit, and when she tells Mr. Spock that it’ll take some time since she hasn’t performed the task in several years, he expresses his complete confidence that there’s no better person on board for the extremely technical and critically important task. Uhura is validated and encouraged, and no doubt every woman watching the show (particularly African-American women, I should imagine) feels a completely natural jolt of pride and potential. Uhura is valued for her skills, and absolutely trusted to exercise them - and even her moment of self-doubt is both expressed and handled without regard to her gender. It’s a lovely moment, and it edifies us all.

Moments like these aren’t strange to watch, neither on television nor in real life. They’re not jarring, because they’re the most natural thing in the world; they’re how men are already treated. We all have a responsibility to make gender less of an issue, even if we must begin by making it more of one.

I don’t just attend technical events; I speak at them fairly often too. If you’re thinking about inviting me to speak, have you considered instead looking outside the usual suspects and actively seeking inspirational female speakers? I made a list of some women you’d want to speak at your event. I’m no better than them. Ask one of them instead of me. I’m not “giving up my space”; I’m asking you to make an affirmative choice now so that in future we can rightly consign this imbalance to history.

Moving forward

I mentioned feminism recently on Twitter. The first two responses (which were from men, who comprise the vast, vast majority of those who read my tweets), were intriguing. Firstly, from a seemingly younger man, judging from his profile picture:

Feminist? Seriously? Why should women recieve (sic) more rights then men or transgendered people? Equal rights.

And then from someone perhaps around my age:

Is there a word for a masculine version of a feminist? Someone who stands up for men’s rights. Don’t think so. Should there be?

What fear we feel, and how readily we couch it in a greater reasonableness.

I understand fear as a motivator; as an animal, I’m hard-wired to. Unfortunately, fear is the ultimate egocentric view-limiter. We forget that our concerns must be weighed not in isolation, but relative to others.

In fact, the definition of feminism (at least, the one I subscribe to - and the dictionary seems to agree) is the advocacy of women’s rights on the grounds of equality. It is not, for example, “female supremacy”, or matriarchy or whatever else these men may be inwardly afraid of. We must change that attitude first; rights aren’t an either-or situation. Some issues are hard, but it’s those we must tackle most directly.

Misogyny is an anachronism, and is cancerous not just to society, to the workplace, to the economy and the large constructs of humanity, but to the individual people that many of us care most about. It’s not an abstract thing to only be debated; it’s a real, actual injustice, inconceivably prevalent even in our ostensibly most advanced nations.

Feminism was a distant and academic concept for me as a younger man, but as I’ve become an adult (a process that by no means ends - or has even significantly begun - when we reach adulthood), I’ve found it increasingly difficult to see feminism and misogyny as somehow separate from the actual women in my life. Because, of course, there’s no separation at all. This is an immediate and appallingly widespread issue for them, and it’s my issue too. Our wives, our girlfriends, our sisters, our mothers, our daughters, our friends and our colleagues. Even strangers on the street.

Every other prejudice or type of discrimination pales in comparison to this one. Religious persecution. Racism. Homophobia. All hideous, and all shameful. If you’re a woman, you can be subject to these things in addition to the curse of our attitudes towards your gender. More than half of our species. A crime whose victims you see every time you glance out of any window in the world.

None of us are entirely blameless. I’ve made sexist remarks. I’ve jumped to sexist conclusions, or made sexist generalisations, secure in the various axes of my male, white, heterosexual privilege. I’m by no means free of blame, nor of guilt. But I’m not suggesting we spend all our time castigating ourselves; that’s not what’s required.

Our society has engineered itself to perpetuate certain attitudes, because those attitudes reflect not only male fears but also our self-interest in maintaining the upper hand. That’s outdated, self-limiting and unnecessary. It can also be changed just as easily, by accretion and by action.

It’s shameful that anti-women attitudes are enshrined in law, both current and proposed, across much of the world. It’s an appalling condemnation of our society that we allow it to continue. It’s an ignored and accepted bigotry, with an unprecedented number of victims. It must be fought.

Drawing conclusions along gender lines is at best unproductive and at worst irrational. Even if you can (currently) argue correlation, that’s a far cry from proving causation. Even then, it’s irrelevant. It doesn’t matter if you believe that a gender-correlated difference exists; the point is that nothing is universally true, and that people must not be discriminated against or even discouraged. It’s the function of an evolved society to root our discriminations regardless of basis. By that process, we usually discover that they were baseless instead.

Ultimately, it comes down to each of us opening our eyes and becoming aware of the sea of subtly sexist constructs and attitudes in which we exist, and of our own contributions to that negative state of affairs. We must rein in any casual sexism we might be guilty of, and we must do whatever we can to repair the damage by ensuring that women are enfranchised, included, and at liberty to determine their own roles.

A key goal must be to help make sure that women have positive role models, and that those people are celebrated on merit rather than either because of or despite their gender; the same situation men enjoy in every walk of life. Nothing combats discrimination as effectively as an environment in which it seems ludicrously out of touch with reality.

That’s the world I’d like to live in - for myself, and for the important people in my personal and professional life who happen to be women.

If you enjoyed this article, you may wish to follow me (@mattgemmell) on Twitter.

Augmented Paper

2012-04-13T10:00:00+01:00

For most of my life, I’ve struggled to quantify what constitutes an enticing interface. There are certain basic aims from which you can take your pick - intuitiveness, attractiveness, clarity, simplicity, consistency, and more - but those are general guidelines. I’ve had trouble defining what an enticing interface is for me.

Whatever progress I’d made was very nearly reset by the advent of the iPhone, and touch-screen devices generally. With the arrival of the iPad, however, I’ve noticed an increasingly-prevalent UX aesthetic that I think gets close to the natural role of these devices in our lives - or at least in mine.

I’ve already written about my aesthetic preferences, and they strongly inform my preferences in software. I’ll begin by briefly touching on my perception of the ethos and design genetics of the three major mobile operating systems we have today.

iOS

Apple’s iOS is already the father, if not quite the grandfather, of modern user experiences for mobile touch-screen devices. Its primary interface is bright and hierarchical, and fundamentally functional and single-screen based.

iOS on iPhone - Home screen and Safari

iOS is ruthlessly designed to be a touch-screen experience; it willingly broke with existing desktop UI concepts inasmuch as it made sense to do so. So far, so good.

When you use iOS for more than a few minutes, though, and particularly on the iPad, you see that its aesthetic is absolutely rooted in skeuomorphism (the practice of adding design elements that make a new thing nevertheless look familiar, and similar to an older, existing thing). It makes virtual things into physical things, transforming the device’s physical identity depending on the frontmost app.

Contacts on iPad

It’s an unashamedly visceral user experience, lavishly so. iOS prefers to make devices into digital analogues (if you’ll pardon the term) of real-world machines or processes. It’s metaphorical, physically imitative and embellished, and there’s a concrete one-to-one relationship between the device and whichever screen it’s showing at the time.

Calendar on iPad

iOS provides hand-sized (or magazine-sized) experiences, designed to comfort you as much as possible, and to coax you into transplanting your natural affinity and affection for physical interfaces, onto your iPhone or iPad. This has proved remarkably successful, and it’s difficult to argue with the approach except on grounds of personal taste.

Windows Phone (Metro)

The Metro user interface style could scarcely be more different from iOS. Where iOS aims to create “soft hardware”, Metro is the pinnacle of information asceticism. Windows Phone is a, well, window onto an information space. The UX is designed to make the device itself invisible, rather than to change the device’s identity.

Windows Phone 7

It’s not quite minimalist, though; it’s more like finding yourself living inside an infographic. The presentation is flat and high-contrast, but there’s little that’s familiar in the surroundings. It eschews skeuomorphism utterly. It’s hip, razor-edged and as modern as it can be without surrendering to the whims of futurism.

It’s almost perfectly digital, and is focused on information and content above all. Metro presents the device as little more than a viewport into a digital information space - indeed, the idea is immediately shown to the user via the concept of the horizontally moving viewport.

Windows Phone 7

If there’s a current mobile user experience that should most appeal to Star Trek’s LCARS apologists like myself, then it’s surely Metro rather than iOS.

Android

Android, to my eye, lives somewhere between the desktop and iOS, in terms of embracing the promise of touch-screen devices and task-centric computing. It’s much more cemented in traditional concepts of “software”, and its user experience frequently betrays the “geek tinkerer” design mindset.

Android Ice Cream Sandwich

It’s widget-y and button-y and icon-y. It’s configuration-exposing and panel-centric (rather than iOS’ app-centric or Metro’s content-centric approaches). It’s more of a desktop UI in overall aesthetic, with necessary adaptions for touch-screen and mobile-sized devices.

Android Ice Cream Sandwich

That’s fine, and a legitimate approach, but it’s not radical and it isn’t going to set the world on fire. It feels like Android has never drifted particularly far from the UI themes we’ve used for years on our Nokias and Sony Ericssons and Motorolas, which have now likely been consigned to the museum of history. The destructive and user-hostile fragmentation of its user experience is also of sad note.

So what’s left?

Invisible interfaces

I’ve noticed something about the apps I tend to fall passionately in love with (on iOS, in my case), and I was intrigued to notice that they’re often the most divergent from the usual iOS interface style of glossy, tangible, comfortable, explicitly touch-inviting designs.

Just over a year and a half ago, I put together a UX experiment called Finger Tools, which proposed that in canvas-like applications, the fingers of your hands could provide tool-selection without needing a permanent user interface presence like a toolbar.

Finger Tools on iPad

It was compelling to use, and gave a strong sense of direct interaction. I found myself thinking of it again recently when using Clear, a to-do list app for the iPhone, whose novel UI eschews on-screen controls in favour of a completely gesture-based interface.

Clear on iPhone

It’s here that I have to offer a confession: I don’t like Clear. I acknowledge the achievement and its success, but to my mind it’s almost the opposite of what I like to see in apps. For one thing, it’s garish, and I find it very difficult to equate shouty visuals with elegance of interaction. The deeper issue is that it eschews controls on principle and as a primary design goal, rather than based on what’s best for the user. I’ve had several conversations about Clear, and in every case someone has mentioned that they don’t find it discoverable, or that they make errors when performing pinching gestures, or some other frustrating thing.

Gestures, like anything else, aren’t a panacea - they are not automatically or inherently better than visible UI. Only good gestures are good - in that only those which add to the user experience in some way should be considered beneficial. Gestures for their own sake are a demo, not a design.

Clear is a nice app (give it a try for yourself, and see how you feel about it), but it’s not for me. There’s something very frictional and forceful about gratuitous non-interfaces, and even (dare I say) something that’s contrary to the core attraction of a touch-screen device.

Augmented Paper

The interface and UX style I most enjoy, particularly on iPad, is something I think of as augmented paper. Augmented Paper, for me, has these properties:

A quiet, aesthetically pleasing, breathable, layout-conscious treatment of information, where functionality is as implicit as reasonably possible, and where interface is minimised rather than either celebrated or avoided.
Information presented beautifully, with a print-like attention to readability and attractiveness.
Not obviously “software”, in the sense of a dated, legacy, widget-heavy, desktop-era design aesthetic.
Neither too lifelike (saturated with gloss), nor too ‘digital’ or artificial (stark, rarified and electronic).
Virtual enhancements where useful, but not so as to compromise the design. Make interaction cues subtle and quiet, without being obscure.
Displaying a core ethos of tactile surfaces, with judicious digital adornments.

There’s a natural tension-point between the (traditional, comfortable) physical world and the (new, powerful) digital worlds, and current touch-screen interfaces are gleefully oscillating around it rather than trying to pinpoint and reach it.

We’re still working out what these devices mean to us and how they fit into our lives, but it seems evident to me that their primary attraction isn’t that they’re new per se, but rather that they’re a far more enjoyable, usable, flexible, contextualisable version of computing interfaces that are more natural citizens of the real world that we inhabit. Correspondingly, it seems foolhardy to focus only on the device’s software alone, rather than its role as a physical, interactive object used by humans.

Much of iOS’ aesthetic can seem twee and even occasionally juvenile and over-designed, whereas Metro turns a device into some kind of rip in the fabric of reality, peeking into the Data Domain behind. Both are attractive and usable in their own ways, but they’re both also demanding, vocal and inelegant in other ways.

An iPad app that’s had a lot of press lately, and which is reasonably well-aligned with the concept of Augmented Paper is the delightfully descriptively-titled Paper.

Paper on iPad

It’s a drawing app that aims to put content and creativity in front of the need for interface, and is moderately successful in doing so. It has some rough edges both technically (laggy input) and in terms of UX (the unnecessarily constrained and poorly-mapped Undo unwinding interface), but it does provide a flash of insight into how undemandingly elegant a software interface can be.

For me, both the gold standard and the most conflicted, poorly-executed Augmented Paper interfaces can be found in text-based applications: digital publishing. The publishing industry understands that there’s something utterly compelling about the size, weight, form factor and psychological appeal of tablet devices that fires many of the same neurons as a beautifully-produced magazine or newspaper. That same industry also has a very difficult time distilling their best paper experiences and working out how to capitalise on virtual versions of them.

It’s interesting to me that one of the best digital (or Augmented) paper experiences I’ve had is from an app designed not to make print more like digital, but the reverse: Instapaper, by Marco Arment. I defy anyone to think this isn’t beautiful:

Instapaper on iPad

It’s still software. It’s still interactive, and malleable, and connected. But it’s beautiful, and the interface isn’t in the way of the experience. It’s redolent of freshly-printed sheets from a laser printer, and is a wonderfully tactile, quiet and comforting thing to look at.

That’s not to say, of course, that quietness has to be the hallmark of well-designed iPad experiences. It’s indeed possible to have all that we enjoy from a magazine (rather than Instapaper’s more newspaper-like aesthetic) in an electronic form. Instead of the more usual dumb PDF, Tap! Magazine (disclosure: I write the Dev Zone section of it each month, but I’m not responsible for the app itself) is a first-class digital citizen, which is actually created on an iPad too.

Tap! magazine on iPad

It’s a magazine page, just like you’d see in print - but there’s judicious digital enhancement and interactivity:

The text is genuine, and OS-rendered. It’s not a PDF. You can resize it as you like, and have it read to you. The text pane is scrollable, without requiring scrolling the entire page.
The screenshot is actually a video, in this case of gameplay. It can be flipped over via the Strategy Guide annotation to see further content.
The app icon is an appropriate link to the App Store.

It’s not a digital copy of what’s in print; instead, it’s something designed for digital, without sacrificing the benefits (in this case, clear presentation of information, and a fanatical devotion to page-layout) of the print world.

It’s so easy to saturate electronic representations of paper with what I call “digital artifice”; the gratuitous and ultimately heavy and objectionable skeuomorphisms and decorations that betray a simplistic thinking process: let’s just make this look the same. That’s a damaging frame of mind, because it enforces a false dichotomy between the real and the virtual. Software should be an enhancement, not a replication.

I found another example just a few days ago, in the form of (yet another) note-taking app. Previously, I’d been using - and hating - the built-in Notes app, which reeks of cheesy mimicry.

Notes on iPhone

You can (now) change the typeface to something less whimsical, but that’s an admission of fault rather than an improvement. Compare it to something that’s been designed for experience, rather than for similarity: Drafts for iPhone.

Drafts on iPhone

Drafts doesn’t try to be a legal pad. What it does do is try to let you enter text as simply, elegantly and quickly as possible. It succeeds, and it’s a far less stressful app to jot notes into for that reason.

Augmented Paper doesn’t always have to be about paper, of course. Sometimes it’s just about something that has a physical analogue, and is enhanced subtly and oh so very carefully with interactivity and information. One of my favourite examples is the virtual version of a dedicated weather station, Magical Weather.

Magical Weather on iPad

It’s quiet, unassuming and beautiful. The weather is animated, the transitions are smooth, and it puts graspable information at the forefront of its design. It’s not paper per se, but it’s a human-centric experience that complements the device.

Apps are experiences

Augmented Paper is a tricky thing to pin down. It’s fine to show examples of apps that I feel fit with the ethos and aesthetic, but it’s another thing entirely to work out how to achieve that same feel with an arbitrary app.

For me, software experiences that feel like Augmented Paper are those that second-guess our (developers’) natural tendency to put functionality first, or to think of our apps as software. Apps are only incidentally software; software is an implementation detail. Instead, apps are experiences.

Design an experience. Make it as beautiful - and as emotionally resonant - as it can possibly be. Then adorn the core experience and content with only as much functionality as is absolutely necessary. Functionality - and software-based thinking in general - is like seasoning. A little is an enhancement; any more destroys the flavour, subsumes the artistry of the chef, and may well be bad for you.

These new classes of devices, so immediately personal and portable and tactile, aren’t desktop-era shrines demanding incantation and prostration. They’re empowering extensions to our real, actual lives - and that’s a profound thing. They take what was once prosaic or mundane, and give us just a taste of superpowers. They’re augmentations, and they should be beautiful.

You should follow me (@mattgemmell) on Twitter.

iPad as a Mac Retina Display

2012-04-06T22:40:00+01:00

With the recently-released new iPad (3rd generation) being equipped with a Retina Display, there’s now only one major category of Apple device without a very high resolution screen: the Mac. We’re sure to get a Retina Display Mac before too much longer, but you can actually preview how OS X may look on such a device right now.

Here’s what you’ll need:

A Mac, running OS X 10.7 (Lion) or later.
A new iPad (3rd generation).
Air Display from Avatron, on both the Mac (free) and the iPad ($10).
The Xcode Developer Tools (a free download from the Mac App Store), and an Apple Developer account (also free).
A local wi-fi network, that both the Mac and the iPad are connected to.

Retina Display recap

Let’s just briefly recall what a Retina Display is, in extremely simplified terms. A Retina Display is a screen that can display approximately twice as many horizontal, and twice as many vertical pixels (so four times as many pixels in total) as a regular display, in roughly the same physical area. It’s a high-resolution display.

Now, when you have a high-resolution display, you have two options for how your software (or operating system) makes use of it:

You can draw everything using the same number of pixels as before, thus making making everything physically a quarter of its old size. That means that things will be tiny, and probably hard to read.
You can draw everything at the same physical size as before, and take advantage of having four times as many pixels in that area to make everything four times as detailed. This is what iOS does with the Retina Displays on the iPhone 4/4S and the new iPad. This means everything looks much more beautiful, and the same physical size as it always was.

Here’s a composite screenshot showing the difference between regular and Retina-resolution app icons on an iPhone. The top row shows non-Retina icons at their original pixel-sizes, the middle row shows non-Retina icons scaled up to Retina dimensions, and the bottom row shows actual Retina icons. Note the increased detail in the Retina versions.

iPhone icons in regular and Retina Display sizes

We can immediately understand that the screen is only half the story; the software has to be aware of the screen, and to be able to draw things using four times as much detail. iOS knows how to do that, and behind the scenes, OS X Lion knows how to do it too.

The high-resolution support on iOS has no particular name (it’s seamless), but its equivalent on OS X goes by the name HiDPI mode. It’s also hidden to normal people, and is visible only to developers (and presumably magical folk). Let’s switch it on.

Enabling HiDPI mode

HiDPI mode can be toggled using a developer tool called Quartz Debug, which is no longer included with the Xcode Developer Tools download. Thankfully, we can still download it simply enough. The easiest way to start is to launch Xcode, and then choose Open Developer Tool from the Xcode menu, then choose More Developer Tools…

Obtaining additional developer tools from within Xcode

You’ll be taken to the Apple developer site, and you’ll have to log in before seeing a list of additional downloads. The one you want is the Graphics Tools for Xcode. It’s a disk image, so download it then double-click it to mount the volume on your Mac.

Downloading the Graphics Tools for Xcode

Inside the disk image, you’ll find various apps. The one you’re interested in is called Quartz Debug. Launch it.

Enabling HiDPI using Quartz Debug on Lion

Quartz Debug has a window called UI Resolution, containing the checkbox we need. Check the box to Enable HiDPI display modes, then log out and log back in to your account (on your Mac) to make the change take effect.

You’ll now have some intriguing HiDPI resolution options for your Mac’s screen, in the Displays pane of System Preferences. They’ll make your screen virtually smaller, but things will be drawn in more detail.

Some HiDPI resolution options for a 27" iMac

Air Display

For now, leave your Mac’s screen resolution alone, and instead take a look at Air Display (once you’ve installed it - and rebooted - it’s also shown as a preference pane in System Preferences). You’ll want to ensure that the Use Retina resolutions when available and the Enable HiDPI resolutions checkboxes are checked.

Enabling HiDPI resolutions in Air Display for Mac

Air Display allows you to wirelessly use a connected iOS device as an extra screen for your Mac, as its name pretty much implies. Very useful. Just make sure your iPad (and your Mac, if it’s a laptop) is plugged into a wall socket; Air Display can drain your battery more quickly than normal.

Launch Air Display on your iPad, and then choose your iPad’s name from the popup in the Connect tab of Air Display’s pane in System Preferences on your Mac. Since you’re adding an extra screen, your Mac’s display(s) will briefly turn blue before returning to normal.

At this point, you’ll still be using regular (non-HiDPI) mode, so your iPad will be treated as a 2048 x 1536 pixel display. This will mean that everything on it will be tiny. Here’s the same Safari window shown side-by-side on a MacBook Air 11”, and a new iPad in regular mode:

Retina iPad 3 as external non-Hi-DPI display

You probably don’t want to be squinting at tiny details on a 9.7” iPad screen, so let’s make the most of that Retina Display instead. Open the Displays pane in System Preferences again, and you’ll see that there’s also a Displays pane on every screen your Mac is using (including the iPad). Move your Mac mouse pointer onto the iPad screen, and notice that there’s a HiDPI resolution option to choose. Click to to enable HiDPI mode for the iPad’s screen.

Regular and HiDPI resolution options for an iPad 3

Your screens will go blue briefly (perhaps more than once), and will then return to normal - but your iPad is now serving as a HiDPI external screen, which is essentially a Retina Display for your Mac.

Big is beautiful

If you launch some apps on the Mac and move their windows to the iPad screen, you’ll see (in certain cases; mostly with Apple-supplied apps) that they’re drawn in much more detail, with sharper text and more beautiful interface elements. Here’s a side-by-side comparison of TextEdit in both regular and HiDPI modes:

Comparison of TextEdit in regular and HiDPI modes

And here’s Safari:

Comparison of Safari in regular and HiDPI modes

Remember that the additional detail is of course at the expense of screen space; your screen is (virtually) four times smaller than in regular mode, but is also four times more detailed. Just as it is with iOS itself. Here’s a screenshot illustrating the difference, again using Safari:

Safari on iPad 3 via Air Display - regular vs Hi-DPI modes

Conclusion

Not all apps support HiDPI mode yet, so you’ll mostly be ogling system-supplied UI elements and factory-installed Apple apps for now, but it’s an enticing preview of OS X running on a Retina Display.

High-resolution screens (and interface rendering) are not only more attractive to look at, but provide considerable benefits for text readability, reducing eye-strain, accessibility for low-vision users, detail in games, and so on. Here’s hoping for a Retina Display-equipped Mac (perhaps a MacBook Air to start with) very soon.

If you enjoyed this article, you might want to follow me (@mattgemmell) on Twitter.

Thoughts on Appsterdam

2012-04-06T14:00:00+01:00

I recently read my friend Mike Lee’s initial and follow-up posts regarding handing over the reins of Appsterdam. I was recently in Amsterdam speaking at mdevcon with Mike, and the following week we were both speaking at NSConference in Reading, England, so we had quite a bit of time to discuss both the Appsterdam initiative itself, and also his intention to alter his role there.

I wasn’t terribly surprised to read (in Mike’s second piece) that some people were either confused as to his motive, or concerned for the future of the organisation. I had a couple of similar comments from others who had read the news. I want to share a few thoughts of my own on what Appsterdam is, what it has the potential to be, and what I think about Mike’s decision.

I had the opportunity to visit the Appsterdam premises when I was in Amsterdam, and to meet many of the people who are part of the movement, and I can understand the confusion of those outside - because it’s a difficult thing to define. Indeed, I think that clarity of identity must naturally become a priority for Appsterdam as it continues to grow.

Investors, local government and even those interested in visiting or participating in Appsterdam are understandably eager to contextualise it as something familiar. Maybe it’s a social club for developers and their families, or an incubator or accelerator for app start-ups, or an adult education facility for software makers. I can’t deny that it’s any of those things, because they’re all part of its focus and goals, but none of those titles characterise it.

For me, Appsterdam is a grander (and slightly woolier) thing than that. It’s an attempt to answer a question that many of us in the software/technical industry have asked ourselves, usually in the aftermath of a particularly engaging, educational, motivation-refuelling conference or similar meeting of minds: why can’t it be like this all the time?

That question, to me, is at the root of Appsterdam’s identity - with everything around it being simply the multiple means to that end. As Mike will be delighted to tell you should you ask him, the kernel of Appsterdam was formed at the 2011 iteration of NSConference, which I’ve written about previously. That particular conference affected me, and Mike, quite profoundly. It was a perfect storm of multiple factors (some organisational, some social, and some personal) that crystallised the value of conference-like situations in the modern age. Not the dissemination of information (we have the internet for that), but rather the human aspect: the mutual interest and motivations, the sense of cooperation and shared trials, the networking, the experience of other perspectives, and the psyche-refuelling quality of being with dozens, scores or hundreds of like minds, for a single purpose.

That description trivially applies to a good conference; Appsterdam is an effort to make it apply to a community at all times. Appsterdam is an effort to distill the essence of our best (temporary) social and professional interactions, and make them persistent. The somewhat Stephen King-esque idea of a conference that goes on forever, and you can attend whenever you’d like.

For that very reason, it’s a misunderstanding to think that a single person taking a step back from organisational and directional responsibilities is somehow the death knell of the movement, because Appsterdam is as decentralised in ethos as an organisation can be. Its membership is fluid, its calendar is multivariate, and its goals are general and founded on a sense of community, rather than a budget, a fiscal year, or a release schedule.

You can’t talk to Mike for more than five minutes without realising that he has a gift for incisive analogies when speaking, and metaphors when writing. Perhaps in this case, the suitable analogy is that of the Lernaean Hydra.

The other side of Appsterdam is Mike’s own role in it, and here lies the crux of the matter. For the very reason that Appsterdam is intended to be broad, to be environmental and ambient rather than corporate and specifically-embodied, there comes a time when every individual must step back from it. In a sense, indeed, that’s Appsterdam’s ultimate function: a nutrient-rich growth culture from which other things can sprout. Not to contain, but to influence and to enable; it’s the greenhouse, not the garden.

Appsterdam can, and should, have milestones and goals, but by its nature it’s not something that can be considered to ever have “shipped”.

Mike has two primary strengths, in my experience: he has an almost unmatched ability to focus, through any degree of distraction, and he’s a master of the possible. He sees the seed of value in an idea (or lack thereof), and he intuitively understands when and where to compromise (or not). He’s a product person; indeed, he could scarcely be moreso. Mike requires a context in which he can ship.

Appsterdam has benefitted from his energy and vision, but now it requires to benefit from his example, instead - and there’s no greater legitimisation of a fundamentally social movement than to see a success story. I believe that Mike’s next venture - that of educational software for iOS - will be both of those things.

I also believe that Appsterdam is not only multi-headed enough to survive and benefit from his stepping back, but that a successful spun-off software business can only serve to fully legitimise the movement, and attract the next generation of app makers to do it all over again.

iPad 3 Retina Display Lock Screen

2012-03-16T17:25:00+00:00

Like many people, I received my new iPad (3rd generation) with Retina Display today (you can find some obligatory unboxing photos here). I often speak at conferences and take my iPad along with me, and I thus always:

Have a passcode lock enabled on the iPad (and all my other devices).
Have my contact information readily available, in case someone finds the device.

The easiest way to do this is with a custom Lock Screen image. I use a template with my business logo and my Twitter, email and phone information.

It looks a bit like this:

(I’ve changed my phone number for the purposes of the screenshot, as you’d expect.)

If you’d like to do the same, you can download the template PSD file here. You’re welcome.

You should also most certainly follow me (@mattgemmell) on Twitter.

PlayStation Vita

2012-03-04T12:00:00+00:00

I recently bought a PlayStation Vita, Sony’s new handheld games console. This article is a brief overview and review of the device, focusing on screenshots and discussion of its UI and interaction design.

All screenshots shown here are smaller than actual size (they’re two-thirds of actual size, in fact - shown here at 640 x 363, whereas the native screen size of the Vita is 960 x 544). You can click each one to go to Flickr, where you can zoom to a full-size version. I took all screenshots on the device itself, by simultaneously pressing the PS and Start buttons.

Box contents

The Vita packaging uses a swooshy blue and white colour scheme, creating a vague mental association with expensive electric toothbrushes, but we don’t hold that against the device itself.

The box includes:

The PS Vita device.
A USB cable, terminating in a proprietary connector.
A power brick, which accepts the USB cable, and a further cable with a plug.
A pack of AR cards. There are three free games on the PS Store that make use of the cards: Fireworks, Cliff Diver, and Table Football (or Table Soccer in the US).
A Getting Started Guide leaflet, running to about four A4 pages.
Assorted papers regarding safety warnings, warranties and such.

The packaging is no bigger than it needs to be, and looks to be entirely recyclable, without any foam inserts. So that’s good.

PS Vita device

The Vita itself is solid, but pleasantly light. It’s larger than a Nintendo 3DS, but not ridiculously so. Here’s a photo of both handhelds alongside an iPhone 4S.

Regarding weight, the official figures are as follows:

Apple iPhone 4S: 140g
Nintendo 3DS: 240g
Sony PS Vita (Wi-Fi, shown here): 260g
Sony PS Vita (3G, not shown): 279g

Subjectively, and perhaps due to its greater width and thickness, despite being 20g heavier than the 3DS, the Vita seems slightly lighter than Nintendo’s device. Both are comfortable to hold for extended periods.

Home screen

The Vita’s Home screen uses vertically-tiled screenfuls of 10 ‘pebbles’ (each representing either an app or game), presented in a 3-4-3 arrangement. The Home screen interface is navigated entirely using the touch-screen; the many hardware buttons (except the PS and Power buttons, of course) have no effect here.

This is the initial primary (topmost) Home screen. I’ve added LiveTweet (more about it later) to it, and changed the background colour to purple from blue. The page-indicator dots on the middle-left show that this is screen 1 of 2, with the second screen below this one.

Each screen can have its own background colour, with an automatic smooth transition between colours as you switch screens. Pebbles are freely arrangeable within the 3-4-3 constraint, and gaps are permitted anywhere. The bubble on the top-right opens the Notifications pop-over, which shows events like friend requests, app downloads, update downloads, and so forth.

If any LiveAreas (again, more on those later) are open, they can be horizontally swiped to from here. Each game you’ve inserted (or downloaded) installs an icon onto the Home screen, which persists even if the game-card (for physical retail copies of games) isn’t currently inserted into the device. Attempting to launch such games will cause the Vita to ask you to insert the relevant game-card.

The aliasing around the edges of the pebbles is much more noticeable in screenshots than it is on the device itself, because the pebbles are in constant subtle motion.

The Home screen can be put into Edit mode by tapping and holding on any pebble, or on any blank area of the screen. The first time you do so, you see an iOS-like hint dialog.

Once in Edit mode, various new interface elements appear to allow you to customise the display.

In Edit mode, you can rearrange icons or entire screens, add or remove screens, customise the background colour/pattern of each screen individually, and obtain version information and update history for relevant apps and games. Non-built-in icons can also be deleted. When changing the background colour of a screen, you’ll see a predictably-swooshy set of Sony background patterns to choose from.

You can also pick a photo from your library.

LiveAreas

The Vita’s menu system includes the amusingly-named concept of LiveAreas, which are essentially hub screens for apps or games. LiveAreas appear whenever you tap an app or game on the Home screen.

Some LiveAreas contain only a single button, to actually launch (or resume) the software, but apps/games can customise their LiveArea as they wish. The Maps LiveArea, for example, has recent directions, the browser has open tabs, and some games have links to their web site, DLC (downloadable content), and so forth.

Here’s the LiveArea for Ultimate Marvel vs Capcom 3:

This LiveArea has several actions available. Along the top, there’s a web link which searches the web for this game’s name, then the electronic manual for the game (both this game and Uncharted didn’t come with any paper manual, though Rayman did), and a button to (I believe) check for updates to the game.

In the middle of the screen, there’s a large button to visit the game’s homepage on the web, then the standard ‘Start’ button (it would be ‘Continue’, and would show a thumbnail of the game’s current state, if the game was already running), and finally a link to the Marvel vs Capcom DLC (downloadable content) in the PlayStation Store.

Finally, the orange panel at the bottom contains auto-scrolling text with a summary of the changes and additions in the most recent update to the game.

This LiveArea is reasonably typical for a Vita game, and shows the degree to which apps and games can customise the screen.

All open LiveAreas exist in a carousel of cards, tiled horizontally to the right of the Home screens (which as mentioned above, are themselves tiled vertically). You can swipe between LiveAreas (and back to the Home screen). Here, I’m swiping Uncharted’s LiveArea off the screen to the left, and bringing in the web browser’s LiveArea on the right:

LiveAreas are closed (which will also quit the app or game, if it’s running) by peeling the top-right corner away, which is suitably animated.

When using an app/game, you return to its LiveArea by pressing the PS button. If you then press the PS button again, you see a stacked “cards” screen of LiveAreas, which shows all open LiveAreas simultaneously.

You’ll also notice that the status bar at the top of the screen shows an icon for each open LiveArea besides the Home screen.

Lock screen

The Vita’s lock screen (which Sony calls the Start Screen) uses the same mechanic as closing a LiveArea: peeling the top-right corner, in this case to unlock the device. The page-corner is always visible, which is sure to drive some people crazy. You can select any photo from your library to use as the backdrop to the lock screen (view the photo in the Photos app, then choose “Use as Start Screen” from the “…” options menu).

You can add a 4-digit passcode code if you wish, which you’ll have to enter after peeling the corner.

If you enter an incorrect passcode 5 times in a row, you will no longer be able to unlock the device, and must restore it.

Brightness and Sound overlay

At any time when using the Vita, you can press and hold the PS button to see an overlay dialog.

It allows adjusting the screen’s brightness (the Vita doesn’t have an ambient light sensor), and configuring various audio-related options that you might need quick or frequent access to.

The Vita’s screen is set to about 80% brightness by default, and I’ve yet to find any reason to change it. The screen is vivid and beautiful, and easily viewable at any angle.

On-screen keyboard

The Vita’s on-screen keyboard is easy to use, with several handy features. Here’s an example of the primary keyboard:

The keyboard is extremely responsive, which is really a characteristic of the screen (only the very barest feather-touch is required; it definitely feels more responsive even than iOS devices, and multi-touch is supported).

The keyboard doesn’t autocorrect your typing, but it does provide multiple suggestions (in an extra bar that appears along the top of the keyboard). When inputting parentheses etc, matching closing characters are automatically inserted and the insertion-point placed inside them.

The letters on the keys are in uppercase in the above screenshot because the Shift key is engaged (that’s why the small indicator light within it is lit green) - when in lowercase mode, the letters are shown in lowercase, which is a nice touch that iOS could learn from.

The arrows on either side of the spacebar are cursor-keys, for easy navigation through text. You’re of course also free to tap in the text itself, and if you tap and hold, the text field will magnify to allow finer control over positioning, as in iOS. There’s also a numbers and symbols mode, available via the “@123” key.

The up/down-arrow buttons cycle through four screens of symbols, leaving the numbers always available. The num-pad layout of digits is very helpful when typing. Overall, it’s an excellent touch-screen keyboard implementation.

Game compatibility

In terms of storage media, the Vita accepts only its own game cards (and its own custom memory cards too), but the device itself is compatible with almost all PSP and Playstation minis titles, when downloaded from the PS Store. There’s already a vast array of PSP titles available to re-buy and download immediately.

The Vita also supports a new feature called Cross-Play, which is also supported on the PS3 with a system software update. For compatible titles, it allows you to begin playing on one device (PS3 or Vita), then pause the game and resume playing on the other device. There’s been word of discounts or free downloads of the ‘other’ version of suitable games when you buy one copy too. I’ve not tried it out myself yet, but for those with a PS3 too, it could be very useful (say when you’re already playing the PS3, but then your husband or wife wants to watch the TV).

Performance

In a word, the Vita’s performance is stunning. I’ve been frequently gobsmacked at the graphics, particularly in Uncharted, and the idea that a handheld device can produce such visuals. I’ve not noticed any lag or frame-rate problems, and generally the entire device reeks of quality and science fiction.

My brother, who got his Vita a few days before me, wasn’t wrong when he characterised it as being like having a PS3 in your pocket.

One particular aspect that struck me is pausing/resuming games via pressing the PS button to return to a game’s LiveArea, then tapping the relevant portion of the LiveArea to zoom back into the game and resume it. It’s completely smooth (with animated zooming transition) every time, with absolutely zero lag. You’re playing the game, then you’re zoomed out to an immediately-swipeable LiveArea/Home interface, then you zoom straight back into the game in progress. It really has to be seen to get the full effect.

Battery life

The Vita is a powerhouse of a device, with a large screen and with both Wi-Fi and Bluetooth networking capabilities (and indeed 3G, if you buy the more expensive model), all of which are notoriously draining on a battery. Thankfully, battery life is more than acceptable.

Sony’s official specs estimate around 4.5 hours of battery life, and that’s entirely in line with my own observations (and those of various online publications). A full recharge takes somewhere between 2 and 2.5 hours.

A full battery in the morning will provide more than enough power for gaming throughout two lengthy commutes, plus lunchtime and your coffee break, with power to spare. You will probably charge the machine every night, and even perhaps once during the day too if you’re a heavy user, but that’s in keeping with the Nintendo 3DS’ battery life too. External battery packs are sure to become available soon (the Vita’s built-in battery is not designed to be readily removable; there’s no battery hatch or cover on the device, since most of the back is taken up by the rear touch-panel).

File transfer

The Vita is capable of connecting (via USB) to either a PlayStation 3, or to a computer (PC or Mac). In the latter case, a piece of free desktop software from Sony called Content Manager Assistant must first be installed (you can download the Mac version here).

After connecting the USB cable and ensuring that Content Manager Assistant (CMA) is running on the computer, you tap Content Manager on the Vita’s Home Screen, then make appropriate selections, allowing you to copy apps, saved data and other content (such as photos/screenshots, music etc) between the device and the computer or PS3. You can also back up and restore data on memory cards inserted into the Vita.

I initially had connection issues with the Mac version of CMA, but they were resolved after I’d rebooted my Mac (almost certainly coincidental, as CMA is just an app that doesn’t install anything outside of its own bundle in /Applications) and set CMA to use only folders on my boot drive as destinations when copying content from the device; previously, I have it set to use my Pictures folder, which I keep on another hard drive. Since I made that change, CMA has been working flawlessly.

Update: I encountered error number C0-11018-1 when attempting to back up the Vita to my Mac. It occurred to me that I had the Vita’s USB cable connected through a rather old and cheap USB extender cable. When I switched to a newer USB extender, or connected the Vita directly to the Mac, the connection issues went away and I was able to backup successfully.

PlayStation Store

The Vita naturally includes a PlayStation Store app, allowing you to buy games and downloadable content (including renting or buying movies).

A most welcome feature of the Vita is that it supports true background downloads, with a progress bar always being available in the global Notifications pop-over when you’re either at the Home screens or in a LiveArea.

It seems that Sony are releasing all games simultaneously in both retail packaging, and as electronic downloads. The prices on the PlayStation Store seem to be the same as retail too (or even slightly less), which is refreshing - though note that if you’re going to download your games, you’ll of course need appropriate storage space on Sony’s painfully pricey proprietary Vita memory-cards.

As mentioned before, the Store offers not only Vita, but also PSP and PlayStation minis titles too.

Near

Near is an app that allows you to find nearby Vita players and see what they’re playing (if they’ve explicitly opted-into that functionality, of course). You can choose whether to share your PSN online ID (if you don’t, you’ll be shown anonymously), and Near maintains a history of your location updates (which seem to be throttled to once per hour, at least in the same location).

The exact distance within which people are considered to be “nearby” isn’t stated, but various online forums suggest it’s likely to be in the 10 miles (about 16km) range. Here in Edinburgh, Scotland (UK), I found fifty nearby Vita owners on the morning of 6th March 2012. It’s important to note that only the relative proximity of players is shown; you can’t find anyone else’s actual physical location, nor can they find yours. The “Radar” display is strictly an abstract radar-like screen, and is not overlaid on (nor does it precisely correspond to) a real map.

The games a person owns and is playing are shown, with a badge to indicate whether you also own that game (or app). Finding a player who has a game you do not yet own is considered a “discovery”. It’s also possible to exchange virtual goodies between non-anonymous players, though I’ve yet to try it.

Near is a well-implemented feature, though I remain skeptical as to its utility for anything more than passing interest. Knowing the approximate proximity of other players isn’t necessary for online gaming, and the system (thankfully) offers no way to pinpoint actual locations, nor to directly communicate with anyone who isn’t already on your PSN Friends list.

It’s worth noting that Sony has clearly considered the privacy and security implications of Near, taking care not to offer anything but a very general sense of “nearness”, and allowing fully anonymous use. Near also allows setting up a list of Private Games (games about which your usage data will not be shared), and (more importantly) Private Zones: physical locations from which you will always appear as anonymous, regardless of whether you’ve chosen to share your PSN online ID generally. Your own home address would presumably be a primary example.

System features

There are various additional system features provided, including but not limited to:

Front- and rear-facing (single) cameras, and an app to take photos and browse your existing photos and screenshots.
A global notifications system, with history. New notifications can optionally play a sound and/or illuminate the PS button, as well as displaying a banner when the device is active.
PSN (PlayStation Network) support, with trophies, friends, messaging, group chat, etc.
A web browser.
Screenshots can be taken (almost) anywhere by pressing PS and Start simultaneously. Screenshots are viewable in the Photos app, and are handily categorised as screenshots rather than photos, and grouped according to the app or game you were using when you took them.
Games can choose to disable certain system features if they wish. For example, Marvel vs Capcom disables screenshots (ostensibly to avoid spoilers), and Uncharted disables network features at certain points in order to maximise performance. Games can also annotate or otherwise modify screenshots taken while they’re running (for example, Uncharted adds the name of the game in small text on the bottom-right).

The web browser is capable and responsive. I very much miss iOS’ intelligent content-aware double-tap to zoom, though.

LiveTweet

Whilst the Vita does not ship with a Twitter app, there’s one available as a free download from the Store, called LiveTweet. It’s remarkably fully-featured and usable.

The UI is reminiscent of Tweetie (now the official Twitter app) on OS X, with a set of side-tab icons for the various sections. It even supports pull-to-refresh, which is a relief. There’s also a cute visual touch whereby if you’re writing a reply, you see the tweet that you’re replying to in a thought-balloon attached to your user photo.

Posting tweets, viewing embedded media, favourites, user profiles, mentions, direct messages, lists and so forth are all supported too.

There’s an interesting hierarchical navigation interface, using a vertical bar (with a grip-strip) just to the right of the main icon tab-bar.

Tapping the bar expands it to show a bar for each level of the hierarchy you’ve navigated, and tapping any bar will take you back up to that level. Successive levels are automatically colour-coded to visually distinguish them. It’s simple and effective.

There are a couple of rough edges at the moment (every apostrophe in any displayed tweet seems to have a superfluous space after it, for example, and neither emoji nor graphical representations of plain-text emoticons are currently supported), but those are minor quibbles which are sure to be ironed out in future.

LiveTweet is an impressive Twitter app, all the more so for being a 1.0 on a new platform. Given that it’s also entirely free, every Vita owner should make sure they have it.

Vita or 3DS?

The Vita and the Nintendo 3DS are so different as to not be meaningfully comparable. Both devices support a huge library of older games as well as their own (the 3DS supporting DS game-cards too), and both are excellent gaming machines that each have compelling titles already available.

Make a decision based on the games you want to play, not on irrelevant and superficial factors like graphics. Either device is an excellent choice. Pick one, and buy it - or get both. Neither detracts from the other, no matter what children on web forums might say.

Final thoughts

The Vita is a compelling device, with exceptionally impressive performance, reasonable battery life, and a usable, responsive user interface. There aren’t any major down-sides or problems that I’ve noticed.

It’s sure to get plenty of attention and big-name titles, including new instalments of the various beloved Sony game franchises. If you’re in the market for a portable gaming device, I can recommend it without hesitation - as I equally would for the Nintendo 3DS (which I reviewed earlier), and any iOS device.

If you’re interested in buying a PS Vita, Amazon (as ever) have some good deals. If you’re in the UK and want to buy a Vita from Amazon UK using this link, I’ll get a modest commission, and it won’t affect the price you pay. I also have a number of Vita games on my Amazon Wishlist (ahem).

If you’re like to share your thoughts on the Vita or any other topic, You should follow me (@mattgemmell) on Twitter. If you’d like to add me on PSN, I’m also mattgemmell (two Ts, two Ms, two Ls) there.

Footnote

After I published this article, I found a useful list of PS Vita error codes and their meanings.

Supporting this blog

2012-02-28T21:00:00+00:00

I’m happy to to say that 2012 has started very well for mattgemmell.com. Quite a few of my articles in the past two months have attracted considerable traffic and given rise to interesting follow-ups elsewhere on the web.

Some of the most popular articles so far include:

I’m thoroughly enjoying my more regular writing schedule, and I’m gratified that many of you are similarly enjoying the pieces I write.

Naturally, there are costs involved in maintaining this blog (not just bandwidth and hosting, but time - indeed, that’s the major cost). I write because I’m compelled to do so, and I doubt that will ever change.

If you want to support my writing (and indeed open source code releases) here, there are a couple of ways that you can help:

Donations

Let me pre-empt the inevitable response by saying “PayPal - boo!” Indeed; I fully agree. I’m looking to move away from their services, but for now it’ll do. If you wish to make a donation of any amount at all, you can click the button below.

Your generosity is very much appreciated.

Source code licenses without attribution

My Cocoa and iOS source code is always free for you to use, and requires you to include an attribution in your app, mentioning me and the name of the piece of code you used.

In some situations, that’s a hassle (or even impossible), so I offer non-attribution licenses for a modest fee. I’ve decided to have a frankly ridiculous sale for the next few days, so if you did ever want to get a non-attribution license, now would certainly be the time.

The online license store can be found here.

Final thoughts

I look forward to continuing to write on any number of topics here, and I hope you’ll continue to read. If you prefer much, much shorter chunks of text, you might want to follow me (@mattgemmell) on Twitter.

The Piracy Threshold

2012-02-17T18:00:00+00:00

Music and movie industries, you’re well-known for being incredibly short-sighted, greedy and stupid. I’m not going to argue with that, because you really are.

All right-thinking, rational people look upon your recent efforts towards creating further draconian legislation (such as SOPA and ACTA) with disdain and dismay, because you’re once again looking in the wrong place for the source of your problems.

Let me make this perfectly clear: piracy is your own fault.

You’ve got the whole situation almost exactly backwards. You laughably think that:

Piracy is an unfixable social disorder.
Piracy happens because of a lack of effective security measures.
Piracy is the consumer’s fault.

Congratulations on that big, perfect zero score. Stepping outside the remedial school for a moment, here’s the revelation:

Piracy is a readily-fixable customer experience problem.
Piracy happens because you’re fucking people (notably, via pricing).
Piracy is your fault.

The experience of almost every media-consuming human being on the internet is summed up by the following graph.

When honesty becomes too difficult, dishonesty is easier.

The majority of people have a basic desire to be honest - and I mean actually honest, rather than some limited definition based strictly on the law. People will go to reasonable lengths to be honest. It makes us feel good about ourselves, and it confers a certain immunity from legal problems.

But then you fuck us. First you fuck us with exorbitant pricing. Then you fuck us with inconvenience by not making your content universally available when we want it. Then you fuck us by treating every paying customer like a criminal.

Fucked by money, fucked by convenience, and fucked by judgement. We know that you hate us, and you’d better be aware that we absolutely hate you too.

So, since you pushed us too far, we decide to fuck you back, by “stealing” your content. In return, we get a better experience all round than if we’d actually purchased it on your primitive spinning discs or in your Orwellian DRM-encumbered digital formats.

I’m a developer, and I know a lot of other developers. Pretty much everyone I know has purchased some of your DRM-encrusted media, then stripped the DRM so they can consume their media in the way they want to. Pretty much everyone. They don’t see that as a criminal act, and they never will. Similarly, pretty much everyone I know feels that it’s absolutely acceptable to download a digital copy of something they already own on a spinning disc. Both of these common practices indicate that there’s an enormous problem with the “solution” of using DRM.

The vast majority of people are happy to buy your stuff, but only if you’re reasonable about it. £10 for a movie isn’t reasonable; it’s greedy. People don’t feel that’s the right price. We’re not asking to get things for free, but we’re not willing to be fucked.

We’ll buy stuff if it’s convenient to do so, and if the price is reasonable. Any sensible business would thus have as its goal “make our stuff convenient to buy, and price it reasonably”. You, however, suffer from some kind of brain cancer where your goal becomes “find ways to force people to buy our stuff regardless of how inconvenient and extortionate it is”.

Well, fuck you. There’s always going to be some kid who can find a way around your next big DRM scheme. There’s always going to be a teenager who places zero value on their own time, and will gladly spend days just to know that, in the end, they fucked you back just a little bit. It’s a losing battle for you, and it’s insane to even participate.

Piracy can never be completely eradicated, because there are always going to be criminals, and there are always going to be brain-addled, hormone crazed teenagers on the internet.

Teenagers grow up, though, and criminals are a tiny minority. Meanwhile, there’s the rest of the entire adult world who are delighted to pay a reasonable price for convenient access to your stuff. The same people who hate being treated like criminals, and who really hate feeling that they’ve been robbed.

Give us convenient content at a reasonable price, and we’ll buy it. Sell the stuff without DRM, for a few dollars. Make it available to everyone, worldwide, at the same time. Then take the massive, unending pile of money, forever.

Or keep doing what you’re doing, and enjoy your ceaseless war of attrition, ever-rising tide of negative public opinion, and eventual forced irrelevance. And get fucked.

(Got a comment? I’m @mattgemmell on Twitter.)

Sleazy promotions

2012-02-14T15:30:00+00:00

Social media has transformed the way that promotions and competitions are run, and not always in a positive way. The temptation to offload marketing onto customers can be difficult to resist, and too many companies forget (or choose to ignore) that many customers rightly see such tactics as sleazy and disrespectful.

Everyone knows that the purpose of a competition is not to give away a prize, but rather to generate interest in (and revenue for) the maker of the prize, and/or the organisation that’s running the competition. That’s fine, and is an inseparable part of our culture - but it’s not carte blanche to treat entrants any way you like.

There’s an understanding that the price of entering a “free” giveaway is that you’ll be exposed to marketing, in some form. That’s an unpleasant and intrusive thing, hence my use of the word ‘price’. Social media has created new categories of marketing-exposure that can be actively damaging to not only the entrant or customer, but also the reputation of the companies involved.

In terms of the customer’s exposure to marketing, there are three main types of promotion that I see regularly. Let’s talk about them individually.

One-time personal exposure

In this scenario, you alone are exposed to marketing, once. This is true of any competition, since you must have become aware of the competition in order to enter it, and by entering you’ve already visited the relevant site.

It’s only a one-time personal exposure if the competition entry mechanism is a private, single-user experience, such as an entry form. This is a fair and sensible mechanism, and I doubt that any reasonable person would take issue with it. Before the internet, many competitions took either this form or the next.

Repeated personal exposure

In this scenario, you alone are exposed to marketing on multiple occasions. This is true of any competition where any of the following apply:

You are automatically signed up to an email (or postal) distribution list upon entering.
You require to ‘follow’ a given Twitter account (or equivalent) in order to enter.
Your contact details are sold to other companies.
You require to do more than simply enter the competition on one occasion, such as checking back later for some reason.

This competition mechanic was the most common before the internet. Entering almost any competition would result in postal mail or (later) email, or even phone calls. Some countries have sufficiently evolved consumer protection legislation to insist that such follow-up exposures are opt-in, but some less advanced jurisdictions still permit an opt-out system, and all of the abuses of trust and privacy which such a system invites and entails. In this type of promotion, the cost of entering is likely to exceed the perceived value of doing so.

People are becoming more educated about privacy and about their exposure to marketing, so examples of this type of promotion are becoming marginally less common. Arriving to fill its place, however, is a significantly worse phenomenon.

Self-propagated exposure

In this scenario, you become the advertisement, and are an accomplice to the marketing exposure of many other people.

Examples are unfortunately commonplace:

Tweet to enter.
Retweet to enter.
‘Like’ on Facebook (or functionally similar) to enter.
Comment/respond publicly to enter (in a way that’s propagated, such as on Facebook).
“Pay with a Tweet” to obtain extra value or some kind (such as additional apps in a software bundle, additional license rights for artwork, etc).

All of these are blatantly abusive, and should never be used as the sole method of participating in a competition or other promotion. They are greedy and sleazy, of course, but far more importantly they undermine the integrity of the entrant within their own social group. It’s difficult to overstate the magnitude of this immorality.

It’s bad enough trying to artificially turn a prospective customer into a delivery mechanism for your marketing, but requiring that they advertise to their chosen social circle is nothing less than appalling. The customer’s credibility, impartiality, judgement, taste and sense of personal ethics are all assaulted if they choose to take part in such a promotion, and the existence of the promotion invites such an assault.

To argue that the promotion itself is alright, and that if the customer chooses to participate then it’s their own fault, is akin to denouncing cancer warning labels on cigarettes, or disagreeing with bans on cut-price alcohol promotions. It’s monstrous to divorce responsibility for availability from that for consumption. Such sophistry is only yet another warning sign that the speaker’s handshake is likely to be slippery.

Those who are responsible for such promotions (and be aware that it’s almost never the customer-facing staff, but rather inaccessible marketing departments, executives, strategic partners and other stakeholders) are choosing to damage your personal standing and character in order to sell their product, in a far more egregious way than marketing has ever managed to do before.

A self-respecting person should choose to devote their attention to other, less blatantly disrespectful organisations and brands.

Hashing for privacy in social apps

2012-02-11T20:50:00+00:00

Three days ago, Arun Thampi blogged about his discovery that the Path social networking app uploads the user’s entire iPhone address book to its servers. There’s been extensive industry media coverage of this, and a new version of Path has been released which now asks for permission before uploading your contacts’ information. The CEO of Path, Dave Morin (@DaveMorin), also apologised for the fiasco in a blog post.

Once the story broke, I noted that Morin had posted a comment on Thampi’s piece, and I replied to that comment, asking (amongst other things) why they hadn’t used hashing instead of uploading the raw contact information. Morin’s reply to me was straightforward and honest on that point, if somewhat surprising:

This is a good alternative solution which we’ll look into. Thanks for the idea.
Dave Morin mclov.in/2012/02/08/…

Morin is not a “youngster” - an article from 28th December 2011 says that he’s 30 years old - so we’re not talking about a brash teenager. Nor are we talking about a management figure with no technical experience; the same article describes his previous role as a key platform engineer at Facebook.

I’m 32 (and a half) years old, at time of writing in early February 2012, so Morin and I work in the same field and are of approximately the same age. The difference is, I not only immediately thought of hashing as an appropriate measure, but was shocked that Path hadn’t implemented their app and servers that way. Nonetheless, this isn’t an isolated example.

From talking to many developers about this privacy intrusion during the past week, it quickly became disturbingly clear to me that many aren’t familiar with hashing at all. This is also predictably (and entirely forgivably) true for the many journalists who have covered the story, unintentionally distorting the issue due to lack of education in the field.

This article, therefore, aims to introduce the concept of hashing in a clear, straightforward, and no-degree-required way, suitable for journalists and casual readers as well as programmers and software engineers. I’ll also explain why it’s suitable for preserving the privacy of contact information whilst still allowing for social functionality, and I’ll touch on whether or not you really need to store that contact information (hashed or not) in the first place.

The false dilemma of privacy vs social features

Let’s consider how the Path (et al) privacy uproar started. It’s simple enough to understand:

Path is a social network, and wants to make it easy for new users to connect with their friends.
An obvious way to do this is to check whether any existing Path user is also a friend of a person who’s just joined. Let’s call this new user Bob, and let’s say there’s an existing Path user called Jane, who Bob happens to know outside of Path.
It’s reasonable to assume that if Bob has Jane’s email address on his iPhone, then Jane is in some sense his friend, and that Bob might want to be connected with Jane on Path.
Thus, a naive developer of the Path app would copy all the email addresses from Bob’s address book on his iPhone, upload them to Path’s servers, search for any matches amongst Path’s other users, and offer to connect Bob to those people. Simple.

Herein lies the (false) dilemma: you’re getting a handy social feature (automatic connection with your friends), but you’re losing your privacy (by allowing your friends’ email addresses to be uploaded to Path’s servers). As a matter of fact, your friends are also losing their privacy too.

What an awful choice to have to make! If only there was a third option!

For fun, let’s have a think about what that third option would be.

Mathematics, not magic

Hypothetically, what we want is something that sounds impossible:

Some way (let’s call it a Magic Spell) to change some personal info (like an email address) into something else, so it no longer looks like an email address and can’t be used as one. Let’s call this new thing Gibberish.
It must be impossible (or at least very time-consuming) to change the Gibberish back into the original email address (i.e. to undo the Magic Spell).
We still need a way to compare two pieces of Gibberish to see if they’re the same.

Clearly, that’s an impossible set of demands.

Except that it’s not impossible at all.

We’ve just described hashing, which is a perfectly real and readily-available thing. Unlike almost all forms of magic, it does actually exist - and like all actually-existing forms of magic, it’s based entirely on mathematics. Science to the rescue!

Now, as mind-blowing as it is to learn that our impossible demands are actually eminently satisfiable, here’s something even more mind-blowing: you’ve already seen hashing at work, and you’ve maybe even seen some Gibberish!

Don’t believe me? I don’t blame you. But just like The Silence from Doctor Who, Gibberish is hiding in plain sight, and you’ll forget about it as soon as you’ve seen it. It might be behind you right now! Allow me to present a (somewhat less terrifying) example.

Have you ever heard of OpenOffice? It’s an open source suite of productivity applications, a bit like Microsoft Office, but the crappy UX doesn’t cost anything. If you wanted to download OpenOffice, you would visit this download page. Go and have a look, if you like. No scary suit-wearing hypno-aliens to be found.

OR ARE THERE?

Take a closer look at the first download box; the green one. It looks like this:

Part of the OpenOffice download page.

Normal enough. Most people just click it, the download starts, and they move on to something else. They do not see.

There’s something strange about that big, green down-arrow graphic. Something… sinister. Look at it, sitting there. Malevolently.

Though the placement is coincidental (due to the browser window’s width when I took the screenshot), that arrow is pointing at something. Something barely intelligible, like a foreign language. It says “MD5 checksums”. The hairs on the back of your neck begin to stand on end. Let’s say you clicked the link, unsuspectingly. The horrible truth would be laid bare:

BLAARGH!

OK, that’s not really what you’d see. Instead, you’d see this file, which looks like this:

Gibberish on a server.

Rows and rows of data, in two columns. The second column quite clearly contains filenames. The first column is of course - wait for it - Gibberish.

Let’s try another example. This time, it’s in your computer. On Mac OS X, try going to this folder: ~/Library/Caches/com.apple.Safari/Webpage Previews. Here’s what mine looks like:

Gibberish inside your computer.

There are over five thousand files in that folder, here on my Mac. Look at the filenames. Inside your own computer, right here within arm’s reach. Gibberish.

Like The Silence, it hides everywhere, and you forget it as soon as you look away. But it’s still always there. YOU WILL NEVER SLEEP AGAIN.

A bit more factually, if you please

The two examples of Gibberish above illustrate two different common uses of hashing:

Creating a checksum of a file.
Creating a unique identifier.

A checksum lets you verify that your copy of a file is identical to the original, for example so that you know it wasn’t corrupted during download. It’s not enough to check that the file size is the same, because you can have two pieces of data that are the same length but are nonetheless different. For example, say a person’s name was ”Neil Inglis”, which is 11 characters in length. That’s unquestionably different from another 11-characters-long name, such as, say, “Arse Badger”.

Thus, we need to know that every part of the file is the same (to a reasonably high level of probability). Hashing lets us do that. The person hosting the file runs a program which generates a hash (Gibberish) that represents (but does not contain; it’s not like a zip file or such) the file. After you download the file, you also run the same program to generate a hash. If the two hashes match, your copy of the file is identical to the original, and you don’t need to download OpenOffice all over again.

You can also use hashes to generate unique identifiers. In our second example, Safari (the web browser, on Mac OS X in this case) has created preview images of web pages that I’ve visited - presumably to show in its Top Sites view, or for some other purpose. Instead of naming those JPEG files with the URL of the web page, which could be exceptionally long and horrible, Safari instead generates some Gibberish (almost certainly based on the URL), giving a consistent length of only-slightly-horrible filename. To find the preview JPEG for a given URL, Safari simply re-generates the Gibberish from a given URL, then checks to see if it has a JPEG with that Gibberish filename. That’s hashing.

There’s a third possible use of hashing, too (and a fourth, and a fifth, and many others), and that’s to anonymise data but still allow matching. If you think about it, that’s obvious from what we’ve already discussed. Here’s the workflow, once again using Path as an example.

Bob signs up to Path, using the iPhone app.
The app asks if it can use Bob’s contact info to find his friends.
The app hashes the email addresses of everyone in Bob’s address book.
Only the hashes are uploaded to Path’s servers. Just the Gibberish.
Path’s servers store the hashed (Gibberish) version of every user’s email address.
Path’s server searches for Bob’s friends’ hashed email addresses in their database of hashed email addresses. Because you always get the same Gibberish whenever you hash a given email address, you can still match them up even though you don’t know what the original email address looks like. “GLORB” = “GLORB”, just as “you@domain.com” = “you@domain.com”.
Bob finds his friends just as easily as if Path had uploaded their actual email addresses.
Path then deletes all the hashed email addresses they uploaded from Bob’s iPhone.

Everyone is happy. Your social friend-finding features are intact, and every bit as convenient as before. But, none of your friends’ email addresses are ever uploaded (in a readable, usable form) to some company’s server. Privacy is preserved along with convenience. It’s a mathematical miracle. SCIENCE, MOTHERFUCKER. DO YOU SPEAK IT?

Boring geek stuff, in brief

Your brain may be complaining about the concept of being able to transform an email address into Gibberish easily, but not being able to reverse the process. I can understand that it’s not an intuitive thing - it is nevertheless a mathematical reality, and commonplace. Those wishing to learn more, or simply to cite a reference on the subject, should read the wikipedia page on cryptographic hash functions, and particularly the concept of a one-way function.

You may raise an objection about using a given standard hashing function as-is. You’ll want to read about the concept of salt (in the cryptographic sense).

You may complain that I’ve not suggested a specific hashing function or algorithm; this is deliberate. I invite you to educate yourself on your choices, and make an informed decision that’s suitable for the time period and technological environment in which you’ve read this article. You’ll want to pay particular attention to contemporary security industry assessments of your proposed hashing function.

Common counterarguments

There follows a list of anticipated counterarguments, shrink-wrapped with rejoinders of varying degrees of flippancy and superciliousness.

Hashing isn’t absolutely perfect in every way!

This is no way invalidates the fact that it’s a hell of a lot better than storing plain contact information, like a crazy person.

(Some specific hash function) is vulnerable to (dictionary attacks, or something)!

Maybe, and maybe not. Salt helps a lot. Security is a percentages game. Never use just one security method. See previous counterargument.

Actually, technically, you’re wrong about (something)!

Quite possibly, but not in a way that meaningfully alters this article. I explained the concept of hashing. I showed how it can be easily used to address the latest flap of privacy concerns in social media apps. I did all of the above with charm, panache, and in a manner that even grunting tech journos have a sporting chance of grasping. I shall now retire to an expensive armchair and bask in the warm glow of a job well done.

Hashing won’t work if the data format varies, like with email aliases or phone numbers!

The argument here is that sometimes, the same data can be formatted in several different ways, and the different versions will of course each produce different hashes. Your copy of my phone number, for example, might include my county-code (+44, for the UK), whereas my copy of it probably doesn’t. Similarly, two apparently different email addresses can in fact be one and the same, such as foo@googlemail.com and foo@gmail.com, or foo.bar@gmail.com and foobar@gmail.com.

You’d think that’d be a problem, but it’s not - and it’s actually another example of a straightforward Computing Science principle that’s worryingly poorly-known amongst developers. The answer, of course, is normalisation: the conversion of the various alternate formats of a given piece of data into one definitive (canonical) format. In the case of phone numbers, this would presumably be a full international number with standardised spacing. In the case of email addresses, I defer to the lecturer who taught my Operating Systems, and Distributed Algorithms and Systems Honours courses at university, Dr. Peter Dickman:

There are relatively few such rewriting rules and they are quickly and easily expressed in a compact form using some more magic, called regular expressions. Instead of uploading the original email addresses and doing the matching at the server, it’s perfectly possible to download those rewrite rules along with the hashing software and do a tiny magic trick, called normalisation, at the client’s device immediately before applying the hashing. This would ensure that the hash values come out the same regardless of which of the equivalent forms was used in the address book.
Dr. Peter Dickman plus.google.com/posts/…

My thanks to Peter (now at Google in Zurich) for writing to me this evening and suggesting this additional counterargument and response (and indeed for his significant part in my formal Computing Science education).

On the storing of personal information

The astute reader (cue everyone tensing up imperceptibly) will have noticed that it’s not actually necessary to keep any user data after you’ve found their friends. Take another look at the workflow for a hashing-enabled Path app, above. The last step deletes all the uploaded hashed data, and the whole friend-finding process still works. Instapaper does it this way, according to a tweet from its creator Marco Arment earlier today.

There’s only one situation where you might argue that it’s necessary to store a user’s address book info for later (hashed or otherwise). It’s this:

Jane signs up for Path, a week after Bob has signed up.
Bob has Jane in his address book, but Jane does not have Bob in hers.
When Path searches for Jane’s friends, it will obviously not find Bob (since it uses Jane’s address book). Thus, Bob will never know that Jane has signed up, and will not be automatically connected to her.

The thinking here is that, if you stored a person’s entire address book, when you were searching for friends you could search not only your other users, but also their entire address books. This would deal with the situation above, and would allow Bob to know that Jane has joined Path even though they didn’t join at the same time.

That’s good for Path, because social networks live and die by the number of connections people make on them. I don’t think it’s great for Jane, though. The fact that Bob isn’t in Jane’s address book shows that, for whatever reason, Jane doesn’t consider him a close acquaintance. She probably doesn’t care that she won’t be automatically connected to him, and doesn’t want him to be notified when she joins Path. That seems like common sense to me. So, I think that this particular scenario is a false one, at least from the user’s point of view.

Update: Dr. Peter Dickman (mentioned previously) emailed me to point out that Jane could also be upset even if Path did not store each user’s address book. If Jane (still without Bob in her address book) joined Path before Bob, then when Bob joined and his address book was used to find his friends, Path would naturally connect him with Jane (since she is in his address book). That’s a privacy flaw in the concept of using address books on a temporary basis to find “friends”: it doesn’t ensure that the relationship is symmetrical (or bi-directional).

In this situation, keeping each user’s entire address book on the server would allow checking to see if a given relationship was symmetrical. My own opinion is that, for information-exposing services (like Facebook, Path, iOS’ “Find My Friends”, etc), the only valid and justifiable automated connection is a symmetrical one.

Peter also points out a third scenario: that of the mutual acquaintance. Consider both Bob and Jane once more, but with a third person whom we’ll call Alice. Bob and Alice both have Jane in their respective address books, but Bob and Alice don’t know each other (i.e. Jane is their mutual acquaintance, but they themselves are not acquainted). In this scenario, let’s imagine that Jane does not sign up for Path, but both Bob and Alice do.

It could be argued that it might be a useful feature if Path could tell Bob and Alice that they have a mutual acquaintance (this would encourage connection-forming, and would also encourage Bob and/or Alice to invite Jane to join too). This raises a grave privacy concern. Perhaps Bob knows Jane from work, but Alice knows Jane in some other capacity that Jane wouldn’t want Bob to know about (such as being a member of a Take That fanclub). If Path were to keep a hashed copy of each person’s address book, it could tell Bob and Alice that they had someone in common, even if it didn’t say who - and Bob and Alice could then potentially work out that the person was Jane, which would cause irreparable damage to Jane’s career when she was outed as a fan of terrible, terrible ‘music’.

In this case, the lesson is that there can be unforeseen repercussions from revealing aspects of a social graph, even if identities are kept anonymous. A conservative and well-considered approach is strongly advised.

Final thoughts

If you’re a developer who’s implementing a social network, please do these things:

Educate yourself about hashing; it’s real, and very useful. Use hashing for personal info. Do the hashing client-side, and only upload hashed data for comparison on the server.
Delete the hashed data after you’ve done your fancy friend-matching stuff, because your users value their privacy, and you probably don’t even need to keep the data anyway.

If you’re a journalist or other non-developer who’s writing about social media and privacy, please do these things:

Know pretty much what hashing is, at least in terms of the Incredible Magic it lets you do.
Realise and understand that privacy and social features are not mutually exclusive. Don’t pull that ignorant false dichotomy bullshit; it’s factually incorrect and laughable.

And regardless of who you are, if you have any taste whatsoever:

Follow me (@mattgemmell) on Twitter.

Using PDF images in iOS apps

2012-02-10T16:40:00+00:00

iPhone developers are familiar with having to provide artwork at both regular and Retina (doubled) pixel dimensions for their apps. With rumours of a Retina Display-equipped iPad being just around the corner, it’s wise to consider moving to fully scaleable vector artwork for as much of your app’s images (such as toolbar icons) as possible.

This brief post outlines how to get your artwork from Photoshop as suitably compressed PDFs, then use those PDFs in your iOS apps.

In this article, I’ll be using a simple piece of artwork as an example: the “close” or “delete” button that appears at the top-left of icons on your Home screen when you put it into move/edit mode (which I call jiggle mode, since you ask). I drew the icon as vectors in Photoshop, at Retina-suitable size, and it looks like this:

Close Button, at (nominal) actual size.

Since it’s entirely made of vectors, we can resize it whilst keeping it sharp. Here’s the same icon, scaled up:

Close Button, scaled up.

Our task is now to get the icon from Photoshop as a vector file, optimise that file, and use it in iOS.

Getting PDFs from Photoshop

We won’t be using Save For Web in this case, as you would if you were saving bitmap (PNG) artwork for an app. Instead, choose the Save As command from the File menu. Choose the Photoshop PDF format from the pop-up menu.

Save As Photoshop PDF.

You’ll now see a secondary dialog, containing options specific to PDF-generation. As long as your artwork is entirely vector-based, you should choose the Smallest File Size preset from the first pop-up menu.

Save Adobe PDF options dialog.

You’ll now have a PDF file which you can use as-is, but we can improve it by making its file-size smaller.

Making Photoshop PDFs smaller

PDFs from Photoshop are larger than they need to be for use in iOS apps. Mac OS X’s PDF processor can make them smaller by stripping out the extraneous data, without affecting your ability to resize them.

The wonderful Panic has made a nice little drag-and-drop utility called ShrinkIt which re-saves PDFs in this way, and it’s completely free. You can download ShrinkIt here.

I did a quick test using the Close Button PDF from Photoshop, having exported versions of it using the “High Quality Print” preset, and also the “Smallest File Size” preset. The resulting file-sizes are below.

“High Quality Print” setting: 57 KB
“Smallest File Size” setting: 53 KB
As (1), after ShrinkIt: 12 KB
As (2), after ShrinkIt: 8 KB

As you can see, using the Smallest File Size setting and then running the PDF through ShrinkIt results in a file that’s more than 85% smaller.

If you don’t want to use ShrinkIt for some reason, you can also just open the PDF in Preview (included with OS X), then choose Export and save the file as a PDF with a new name. That will produce the same reduction in file-size that ShrinkIt provides, but is somewhat less convenient. Note that if you do use Preview, do not use any Quartz Filters - particularly not the “Reduce File Size” filter, which paradoxically will often considerably increase the file size.

Using PDF images in iOS apps

There’s nothing particularly difficult about loading and rendering PDF files as images on iOS, but for the sake of simplicity, I’d recommend using Nigel Timothy Barber’s UIImage+PDF category on github. The category makes it trivially easy to display PDF images in your app.

Downloads

If you’re interested in the Close Button icon used as an example, you can grab it in a couple of formats:

Final thoughts

Resolution-independent artwork and interfaces are the way forward, and save you time (and design expense) in the long run.

To keep up to date with new articles here, and/or for pithy, interesting commentary in bite-sized chunks, you should most certainly follow me (@mattgemmell) on Twitter without further delay.

Etched effects in Photoshop

2012-02-06T16:30:00+00:00

My previous Photoshop tutorial on using noise for subtle texture was well received, so I’ve decided to write more. This time, we’re creating an etched effect (in this case, for text on a metallic background, but it’ll work for any background and is equally applicable to icons and other shapes, as well as text).

It’s exceptionally easy to create an etched effect, since we only need to replicate two aspects of how shapes look in the real world when they’re cut into a surface:

The natural shadows inside the cut-out part.
The subtle pools of light falling onto the front edges of the cut-out part.

To start, create a new document and fill it with a suitable background. I chose a simple gradient layer with a grey gradient, to give a basically metallic appearance. I then added some text, and made it a bit darker than the darkest colour used in the gradient.

Some text, with a gradient in the background.

We only need to apply two effects to create the etched effect; one for each of the visual factors I mentioned previously. First, we create the interior shadow using the Inner Shadow layer effect.

Inner Shadow settings.

You can tweak the settings to adjust the apparent visual depth of the etching, but I find that a Distance of 2 pixels and a Size of 4 pixels works well for a believable effect. Make sure you set the light angle to 90 degrees if you’re designing for iOS, or whatever global light angle your particular target platform simulates.

Next, we need to replicate the effect of light spilling a little way into the carved-out shapes. Interestingly, we can do this by making unconventional use of the Drop Shadow layer effect.

Drop Shadow settings.

By changing the shadow to pure white, with a Normal blending mode, and making it only 1 pixel in Size and 1 pixel in Distance from the layer’s contents, we can create the impression of some light reflecting along the bottom edge of whatever is in the layer (the text, in our case).

Both those styles put together create a pretty decent etched effect for the text, as shown below.

The final etched effect.

The same Layer Style can be copied and pasted onto any other shape or icon you like - it’s great for titlebars and similar interfaces. You can download the finished etched effect as a zipped PSD here.

If you’re interested in more beginners’ UI effects tutorials for Photoshop, follow me on Twitter and let me know.

How Developers Can Help Designers

2012-02-06T14:00:00+00:00

This article is a follow-up to my previous one, How Designers Can Help Developers, and covers the reciprocal situation. As developers who work with designers, it’s our job to make that cooperation as smooth and easy as possible.

The spec

Know what you want

The most difficult part of commissioning a graphic design job is knowing the sort of result you want. There can be a tendency to just ask your designer to “make something” - and they will, but it may not be what you’re after. You wouldn’t accept a requirements specification for a development job that was too vague to work with, and designers aren’t any more psychic than you are. Devote sufficient time to narrowing down the sort of work you’re looking for.

Examples are helpful

If you don’t have a strong concept in mind, you probably at least have preferences. Put together some samples of things you do and don’t like, noting what aspects you’re responding to, and why. Other people’s work is fine, as are portfolio pieces by your actual designer. Often, the process of putting together these sample likes and dislikes will help clarify your vision for the work you want done.

Trust your designer

A wise person uses the talents of others, instead of trying to muddle through alone. Trust your designer’s skills and experience. Don’t treat designers as scribes for artwork; allow them the flexibility to contribute and to delight you. Don’t be too prescriptive.

A sketch goes a long way

You’ve probably hired a designer because you’re not a great designer yourself. If you’re like most developers, you’re likely to be a terrible designer, lacking any significant ability in visual arts. That’s absolutely fine, and normal. Nonetheless, a (terrible) sketch of what you’re after is often far, far more useful than a description - no matter how precise. Don’t be afraid to scribble something down for guidance; it can be exceptionally useful to make sure both parties are starting on the same page.

Consider sample data

As a developer, you have an idea of what sort of data your app will manage and display. Your designer, unless told otherwise, is likely to use generic sample data or even random text for layout purposes. It’s better for both parties if you supply realistic, meaningful sample data from the beginning - paying particular attention to extreme cases (shortest possible, longest possible, etc).

Present all the work up-front

Go to extreme lengths to ensure the entire design job is described up-front, as for any job. Adding things later will not only potentially incur disproportionate costs, but will also be harder to schedule, and could have knock-on effects on already-completed design work. As a developer, you’re fully aware of the huge cost of late-stage changes - the same applies to design.

Remember design constraints

Your designer will create their best work to meet your specifications, so it’s important that those specifications are accurate - including limitations. Screen size, orientations, font licensing, required branding colours/liveries, available space for ads or other static elements unrelated to primary content, and so forth. Think carefully about the constraints for the design, and ensure your designer is aware of them from the start.

Professionalism

Be responsive

It’s to your financial and professional advantage to be responsive when your designer presents work for feedback, or asks a question. Design isn’t something that should be done after development, nor even during: ideally, a completed spec is followed by a design, which is followed by implementation - so devote due time and diligence to working with your designer.

Don’t assume it’s easy

The bane of a developer’s life is that non-developers assume that programming is easy. A change to a feature, supporting multiple things instead of just one thing, or changing how something works - we often have to explain the effort involved, and justify the resulting cost. The same applies to design, so resist the temptation to assume that a change must be easy or quick simply because it’s “just” visual.

Don’t micro-manage

Your designer is a professional, and their discipline isn’t measured by the same metrics that so irritate developers (code check-ins, lines of code per day, tickets resolved, etc). Designers must often allow ideas to develop, to experiment with approaches, or to step back from a problem for a short while to get fresh perspective.

Progress in a design isn’t quite as readily measurable as with programming. Allow time for the creative process, and let your designer present you with a coherent, consistent and fully-developed piece of work when it’s ready.

Use the same tools

Wherever feasible, have the same tools as your designer - at least to the extent of avoiding undue inconvenience on either side. For a professional developer, a copy of Photoshop isn’t going to break the bank, and can be a very wise investment when it comes to re-doing artwork cut-ups on a deadline if your original designer isn’t available. At the very least, have something that’s sufficiently up-to-date that your designer doesn’t have to jump through hoops to work with you.

Speak the same language

Just as your designer accepts the responsibility to provide graphic cut-ups from her design for you, you should similarly accept the responsibility for translation between the design work and the programming world. If you have peculiar file-naming requirements, take care of them yourself later. If you need colours in hex format for CSS, or in RGB zero-to-one format for use in code, do those conversions yourself, and don’t needlessly complicate your designer’s life. Omit or translate terminology that won’t necessarily make sense outside of your implementation work.

Allow use as a portfolio piece

If your designer is particularly proud of their work for you, they’ll ask to use it as a portfolio piece. Allow them to do so. It’s the decent and sensible thing to do, and it’s free marketing for both of you. It also reinforces mutual goodwill between the two of you, which will be useful when it comes time to commission the next design job when your designer has a busy schedule.

Business matters

Pay on time

Pay your designer on time, without excuses. Their payment schedule is independent of your developer process and release date. As soon as you’re happy with the work, pay whatever remains of the bill in full. For extra goodwill, and where feasible, pay immediately instead of according to the invoice’s due date.

Don’t condone spec work

Spec work is work done before payment is agreed upon (and often without any guarantee of payment). There are many web sites where you can submit a design brief and a budget, and designers will then create work to fit your brief (to a greater or, usually, lesser extent). You’ll then choose the piece you like, pay that person the fee, and everyone else gets no payment at all for their work.

This is a terrible, destructive, unsustainable way to do business, and it’s actively damaging to the entire industry. Do not invite or support spec work, in any form. Instead, do your research about designers you’d like to use (getting personal recommendations, and requested portfolio examples), then choose a designer, put a contract in place, and work with them.

Understand the model

Commonly, you’ll receive one (or perhaps a small number more) design to fit your brief, and will be entitled to one or more rounds of changes or refinements to that design, as part of the agreed-upon fee. Any further concepts, designs, rounds of changes or other extra work beyond that will incur extra cost. That’s an entirely normal, reasonable and fair system, and it’s the reality of the design industry.

The way you offset the uncertainty of extra cost for design changes is to present a complete and accurate brief at the beginning, and to be responsive to your designer during the process. By contrast, you do not complain about the basic model, or expect unreasonable amounts of design hours for a flat fee.

Source code is extra

In the majority of cases, the “output” of development work is the source code for the app or web site; the product and the inner workings are one and the same. Thus, in most cases (though by no means all) for contract development/programming, what you’re selling is the source code. That isn’t quite so true in the design industry.

The “output” of a design is the graphic work, in a format suitable for use - commonly PNGs, EPS files, PDFs, perhaps JPEGs, or some other such thing. It’s not so common for the actual work files (Photoshop PSDs, Illustrator AIs, etc) to be included in the fee - indeed, it’s normal for those to cost significantly more. This is normal, and equitable - if you need them, be aware that it’ll cost extra, and be willing to pay it.

Final thoughts

As I said in my previous article, design and development are two inseparable halves of the process of creating quality software. Professionals on both sides should always strive to work together as effectively and respectfully as possible.

Feel free to follow me (@mattgemmell) to keep up to date with new articles here, or subscribe to the RSS feed. Likewise, do feel free to share your own thoughts on design, development, and how the two fields fit together.

How Designers Can Help Developers

2012-02-02T16:00:00+00:00

Traditionally, developers aren’t great designers, and vice versa. There are many exceptions (ahem), but generally the art of one group is a mystery to the other - yet we routinely have to collaborate on projects. As someone who has worked in both areas, I’ve put together a list of tips for designers, on how they can make life easier for the developers who have to bring those designs to life as apps and web sites.

This article’s topic was suggested and inspired by two great designers I know: Evgenia Grinblo and Sarah Parmenter. You should also check out Sarah’s presentation at Update 2011, which covers several of these points too.

Photoshop hygiene

Developers often have to deal with Photoshop PSDs from designers, so anything that benefits designers themselves is also good for developers. These tips pertain to creating maintainable, understandable PSDs for everyone.

Use an intelligent method of version-control

A folder full of ambiguously-named versions of PSDs is the bane of any designer’s life. Either decide on a sensible naming scheme for file versions (ideally one that will cause the files to show in strictly sorted order when viewed alphabetically), or use an actual asset management or version control system.

Keep your layers

Don’t flatten anything that doesn’t absolutely have to be flattened. Do exports by grouping and hiding/showing layers, exporting, then restoring the document to its previous state. Don’t destroy useful data. Machine performance isn’t a reason to flatten: get more RAM, or a better machine!

Name all your layers meaningfully

I know it’s a pain, but it really aids comprehension, particularly when reusing elements of a document. Make sure that the names of text layers reflect their content (they can get out of sync), and that duplicated layers are renamed to something more appropriate than “copy”.

Use groups, and do so sensibly

A discrete visual element composed of multiple layers should be in a group, and overall the groups should usually follow a standard left-to-right, top-to-bottom pattern if the document is a single design. Hierarchy and order are better than colour-coding your layer labels, because colours have to be maintained when layers are moved around.

Prune unneeded layers

Old versions, templates and reference materials, temporary duplicates and such should be deleted if they’re of no further use. Occasionally do a quick run-through of your layers, getting rid of anything that isn’t serving a purpose.

Use Layer Comps

Photoshop’s Layer Comps feature lets you create sets of layer states, such as visibility, position and even Layer Styles. You can use it to neatly incorporate multiple parts of a design (like multiple tabs in a web layout, or screens in an app) into a single document. It can reduce the need to duplicate layer groups and maintain them, and can thus reduce file size too. Make it part of your toolkit.

Keep everything as vectors, and scaleable effects

Go to extreme lengths to keep designs fully resizable. For app design particularly, it’s comparatively common to suddenly need the entire same set of artwork at twice the dimensions, for newer devices with doubled pixel-density. Make sure you don’t need to redraw a load of bitmap art at short notice.

Helping developers

There are also several tips which pertain specifically to designs for apps and web pages, which naturally have their own requirements and constraints.

Learn how to preserve rounded corners while resizing

Operating systems tend to standardise on a particular corner-radius for rounded elements, and use it everywhere (on iOS, it’s usually 12 pixels). Whilst Adobe Fireworks knows to keep a rounded rectangle’s corner-radius the same during scaling, Photoshop doesn’t - so make sure you’re familiar with the Direct Selection tool for selecting corner-producing points and resizing shapes the old-fashioned way.

Design at 72 ppi

A pixel is a pixel, and more of them just means a bigger document. Don’t confuse matters by changing the document’s resolution.

Snap to whole pixels

Make sure relevant shape tools (such as the rounded rectangle tool) are set to snap to pixels. Use the pixel grid and/or guides according to your taste. Prefer strong edges, sitting precisely on the pixel, because sub-pixel rendering on devices will otherwise turn your beautiful design into mush. Relatedly and consequently, work with even-numbered dimensions both overall and for individual elements, to ensure crispness. Thanks to Matt Drance for this point.

Always use RGB mode

This is important not just for colour display, but also for when developers need to sample colours from the document to use in code. You can’t go wrong with RGB.

Asset-preparation is part of your job

Many (most) developers don’t know how to use Photoshop for anything but very basic edits. Properly exporting cut-ups for use in apps or on the web is the designer’s job, since they’re most familiar with the document and with Photoshop.

I know it’s a huge pain, and it can take a long time, but it’s the “other 90%” of the job after the design work is done.

Be careful with fonts

Different devices and operating systems have different pre-installed fonts, and there’s no guarantee they have all the same fonts that you do on your design machine (indeed, you probably have far more fonts than the average person). It’s always best to render text as actual text in apps or on the web, so fonts are an important consideration in your design not just for visual reasons, but also for feasibility.

Remember that the license you have that allows you to create designs with a given font probably doesn’t allow that font to be embedded in an app (or on the web) in its entirety. Take care to communicate with your dev (and/or client) before relying on a certain font in your design.

Mimic the platform’s text-rendering (where possible)

For visual integrity, experiment with Photoshop’s text anti-aliasing settings to best reproduce the target platform’s rendering. For iOS, for example, you’ll likely want the “Crisp” anti-aliasing mode.

Be sure of design dimensions

Particularly for apps on mobile devices, screen size isn’t the whole story - you’ll commonly have to account for the presence or absence of system status bars and so forth, and how they affect dimensions in both portrait and landscape orientations (an iOS-like top status bar will reduce the smaller dimension in landscape, and will reduce the larger dimension in portrait, for example). Be sure to check with your dev whether the app is truly full-screen or not.

Use the platform’s idioms

Each platform (operating system) has its own idiosyncratic user interface elements, and interaction styles (these will also vary by device category). Be conscious of them. A good rule of thumb is not to design too far outside those concepts, unless you have a compelling reason to do so. On iPad’s particular flavour of iOS, for example, you’ll find these concepts:

A nigh-universal requirement to support both orientations.
Two-pane interfaces being acceptable, simultaneously in landscape and modally in portrait.
Pop-overs as a UI element and grouping mechanism.
A very specific style of documents-browser.
The expectation that hierarchy-navigating back-buttons have a specific left-pointing shape.

And so forth. Be familiar with the platform, because your design has to fit it. There’s no single design that suits all target platforms (not even on the web, without some degree of adaption and flexibility).

Design once for landscape, then design again for portrait

Different orientations require different physical interaction styles as by-products of not only screen aspect-ratio, but also the form-factor, weight and balance of the device when held. A design which doesn’t adapt to accommodate more than the raw aspect-ratio change is a weak compromise at best.

Design for each major screen-size, and their contexts

In app design, both content and interface presentation should be different on a phone-sized device than they are on a tablet, or a desktop computer. For mobile device categories, we also need to consider attention-span, distractions, the physical impairment of having to support the device while using it, and the possibility of the user being in motion and/or at risk (obstacles while walking, traffic when crossing the street, the need to safely maintain control of a vehicle, etc).

These contexts of use are irretrievably tied to the size and nature of the device, and an effective design will consider these factors.

Use genuine or at least realistic content

The hallmarks of good sample content are as follows:

Sample copy spans the entire range of possible lengths, not just what’s convenient for the mockup.
Required data, particularly such as user photos, are occasionally omitted, and a concrete design is presented for this situation.
Undesirable examples of input are considered; for example, extremely portrait or extremely landscape aspect-ratios in images which your design would prefer to be square.
Names include ‘extreme’ or unfamiliar examples, including very long and non-breaking forenames and surnames. A poor design features only Bob Janeson and Jane Bobson.
Addresses are not constrained by locale. Almost every possible length, format and arrangement of address can be found somewhere in the world. Allow space and flexibility.
Lorem ipsum is not found anywhere in the design.

Consider localisation

When most people think about supporting other languages, they’re thinking about text. When a designer or developer thinks about localisation, however, they should be thinking about layout. For localisation purposes, your designs should ideally accommodate a fifty percent variance in text-width, for all textual elements, compared to English.

Asian languages can require up to 50% less space than English to display equivalent text, and European languages can require up to 50% more space then English. In particular, your button designs and help-text placement should be very conscious of these statistics.

Respect the global light source

As a designer, it’s unlikely you need to be told this, but each platform has its own sacred and inviolable global light-source (on iOS, for example, it’s directly above-centre, or 90 degrees). Any and all lighting and shadow effects should be consistent with the target platform’s light source.

Make navigational or organisational constructs explicit

If your design incorporates constructs like tabs, navigational drill-downs or other disclosure mechanisms, make their existence and function clear to the developer. Be sure to respect platform conventions for such constructs, as mentioned above. Developers need to be aware of information hierarchy very early in the implementation process, so be sure your design clearly communicates your intent. Layer Comps are particularly useful in this scenario.

Export cut-ups without compression

Use PNG with alpha (transparency) unless explicitly told otherwise. Don’t use JPEGs unless asked. File-size is no object; developers and/or their development environment will suitably optimise the resulting images. Export each element with a transparent background, not a solid colour (even if a background part of your design does feature a solid colour).

Ask about shadows

Communicate with your developer about whether shadow effects should be included in exports. Commonly, developers will apply shadows themselves later, using CSS or by drawing them in code, which can actually be easier or more convenient and consistent than using pre-rendered bitmap shadows. Don’t assume that shadows should be baked into the images (though by all means mock them up for design purposes, using layer effects).

Understand how buttons are constructed

Buttons in apps or on the web are rarely created using a single image. Instead, they will almost always be either:

3-part images, with a left end-cap, a right end-cap, and a single-pixel-wide repeating central section (to allow for horizontal expansion of the button); or
9-part images, with top/middle/bottom-left end-caps, top/middle/bottom-right end-caps, and three repeating top/middle/bottom central sections (to allow for horizontal and vertical expansion of the button).

Design your buttons as end-caps with thin repeating middle portions. Take suitable care with gradients. For 9-part images where gradients probably can’t be rendered statically without visual banding after vertical expansion, discuss with your developer whether you can supply transparent-backed image parts and have the gradient applied via code or CSS afterwards.

Final thoughts

The creation of any kind of software is (or should be) a partnership between graphic design, interaction design, and implementation. None of these disciplines is any less important than another, and all are vital. By being aware of the needs of those working in other fields, we can be more effective and valuable in our own work.

I also wrote a follow-up article presenting the other side of the equation - how developers can help designers. As usual, I’ll continue to announce new articles on Twitter; feel free to follow me (@mattgemmell) to keep up to date. Likewise, do feel free to share your own thoughts on these topics too.

iPhone User Interface Cookbook giveaway

2012-02-01T12:00:00+00:00

The lovely people from Packt Publishing asked if I’d like to give three copies of their book, the iPhone User Interface Cookbook by Cameron Banga, to lucky readers of this blog (or indeed my lucky Twitter followers). I said… why not?

The rules are very simple:

You submit your name and email address via the entry form.
The competition closes on Wednesday 15th February 2012.
Please enter only once. Give everyone else a fair chance too.
Winners from the U.S. and Europe can either choose a physical copy of the book or the eBook. Users from other locales are limited to the eBook only.

Thanks to a very enlightened attitude from Packt Publishing, I’m hosting the competition entry form myself (via Google Docs), and I’m also doing the random draw of the three winners. I will only send the three winning email addresses to Packt Publishing (so they can send you the book). If you don’t win, I’ll delete your entry after the winners have been chosen, and no-one else will ever get access to it (not even Packt). I insisted on this for the sake of your privacy, which I strongly believe in, and I’m grateful to Packt Publishing for agreeing. I receive absolutely nothing for helping with this giveaway either.

So, feel free to enter the competition, and best of luck!

Finally, as we all know, giveaways are intended to generate interest in the thing being given away, so even if you don’t win I’m sure you’ll want to find out more about the book.

Subtle UI texture in Photoshop

2012-01-29T16:45:00+00:00

On iOS and almost every other operating system, user interfaces tend to use gradients to give a sense of contour to interface elements. The trouble is, gradients alone can look artificial due to their unrealistically perfect visual smoothness. In the real world, almost nothing is completely flat and smooth - and that’s a good thing, because we rely on friction for grip.

We can add a touch of realism to our interface designs by combining gradients with subtle textures. My own favourite type of texture is noise, which gives an understated but effective sense of tactility. I used noise for texture extensively in my UI design for the Favorites 2 iPhone app.

This brief article explains one possible way to combine gradients with subtle noise in Photoshop (as with any effect, there are many other approaches to achieving the same thing; this is just how I usually do it). I used Photoshop CS5, and this tutorial should be suitable for Photoshop beginners. It’s aimed primarily at app developers, rather than experienced designers.

(Note: if you use Acorn instead of Photoshop, Gus Mueller has written a version of this tutorial for Acorn.)

There are three main stages to combining noise with gradients, the first of which you’ll probably only need to do once.

1. Creating a noise pattern

The idea here is to make a Photoshop Pattern containing noise, which we’ll then apply to whatever objects we want to give texture to. Start off by making a new document (500 x 500 pixels is good), and filling it completely with a solid colour. I’d advise trying 50% grey.

Next, use the Add Noise filter (Filter menu, Noise submenu) to add some noise. The settings I tend to use are shown in the screenshot below; 50% Gaussian RGB.

Add Noise filter options dialog.

That’ll produce a fairly horrible TV-static-like pattern in your document. Select the whole thing, and choose Define Pattern from the Edit menu. Save your pattern with a suitable name, as shown below.

Saving some noise as a Pattern to use later.

You’re now done with this Photoshop file, so just close it (there’s no need to save it).

2. Creating a Gradient Fill layer with a Vector Mask

It’s always good to keep shapes as vectors for as long as possible, so you can tweak and resize them without destroying them. For that reason, I tend to draw all my UI elements using the Shape tools in Photoshop, then apply Layer Styles to achieve a particular look.

The problem is, whilst there are both Pattern Overlay and Gradient Overlay Layer Styles, the Gradient Overlay takes precedence over the pattern, so if you want to have both visible you need to reduce their opacity, which can wash the gradient out.

It’s better to use an actual Gradient Fill layer, with the same Vector Mask as the shape you want, then apply Layer Styles to that layer instead. It takes a couple of extra steps, but it’s still easy and quick.

First, use one of the Shape tools to make the shape you want. You’ll see the resulting Shape Layer in the Layers palette. I made a rounded rectangle in this example. Now, make sure the shape’s Vector Mask is selected by clicking on it in the Layers palette (it’s the rightmost of the two boxes in that layer’s row; you can see that it’s selected by the four black corners around it in the screenshot).

Shape layer in the Layers palette.

Now, switch to the Paths palette. You’ll see that your shape’s Vector Mask is shown as an implicit path.

Paths palette, showing vector mask path of a shape layer.

Next, save that path by choosing Save Path from the fly-out menu near the top-right of the Paths palette. It looks like a little grey down-arrow beside some horizontal lines. Give the new path any name you like, and make sure that it’s now selected in the Paths palette.

Saving a shape’s vector mask as a path to use later.

With your saved path still selected in the Paths palette, create a new Gradient Fill layer. You can do this using the Fill/Adjustment layer popup at the bottom of the Layers palette, which looks like a circle that’s split diagonally into black and white halves.

Making a new Gradient Fill layer.

You’ll now have a Gradient Fill layer that has your shape’s Vector Mask pre-applied to it: essentially a shape that has a gradient background. We’re only interested in the new Gradient Fill layer from now on, so you can delete the old shape layer.

Gradient Fill layer in the Layers palette.

You might want to take this opportunity to click the Gradient Layer’s gradient swatch in the Layers palette, to choose the actual gradient you want. When you’re ready, open up the Layer Styles dialog and enable a Pattern Overlay.

3. Using a Pattern Overlay to add noise

There are two things you’ll want to do in the Pattern Overlay settings:

Choose your noise pattern from the pattern popup.
Tweak the opacity of the Pattern Overlay until the noise is subtle but noticeable. You’ll probably want something in the region of 5% opacity, depending on how much noise you applied, what the base colour of your pattern document was before you added noise, and what colour your layer’s Gradient Fill is. Just experiment until you find something you like.

Pattern Overlay options.

That’s pretty much it. You can toggle the Pattern Overlay on and off in the Layers palette to see the difference it makes; you should notice a slight but pleasing sense of roughness and realness when it’s enabled, making the shape just a little bit more inviting.

Here’s an example of two identical buttons, firstly with just a gradient (top) and secondly with some noise applied (bottom). Since this screenshot is on Flickr, JPEG compression might make the noise a bit less refined than you’ll see in Photoshop or in an exported PNG for your app.

Buttons without and with noise applied

Here’s a (similarly JPEG-compressed) close-up of the difference between the two buttons.

Close-up of buttons without and with noise.

You can download the finished button as a zipped PSD here.

Texture is an inherent part of any surface in the real world, and provides a cue to our brains that we’ll be able to grip or otherwise interact with that surface. Delicate use of noise can add a welcome note of reality to your interfaces, and make people want to use them.

If you’re interested in more beginners’ UI effects tutorials for Photoshop, follow me on Twitter and let me know.

iBooks Ideas

2012-01-19T20:20:00+00:00

I was intrigued that a few people saw my recent article about iBooks Author as a criticism (in the negative sense). That wasn’t my intention at all, and indeed I’m very enthusiastic about the ecosystem (iBooks Author, its file format, iBooks 2 as a reader/viewer, and the iBookstore as a storefront and delivery mechanism).

My piece simply acknowledged that, as in any situation, there are trade-offs to be made, and that a book isn’t a project to be undertaken lightly or without due consideration. I’ve thought about it a bit more, and I’m becoming increasing aware that the interactive features of iBooks 2 could be game-changing for many genres of book - not just textbooks.

Earlier today I posted a list of fifteen suggestions, and received a few more in response, and thought I’d write up that list to hopefully inspire potential authors and even traditional publishers.

Choose Your Own Adventure. Books where you can select which path the story should take, making decisions so you’re more involved in the narrative. Previously, we did this by conditionally turning to one page or another.
Mystery novels. Let me see the clues, or hear the hesitation in a character’s voice. Let me inspect a scene. Very few mysteries, as written, allow the reader to make an informed guess (or deduction) as to the culprit. Richer media lets us truly involve the reader.
Action. Include climactic or cliffhanger scenes as visuals, or mood-setting music or video. It might even improve the chances of your novel being optioned for a TV or movie adaption.
HTML 5 Tutorials. Since the iBooks 2 format allows embedding of HTML 5 code, tutorial material can include actual working examples in each chapter.
Wedding album. Photos, guestbook messages and even videos can be included in a virtual coffee-table book for everyone to enjoy, not just those who paid for a copy of the DVD from the videographer.
Your portfolio. Designers, developers, musicians, video editors… the list goes on. An interactive portfolio, showing your best work in the most effective way, complete with contact information and links to your online presence (or web portfolio pieces). For iOS developers, particularly, this would be powerful marketing.
Your family history. Genealogy fans can include the old home videos, scanned photographs, links to census data, and so on.
Band biographies. History, trivia, music, live performance videos, photos and interviews.
Movie Novelisations and Companions. With embedded extra-value clips from the big-screen version. Or: a director’s commentary, with special effects notes and interviews.
School Reports. Your child’s report on his or her vacation, trip or project doesn’t have to be static. We all have still and video cameras in our pockets these days, so why not use them?
Cookbooks. Recipes, with interactive how-to videos for those tricky souffles or macarons. Or even for the non-tricky bits, to help those who are clueless in the kitchen.
Skill-training. Whether it’s genuine (like origami) or humorous (“100 things every man should be able to do”), it’s a lot easier to learn by watching and replaying rather than simply reading and looking. I could do with a bowtie-tying guide. This also has strong possibilities for martial arts, crafts, public speaking, law enforcement and more.
Instruction manuals. Build your Lego kit, assemble your Ikea furniture, or convert Optimus Prime from a truck into a robot. Run through the process step by step, seeing exactly how everything moves and goes together. Even user guides for software or hardware, or videogame strategy guides.
Episode guides. A souvenir guide to your favourite TV show, complete with trivia, bloopers and extras.
User Interface/Experience Design books. Read case studies showing the iterations of designs on real projects, and explore animation and interactivity in their own terms, without relying on static diagrams.
Treasure hunts. I’m informed that HTML 5 widgets can (with permission) access your current location from within a book. Imagine the possibilities of that technology.
Client proposals. Wrap up your pitch in book format, with interactive visuals, estimates, timelines, contact information and a profile of your staff.
Rulebooks. Dungeons and Dragons, Warhammer, cricket, baseball… the list is almost endless.

And so forth. Now, granted, some of these ideas could be constrained by the current maximum selling price of $15 for an iBooks Author-created book, but I think the majority of the list would fit into that bracket (there are also other strategies, including splitting content between volumes, and so on, to say nothing of any potential future change in pricing policy).

I’m excited about the iBooks 2 ecosystem, not just because it’s got people really talking and thinking about education, but because it finally puts a powerful tool into everyone’s hands and says “show me what you can do with this”. Even if you have reservations about Apple’s walled garden, it’s difficult to ignore the huge potential of the technology itself.

Once you move away from thinking only in terms of textbooks proper, it quickly becomes clear that rich reading material has fascinating and exciting applications throughout the entire world of (heretofore) printed matter.

Footnotes:

If you’re interested in further discussion about iBooks Author etc, I’m probably talking about it on Twitter. You might want to follow me (@mattgemmell).
I enjoyed C. Y. Reid’s sensible piece on why he’s in favour of iBooks Author. You should read it.