And yet John and MG are totally right. You either see it or you don’t. This is egalitarian, relating to all facets of life, in every nuanced area of preference or priority. For whatever details a given person appreciates and values, far more people will be disinterested and be unlikely to even distinguish differences. How about those Android aficionados? They’ll point to the flexibility afforded by true multitasking, freedom to install unapproved apps, etc. They shake their heads at silly iPhone lovers, hold their phones up high and take pride in these qualities. To them, these are the finer points. This is the “polish.” The rest of us just don’t see it.

For many of us who make, use, or write about software for a living, polish is all about removing from the software as many jarring behaviors as possible. Sweating the small stuff. It’s exactly the details like the persistently stuttering scrolling that MG points out that continue to make Android products appear less polished to us. It’s seriously unnerving. It’s a big freaking deal to us, while other people just don’t see it.

It doesn’t have to relate to expense, and isn’t restricted to a premium class of product. It’s also, of course, not restricted to vision. I can imagine some of my wine-loving friends holding up a $15 bottle of something precious they’d discovered, while expressing disdain for a $200 bottle of swill that somebody else just adores. Nor does it need to be something “high class.” I’m sure a number of hard-working farmworkers could explain to me in agonizing detail why I picked the absolute worst rake and shovel for my garden.

If you’ve got a taste for something, a nose for something, an eye for something, an ear for something, a feel for something, and you find a product that soothes that sense, then you have a special gift: the ability to cast judgement on inferior efforts. Other folks? They’ll either sense it too, or they won’t.

He describes the evolution of his own shorthand for annotating one particular kind of design feedback: the vertical misalignment of an element. He started out with a thin line indicating the vertical white space above and below the “misplaced” element, but settled on a more exaggerated use of squares above and below, to express how different the visual whitespace weights are.

While I applaud the thinking that went into Jason’s conclusion, it feels a bit too clever to me. I think it would be tedious to bother calculating and drawing perfect squares above and below the target text, and the squares on their own convey little information about the recommended design solution.

Instead of skirting around the recommendation, why not annotate the image with an overlay that shows the space that a corrected element might occupy? In this case, the implication is that the text should be altered in some way so that it forms a middle aligned element within its field:

With this notation, the green highlighted area represents the minimal vertical space that both contains all of the targeted element, and is middle aligned in the context of other elements. I believe this highlights, as well as Jason’s perfect squares do, that the current text is out of middle alignment. And like his squares, the degree of misalignment is conveyed by the unoccupied portion of the green band.

Beyond identifying the problem, it also offers a canonical fix: nudge the existing element, or increase its size so that it’s middle aligned within the green band. The band itself serves as a visual placeholder for a final, properly aligned element. Best of all, this annotation is quicker to make than perfect squares, and easier to verify at a glance that it conveys the intended feedback.

Consider the work that went into the first word processors and web browsers, whose work can now be mimicked by a Mac developer who knows how to embed NSTextView or or WebView. Imagine the time that early game developers invested in rudimentary sprite drawing, animation, and collision, which is now achieved easily in iOS games with open source packages such as cocos2d.

Still, building truly great software continues to elude most developers. It’s easy to assume that a large amount of time invested in a project, combined with an impressive outcome, is the key to a successful product. But it’s not so simple.

The ninety-ninety rule is often cited when describing the challenge of finessing a product after most of the hard work has seemingly been done:

“The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.” — Tom Cargill

I agree with this perspective, and I cite it often when discussing software with others. The rule as stated is in terms of “code” but is also applicable to all the visual design, user experience, marketing, and positioning of a product. I think the rule is also recursive: whatever is missing can always be split up such that an “easy” 90% of the job can be done, leaving an elusive 10% of finesse work.

Many developers mistakenly assume that after they’ve put a ton of work into a project, and it achieves some impressive feat, that their work is done. When you focus on the enormity of work completed thus far, it’s tempting to pat yourself on the back and call it a day.

But customers don’t care about the hard work that went into the 90%. They only notice the flaws or omissions in the 10%. Imagine if Michelangelo’s statue of David was perfect in every detail, except that where David’s face should be, a clump of ragged, unfinished marble lay crudely in its place. Instead of marveling at the exquisite details of David’s feet, torso, and arms, viewers would reject it as unfinished and clumsy.

An important takeaway for software developers is that the missing 10%, or the missing one-tenth of 10%, may be something that will take a great deal of work to get right, but it may be something you simply overlooked the importance of.

You might build an impressive skyscraper projecting 40 stories into the sky. The architecture, interior design, plumbing, and electrical work may all be superior to that of your peers. But if some blindness in your product vision prevents you from adding windows, the product will never sell. It doesn’t matter how much time or effort went into this masterpiece: nobody will live in a windowless skyscraper.

“Classic computer programming has largely failed, because it failed to copy nature. Nothing in nature works 100% of the time, but it sure works well MOST of the time – and when it fails, well, you die and get replaced. A human being, for instance, is an absolutely amazing machine, and is provably NOT provably correct.”

I particularly like the example in the second half, having to do with smartly interpreting a typed ISBN numbers for product search. How do you strip the meaningless dashes from a search term, except when they’re utterly meaningful? This kind of thinking is important to fine-tuning an application. Nobody will appreciate the hours you spent laboring over the question, but for some reason they’ll just think your product is particularly awesome.

It’s interesting that the pursuit of perfection in an application has to involve the pursuit of compromise. By solving a problem in a way that degrades gracefully to unsolvable, you offer a happy, possibly even surprise solution to many people who would not otherwise expect one.

The interface is clean and somewhat traditional, based on a familiar 3-pane layout that is common to applications such as Apple’s Mail and my own MarsEdit. But Stunt Software also takes some innovative leaps, adopting a “HUD style” interface for the in-window attributes editor, a style which Apple typically reserves for full-screen media editing palettes.

I’m a bit of a luddite when it comes to taking these kinds of UI risks, but on the whole they do not strike me as offensive in On The Job. Some aspects, such as the iPhone-inspired odometer-style numeral editors, strike me as questionable for the desktop. They can’t be pushed or pulled and don’t have momentum like their iPhone counterparts, but they do look pretty nice.

One way to justify the gratuitousness of these elements would be to support spinning of the elements with a direct click and drag, or even better with a push of the mouse’s scroll wheel.

Overall, I think it’s fair to say that pushing the limits of UI design is justified and encouraged if a designer is also keeping a careful watch on the finer points of the end result. It’s hard to challenge many of the choices made for On The Job, because it is bursting with clear points of consideration for the user. Consider the default names for clients and jobs. Instead of using the typical “Untitled,” they start with the inspirational “First”. After that, the default language changes to “New.” These are the adjectives we use in everyday life. Nobody starts business with an “Untitled Client.”

Which isn’t to say everything is perfect. I gave the application my patented “scrunch test.” This involves simply sizing a window to the absolute smallest it will go, and observing how the UI reacts. I do it almost by instinct with every new application I try, and On The Job doesn’t exactly shine in this regard:

Notice in particular how the HUD-style elements in the lower right have become a disgusting mess of overlapping words and buttons. I have a litmus test for these kinds of design decisions, where a user’s actions can put my application into a state of embarrassing ugliness or dysfunction. My rule is pretty simple:

Give a user as much freedom as you can without empowering them to make your application look ilke ass.

To this end, I usually restrict the sizes of my windows to the smallest size that can reasonably accommodate the UI in most cases. Obviously, when it comes to uesr-provided data it can be hard to prevent 100% of the ugly scenes, but a situation like this, where buttons simply don’t have room to live, is a clear case for limiting the window’s width.

But in spite of little quibbles, On The Job is a fantastic piece of design and engineering. I would recommend it without hesitation to consultants who bill even one client on a regular basis. I’ve given up consulting myself, but this application is almost enough to make me consider resuming. Perhaps I’ll start tracking my time, and issue myself invoices at the end of the month. Ouch, this blog post is costing me $175!

Bob Walsh brilliantly summarizes the conundrum of small indie business people like myself, in the title of his blog: 47 Hats. If I may say so myself, I’ve adapted pretty well to wearing all these different hats. But inevitably, some of them don’t fit as well as others.

I’m not completely inept when it comes to graphic design, but I’m far from professionally capable. The beautiful aspects of my applications are mostly thanks to the brilliant work of designers such as Bryan Bell, who I will continue working with. But I also need somebody at the ready for a sustained period of design brainstorming and production. It’s time for me to take off this hat and hand it to somebody else.

Will you be my visual genius? Will you wear this hat?

About The Hat

As a part-time contractor to Red Sweater, you will facilitate the expansion of the company’s graphic identity in all areas including desktop UI, iPhone UI, web presence, advertising, and more. The position is hourly, with a guaranteed minimum per week or month to be arranged.

The position is primarily “visual design” but your skills in interaction or usability design would also be put to good use.

You’ll have a major impact on the look of Red Sweater’s products and presence. You’ll get paid. And when we get huge one day, you’ll be able to say you were there “way back when.”

The Qualifications

Sound like a position you’d excel in? This hat fits a designer who:

• Pushes pixels and pulls vectors with confidence and skill.
• Is passionate about typography, layout, and visual balance.
• Respects the tradeoff between usability and aesthetic beauty.
• Embraces platform design trends with moderation and taste.

On a personal level, the type of designer I will get along with:

• Work iteratively and collaboratively.
• Accepts criticism but stands up for strongly-held beliefs.
• Designs with integrity and would never steal the work of others.

To Apply

This is an open invitation to talented designers of all ages and circumstances. The only hard requirements are professionalism, skill, and availability for part-time work. Let’s make it happen!

Please send an email to “jobs” at red-sweater.com. Include in your message at least the following information:

• Your name and professional status.
• A portfolio of your best graphic design work.
• Your minimum and maximum hourly availability per month.
• Name up to three designers who you admire. What do you respect most most about their work or how they conduct it?

Feel free to include other information such as your expectations for pay rate, questions about Red Sweater or my work style, etc.

I look forward to hearing from you. And to taking off this hat!

Today Joel shared a very short and dangerous pronouncement on the use of hidden and disabled menu items:

A long time ago, it became fashionable, even recommended, to disable menu items when they could not be used.

Don’t do this. Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work.

Instead, leave the menu item enabled. If there’s some reason you can’t complete the action, the menu item can display a message telling the user why.

He’s absolutely right about hidden menu items, but on the subject he emphasizes, disabled menu items, he’s absolutely wrong.

Joel argues that instead of disabling a menu item, applications should leave them enabled, and instead display an informative message when the user tries to use them. This solves one problem: that of the user who is perplexed as to why a menu item is disabled. I recognize and applaud the desire to fix this issue. But enabling every menu item creates more usability problems than it solves.

Disabled menu items convey valuable information. Users who are skimming menus in order to figure out what to do are trained by years of experience to skim past disabled items and look for enabled ones instead. The more complex the application is, the more valuable this dichotomy becomes. In essence, disabling menu items gives application designers a means of “funneling” user attention to the actions in an application that will actually work at this moment in time.

Sure, it’s frustrating when you can’t figure out why a menu item is disabled. But what would be unbelievably frustrating is drowning in a sea of enabled menu items, for which the application offers no immediate usability guidance. Instead of skimming past disabled items, a user could be forced to select several, each time receiving a valuable instruction (punishment) as to why it was a worthless move. In time the user would learn to avoid these irritatingly enabled menu items, but they would be offered no future assistance in actually avoiding them.

Joel is right that it’s a bad idea to outright hide menu items. Users become comfortable with an application by learning its topography: where each menu item is in relation to its menu and the other items in that menu. When you go about willy-nilly removing and adding items, it can cause confusion. If you’ve ever visited an old home town after years away, you know this problem. You’re sure your favorite restaurant is around here somewhere, but so many of the shops and landmarks have changed, it’s hard to find it as quickly as you once could.

Joel’s suggestion may increase the learnability of an application in one very specific way, but at the expense of long-term usability. Although it can be argued that an application needs to be learnable in order to attract long-term users, I think user loyalty will be greater when the usability of the application is maximized.

What would be a better solution? The idea is to answer the naive user’s question: why is the menu item disabled? For this purpose I can think of many solutions. The application might show tool tips as the mouse hovers over the disabled menu item. Or if the problem is especially grievous, it could warrant a dedicated reference page in the documentation, where users could easily look up the cause of their frustration. The point is to build a framework for application learnability that does not seriously affect the usability of the application for experienced users.

It’s not often I get to say it, but hear me loud and clear today: don’t listen to what Joel says about menu items!

The very first iPod looks sort of monstrous compared to today’s sleek beauties. An awkwardly mechanical scroll wheel, surounded by buttons with large enough gaps to gather dirt, sand, and who knows what. A monochrome LCD display takes up perhaps only 25% of the front surface of the device, looking tiny and impotent on the cigarette-pack-sized case.

The lettering etched into its shiny metallic back reflects its originality: just an Apple logo and the word “iPod.” Branding for a product that stands alone in its market, one that doesn’t need to differentiate itself from the capacities or capabilities of a sibling or competitor. An iPod exists. It holds 1000 songs. And you can buy one.

So I bought one, in spite of not getting it. The truth is, as an Apple employee I was given an offer I couldn’t refuse. Instead of paying the list price of $399, Apple would be offering all of us a one-time half-off deal. Putting a bunch of MP3 files on a portable device and walking around listening to them was the last thing I saw myself doing, but $200 for a 5GB hard drive seemed like a decent deal at the time. I bought the original iPod because it struck me as an affordable hard disk!

But why did I not get it? I loved music, and still do. I embraced technology. I was the ideal target market. But to me, listening to music meant selecting a CD or stack of CDs from my shelf, and carrying those scuffed plastic cases to wherever I wanted entertainment. Disorganized stacks appeared on the surfaces around my home stereo. A pile was always getting moved from the front seat of my car to the back, making room for a passenger. And when I had a full load, they migrated further to position beneath my seat. Compact discs were pure convenience.

I was suffering from a major “getting it” gap. My impressions of what I needed were so distorted and abused by habit that I was blind to the notion of a new device enhancing my life. There was nothing more liberating than the CD. The CD represented listening to my music wherever I was, whenever I wanted to. What did I need with MP3 files and a little device that forced me to transfer files to it? That sounded awkward to me.

What’s interesting to me about this nostalgic trip down memory lane is not so much that I was dense about the iPod and what it could do for me, but that Apple went right ahead and developed the thing anyway. I imagine that most people suffer from this same habitual resistance to new ideas, especially when the new ideas are trying to replace habits that people believe are already optimal. The density I describe here represents serious marketplace inertia for any company that develops game-changing products. How does an innovator convince ordinary people that they’d be happier on the other side of this mental gap?

And most interestingly of all, how does an innovator convince themselves there’s a gap, and that getting people over it will change the world? I only got over the iPod gap with the benefit of a physical object I could hold in my hand, a set of headphones, and some seriously rocking tunes. Apple got over it considerably sooner than that.

Many of us consider ourselves innovators, albeit on a smaller scale than a company such as Apple. So try to imagine a product, a philosophy, or a way of life. Hold it in your hands and examine it carefully. I know you’re sure you don’t need it, and you can’t imagine what you would ever use it for. Neither can anybody else. But in a few years we’ll wonder how we ever lived without it.

Now all you have to do is get over the gap and build it.

One of the points that resonates most for me is Brent’s point about friction:

Present as little friction as possible—don’t overwhelm the new user so that he quits without trying the app. Ask for just the minimum required to make an account: username and password.

I think about friction a lot, both when designing features into my products, and when thinking about how to market them. If you’re an indie software developer and you get me talking for more than about 30 seconds about business, I’ll invetiably start talking about the first-launch experience and how it relates to sales. I call it the “run away screaming” factor.

Every product has shortcomings that will cause some users to run away screaming. The best we can do is try, with each iteration, to make fewer and fewer people do so. If 100 people download your product, and 90 of them run away screaming after launching it once, then you’ve only got a chance of selling to 10 of them. We can assume that statistically, some fixed percentage of the people who remain will end up buying. So cut the flee factor down to 80 and you’ve just doubled your sales.

The easiest way to make a user run away screaming from MarsEdit would be to require that they perform some tedious and complicated setup process in order to get up and running. The truth is, most of the time MarsEdit can figure out how to configure everything just by peeking at your blog’s home page. So I try to alleviate that fear with MarsEdit’s very simple first-launch dialog:

The first screen is intended to be inviting to both established bloggers and curious users who just happened to download a copy of the app before they’ve even started blogging.

For users who already have a blog, they proceed to the second screen:

By the time users have stopped laughing with joy at how easy the process was, MarsEdit is asking them for their user name and password, and proceeds to download the last several posts from their weblog.

Don’t believe me that it’s so simple? Go ahead, I dare you to try it!

I have a soft spot for digital media that defies its nature and tries to adopt a more organic appearance. I suspect a lot of people share this aesthetic preference, so it’s ironic (heh, heh) that we don’t see more of it. I suspect the reason we don’t is because it’s really hard to do right.

What’s particularly good about the Ironic Sans blog is that it captures a lot of the clean perfection of digital while still being jaggy and texturized. The banner headline is perfectly legible in spite of its beautifully bleeding hatched fill. Meanwhile, the cross-hatched pattern that frames the page gives a clear border for the more-or-less conventionally faced digital content.

The juxtaposition of pseudo-analog and digital content just, I don’t know, it makes me excited. It makes me want to look at the site for its own sake. In fact, I wrote most of this blog entry before bothering to actually read the content that Gruber had linked to, a geeky encoding of the New York skyline into gray-scale representation of a histogram.

Some of you are probably wondering, if I like this digital defiance so much, why doesn’t Red Sweater’s design embrace it? Well like I said, I think it’s actually really hard to do right. But if I were a designer, I think I’d really enjoy working on this kind of digital design.

Update: Check out the blog post describing Ironic Sans’s design, pointed to in the comments by the site’s designer/author.