Some general guidelines

• For UI elements, use 24-bit PNGs with a transparent background.
• Use alpha transparency, not index transparency. Be careful to not use fancy blending modes on top of transparency in the source file – anything beyond basic alpha transparency won’t be respected in a flattened PNG.
• Include any drop shadows or highlight effects in the exported image. Keep in mind the lighting source should always be the top center of the screen.
• Keep a source file around (i.e. PSD) for each asset you export, so you can make changes to it in the future without messing up the dimensions or alignment of the image.
• Use Photoshop or Fireworks to create graphics for production. AI is resolution independent, so it is much harder to control pixel-level details and you will often end up with blurry lines when you rasterize the image.
• If you find that antialiased lines look fuzzy in your flatted PNG, you may need to whip out the pencil tool and clean it up by hand.
• When providing colors, use RGB values. Your developer may want the values in percentage format; to get this, use the color picker to get the numerical value and divide it by 255. If it needs to be partially transparent, specify an alpha value. (20% alpha means the same thing as 80% opacity.)

Text

Any text labels in the UI are implemented directly in Cocoa, so you should provide detailed specifications for how the text should appear. Most labels in the UI should be Helvetica, the system font, but you can specify any font that is included on the device.

You should also specify whether overflow text should be truncated (as with button/titles in the default UI) or wrapped (as with an expanding content area).

What you should provide: Font name, size, and color, as well as parameters for any shadow effect that should be rendered (shadow color and x,y offset in pixels).

Buttons

A "button" is pretty much anything that is tappable, and it can have different visual states depending on the context. You need to take all of these states into consideration when building custom buttons.

Your average button has three states you should provide to your developer:

• Normal: The button is active and can be tapped.
• Disabled: The button is inactive and cannot be tapped.
• Highlighted: The button is currently being touched.

And there is a fourth state that may be required for buttons that can be toggled, or buttons which are part of segmented controls:

• Selected: The button has been toggled on can be tapped to return it to the normal (off) state.

It is important to ensure that the assets you provide for these states are identical except for the differences in visual styles. You should also specify the appearance of the text label (if present) for each state.

When delivering assets for production, you have a few implementation options, depending on the properties of the button.

Fixed-size buttons

Some buttons are always going to be a predictable size. Generally speaking, this applies to buttons that rely on iconographic imagery and therefore don’t contain any text. Buttons that contain text, even when presented at a fixed width in the UI, should always be stretchable in at least the x-dimension to accomodate changes to the label or localization.

For a fixed-size button, you can export the asset as-is. When you have a number of fixed-size buttons that share a single context, it is often easier for the developer to achieve the proper alignment if you choose a universal height or width for all buttons in that context.

What you need to provide: Just the image at the proper dimensions to be fitted into the UI, along with any applicable visual states.

Stretchable buttons

In Cocoa, it’s possible to take a button image and do automatic slicing to make it stretchable in either the x-dimension, y-dimension, or both. This is really nice for us because we don’t have to slice them up ourselves. Yay! It does have some limitations, though, and these are important to remember.

The way it works is that it takes the button image, then uses a pixel value for cap size to slice the image in code. The caps are then set aside, and the inner pixels are repeated in whichever direction is specified.

If you want your button to stretch in both directions, it must be a flat color or tiling pattern (basically, it needs to repeat elegantly in either direction). A gradient will not stretch properly. In the example above, the button can only stretch in the x-dimension and must have a fixed height. For most UI buttons this is perfectly acceptable.

Generally speaking, it’s best to provide UI assets in the smallest form possible, so try to reduce your image to include only the caps and whatever needs to repeat in-between.

What you need to provide: The button image for all applicable visual states and the cap size in pixels for each direction you need the button to expand in. In the example above, the cap size is 8px and it expands horizontally.

Drawing the button in code

So what do you do when you want a button that expands in all directions and has a gradient or some visual style that defies stretching? Well, chances are good the button could be replicated in code, although this can be significantly more work for the developer, is harder to modify, and sometimes incurs a penalty to performance. Always check with the developer before embarking into this territory.

This button is a good candidate for drawing in code thanks to that fancy highlight effect and its need to support arbitrary amounts of content. In this case, what you need to provide to the developer is not images but a set of parameters. Generally speaking, Cocoa can draw most of the things you can draw in Photoshop: shapes, gradients, shadows, even blending modes.

Here’s how you would describe the normal state of this button to a developer. You can access all of these parameters in Photoshop.

Shape: Rounded rectangle with a corner radius of 9px

Gradient (stop, rgb):
0%, white
49%, white
51%, (0.93, 0.91, 0.95)
100%, (0.90, 0.91, 0.93)
The gradient is linear with an angle of -90°.

Drop shadow:
Color: 100% black, 70% alpha
Distance: 2px
Size/blur: 4px
Angle: 90°

Inner padding: 15px on all sides. The text should be 16px bold and centered vertically.

Here’s a nice tutorial on creating a glossy button in code. It should give you a sense of how the process works and what’s possible.

What you need to provide: Detailed specifications with all the color, style, and shape information needed to recreate the button. Don’t forget to also provide specs for all relevant visual states.

Layout

When laying out a UI, you are usually dealing with content areas that are either of a fixed size and position, or variable size and position relative to contents. It can be very helpful to developers to describe these parameters as explicitly as you can, while also providing guidance on how to handle elements that reflow, expand, or change size & position.

What you need to provide: Pixel-level specifications about where UI elements (or blocks of elements) should go, as well as guidance for how to handle elements that move or change dimensions.

Masks & compositing

You can use any solid black shape on a transparent background to create a mask that can be applied in code. The mask can also use partial transparency, so you can actually achieve sophisticated effects this way if you want to get creative.

Generally speaking, it’s most useful for fitting dynamic content into a more general UI asset. For example, you could take an image of a CD’s album art and make it appear to be part of a prerendered CD case by using an image mask of the proper shape and size.

You should talk to your developer about how to implement artwork like this before you create your assets. Sometimes masking and compositing is the right approach, but sometimes it can come with a performance hit. Some cases would be better handled by generating the artwork in code and caching it for reuse.

What you need to provide: For masks, provide a black shape on a transparent background. For compositing, provide all the graphics that you need to layer together to create the object. Make sure they all have the same dimensions and are already aligned properly, as with the fixed-size buttons described at the beginning of this document.

Get creative and work together!

This really just scratches the surface, and if you take the time to learn about how graphics are implemented on the platform you’ll discover lots of creative ways to build a UI. I highly recommend sitting down with your dev (or someone familiar with the features of the platform) and talking through your ideas. You may discover options you hadn’t considered, and together you may come up with a plan of attack that is more beautiful, responsive and fast than it would be if you never put your heads together.

Q: To what extent has sci-fi (TV, movies, books) influenced your UX work?

A: That’s a great question. I think you can look at science fiction as our collective fantasy about technology. If you want to understand not how people use their computers but how they want to use them, popular sci-fi is the first place you should look.

In the past few years I’ve really moved away from web app design or even traditional desktop app design, favoring touchscreen devices instead. The computers of the future don’t have mice (“Hello computer!”). Rarely do they even have keyboards. We crave ubiquity and personality in our interfaces; something always there, always responsive, controlled as directly and easily as any tangible system. Star Trek predicts all of this, and now more than ever you can see those predictions becoming reality.

Something that I think will be interesting to look for in coming years is the development of the human element in UI. Will we begin to realize our fantasies of the jovial robot butler, or the sweet voice of Majel Barrett-Roddenberry greeting us when we login? Only time will tell!

While the HIG has a lot of good information, it doesn’t go into the details of implementation, so I’m going to go through the process of how I would design a toolbar icon. I’ve chosen the iWork style because I really like how crisp and clear they are, and I think they are a good model to work towards.

So let’s take a look at the Pages toolbar.

Let’s take a note from Gmail and add a “Labs” button. This imaginary feature would take the user to experimental or even user-made plugins and macros.

Step 1: Pick your metaphor

First we have to think about what kind of metaphor would best represent this feature. The HIG offers the following guideline:

“As a general rule, a toolbar icon that depicts an identifiable, real-world object or recognizable user-interface element gives first-time users a clue to its function and helps experienced users remember it.”

So what makes me think of experiments? A beaker seems like the obvious choice. Anyone with high-school chemistry would know that symbol. But before I draw anything I should do some research. I fire up Google Image Search and Flickr with a search for “beaker.” It looks like I have a couple of choices for the shape of the object.

This is actually the kind I was thinking of, but I think these kind of beakers are generally only used in stock photography. I’ve never seen or used one like it in an actual lab. I got a lot more results for this type:

This is also what I remember from science class. The other beaker style is perhaps a bit more recognizable, but in the interest of realism (and not looking too Weird Science) I decided to go with this one.

Step 2: Figure out your sizes

So you’ll notice that Pages’ icons are very crisp, with 1 pixel outlines at both the large and small sizes. This indicates that the designers created two sets of icons, one for the large size and one for the “use small icons” size. If they had only used one and resized it, the line would not be 1 pixel exactly on both. Whichever one that was resized would have fuzzy lines. If you have the time to do this, it’s a nice way to ensure that your icons will look good no matter what your user chooses (you can also selectively reduce detail/complexity at the smaller size to ease recognition).

I’m going to design my icon for the larger size (32×32) and then size it down as needed for the smaller size. Figure out what the “large” and “small” sizes for your app are and keep these in mind. For a pixel-crisp style like this you’ll want to design at the size the icon will appear.

Step 3: Vector outlines

Open up your drawing program of choice. I prefer Fireworks for this kind of icon because it allows me to work with vectors while zoomed in to look at where the pixels actually fall. Go ahead and trace or draw the basic shape. Keep perspective and lighting (which should be top-down) in mind. The HIG says: “The perspective of a toolbar icon is straight-on, as if it is sitting on a shelf in front of you.”

At this point it’s a good idea to look at the fingerprint of your icon. That’s what I call the silhouette of the shape. Icons with different functions should generally have distinct fingerprints. Check to make sure the shape is recognizable and not too similar to anything it’s going to be adjacent to.

Step 4: Color, detail and shading

Now it’s time to fill in the colors and details. I like to zoom in pretty close for this step, but I keep an eye on the actual-size icon as I work. (In Fireworks you can do this easily by selecting Window > Duplicate Window.)

Be brutal about cutting unnecessary shading and details. Show only what you need to in order for the user to get what the icon represents. In the case of the beaker, I added two embellishments; the bubbles, which indicate that the green goop is “active” (and hopefully expresses something experimental and/or volatile) and the volume markers, which help make the beaker more recognizable.

Don’t be afraid to use bright colors here. As the HIG says, “Making each toolbar icon distinct helps the user associate it with its purpose and locate it quickly. Variations in shape, color, and image all help to differentiate one toolbar icon from another.” Also make sure the colors that should be consistent between the icons are – highlights, shadows and outlines fall into this category.

One more thing that’s actually quite important. Watch your alpha! Make sure that things that should be transparent actually are (like shadows, or in the case of the beaker the glass). I like to work with a couple of different-color backgrounds to switch between as I draw, including one that’s the standard Leopard window color to see what it will look like in production. You have no idea what this icon might end up on top of in the future! (Er, avoiding the obvious dirty joke there.)

Step 5: Flatten and pixel-tweak

Save your file so you have the originals handy if you need to resize the icon, then go ahead and flatten your vector layers.

Time to break out the pencil tool! Start looking for places you can simplify your lines. Be especially ruthless around anti-aliased corners, which will have a mess of pixels you probably don’t need and will make your lines look fuzzy.

This is also where I add in line shading and other small details. You may not see much difference in the big, zoomed in picture, but at actual size the tweaked bitmap (right) looks much cleaner. Especially note the simplification of the spout shape.

So after fiddling with the pixels to my satisfaction, I’ll go ahead and plug it into the toolbar to see how it matches the other icons.

Step 6: Generate other sizes as needed

So I have the large-size icon but I’ll also need a smaller one. The first thing I do is size the icon down and clean up the lines. Then I’ll go over the details and make sure that nothing is lost at the smaller size. I noticed that if the spout was made any smaller, it became difficult to distinguish the shape, so I actually made the top of the beaker identical in both sizes. I also redrew the volume markers to fit better on the smaller icon.

So there you go! It seems like a tedious process, and in some ways it is (depending on your style, you may be able to skip pixel-tweaking), but once you get into the right mindset it’s not so bad. You just want to make sure you’re thinking small and keeping an eye on consistency.

It’s easy to think I work in an an exciting, dramatic field that’s always pushing the boundaries of what’s possible, and continually reinventing itself in new and better ways. Users love the web, right? We’ve done a great job, haven’t we?

The thing is, somewhere around 2006, the web stopped growing. Web designers in general started to become increasingly more complacent and frankly bored with their jobs. Making a web app? Okay, plug in the templating framework of your choice, set it to CRUD mode, code up an HTML form and stick a JavaScript library on top of it. Content? Who needs it! Just hook it all up to Twitter, FaceBook, Flickr, Google Maps and hell, maybe some RSS feeds too. The design has to be catchy enough to get users interested, but don’t worry too much about making it usable. People will just be plugging in to it through their phones, desktop clients, or RSS readers.

Hello, web professionals. Welcome to the future. No wonder the conferences have degenerated to a stream of excuses as to why a full quarter of the world is still using IE6. And there’s an uncomfortable amount of silence regarding anything new. There is nothing new – and there hasn’t been for three years now. The big voices have fallen silent, and no one is rising up to take their place.

The problem isn’t the web. The problem goes much deeper than that. Our interface metaphors are flawed, our input devices are outdated, and the essentialization of most human-computer interfaces, on the web or in your OS, boils down to this:

No, no, no. People, we can do better than this. AJAX doesn’t make this right. It might make it feel more responsive, but at the end of the day it’s still just data entry.

The next time you design an interface, pretend your user doesn’t have a keyboard. What if all they had was a confirm button and a cancel button? This is basically what most game interfaces are. What about the iPhone? It has a keyboard, but only nominally. iPhone developers can’t rely users being willing to deal with the keyboard, and they have to be more creative with their input methods.

The restriction of having no keyboard has driven a lot of innovation on both game consoles and mobile devices. Where is that innovation on the web? Why are we still treating this thing like a terminal running Lynx? (And don’t you dare blame the browsers. You can do better and you know it.)

Here’s a thought experiment for you. Design an IM client that does not take input from a keyboard. (And I’m not talking about voice recognition here either. That’s not allowed.) After about five minutes of thinking about how awful and tedious that would be, you might be surprised with what you come up with. Maybe it could work like a conversation tree in a video game. Or maybe you could select a mood and a topic and it would automatically generate speech for you. Or you could go the abstract route and come up with an entirely different conversation model than what we do in person, leaving written language completely out of the equation. The sky, as they say, is the limit.

Give it a half hour of thought and you might actually get excited about it. Why? Because you’re tired of this nonsense too. We all are.

We all know where this is going.

Try your best to avoid being stuck in:

• A turbolift.
• A transporter pattern.
• A static warp bubble.
• The holodeck.
• An infinite loop.
• The 19th century.

Never be any of the following people:

• The good friend of a bridge officer, who no one has ever seen before, and who appears at the beginning of the episode.
• The love interest of: James T. Kirk, Julian Bashir, William T. Riker, or Lwaxana Troi.
• A spunky young ensign who is trying to prove him/herself.
• Any member of the crew of the original Enterprise appearing on a series other than their own.
• A member of any opposing force with redeeming characteristics or sympathetic qualities who opens up to a Starfleet officer.
• An enemy defector with heartfelt emotional allegiance to his/her race or government.
• Any android other than Data.
• The only member of the away team who is not a bridge officer.
• Tasha Yar.

Rule #1 is that you must be communicative about your expectations and preferences. If you hate blue shiny things, say you hate blue shiny things. Send your designer examples of art you like. If he requests more information or feedback, give it to him. If you want his opinion on something, tell him that. I know you’re thinking, “But I’m hiring a designer because I don’t know about this stuff!” And that’s true. But he is trying to help you realize your vision, and you’re both likely to be unhappy with the results if you don’t communicate your goals.

2. Don’t be afraid to say you don’t like it.

This happens to everyone. Your designer works all night on a mock-up and it just doesn’t sit right with you. Maybe he does a couple more revisions and it still isn’t working. The more he works, the harder it can be to say it’s not what you’re looking for. But remember that your designer is (probably) a seasoned professional. Believe me, he is used to criticism and negative feedback. It will not hurt his feelings or make him discouraged. When you say you don’t like it, he’ll know he’s going in the wrong direction and try something different. Unless he truly is a one-trick pony (in which case you should probably find a new designer), your honesty will help him do his job better.

3. Be as specific as possible in your feedback.

One nice thing about working in the world of digital art and media is that our work is no longer nearly as static as it used to be. Imagine a painter in 1829. If you commission a painting and you don’t like how it comes out, he has to start all over again. He can’t go back and make the sky purple or have the subject face the other direction. By contrast most contemporary designers and artists create their work on a computer in the form of large, complex multi-layered documents. Relatively speaking, these are incredibly easy to change. Elements can be added or removed non-destructively. Colors can be changed on a whim.

When you send feedback on a revision, don’t just say “I don’t care for the headers.” Instead, say what you like and don’t like about them. An example might be, “The font is good, but they don’t pop enough.” A designer will know what to do with that, and more importantly they will know what not to change.

4. Leave some room for creative space.

Unless you’re just hiring a Photoshop jockey (and I hope you aren’t), try to remember that your designer is not just creating deliverables but also coming up with ideas for you. They are thinking of creative solutions to your problems and looking at your company or product through the lens of usability, branding, or aesthetics. This process involves research, mental energy, and most importantly time. When you have a timeline, make sure your deadlines for deliverables and milestones are clearly communicated at the start of the project. And then leave them be! Don’t ping every day asking to see “how it’s coming.” If they even have something tangible to show you, they won’t want to. Give them room to come up with something great.

5. Remember they have your best interests in mind.

This one’s important for dispute resolution. It’s true that the customer is always right, so a paying client can usually win any dispute by pulling out the “who signs the checks” card. But it probably isn’t in your best interest for you to do this.

When your designer disagrees with you, it’s his professional responsibility to explain why. Even though he does creative work, it is still ruled by logic, research, and experience. If he doesn’t want to do things the way you wanted, he probably has a reason that he thinks is aligned with the goals you expressed to him in step #1. It’s your right to ask for this reason and to spend time talking it out if you need to. But insisting on something on principle, without regard for your designer’s judgment, is a waste of his talent. He’s not your enemy; always assume that he is trying to help you.

Being a computer nerd growing up in the 80s, I was lucky enough to have first-hand exposure to some of the greatest interactive fiction games of all time. My parents played Colossal Cave together on our Apple ][ and it was my mom who figured out the answer to the insidious final puzzle. Our basement was (and probably still is) full of Zork maps, notes, and drawings from a time before FAQs were plentiful and free on the internet. Some of those games took us six months or more to solve (Suspended, I’m looking at you) and required collective effort from our entire family. It was awesome.

Many computer folk were IF players back in the day. But what you may not know is that there is still an active community of people writing and distributing these games. And best of all, both the games and the interpreters are free! I don’t think the quality of these “amateur” games is any lower than the Infocom games I played in my youth. If anything, I think the genre has grown in incredible ways, and you can find some truly unique stories and play experiences in the IF archive.

So, let’s dig. I’ll tell you about a few of my favorites, and you’ll go play them. All you need is an interpreter (I recommend Spatterlight for the Mac).

Christminster
1995, Gareth Rees – Download

When I was younger I spent an entire summer vacation playing Christminster on my Mac Plus. The basic story is that you visit your brother at college only to find he has gone missing. Your investigations lead you to a curious and sometimes mystical conspiracy. The game is incredibly rich, featuring memorable NPCs and some of the best descriptive writing I have seen. Bonus points for having a (likable) female lead.

Shade
2000, Andrew Plotkin – Download

A true mind-fuck, and one of the most renowned one-room games. You start out in your apartment, looking for your tickets as you get ready to leave for desert retreat. You can’t find them, but you do notice a slow trickle of sand into the room… seemingly coming from nowhere. There is not much you can do in this game but wait for the inevitable, but you’ll do it anyway, out of hope or perhaps morbid curiosity. Truly frightening and difficult to forget.

Worlds Apart
1999, Suzanne Briton – Download

The only IF that has ever made me cry. You wake up in a strange world with no memory of yourself, and you end up on an inter- and intra-personal journey to unlock your blocked-off memories. The author has a remarkable ability to create a world both dreamlike and incredibly real, complete with specific species of plants and animals. A long game, but the ending is beautiful and satisfying. Worth playing through.

Spider and Web
1998, Andrew Plotkin – Download

This game has won a million awards and deserves all of them. On the surface, it’s a futuristic spy thriller, but the gameplay is what makes this game so unique and entertaining. The narrative is “told” entirely through flashbacks – which means it is, in a way, fatalistic. You can’t do something that didn’t actually happen, can you? It may sound strange, but play just a few puzzles and you’ll see how subtle and brilliant it is (while still being quite challenging). It also culminates in one of the most spectacular twist endings in any IF game. Probably one of the more original games you’ll find anywhere.

Lost Pig! And Place Under Ground
2007, Grunk via Admiral Jota – Download

The 2007 IF Competition winner. I wasn’t expecting to like this at all, but it won me over immediately. You play a simple orc named Grunk caught up in an underground adventure to find his lost pig. The writing and dialogue are incredibly funny, as everything is done in oafish Grunk-speak. You can also set your pants on fire. What’s not to love? Charming and amusing with memorable puzzles and an impressive array of destructive actions you can try.

…and more

So hopefully now you’re hooked and desperate for more. Don’t worry, it’s out there. Start with Baf’s guide to the IF archive (now slightly out of date), and after that try browsing through the IFDB. And there are always more great titles emerging every year for the IF Comp and the XYZZY awards. Go forth!

And yet, there is still one large (and vocal) market segment waiting for rescue from their corporate overlords. I’m talking about professional designers, photographers and artists, who continue to be slaves to Adobe and its golden goose, Photoshop.

Now, there are several independent apps out there that offer some of the functionality of Photoshop. Many of these are quite good: Acorn, Vector Designer, Pixelmator. But no graphics professional is going to use any of these apps instead of Photoshop, despite the much lower price tag. The problem is not that the apps don’t have useful features. It’s that they haven’t managed to target a segment of the population that uses Adobe software to do their job and present them an alternative with the feature set they need.

Well, I’m here to help. I’m presenting four professional user archetypes of Photoshop along with what features they would need to switch to another application. Note that they rarely overlap. Hopefully this illustrates the futility of appealing to all of these people at once. Pick one segment of users and fine-tune towards their needs.

Pierre the Painter

Pierre and others like him use Photoshop for something we call digital painting. Their typical workflow involves scanning a sketch or sketching onscreen with a tablet, then inking and painting the sketch with different kinds of brushes. They rarely if ever use vectors because they don’t have the same organic qualities as natural media, so they usually work at a very high resolution to allow for printing and exporting at a variety of sizes.

Essential features:

Brush editor: Size, shape, opacity, blending, pen pressure. The more options the better. Brushes are the crux of everything they do.

Peripheral support: Must work seamlessly with their pen tablets and scanners.

Color tools: A fully featured and prominent color palette as well as an eyedropper tool that they can easily swap to from the brush. Color proofing tools are important for artists who want to print their work.

Smudge: Aids blending, should ideally have similar options to the brush tool.

Layers: Pierre uses layers and layer blending to build up a painting from bottom to top. Changes to layers should be in the form of layer properties – in other words, you can go back later at any time and add/remove effects. (We call this non-destructive editing.)

Wish list:

Canvas texture: Natural media textures that affect brush dynamics on the “canvas.”

Line correction: Automatic line smoothing, perhaps as a brush option, would help correct a shaky hand when inking bold lines.

Where others have done it right:

Take a look at the oekaki phenomenon. Oekaki typically uses a simple web-based illustration tool and enjoys massive popularity in Japan and all over the world. Even though the feature set is relatively small, a creative artist can achieve a wide range of visual effects.

Corel Painter is also quite good, but much more complex and just as crufty as Photoshop in some ways.

Dana the Designer

Dana uses Photoshop primarily to create mock-ups and layouts, usually involving a fair amount of text. She uses vector tools to draw shapes and embellishments, typographic tools for text layout and headings, and bitmap tools to add images to her design. Assembling all the various pieces of a design into a cohesive whole means she needs to be able to work easily with many different kinds of graphic elements.

Essential features:

Robust typography tools: Design is 90% typography, so the more options here, the better. Kerning, anti-aliasing, conversion to paths – all the usual suspects.

Layers: The ability to move, group, lock, name and otherwise manipulate layers of all kinds is critical.

Layer effects: You should be able to add basic effects like stroke, drop shadow, transparency, etc. to any kind of layer. Same for blending effects. But keep it non-destructive! Anything you add should be removable later.

Basic vector tools: A pen tool, simple shapes and lines with the option for stroke/fill on any of them. Basic pathfinding tools (join, union, add/subtract) are a bonus.

Image masking: Designers often don’t require extensive bitmap manipulation (level correction, etc) but do need to fit these images into shapes in their design.

Wish list:

Grid tool: Rules and guides are a given, but additional tools to help you set on a grid with pleasing proportions would be great.

System anti-aliasing: For web designers. A text tool that emulates the system anti-aliasing you’d see on various kinds of computers.

Where others have done it right:

Fireworks (originally Macromedia, now Adobe) is a good example of an app with a boiled-down feature set for designers. It includes “lite” versions of many tools you can find in Photoshop or Illustrator. Despite not being as powerful, many designers prefer it for its relative simplicity.

Patrick the Photographer

Patrick uses Photoshop primarily for post-production work on his photographs. He imports an image from his camera, opens it at a high resolution and does level/color tweaks on the image. He may also use some limited drawing tools for clean-up.

Essential features:

Level/color correction: All the usual suspects for photograph enhancement. Non-destructive please! If you add a correction, you should be able to edit or remove it later.

Heal and clone: Used for cleaning up artifacts and photo manipulation.

Basic drawing tools: Airbrush-like drawing tools with blending options are helpful for enhancing a subject. Used often on pictures of models.

Quick mask: Easily isolate a subject or portion of the photograph for editing. The ability to have alpha properties on a selection further enhances this tool’s usefulness.

Wish list:

Automatic depth-of-field blur: Detect elements in the foreground and blur elements in the background. Useful for when you are working with low-quality photographs.

Photo browser: Interface seamlessly with the user’s library of photographs.

Where others have done it right:

Of the four archetypes, this one enjoys the best coverage on the Mac. Both Aperture and Pixelmator do a nice elegant job of working with photographs. Both of these are reasonable alternatives to Photoshop for professionals.

Ian the Illustrator

Illustrators and icon designers fall into the same group and generally need the same tools. They rely almost exclusively on vector tools to do their work, and the more powerful the better. They may work from initial sketches but otherwise rarely do hand-drawn work with a tablet.

Essential features:

Powerful vector tools: A well-designed pen tool, point/handle editors and pathfinding tools are all absolutely essential. Any path, once placed, should always be fully editable.

Gradients: Standard gradient fills are a must have, but many will also want mesh gradients or gradients that follow a path.

Export to standard file formats: One of the reasons illustrators work in vectors is so the final output can be resolution-independent. You should be able to export to a variety of standards like EPS, SVG and PDF. Bonus if you can export to AI as well.

Bitmap layer for tracing: Your canvas should be able to support bitmap layers so you can easily trace over photographs with the pen tool.

Wish list:

Icon preview: Automatically generate a view that lets you preview your icon at a number of different sizes on various backgrounds.

Hand-drawing tools: Tools that convert input from a pen tablet to paths are great, but even better when you can use different kinds of brushes that respond to pen pressure.

Where others have done it right:

Sadly, I can think of no professional-grade vector illustration tool. Some swear by the open-source app Inkscape, but I’ve never seen it used in professional circles and don’t have much personal experience with it myself.

Say what you will about Photoshop, it’s pretty amazing that one single app services all four of these archetypes. However, the flip side of that is that for any one of them, 75% of the app’s features are totally useless. Specialization and customer service is where independent software is strongest. If you can align yourself with your users, and if you listen to their needs, you will find yourself with a very willing audience. We all hate paying $1k+ to Adobe for a bunch of features we never use. We’d much rather pay $50 to an indie developer for exactly what we need.

Do you remember the popular kids? You know, the people who sat at the best lunch table, wore the most fashionable clothes, and went to awesome parties? Objectively, there was nothing particularly special about this clique, but everyone understood that they were “cool.” Coolness was in fact their salient characteristic.

What I find interesting about being cool is that it’s simply not a label you can give yourself. In this context, cool means that everyone else thinks you’re cool. Think about what that does to the locus of control when it comes to coolness. The popular kids didn’t make themselves cool – it was the rest of the school who did.

(Once in a while, someone can define a new understanding of coolness, but only if they are not trying to be cool. It is one of the great paradoxes of human interaction.)

The thing is, this phenomenon does not just apply to cool. It applies to just about any feature or characteristic you can think of to define a group of people as different from others. You can be an emo, a goth, a slut, a jock, a dork, a hipster, or whatever else, without passing some objective test that shows you have the right set of qualities to earn the label. Those are labels other people give you based on their understanding of you and the world.

This is normal and I suspect mostly understood. We all do it; it helps us formulate our big-picture worldview without spending too much processing time on individuals that aren’t immediately relevant to us. The problem is when the label starts to mean something to you as an identity.

Let’s talk about the word “nerd.” Let’s just deal with that word for a second and think about what it means. I assume that most of the people reading this article are like me and probably think of themselves as nerds. I’m also going to assume they are reasonably internet-literate and have read their share of the incredibly common treatises on what it means to be a nerd and why we’re better than everyone else (especially if you read Reddit). Perhaps the most well-known of these is Rands’ Nerd Handbook. It’s actually quite well-written, and I personally have a lot of respect for the author. But I find this particular article condescending and counterproductive. It reads like a laundry list of excuses written for people who don’t “get” nerds.

Listen. Being a nerd is just like being cool. It’s an arbitrary label originally assigned to you or people like you because you act a certain way or have certain interests. If you encounter someone who doesn’t seem to “get” you, it’s not because they need a five-page article about what you’re about. It’s because they are interested enough in you to try to get past the label and interact with you on a level that’s deeper than just “nerd” or “not nerd.” Shoving them back over the line with a huff and a mumbled “it’s a nerd thing, you wouldn’t understand” is escapist or elitist, depending on your mood that day. Take your pick — the stereotypical nerd is both.

The cool kids aren’t fundamentally different than any other clique, and neither are nerds. Yet it seems as though we keeping trying to believe that we are. It’s stupid and just as bad as telling yourself that it’s okay to act the way you do because you’re “cool.”

Embrace what you are, but don’t use a label as an excuse to stop growing. Be a good person, whatever that means to you. There are enough walls and boundaries in this world without us trying to build them higher.

I’ve been thinking a lot about this as I read Gladwell’s latest book Outliers. I won’t go into the details of what he says in the book, because it’s worth checking out on your own. But the basics of what he discovered when he studied exceptionalism can be summed up in two sentences. Experts practice a lot, and must have the opportunity to do so to become experts. And seemingly arbitrary factors such as when you were born or where you were raised can have a big impact on your success.

Suddenly the truth of the gifted program becomes clear. For some reason or another, some kids got a jump-start on their intellectual development. The top 8% were identified as efficiently as possible and accelerated. I guess that’s the best public school can do, and I’ll never fault them for that. They simply can’t help everyone. But it certainly does reveal a few things about the pattern I have observed as the lot of us age into gifted ex-children.

As you grow up, the special programs tend to disappear, and by the time you reach college it’s assumed that you are capable of finding something suitably challenging on your own. Additionally, your exceptional intellectual growth as a child has probably slowed down and the other students are catching up to you. You may even be starting to see them pass you. Just like that, the gifted label is gone. Children are gifted. Adults are ambitious, hard-working, and driven.

So what happens to you now? The understanding that you are somehow different from the people around you has already become a part of your subconscious. You might struggle to fill the void of the “gifted” label with something else. “Nerd” or “geek” maybe. You might feel pulled towards engineering and computer science, where the myth of exceptionalism still thrives. Or maybe you just let it go quietly, and mourn the death of your childhood potential. It was nice while it lasted.

But the fact is, you were never gifted. No one is. No one is deemed worthy of some special gift that makes them better than everyone else. And the myth that you were may – may – have prevented you from doing the things that you needed to do to become truly great. Like working hard. Seeking challenges. And not taking anything on faith.

I spent four years in college doing more or less nothing and wasted every good educational opportunity I had because I believed I was too good for it. Because it’s hard to hear that getting good takes work – no more, no less. I’m lucky in that I have a singular love for what I do that kept me plugging away at it, but I still struggle with the notion of hard work and practice. I get angry at myself when I don’t do something perfectly the first time. I have to coach myself to keep trying. It gets better slowly but only through extreme, sometimes painful awareness of the fact that I am not gifted.

But in a way it’s kind of nice. I always felt guilty, that I never deserved whatever “gift” I got. Now I know that it’s just a frame of mind — and that can be taught. And where there are people willing to teach, we are all gifted.