A design can be wrong. The entire thing can be wrong, parts can be wrong, or even a tiny, 10x10 pixel area can be wrong. Not, "I think it's good but it needs improvement" but flat-out wrong. 1 + 1 = 3 wrong. A spelling mistake in a book wrong. A syntax error in a code file wrong. It's not an opinion, it's not a matter of subjectivity, it's a fact: a design can be wrong.

Dribbble Mayhem

Dribbble is a site where designers can upload small screenshots of their upcoming work and receive critiques from other designers. Recently Jason Lynes posted a screenshot challenging the status quo at Dribbble and asking others to hold all feedback unless the designer explicitly asks for it. A mini-firestorm kicked up in the comments, but the most interesting comment was from Jason himself regarding the concept of design criticism:

Screenshots are 400x300, too small to convey purpose, context, and intent in the design. How is that enough information for you to tell me my font's not working, or my color's wrong? For design criticism to be effective, you absolutely must have context. Dribbble has none.

Is he right? Do you really need to see the whole picture before commenting on design execution? No. Definitely, absolutely, positively no. A design can be wrong without any context. Here's why.

What Can Go Wrong

Designs can succeed or fail on a number of levels, some of which are subjective, some of which aren't. Things like the overall concept, mood and its visual appeal are subjective: one person might think a design succeeded in its overall goals whereas another might think it failed. To decide this you probably need to have knowledge of the big picture, the overall design goals, the context. In most cases this cannot be decided by a quick glance at a 400x300 screenshot. If it's a miserable, hopeless failure then you can, but if it's on the border then context is what's needed to make a final call.

So without any context what can you really critique? Design execution. The execution of a design is the nitty-gritty details of the design. The pixel-level details. The alignment of individual elements. The kerning of a logo or headline. The sharpness of an edge. These can be wrong. These can be so incredibly wrong that they stand out no matter how good the overall concept, mood and visual appeal may be. Screwing up the execution of a design ruins the design. Game over, it's wrong, and no context is needed to understand its wrongness. A 400x300 pixel screenshot on Dribbble can be wrong without knowing anything about the project. An iPhone app icon can go from right to wrong in just a few pixels. One misplaced pixel. One misaligned button. One blurry edge. This is what makes a design wrong, this is what makes an execution of a design go from good to garbage.

Examples Of Wrong Design

Wrong kerning on a logo or headlineYes, you can screw this up if it's obvious enough so make sure to manually adjust kerning between letters if needed.

Misaligned elements, uneven paddingElements in a design should be aligned to something: other elements, a grid, a golden ratio frame, the edge of the page, something. If it looks like you tried to align it to something else and it's not perfectly aligned then you failed, it's wrong. Either something is perfectly aligned to something else or it's not aligned to the other element at all. If it's 98% aligned it's wrong. The same goes for padding around elements and whitespace. If you are designing tabs for a website and the text is not aligned properly within each tab it's wrong. 1px off is wrong. It's sloppy, it's junior, it's not professional. What if a plumber only half-tightened a pipe and it was only leaking a little bit? Would you think that was acceptable or would you ask him to actually stop the leak? The same applies here. Either things are aligned properly and have uniform padding or they don't. Either a pipe is leaking or it's not. Simple as that.

Blurry edgesThese look terrible and can ruin a design instantly. What's a blurry edge? It's an edge of a vector object that doesn't lie fully on a single pixel but straddles two pixels. The most egregious examples are long, straight lines that the designer was too lazy to make sure were the width of a whole pixel so they end up using 2 pixels when they should only use 1. To fix these in Photoshop (if using vector shapes) switch to the white arrow tool and select points of your shape individually, then zoom in close and use the arrow keys to move points over a tiny amount until they're perfect.

Broken patternsA pattern is a technique that a designer sets up and reuses in a repeating fashion. Dotted lines would be one example, an overlapping plaid pattern could be another. Anything that repeats in a set manner needs to adhere to its own defined pattern or else it's a mistake. A dotted border that is missing a pixel or has too much spacing between two dots. Ten boxes in a row and the space between the 3rd and 4th is a few pixels off. A stripe pattern using lines 10 pixels wide uses a 9 pixel line by accident. These are mistakes, it's not a subjective matter. If you're not careful when copying and pasting layers in Photoshop it can happen.

Techniques To Avoid Design Errors

If you're not sweating every pixel then you're already off to a bad start. What does that mean? It means using alignment and measurement tools to make sure everything is perfect. It means double-checking to make sure an element that's supposed to be centered actually is. The details are the design. They're not an afterthought or something you fix later, it's something embedded in everything you do. Every icon, every line of text, every box, every pixel should be cared after as if it's 10 feet tall staring you in the face.

Design errors separate stock-photo-slappers, clip-art-arrangers, and programmers-turned-wannabe-designers from real, world-class, totally-fucking-amazing professional visual designers. If you're not a world-class designer but aspire to be one, don't ever commit a design error. Your visual tone could be off, the colors could be muddy, the concept could need tweaking but you should never, ever make a mistake that I've listed. There's no excuse, and the best part? Fixing a design error requires no design talent. You don't have to write like Ernest Hemingway to be able to spell words correctly and you don't have to be a great designer to simply double-check every pixel and make sure it's in the precise place you planned it to be.

Back To Dribbble

Designers who care about their work want to know when something is wrong. Not subjectively wrong (although that's good to discuss as well) but objectively wrong like a design error. A flat-out mistake. If someone spots a design mistake in my work I want to know because I want to fix it; I want my work to be perfect and represent my best efforts. It's not an ego thing, it's not a hurt feelings thing, it's a professional thing. If a plumber leaves a pipe leaking then it's a mistake. If a writer misspells a word in a novel then it's a mistake. If a designer makes a design error then it's a mistake. Plumbers who don't care about leaky pipes aren't professionals. Neither are writers who leave misspellings in books nor designers who make egregious design errors in final designs. Either you're a professional or you're not, it's as simple as that.

Sorry folks: Beak, my fledgling, ever-unfinished Twitter app for the Mac and iPhone is dead and will never be worked on again. Why? Please let me explain.

Beak's Beginnings

The first line of Objective-C I ever wrote was for Beak. Starting out in the world of Mac development with a Twitter app is pretty ambitious and I learned a lot. I didn't know what delegates were until I started using MGTwitterEngine. I never knew how to build custom AppKit user interfaces either. I never opened Interface Builder before I started designing Beak's (underwhelming) Preferences window. In short, I cut my teeth on Beak and it shows. It was never really polished, nor did it represent any kind of best practices for Mac development; the main interface component is a WebView so that says a lot by itself. It was my learning tool, my first trek into Cocoa development.

Why I'm Done With It

I have a full-time job working on the web and Cocoa development is my evening & weekend passion. If I'm lucky I'll have a solid 2 hours at night to crank on some code, but many nights it's less than an hour, or no time at all. Building a fully-functional Twitter app is hard and it takes a lot of time. To build a nice offering in the market you have to implement the same 30 features as everyone else and then after that you can start to differentiate. Ever heard of a Twitter app without Favorites? Or Direct Messages? There are a bunch of things you absolutely need or else people complain. Heck, I still get a few emails a week about Beak not saving your password. (Hint: I didn't forget about that feature, I just didn't know how to store anything in the Keychain when I first wrote it.)

Besides lack of time, I broke the golden rule: I didn't build an app that filled my own needs. I don't use Beak. I never used Beak. I also never used Twitterrific or Tweetie or any other Mac Twitter app. I use the Twitter website. Why? Because my primary usage of Twitter is for finding new links and I read those in a browser. I don't like being in a desktop Twitter app, clicking a link, being transferred to Safari, reading an article, then switching back to my timeline in a different application. It's just how I use Twitter. Everyone uses it differently, and I'm probably the oddball here, but that's just how it is. Perhaps if I made Beak a gigantic, full-screen application with a built-in web browser I would've used it.

My third reason is simply a lack of interest in long, time-sucking projects. Like I said before, I do Cocoa development on the side, as a hobby, and as such I like to be entertained and to feel motivated. Dragging along to build an app for months isn't exciting to me. I like tiny projects because they keep me excited and I can always see the light at the end of the tunnel. Digital Post was a nice, concise project. I spent about 40-50 hours of work to build the 1.0 version. I could envision the entire project in my head at all points, so I was always shooting for the finish line. These kinds of projects just fit me better and they keep me motivated, excited and pushing hard at all times. It seems like a simple concept but it's taken me years to understand what motivates me and what doesn't. Beak 1.0 for Mac and, recently, Beak 1.0 for iPhone were both so complex their launch loomed far in the distance, like a mirage I could never run fast enough to touch.

Lots Of UI, Not As Much Code

I'm a designer. More specifically, I'm a user interface engineer. I design software and then I implement these designs. The main reason I write software is to make my mockups clickable and real. I have 50+ PSDs of never-implemented Beak interfaces. I have dozens of NSView & UIView subclasses with prototyped custom interface components ready to be hooked up. My brain and mouse would rush ahead to knock out the user interface and UI code but then, time after time, I'd get sidetracked and bogged down by network code, error-handling, API issues, memory leaks, 45fps scrolling instead of 60fps, caching code written & rewritten, complex text layout problems, etc. I'm good at solving these problems but after spending night after night tweaking and rewriting non-UI code I'd just get burnt out and would ditch Xcode for Photoshop just to give the other side of my brain something to latch onto. Then, inevitably, I'd start designing the UI for the next big Beak feature and would get frustrated knowing that I still had the previous feature to finish before I could move on.

Thank You

Over 30,000 people have downloaded Beak since it first debuted, a number that's just incredible to me. Even with all its flaws I still get emails and Twitter replies from people who think it's fantastic. It sounds crazy, but Beak made people think of me as an app developer and no longer just a web designer. It completely revitalized my skill set and realigned my career trajectory. It taught me Objective-C and made it possible for me to build an iPad app that launched Day 1 of the iPad App Store. It opened my eyes to real, double-clickable (and single-tappable) software development that I had never experienced when working on the web. I owe Beak and everyone who ever downloaded Beak a sincere Thank You that cannot be expressed in hypertext. Honestly, thank you.

(To answer a question before it pops up, I have no plans to open source Beak, nor do I want to hand the project off to someone else to finish. It's a project too close to my heart to give away so it will simply die an elegant death on my hard drive and in the cloud where it sleeps at night.)

I've been playing with my iPhone for a little bit, here are my quick, unorganized thoughts.

• I bought a bumper, and before I put it on, it felt like the phone was incredibly droppable. The tapered edges feel like they want to slip through your fingers. I highly recommend the bumper.
• The plastic back on the 3GS has a slightly higher coefficient of friction (less slippery) than the new iPhone 4 back which I assumed before I got the phone. Not slippery, but definitely slipperier than my previous iPhone.
• The camera is astounding. I took a quick picture of a flowering tree outside the office and it was incredibly sharp and beautiful. Probably the nicest picture I've taken in years.
• It's thinner, about the same size as just the plastic case on the 3GS. Slightly thicker than the iPod touch which is like a wafer.
• The screen is making my eyes buggy because it's so sharp. I've never seen a screen with this type of pixel density and it's so sharp it's almost jarring, like my eyes aren't used to it yet.
• The screen is brighter and has a different color profile than the 3GS. It's a lot more contrast-y, blacks are blacker, whites are whiter. The angle at which you can view the screen is incredible due to the new IPS display.
• Text rendered on the new screen looks foreign it's so sharp. I've never seen Helvetica like this. Viewing text on the display is now my favorite thing to look at.
• Apps that haven't been updated with 2x-resolution raster images look like shit; pixelated and blocky and clunky. I didn't think I'd notice but I definitely do, it's unmistakeable which ones aren't optimized for the new screen.
• The fast app switching feature in iOS 4.0 makes the phone feel way faster than the 3GS. Obviously if you load iOS 4.0 on your 3GS it'll seem faster too. I think this feature is biasing my overall feeling of quickness on the iPhone 4, but everything seems much faster. Apps feel like they want to start displaying their interface before their opening image is done zooming out. Reminds me of when apps open really fast on a Mac, before their first bounce is done.

So far, it's brilliant.

Your app has too many settings, too many things to tweak. API endpoints? Colors of the rainbow? 100 different fonts and font sizes? Temperature in Kelvin? Switch the app to use Esperanto?

Kill the settings, kill them all.

Your Vision Is Your Software

You're the developer, build what you want. Your app should be an expression of your opinions. Jason Fried from 37signals shares this thought as well. Here's what he had to say in his first book Getting Real:

Some people argue software should be agnostic. They say it's arrogant for developers to limit features or ignore feature requests. They say software should always be as flexible as possible.

We think that's bullshit. The best software has a vision. The best software takes sides. When someone uses software, they're not just looking for features, they're looking for an approach. They're looking for a vision. Decide what your vision is and run with it.

And remember, if they don't like your vision there are plenty of other visions out there for people. Don't go chasing people you'll never make happy.

His company has made millions of dollars leaving out the fluff that others love to include. They built their first application Basecamp to satisfy their own needs and left out the features they didn't think were important. Jason considers his team software curators, continually trimming and editing features down to their essence. They build opinionated software.

Trim The Fat

If there's a choice between setting a value to A or B, and you always choose A, why not just make A the main, unsettable, unchangeable choice? If you think A is the best decision, why even let people choose B? Well, in App Store land, people like to whine about B. They'll post 1-star reviews asking when B will exist and say that they'll bump it up to a 5-star review when B is implemented. Others will see that review and ask about C, or D, because they think those are equally important.

This is all bullshit.

You're the developer. Everything is up to you. Apple doesn't listen to users and they're the most successful technology company in the world. They have a fearless leader who's not afraid to piss people off by removing floppy drives or buttons on a mouse. He's not afraid to scrap successful, acclaimed products and start over from the ground up. He builds what he wants because he knows he's building great stuff. That's what you should do, too.

Recently, Iconfactory announced that they're rewriting and rethinking their flagship Twitter application, Twitterrific:

The previous design ended up being overwhelming for normal users (and even some experienced ones) and became very confusing for people with multiple accounts since it was unclear which account was performing a search or looking at trending topics. There were also three different areas to set preferences and many of the options in the preferences were unnecessary and confusing to most users so they were avoided or left to defaults anyhow. So we took a leap and removed the preferences completely, only adding them back in when we found something that absolutely needed it.

Here's a comparison screenshot between the old Settings options and the new, completely slimmed-down version. They gutted their Settings; they're nearly gone. This takes a lot of guts and you can only do this if you really know what kind of software you want to build. You've gotta have the big picture in your head and you have to know where you won't compromise. Inevitably some power users may be upset but the Iconfactory is looking at the overall user experience and that matters more than what some tech bloggers think.

Power Users Don't Matter, Build For The Masses

Feature lists and pages of settings get a small segment of power users excited, not regular users. Regular users want elegant, smart software that just works right without having to fiddle with any additional settings. A perfect example is multitasking in Android vs. iOS 4.0. Apple waited to introduce multitasking because they didn't want to build a system where background apps drain the battery. Compare this to Android: just a few weeks ago Larry Page said that some background apps will drain your battery if you let them. Multitasking in Android was built solely for power users who are expected to force-quit apps and manage their phone's radios in order to maximize battery life. (Here are 20 tips to improve an HTC Evo's battery life.) Jobs made the call to build multitasking the way he saw fit, not the way the tinkerers and phone hackers wanted.

Don't compromise your vision, don't compromise your opinion. If you think 12px font looks best in an interface, don't allow people to move it to 10px. If you could never picture yourself changing a setting to anything else but A, don't even give the option to change it to B. Just don't do it. Build software for you. There are many, many people out there just like you who will appreciate it.

Build what you want.

Digital Post, my newspaper app for the iPad, uses a number of custom user interface elements to build out the full user experience. One of these custom components is a horizontal topic selector that you can swipe and also tap to select individual topics.

Original Concept

Facebook for iPhone was one of the first apps to use a horizontal scroller to let you navigate various screens or topics. When first designing the interface for Digital Post I thought it was a perfect opportunity to do my own version suitable for an iPad app.

Building The Main Slider

The requirements were simple: can be swiped left or right and each item in the menu can be selected. This led me to make the main component a UIScrollView subclass. I subclassed it because I needed to do my own custom drawing in its drawRect method to execute the design. Let's take a look at the drawing code, it's very simple:

- (void)drawRect:(CGRect)rect {
    UIImage *bg = [[UIImage imageNamed:@"slider.png"]
      stretchableImageWithLeftCapWidth:15 topCapHeight:0];
    [bg drawInRect:self.bounds];
}

Here we're taking a PNG, stretching it horizontally, and drawing it in the precise location that this scrollview is located. The left cap of 15px means that the first 15px of the image are kept pixel-precise, the 16th pixel is used to stretch across the wide area, then the final right pixels are kept pixel precise also. This is a common technique to execute custom designs, I wish I could do this in CSS!

Adding The Tappable Topics

To make a UIScrollView actually scroll you need to know the total width (or height) of the content it contains. For my scrollview, I programmatically add the tappable topics and then calculate the total width of them once I'm finished. I first thought to make each topic a custom UIButton but for some reason, if the buttons are one-after-another with no pixels in between, the touch events they intercepted stopped the slider from scrolling. I couldn't quite figure out the issue but fortunately there are numerous ways to accomplish the same design. Instead of UIButtons I decided to use UILabel subclasses and add the tap events myself using UIGestureRecognizers, one of the new APIs available on the iPad. Here's the code that calculates the total width of this scrollview's content:

CGFloat contentWidth = 20;
for( NSString *string in topics ) {
    contentWidth += [string sizeWithFont:[UIFont boldSystemFontOfSize:18]].width + 30;
}
self.contentSize = CGSizeMake(contentWidth, self.bounds.size.height);

Here I'm using NSString's method sizeWithFont to calculate the exact size of a string rendered using a given font. The 30px extra is to account for 15px padding on the left and right of each one. Once I've iterated across my entire array of topics, I now have an exact pixel amount to assign to the contentSize property.

After calculating the total width, I add each topic one at a time to the scrollview. (DPTopicLabel is my UILabel subclass.)

CGPoint startingPoint = CGPointMake(10, 0);
for( NSString *string in topics ) {
    CGRect labelRect = CGRectMake(startingPoint.x, startingPoint.y,
      [string sizeWithFont:[UIFont boldSystemFontOfSize:18]].width + 30,
      self.bounds.size.height);
			
    DPTopicLabel *label = [[DPTopicLabel alloc] initWithFrame:labelRect andText:string];
    if( [string isEqualToString:@"Top Stories"] ) {
        [label setSelected:YES];
    }
			
    UITapGestureRecognizer *tap = [[UITapGestureRecognizer alloc]
      initWithTarget:self action:@selector(handleTap:)];
    [label addGestureRecognizer:tap];
    [tap release];
			
    startingPoint.x += label.bounds.size.width;
    [self addSubview:label];
    [label release];
}

First, I create the CGRect that will be the exact position of my tappable topic. The CGPoint startingPoint is updated at the end of each iteration to push it ahead to where the next topic will go. Next, I create my new DPTopicLabel and use my custom initWithFrame:andText: method to pass in what the text should be. If the string is "Top Stories" then I call my setSelected method which draws the custom background for a selected topic.

After I create the topic I need to make it respond to touch events. There are a few ways to do this but I like how the new gesture recognizers work so I used that. Once you add a gesture recognizer to a view, you tell it what type of gesture you want it to recognize (complicated, eh?) and then what method you want it to call when it happens. In this case I'm catching tap events and passing in my handleTap method which will toggle the selected state of my label.

All that's left to do at the end is change my startingPoint variable and add the label to the overall scrollview. Done!

Conclusion

This isn't magic and it's not all that complex. Building custom UI components is all about being thoughtful and planning out each step. The steps here:

1. Add a scrollview
2. Draw its background
3. Add custom labels one at a time
4. Set one of those to be selected, that has a custom background

Feel free to use these techniques & code in any personal or commercial projects you may work on.