Lack Of Understanding

A few friends and I were the co-founders of 9rules, one of the largest independent blog networks of its day. I designed the fairly well-known (if you had a blog back in the mid-2000s!) 9rules leaf logo, which, to this day, is still the only good thing I've ever made while using Illustrator. For some reason, this was my most copied design ever. Toyota copied it for a yearly conference they run. Hell, it's even used as the logo for a mall in South Africa.

The dumbest thing about using the 9rules leaf logo for something other than 9rules is that the logo had a specific meaning. We had 9 principles we followed with the startup so there were 9 leaves. The design was meant to resemble a '9' and an 'r' side by side. The colors meant something, too. The logo represented our startup, it wasn't some arbitrary swoosh or vector swirl, we spent a lot of time on it and it was unique to our business.

When companies steal a design made for something else, they skip the part where they toil over the design and develop a deep love and appreciation for it. In 2009, Jason Fried wrote a blog entry about why you shouldn't copy them or anyone else. Here's a snippet.

"Here’s the problem with copying: Copying skips understanding. Understanding is how you grow. You have to understand why something works or why something is how it is. When you copy it, you miss that. You just repurpose the last layer instead of understanding all the layers underneath."

Copying someone else's designs, the way Samsung did with Apple's interface and industrial designs, skips over the whole part about why they were like that in the first place. Why did a designer throw out 20 iterations and pick the 21st design to be the one to ship? What led them to the those specific conclusions and insights? What down-the-road thinking influenced the design? Samsung doesn't know why Apple went with a homescreen with a fixed row at the bottom, they just know that the iPhone is hot and they want all their phones to look like the iPhone in the eyes of consumers. That's why they stole Apple's interface designs: to short-circuit the innovation process and jump straight into the line ahead of everyone else.

I really don't care about patents or trademarks or trade dress or any of that. To me, a designer, it's just about honor. Deciding to use someone else's pixels as your own is not just lazy, but it's dishonest. It's a slap in the face. And that's why I'm glad Samsung owes Apple over a billion dollars, because so much design theft happens in the world, it's about time someone or some company got knocked down a few pegs because of it. This victory isn't just a victory for Apple, it's a victory for every designer who has been ripped off by people who didn't care or thought they could get away with it. Tonight it's clear that sometimes they can't.

• Buttons
• Panels
• Windows
• Profile Pictures
• Icons

If you really think about it, most interfaces (especially for iOS apps) use tons of rounded rectangles in different shapes and sizes. Long and skinny ones with lots of shine. Squarer, flatter ones with some texture. Smaller, slightly inset ones with photos inside. The list just keeps on going. I actually joke around with friends that my main job is making rounded rectangles look great, so I thought it was time to show off some common techniques.

Drawing Them

It's important to keep your elements in Photoshop in vector format as long as you can because they can be scaled and re-styled easily. To draw a rounded rectangle, I use (gasp!) the Rounded Rectangle Tool with Snap To Pixels turned on. This is incredibly important or the edges of your shape will lie on a half-pixel and look blurry. There are some other ways to draw rounded rectangles in Photoshop (which Marc Edwards has conveniently outlined) but I typically stay with the vector shape tool because it's easy.

If the edges of your shape aren't sharp, then strokes/gradients/highlights/shadows you add later won't be perfect.

Up or Down?

If your goal is to craft subtle and realistic user interfaces that look and feel like real world surfaces, you'll be making a choice: is this element popping off the screen (convex) or indented into the screen (concave)? Buttons are convex whereas large panels containing text and other elements are typically concave.

On the left is a convex button that is designed to look like it's bulging off the screen. It appears bulged out because it's made to appear just like a convex object would appear in real life if it had 90°, top-down lighting. That means that 1) the light catches the top of the object and adds a lighter stripe of highlight, 2) as the bottom bends back down towards the screen, the light is blocked and it gets darker (light-to-dark gradient), and 3) it casts a very subtle shadow, indicating that it's sitting on top of the surface. This specific combination of highlights, gradients and shadows is the most basic way to make a rounded rectangle appear bulged out and convex.

On the right is a larger panel that is designed to look inset into the screen. The fill color is a mostly-transparent black, it has some inner shadows, and then a thin white drop shadow at the bottom. If we analyze this using the same lighting conditions as the previous example, it's made to look sunken in because 1) the edges or lips of the shape are at the surface and cast an inner shadow inside (these edges block light like an awning off a building blocks the rain, causing a shadow) and 2) as the bottom edge of the shape comes back up to meet the surface, the light catches that lip and causes an edge highlight.

Download this PSD here.

Pictures

Most iPhone apps that display profile images have them look slightly sunken into the surface or popped out and semi-glossy. This is achieved with mainly the same techniques from above, but for the glossy one I added a diagonal gloss line (a white-to-transparent gradient cut into a triangle) as a separate layer.

Download this PSD here.

Mixing It Up

Although there are distinct elements common in most convex-or-concave elements, there's no special formula for how to accomplish these effects in Photoshop. I typically tweak size and opacity sliders on Inner Glow, Inner Shadow, Stroke and Drop Shadow layer styles until things look good. Other people are Bevel & Emboss specialists. Here are some more examples of rounded rectangles styled in some different (but reusable!) ways.

Download this PSD here.

Scratching The Surface

These are just some of the myriad ways you can style and use rounded rectangles in your interfaces. If you really want to see some creative designs, check out some icon designs on Dribbble. All it takes is some imagination and experimentation, and you can use gorgeous rounded rectangle designs throughout your interface.

It's not remarkable, but it caught my eye because the look of the embossed text in the cap is exactly the look that so many designers are trying to replicate these days, myself included. What look is that?

The emulation of physicality.

A current trend in the design of digital interfaces is to subtly hint that the objects on the screen have weight, volume and surface undulations like they would if they were manufactured and held up in front of you. This is why Apple puts defined, shiny gloss lines on buttons and toolbars: because they're emulating a plastic lens shape and how lenses interact with light. Lenses refract light in precise ways and the specific coloring, gradients and glows used in iOS toolbars and buttons were put there specifically to make them look more like a long, plastic convex-on-both-sides piece of glass instead of just pixels on a screen.

Imagine if the iPhone's interface were manufactured and put up on a wall. There'd be realistic textures like linen, leather, shiny plastic and matte aluminum. These textures wouldn't all sit at the same distance from the surface, they'd be staggered — some elements indented, some elements poking out — because the real world isn't flat. Everything is either convex or concave, shadowed or highlighted. Just look at how many angles and surfaces a simple light switch has. Convex, bubbled text that casts a shadow. Indented, shadowed crevices. Light-to-dark gradients on surfaces.

And people all over are putting realistic switches into digital interfaces. They're trying to emulate the highlights, shadows and gradients that a real switch has when lit from above. Indented buttons, convex panels, glossy shines, textured mattes, embossed text, and it goes on. These are the elements that interface designers use to make their products appear touchable, tactile and hefty.

Now this physical emulation of real objects can be taken too far, but just like with everything else, moderation is the key. Some of the top apps in the App Store use these exact techniques to great effect. The leather and embossed buttons in Camera+. The indented and matte tweet actions row in Tweetbot. The textured opening screen of Path. You may not immediately notice these little details, but they make digital interfaces appear more valuable, like little hand-crafted executive paperweights: expensive, heavy and solid.

The pixel-perfect emulation of physical surfaces and lighting in a digital interface is the secret weapon of interface designers. Little touches like panels that are slightly indented and shadowed, subtle cloth-like texturing, and white highlights on embossed label text may not be immediately perceptible, but they add a richness to the overall experience that most apps just don't have.

Low Information Density

Mobile phone screens are small so each pixel is incredibly valuable. Horizontal screen real estate is even more valuable because you have fewer pixels on the horizontal axis than you do the vertical if you're holding your phone in portrait orientation.

Apple provides UITableViews two main display modes: plain and grouped. Plain rows extend to both edges of the screen and are primarily used when a lot of information needs to be displayed like in Mail, the App Store, Facebook, Music and all previous versions of Twitter for iPhone. For reasons I cannot explain, the latest version of Twitter's iPhone app uses the grouped style that doesn't extend to either side of the screen. This automatically introduces 10px of padding on each side which cuts the horizontal resolution down to 300px, leaving 20px less room for each tweet. Since the primary focus of Twitter is to, wait for it, read tweets, this is not a good thing. In fact, this coupled with the removal of the text size setting causes the new version to show fewer tweets per screen compared to the old version.

Twitter yesterday is on the left, Twitter today is on the right. I scrolled to the same spot in both apps to make the row height comparison more obvious.

And I can't exactly put my finger on it, but the new grouped tableview style makes the interface feel more claustrophobic, more boxed in and constricting. Because of this change it no longer feels like you're in Twitter, it feels like you're just watching Twitter, or viewing Twitter's website inside the app. Margins on either side of an interface are for the web. This is an app, and apps need to expertly use the few measly pixels they have.

Forced "Discovery"

A main focus of this redesign is the new Discover tab which 1) shows random things to you, and 2) cannot be hidden. Seriously, I can't make heads or tails of what it's supposed to be showing me. I think it's a personalized-social-graph-recommendations-search thing all jumbled together. Unfortunately, using search and/or giving a shit about hashtags is at the bottom of things I use Twitter for, mainly because the trending topics are dominated by stupid rap music memes or Justin Bieber fans. Here are some of the most popular trending topics this past year: #aintnothingsexyabout, #4wordsaftersex, #BestSexSongs, #secretturnon, #youknowitslovewhen, #muchlove, #IsmileWhen, #yougottaloveitwhen, #youdeserveashoutout, #ItsMyAddiction, #WhatNotToSayAfterSex, #sevenwordsaftersex, #thingsblackgirlsdo, #thingsblackpeopledo, #doesntmeanyourblack and #NotAllBlackPeople so please excuse me if I don't trust Twitter to bubble up and show me interesting, recommended, personalized content.

Removal Of Gesture Shortcuts

My primary usage of Twitter includes the following:

• Clicking on a link within a tweet.
• Replying to tweets.

When I wake up in the morning and check Twitter, these are the actions I take. I see tweets with links and I check out the link. I see mentions and I reply back. The way that I accomplish these tasks is through the use of gesture-based shortcuts that I've come to know and love, and, unfortunately, the shortcuts I use to quickly accomplish these two tasks are now missing and I have to tap more times to do it.

Previously, to view a link inside a tweet, I'd tap once on a tweet, then tap on the link to view the webpage, then swipe back in the navigation bar when I was done. In the new version of Twitter, it takes the same number of taps to get to the webpage, but it now takes 2 taps to get back to the spot in the timeline where I was previously at instead of a single swipe.

To reply to a tweet from the timeline view, you used to be able to swipe on the row to expose the action icons allowing me to swipe-then-tap to initiate a reply. In the new Twitter, this gesture has been removed so I need to tap on a tweet, wait until the next screen loads up, then tap on the reply icon on that screen to start the reply. Then, after I post the reply, the new version of Twitter brings me back to the single tweet view forcing me to tap one more time to get back to the timeline. On the old version of Twitter, as soon as the modal tweet window is dismissed, you're already back in your timeline. More taps, more waiting.

Removal Of Features

Removing features from an app once they're in place and being used is a tricky decision. On one hand, it can make your overall product simpler and cleaner but on the other hand it pisses off people who were using those features. The latest version of Twitter for iPhone ditched a lot of existing features and it's already causing some consternation. Here are a few features that are no longer available:

• Favstar integration
• Translation of tweets
• Link reposting
• Copying a link by long-holding it
• Turning a Twitter user into a contact
• Shortcut to reading a link later
• Changing text size
• Showing only username or only full name in timeline
• Landscape mode
• Can no longer quickly tell if someone follows you

This is a fairly long list of things to remove, and I'm sure I still missed a few. I'm already really annoyed at seeing full names in my timeline and having a larger text size means fewer tweets shown on the screen at once.

Things I Like

The new Twitter for iPhone isn't all bad, there are some significant additions that I'm a fan of. I like the Interactions area which shows favorite, follow and retweet activity. I like the favorite and retweet counts on the individual tweet screen. And, although the padding on the outside of tweets is a bad thing, I do like the slightly-tweaked padding on the inside of tweets and the removal of the gradient.

I think the new app will be more inviting and accessible to new users, but I don't like that this comes at the expense of the user experience and existing gesture shortcuts. There's a way to make both novice and advanced users happy, and I hope Twitter 4.1 does a better job at appealing to all sides of their userbase than 4.0 has done.

Here's a quick list of what's new:

• Cleaner, simpler, sharper, less blue, more white.
• There is now a separate homepage that's not merely a list of blog entries. Those are over here.
• My portfolio is back.
• A new services page for people interested in having me work on their apps. More on this in a bit.
• A nicer, more carefully written about section with an extremely classy photo frame.
• An updated contact page that works better than the last one. Spammers, let's do this.
• On single article pages the navigation bar is sticky at the top as you scroll for quick access.
• Now I actually link to Design Then Code. Fancy that.

Thoughts On The New Design

The previous design looked faddish and I stopped liking it almost instantly after it went live. Too blue, too bubbly, too a lot of things. For this design I wanted something that would stand up and look good awhile from now, not fall on its face and be dated in a month. But at the same time, I wanted to keep the elements of the previous design that I thought worked well, namely, the typography design for an individual article. The column width is the same, the fonts are the same, and the spacing is nearly the same, but the chrome around it is now cleaner and more subdued.

Up to about a week ago, a lot of things on the page animated into position; logos fading in, navigation sliding across, etc. After taking a hard look at it, I decided to remove the superfluous initial animations and take the experience down a notch into a more subdued feel. I love animation, and I really love CSS3 keyframe animation, but I don't want people to be distracted if they're here on my site to read an article, especially if they came here via a search engine. So, I took it all out.

One design concept I really liked about the previous site was that nearly every section of the site had its own feel with a slightly customized version of the main layout. I wanted to retain that same feeling with the redesign, so you'll notice that my portfolio, services page, about section and contact form all have a look that's unique compared to the other main sections. Personal sites can get rather tedious so I wanted to make sure visitors were greeted with a little bit more personality than they were expecting.

Services

I don't take on much client work, in fact, I haven't said "yes" to a project for a number of years until very recently. The reasons for this are numerous, but primarily it's a matter of time. I have a fun full-time job (that I don't plan on quitting) so outside of work if I'm using my computer I'm typically working on Design Then Code or various unfinished apps. However, outside projects can be fun if they're the right kind of project, so I'm taking a bit of a leap and plan to take on a few, small projects throughout the year. My new services page outlines the type of things I offer as well as my current hourly rate.

And Finally

As someone who doesn't blog as much as he should, I believe I'm contractually obligated to say that this redesign will make me want to write more. I hope that's the case, but please don't hold your breath!

And, oh yeah, there's a tweet button now at the bottom of all entries. I hear it's what the cool kids are doing.

If things under the glass move as you move your finger, the illusion of direct manipulation of a digital interface is created. If you move your finger and, then, a split-second later something moves in response to your movement, that breaks the illusion. Apple has fully understood this from the beginning, and the iPhone has always responded to pinches and flicks with nearly 1:1 accuracy, especially in the browser, which is where iPhone users (myself included) seem to spend most of their time.

Android, on the other hand, has always felt laggy to me. I've used the Nexus One, all the carrier versions of the Galaxy S, the Nexus S, HTCs, Droids, the list goes on, and none of them have felt right-on-the-button perfect when I move my finger around on the screen. I move, the phone processes some things, and then the interface moves. This has been the Android way since Android's inception. The built-in browser is the most egregious example of sluggishness, especially when pinch-zooming or double-tapping. Check out this video of an iPhone 3GS vs. a Nexus S. Astoundingly, jaw-droppingly bad.

Now with this in mind I just saw that the Galaxy Nexus, the new supreme king of Android phones, has been unveiled. This Is My Next has a hands-on review and this is the single line that stood out to me:

The subtle, pervasive lag that has characterized the Android UI since its inception is still there, which is not a heartening thing to hear when you’re talking about a super-powered dual-core device like the Galaxy Nexus.

Pervasive lag? On a mobile device that's running the very latest Android version? Powered by one of the beefiest mobile processors in the world? Samsung's cream-of-the-crop phone running Ice Cream Sandwich is still, still laggy?

Totally fucking unacceptable.

Imagine if your mouse cursor couldn't keep up with your hand movements, or if letters didn't appear on the screen until a moment after you pressed your keyboard. That's how egregious of a user experience problem this is. If a user interface doesn't respond as quickly as possible to a user's intentions and movements, it's a pile of rubbish. Immediate touch response has been solved by Apple for years, why can't Google and Samsung and Motorola and HTC solve it as well?

Other teams crank out apps every few weeks, throwing the proverbial app at the wall to see what sticks. To be frank, most of these apps are ugly and useless and they bring the overall bar of the App Store lower and lower. Unfortunately, some huge successes in the App Store have fell into this category: apps that nearly every developer has taken a look at and said, "I could build this in a weekend!"

The most recent trend-cum-scam in the App Store is the faux security app where you build background images that look like an Android lock screen graphic. These apps just make images, they don't really do anything related to security. Tens of thousands of people have bought these apps under the guise of enhanced security but, inevitably, leave low-star reviews when the app doesn't actually do anything it says in the description.

Which brings me to Nice & Mean.

10 Hours, 1 App

After discussing these Android-lock-screen-maker apps with my friend Kyle, I told him I wanted to do a little experiment: I wanted to build an app in about 10 hours that was made "for the masses" to see how it might do. I don't know why, but the first thought that popped into my mind was an app that showed reaffirming, positive messages to the user after they press a big red button. Very exciting. So I started working on it and I gave myself a maximum timeframe of about 10 hours to design it and code it.

After the design was done and the app was mostly developed, at about 2am one morning, I woke up with an idea. Why just show nice phrases? Why not show mean ones, and do the whole yin/yang good/evil thing? It adds a new dimension to the app and it might expand the audience to a wider demographic. So after a little bit more time than I had originally planned for, I had a finished app. Two sides, each has a big red button. One side tells the user Something Nice, the other tells them Something Mean. The icon uses the well-known greek tragedy & comedy masks.

May I present Nice & Mean, an app that can brighten your day (or ruin it!) depending on which side of the app you use. Find Nice & Mean in the App Store.

An Experiment

I have no idea what to expect. It could sell 10 copies, 100 copies or 10,000 copies. People might love it, they might hate it, they might think it's dumb or they might think it's hilarious. All I know is that even though it's a simple app, I put a lot of thought and polish into it. I don't know how it will sell, but I do intend to write a follow-up after a few weeks.

Stay tuned.

1. 15" & 17" MacBook Pro refresh. The next iteration of these two laptops will include a removal of their optical drive to decrease thickness and overall weight. They won't have soldered on flash memory like the MacBook Air but I bet an SSD drive will be the standard configuration.

2. 13" MacBook Pro will slowly fade into that good night. The "Pro" line will be mostly designated by size and a 13" MBP is the odd-man-out.

3. 11" & 13" MacBook Airs will be Apple's bread and butter laptops and will get faster processors and better batteries as time goes on. No PC manufacturer can beat Apple on the price of an "ultrabook" even if Intel dumps tons of money into the arena. The Airs are selling like crazy so I can see Apple doing nice updates every year or so.

4. The iPhone 5 will come out in October and will be thinner, have a larger screen (but same resolution), and will be much speedier than the iPhone 4. Hopefully with more RAM, too. The screen will be closer to the right and left sides of the phone and will take up a greater overall surface area compared to iPhone 4.

5. An iPhone 4S will be released at the same time as iPhone 5. This will be made of slightly cheaper components so Apple can sell it for $99 on a 2-year contract. Mostly same dimensions as current iPhone 4 but potentially with more RAM or a faster processor. The big deal is this will be sold to Chinese carriers.

6. How many times does Apple have to say that this year is "the year of iPad 2" for people to understand that an iPad 3 won't come until next year? iPad 3 will have a screen with 2048x1536 resolution at the same physical dimension as the iPad 2. Form-factor will mostly be the same except the home button will look more closely like the upcoming iPhone 5's wider button. It'll likely have more RAM and a faster processor. It could also cost more than existing iPad 2 and then Apple could keep making iPad 2s but price it $50-$100 lower per model to stay attractive at the low end and kill Android tablets that try to undercut.

7. Mac Pro gets killed and replaced by a new type of desktop machine or configuration, perhaps just some Mac Mini-like boxes Thunderbolted together for hyper-fast processing. Apple is caring less and less about the professional end nowadays and more about the prosumer end so a product revamp here aligns well.

A designer who does not write markup and CSS is not designing for the web, but drawing pictures.

The reason I know that this stirred up controversy is because I received dozens of replies, nearly instantly, about how much they disagreed with the statement. On the other hand, the tweet was retweeted over 70 times so that means a healthy number of people agreed with Andy's view of the web design profession.

So who's right? Is there a correct answer? I don't know, but what I do know is that designers who are also programmers are incredibly valuable so let's talk about why.

I'm the odd combination of both a designer and software engineer. I've been designing websites and software for more than half my life, and I've also been developing websites and software for the same span of time. In the early 2000s I helped start a successful design firm and a (mostly) successful startup, and as any entrepreneur can tell you, you have to be able to wear multiple hats and do a great job no matter what you're doing. Hell, I was even half-decent at cold-emailing companies and selling advertising spots. After the iPhone came out I learned Objective-C and the Cocoa APIs and now I also design and build iOS software. I work on web software during the day and mobile apps at night.

I design all day long, I code all day long.

But most people don't do that.

Most of my friends who are designers are pretty amazing at what they do. World-class icon artists. Apple Design Award-winning user interface designers. Terrific web designers. The crazy thing about most of my hyper-talented friends is that, for the most part, they were the ones who disagreed with the notion of designers needing to know how to code. They had well-written thoughts about the importance of specialization and how teams of individuals doing individual jobs worked well, and there's really nothing wrong with that.

My issue with this whole situation is that it seems that designers were against even learning, just a little bit, about how to be a programmer. It's like the mere notion of them stepping outside their comfort zone was an affront to their talents, when nothing could be further from the truth.

If someone is talented enough to do a great job within his or her skill set, then they're probably talented enough to learn a bit about someone else's job, too. Designers learning how to program. Programmers learning how to design. Product people learning how to actually design or build something instead of just writing about it. (I kid! Sorta.) Whoever you hand your work product over to, that other person's skill set is what you should learn about.

Do It All, Reap The Rewards

Almost everyone has read stories about businesspeople with ideas for products or mobile apps and "all they need are some programmers and designers" to make it real. Or perhaps about programmers who build amazing systems and prototypes but they lack the polish a designer can bring. Or how about designers who design immaculate interface mockups but need a developer to make them real. All these stories are cop-outs. They're tales of woe from people who lack the curiosity and drive to just Figure It Out™ and start learning a new skill.

Do you know who the most valuable software people are in the world? They're the ones who can think up great ideas, elaborate these ideas on paper, design the interface, then prototype and build the idea into a real thing. Idea to design to code to product. One person who can do it all. One person whose skills cut across job titles and areas of purview with an overwhelming drive to do the whole thing because that's just how they do things.

Who are these people? Who are these designer-programmer hybrids? Brandon Walkin, Kyle Van Essen, Shaun Inman, Michael Simmons, Andreas Illiger, Michael Villar, Ben De Cock, David Kaneda and Cathy Shive just to name a few. Also, me. We're out there and we're designing and building amazing stuff, mostly on our own.

I can't really speak for anyone else, but I'm guessing the common trait amongst us is that we're curious, almost to a fault. I'll read about programming languages, science, math, psychology, economics and space until the cows come home. I absolutely had to write software for the iPhone when it was announced so I had to teach myself C and Objective-C. Jesus, it was hard, but I did it. It took awhile, but now I consider myself a fairly competent Cocoa software engineer and I write & sell tutorials that try to teach others what I learned.

So do designers absolutely have to learn how to program to be a good designer? No, it's not a requirement. There are plenty of amazing designers out there who don't know CSS. But there are also plenty of designers out there who know CSS and advanced JavaScript. There are others who know CSS, JavaScript, Ruby on Rails and some SQL. And a few more who can setup and administer web servers. And a couple more who can write iPhone apps. And maybe a few more who know Java pretty well, too.

Can you be one of those people? Someone who is great at their main area of expertise, but also pretty good at other areas of expertise as well? Someone who can dream up software then design it, build it, and ship it? Yes. A thousand times yes. Like anything else, it takes determination, hard work, and lots of curiosity.

• Delight users with a beautiful look & feel
• Take a novel approach to an interesting problem or market niche
• Inspire user confidence through user experience consistency and ease-of-use
• Guide newcomers around so they can learn and then show others

Making users feel comfortable, welcomed and intrigued at the possibilities your app offers are some of the most important things you can focus on. Don't just dump them into a field and expect they'll find their way to water, guide them and teach them so they'll become experts at using your app (then tell their friends!).

Here's John Gruber's take on the importance of the first-run user experience.

Another aspect of the Mac OS X user interface that I think has been tremendously influenced by Steve Jobs is the setup and first-run experience. I think Jobs is keenly aware of the importance of first impressions... I think Jobs looks at the first-run experience and thinks, it may only be 1/1000th of a user's overall experience with the machine, but it's the most important 1/1000th, because it's the first 1/1000th, and it sets their expectations and initial impression.

The tough part about focusing on the first-run user experience is that, as a developer, you never see it. You start up your app, start adding data and using it, develop, test, develop, test, debug, use it some more, then launch it. Unless you're consciously thinking about it, you'll probably never see a bunch of blank screens. This is incredibly dangerous because all your users will see a blank screen in the first 10 seconds, and you may not have seen it in weeks, months, or ever.

Color

Color, a new photo-sharing app, just launched last night and while the major news outlets were gushing over the money they raised, the real story unfolding is that the app has a terrible first-run user experience and their app is getting decimated in the App Store with 1-star reviews.

The primary reason why users hate Color is because they completely botched the blank slate user experience. From Jason Fried:

Ignoring the blank slate stage is one of the biggest mistakes you can make. The blank slate is your app's first impression and you never get a second...well, you know. […]

Unfortunately, the customer decides if an application is worthy at this blank slate stage — the stage when there's the least amount of information, design, and content on which to judge the overall usefulness of the application. When you fail to design an adequate blank slate, people don't know what they are missing because everything is missing.

When you first start up Color it asks for your name, then it prompts you to take a photo of yourself. Once you've completed these two steps it essentially feels like there's nothing else to do. The screen shows the photo you just took and… nothing else. It's all whitespace. There's nothing to browse or explore, nothing to poke around or get interested in, no indicators that there are other things to do.

Now there are most certainly cool aspects of Color, but these are only apparent if the app is being used by a number of people all within the same vicinity of each other. Unless a dozen people all in the same room or event are using Color at the same time, there's really nothing to see. It's a photo-sharing app that only works if others near you are also using it. The problem is that since no one is currently using it, no one wants to continue using it. It's a classic chicken or the egg problem, and unfortunately for Color, the $41 million they raised didn't solve it.

What's really interesting is that Color could have actually gotten around this problem by launching at SXSW and making a big splash to get tons of people using it all in the same geographic area. This might have vaulted them past all the issues people are experiencing now as people download it around the world, but few people are using it in close proximity to one another. The idea that the executives at Color specifically chose not to launch at SXSW boggles my mind.

Solving The Color Problem

Color already blew their first impressions with hundreds of thousands of people, but there are some changes they could make right now to stop the bleeding.

1. Check geographic regions at increasing sizes until a decent number of photos are actually available to be seen, then show those in the app. The point of Color is to show photos from people nearby, but showing photos from people in other states is at least better than showing absolutely nothing.
2. Work hard on a well-designed interactive tutorial that is launched the first time someone starts the app. It should explain what Color is, why it's cool, why you want to use it, and get users started and interested to find out more.
3. Acknowledge that Color is more interesting when many people in the same vicinity are using it, encourage people to tell their friends about Color. They have $41 million, if they gave away a few dozen iPad 2s, t-shirts and stickers that'd probably jumpstart users' excitement.

Is it too little too late? Time will tell. Let's hope Color doesn't turn out to be the Cuil of 2011.

Different shapes and sizes. Flip phones and sliders. Candybars and decks of cards. Lots of hardware buttons. A hundred takes on the D-pad. A small screen (or two). This is what mobile phones looked like from the time I bought my first in the late 90s till early 2007.

But since the iPhone debuted, they all look like this:

They're all rectangular with a screen that fills up nearly the whole front face of the phone. Some still have physical keyboards, but that's a vestigial tail that will certainly fall off at some point in the future. All have only a few hardware buttons. All have nearly the same dimensional proportions. All have nearly the same thickness, give or take some tenths of an inch. All have nearly the same weight and feel in your hand.

Why is this?

Because the future of mobile hardware design is for it to fade away completely and have the focus be the OS and apps it runs.

Nokia's Windows Phone 7 Concept

Engadget recently posted a concept design showing a new Nokia phone that would run Windows Phone 7. Predictably, it looks like an iPhone and every other smartphone that's been manufactured in the past year or two: rectangular, a huge screen, small outside bezel, thin.

It looks good, or, I should say, the tiny amount of surface area not dedicated to the screen looks good. It will probably feel good in a person's hand, but what phones don't feel good in a person's hand nowadays? They all do, because they're all designed to look the same. They're all designed to look like the iPhone. A glowing rectangle surrounded by a thin strip of material that sends data to the rectangle.

The Future Of Mobile Hardware Design

I've looked into the future and have seen what mobile devices will soon look like. I know, it sounds impossible, but here it is.

All screen, no bezel, no chrome, just interface.

Look at the mobile hardware trends in the last few years: the screens are staying about the same size but the hardware around them is shrinking. Thinner phones, thinner bezels, more focus on the screen. At some point in the future all we'll have is the screen and the software that it's running because that's all that matters.

The iPhone started the trend of the focus being on the software. Your phone becomes the app that it's running. How many people focus intently on the bezel around the screen while they're using their phone? No one does. You stare at the screen. As technology advances and miniaturizes, everything will get faster and smaller. The hardware will fade away and software will be the only thing people care about.

And it's all because of the iPhone.

Near the end of last summer I had an idea of what I could do with these various unfinished projects: turn them into in-depth tutorials. So many friends of mine are designers who have never programmed before, or developers who never learned iPhone development, so the least I could do is re-package these forgotten projects (and new ones!) into something that might teach others what I've learned about iPhone UI design and development.

Design Then Code will be the site where these tutorials are published. If you go there now you can register to be notified when the first set of tutorials are available.

Design, Development or Both

Each tutorial has two parts: design and development. The design half discusses how to create a particular app's user interface in Photoshop with all steps explained along the way including lots of screenshots. It includes the PSD file as well. The development half discusses how to execute that design in code. This half includes the Xcode project.

I imagine that current iPhone UI designers would only want the development half, whereas iPhone developers would want the design half. And many others might want to read the entire thing. That's why I split them in two instead of making each one a monolithic guide.

I don't go through every screen and every feature of these fictitious apps. What I discuss is more like a fully functional interface prototype for a single screen. Each tutorial includes high-fidelity design instruction coupled with the UI code to make the interface real for a part of an app, usually the main screen. I think that coding custom iOS app interfaces by hand is an extremely important skill, and I want to teach people what I've learned about Cocoa user interface development.

Here's a preview of the first two tutorials. The first is a futuristic music production app for iPad, the second is a retro, western-themed design app for iPhone.

Building iOS Apps From Scratch

While working on these tutorials, I realized that if someone is starting with no knowledge of Objective-C or the Cocoa frameworks they might have some trouble getting up and running. To help teach people the fundamentals of iOS development I wrote an e-book called Building iOS Apps From Scratch and will be providing that for free so people can learn the basics of Objective-C and Cocoa. If you signup at Design Then Code you'll get instant access to an early (but complete) version of this guide. The final version will launch at the same time as the main site.

Look for the full site and the first set of tutorials soon!

Download TweetView.xcodeproj and then follow along below.

One of the challenges of creating a Twitter app for Mac is exactly how to build the timeline interface. Not the design, although that's very challenging as well, but the implementation of the timeline since it's very important to the overall stability of your app. Beak used a Webview because when I built it I didn't know much about AppKit or custom interface drawing. It's good for when you're just starting out, but if you really want to build great apps, you're going to eventually need to learn how to draw things natively.

Earlier this year I started work on a totally native implementation of Beak and the timeline code was perplexing. I played around with using an NSTableView (NSCells suck), an NSCollectionView (uses too much memory to have all tweet views in the timeline at once, also, inflexible), a custom NSScrollView (built like UIKit's UITableView with reusable views, this was the best solution), but in the end the most interesting part was drawing the individual tweets.

Drawing plain text with the same style throughout isn't that tricky. Drawing an NSAttributedString with some custom styles isn't that tricky either. The tricky part is that there are various interesting parts of a tweet's text (links, hashtags, usernames) and they all need custom styles and the ability for the user to click on them to initiate an action.

Step 1: Initial Paragraph Style

The content within our NSTextView is an NSAttributedString. What's an attributed string? It's actually a very simple concept: it's a string with some key-value pairs attached to parts of the string. These key-value pairs could be anything, but if you're adding styles, the key has to be one of a variety of pre-defined values that AppKit provides. For example, say a string has three words in it and you want each word to be a different color. You could set a color for the special key of NSForegroundColorAttributeName for each word and then you're golden, it'll be drawn with three different colors. There are a number of these stylistic attributes and a full list can be found here.

You can have more than one attribute defined for a particular word or range of characters. By default, we're going to set a number of styles for the entire range of the status string. These include a paragraph style (line height, spacing, text alignment), a text shadow to make the text appear inset on the gray background, a color, font size and more.

NSShadow *textShadow = [[NSShadow alloc] init];
[textShadow setShadowColor:[NSColor colorWithDeviceWhite:1 alpha:.8]];
[textShadow setShadowBlurRadius:0];
[textShadow setShadowOffset:NSMakeSize(0, -1)];
							 
NSMutableParagraphStyle *paragraphStyle =
  [[NSParagraphStyle defaultParagraphStyle] mutableCopy];
[paragraphStyle setMinimumLineHeight:22];
[paragraphStyle setMaximumLineHeight:22];
[paragraphStyle setParagraphSpacing:0];
[paragraphStyle setParagraphSpacingBefore:0];
[paragraphStyle setTighteningFactorForTruncation:4];
[paragraphStyle setAlignment:NSNaturalTextAlignment];
[paragraphStyle setLineBreakMode:NSLineBreakByWordWrapping];

// Our initial set of attributes that are applied to the full string length
NSDictionary *fullAttributes = [NSDictionary dictionaryWithObjectsAndKeys:
  [NSColor colorWithDeviceHue:.53 saturation:.13 brightness:.26 alpha:1],
  NSForegroundColorAttributeName,
  textShadow, NSShadowAttributeName,
  [NSCursor arrowCursor], NSCursorAttributeName,
  [NSNumber numberWithFloat:0.0], NSKernAttributeName,
  [NSNumber numberWithInt:0], NSLigatureAttributeName,
  paragraphStyle, NSParagraphStyleAttributeName,
  [NSFont systemFontOfSize:14.0], NSFontAttributeName, nil];

[attributedStatusString addAttributes:fullAttributes
  range:NSMakeRange(0, [statusString length])];

[textShadow release];
[paragraphStyle release];

Step 2: Finding The Interesting Parts

We're looking for links, usernames and hashtags, so the best and most customizable way to do this is to use regular expressions to parse through the string and pluck them out.

I used RegexKitLite and the libicucore framework to provide the backing for the regular expression code, and then wrote the following methods to return an NSArray holding strings that matched the expression.

- (NSArray *)scanStringForLinks:(NSString *)string {
    return [string componentsMatchedByRegex:@"\\b(([\\w-]+://?
      |www[.])[^\\s()<>]+(?:\\([\\w\\d]+\\)|([^[:punct:]\\s]|/)))"];
}

- (NSArray *)scanStringForUsernames:(NSString *)string {
    return [string componentsMatchedByRegex:@"@{1}([-A-Za-z0-9_]{2,})"];
}

- (NSArray *)scanStringForHashtags:(NSString *)string {
    return [string componentsMatchedByRegex:@"[\\s]{1,}#{1}([^\\s]{2,})"];
}

These regular expressions aren't as great as they would need to be to ship, but they do the job for the purposes of this tutorial. There are better regular expressions out there for matching URLs in strings, and if you find one, make sure to adhere to the strict escaping rules outlined in the RegexKitLite documentation.

Step 3: Do Something With The Matched Strings

We have arrays holding the interesting bits of our tweet status string, so what do we do now? I iterated across each array, found the character range where the string exists, then added custom attributes to the NSAttributedString at that exact position to style it differently.

for (NSString *linkMatchedString in linkMatches) {
    NSRange range = [statusString rangeOfString:linkMatchedString];
    if( range.location != NSNotFound ) {
        // Add custom attribute of LinkMatch to indicate where our URLs are found.
        // Could be blue or any other color.
        NSDictionary *linkAttr = [[NSDictionary alloc] initWithObjectsAndKeys:
          [NSCursor pointingHandCursor], NSCursorAttributeName,
          [NSColor blueColor], NSForegroundColorAttributeName,
          [NSFont boldSystemFontOfSize:14.0], NSFontAttributeName,
          linkMatchedString, @"LinkMatch", nil];
			
        [attributedStatusString addAttributes:linkAttr range:range];
        [linkAttr release];
    }
}

This is all pretty normal except for the final attribute I add for the custom key "LinkMatch". Here, I attach the actual matched string as the object attached to the "LinkMatch" key. Now, our attributes are not only storing style information for this link, they're also holding the URL itself. This will come in handy in a bit.

I also iterated across the username and hashtag matches and added the custom attributes "UsernameMatch" and "HashtagMatch" respectively.

Step 4: Display In An NSTextView

At this point our NSAttributedString is good to go. It has default styling across its full length, and it also has custom styling for individual parts defined by our regular expression. If we display it within an NSTextView it should look perfect, and, from the screenshot at the top of the entry, you can see that it does.

Displaying a tweet is all well and good, but what about user interaction? How do we trigger custom actions when a user clicks on the links, hashtags and usernames within the status text? Ah, that's where the custom key-value pairs described up above come in. What we want to do is know when the user clicks on anything inside the tweet text, and then identify the exact mouse coordinate of the click. Using this coordinate we can then make some calls to figure out what was under their mouse when they clicked and if it was a part of the text we want to take an action on.

First, we need to be notified when clicks happen within our text view. I found that the easiest way to do this is to subclass NSTextView and override the -mouseDown: selector to inject our own functionality. Here's the first part of that code.

@implementation TVTextView

- (void)mouseDown:(NSEvent *)theEvent {
    // Here's where we're going to do stuff
    [super mouseDown:theEvent];
}

@end

Notice that at the end of the selector we pass the event back up to super. This is so that the default NSTextView mouse-handling code can fire, like selecting text with a mouse cursor. If we didn't pass the event up to the super class then all built-in mouse click actions would be broken.

Now for the meat of our implementation. We have to identify the coordinates of the mouse event, then translate that into the part of the string that falls underneath the mouse cursor.

NSPoint point = [self convertPoint:[theEvent locationInWindow] fromView:nil];
NSInteger charIndex = [self characterIndexForInsertionAtPoint:point];

The characterIndexForInsertionAtPoint: call is the key to this entire tutorial. Starting in Leopard, NSTextView provides this neat functionality to retrieve the character position for a given coordinate, that is, if you provide a specific point it will tell you at how many characters into the string it occurred. Since we can retrieve the index of the mouse event, we can then make the following call to retrieve the attributes for that specific position:

NSDictionary *attributes = [[self attributedString] attributesAtIndex:charIndex effectiveRange:NULL];

Why access the attributes? Well, we tucked away some interesting metadata back in our original attributed string definition, so we can get that back and immediately know what username, hashtag or URL is sitting underneath the user's mouse cursor when they click and act on it accordingly. Presto!

if( [attributes objectForKey:@"LinkMatch"] != nil ) {
    // Could open this URL...
    NSLog( @"LinkMatch: %@", [attributes objectForKey:@"LinkMatch"] );
}
		
if( [attributes objectForKey:@"UsernameMatch"] != nil ) {
    // Could show a Twitter profile HUD overlay...
    NSLog( @"UsernameMatch: %@", [attributes objectForKey:@"UsernameMatch"] );
}
		
if( [attributes objectForKey:@"HashtagMatch"] != nil ) {
    // Could flip to the Search view and search for this hashtag...
    NSLog( @"HashtagMatch: %@", [attributes objectForKey:@"HashtagMatch"] );
}

And that's it! Custom-styled tweet text displayed in an NSTextView subclass that can identify when users click on different parts of the tweet and act accordingly.

Download the full Xcode project here and, as noted in the source code files, you can do whatever you want with the code.

As a developer, I want to keep my applications safe from piracy. Itʼs always a predicament to find a solution that will not bother your real customers. We are going to look into some common licensing schemes, but before we do, letʼs make sure we are all on the same page.

Definitions

Serial Sharing
Giving a serial number to a friend or a group of friends that use it beyond the purchased license count. This can be done by both sharing the serial number itself or by sharing the preferences property list file that is most commonly found in ~/Library/ Preferences/.

Cracking
Also known as patching: changing certain bytes in an application in order to make it think itʼs registered at all times. It also includes the app being changed in a way so that it accepts any registration information. Every application update has to be cracked individually, it does not carry over version to version.

Keygenning
Creating an application that generates serial numbers. This is done by inspecting what an application checks for in a serial and then producing serial numbers that will validate under that scheme. For example, a serial might be considered valid if it is 5 characters long and the first character is A and the third character is 1. Therefore, a pirate would create an application that creates serial numbers that follow that scheme, such as A21GD, AQ111, etc. Keygens are overall the worst thing that can happen to your application because you cannot differentiate between a serial number that is legal and one that is illegal, except using a purchased serial number database.

RSA
An acronym for Rivest, Shamir and Adleman, the original creators of RSA. It is a form of cryptography that uses a pair of private and public keys to encrypt and verify data. A message sent encrypted using the private key will only decrypt properly with the public key, which makes it possible to verify that the sender of the message is who you truly believe they are. Licensing schemes sometimes use RSA in order to confirm that licenses only came from the application developer, and not a pirate.

Now that that is out of the way, on to the schemes.

Offline Activation

This is the most basic of licensing schemes. It involves the user inputting a serial number with an optional name or email address, and verifying it locally on the userʼs computer. It is vulnerable to all forms of piracy because the verification schemes are available for the pirate to reverse engineer and there is no checking against a purchased serial database. Blacklisting can be implemented to stop rampant serial numbers, but because it vulnerable to keygenning, blacklisting can only go so far.

Though it is vulnerable, it does not bother real customers. It is a great solution if you are confident in your application and arenʼt concerned with piracy.

Online Activation

Online activation is the next step up from offline. It verifies the serial number over the internet in order to prevent people from sharing their licenses. If a license were activated 500 times on 500 different computers, obviously the license is being shared. Online activation makes it easy for a developer to blacklist serial numbers on the fly. Usually the verification is done by loading a URL such as https://myawesomeapp.com/verify? user=nickpaulson&serial=THIS-ISMY-LICE-NSE1 and reading the response. The responses can be many different things, but two are most common, with one being more secure than the other.

The first is by returning plaintext information about the result of the verification. It could return something like “status: success” or “status: blacklisted”.

There is a problem, however. Once the serial number is verified, it is most likely going to be placed in the applicationʼs property list so it can be verified locally on the next startup. It would be a burden on the user to have to verify their serial number with the server on each startup, especially if they are trying to run it without an internet connection. Therefore, this method is vulnerable to serial sharing, cracking, and keygenning. A keygen can be created that generates a serial number and then writes it to the applicationʼs preference file. This bypasses the internet verification completely. The userʼs preferences file can also be shared, and a crack can be made by changing (usually) just a few bytes.

The second response is something more complicated, but also more secure. Instead of returning a simple string, it can return an RSA-encrypted message containing the result of verification along with the serial number. If this cannot be decrypted, then someone else must have created the message artificially, and it therefore must be invalid.

Instead of writing the serial number to the preferences file to be verified on startup, the RSA-encrypted message would be. On the next startup, if the message in the property list fails to decrypt, someone was messing with the license. Because the RSA- encrypted message cannot be created by a third-party, this method is not vulnerable to keygenning. It is, however, vulnerable to serial sharing (via a shared preferences file) and cracking.

Third-Party Solutions

Many companies provide licensing schemes for a cost. Two examples of such companies are Kagi and Esellerate. There is also a free, open-source solution named Aquatic Prime. Letʼs take a quick look into how they work.

Kagi & Esellerate
These companies provide a framework or library to be included in your application. They supply you with a unique identifier that is used to verify licenses. It is a quick and simple drop-in solution for your application, and they also handle payment processing for you. However, there are some rather large drawbacks to using these companies. It is very obvious to a pirate that you are using Kagi or Esellerate, and it makes the stealing processing much easier for them. Once the generic algorithm for verification is reversed to create serial numbers, your application, along with all others that use Kagi or Esellerate, are instantly vulnerable. It is not difficult for a pirate to find the identifier in your application, and stealing your application becomes very simple. As a result, Kagi and Esellerate are vulnerable to cracking, serial sharing, and keygenning.

Aquatic Prime
Aquatic Prime is an open-source framework for the creation and verification of licenses. It provides an application that developers can use to generate licenses, along with a framework that can be dropped into an application for license verification. It is RSA-backed, which adds to license security. But donʼt be deceived, Aquatic Prime is quite vulnerable. First off, like Kagi and Esellerate, it has a generic scheme with a unique identifier. In this case, the unique identifier is the RSA public key. This generic scheme is very easily patched by pirates. Also, if the framework is linked instead of compiled inside the application, a pirate can just replace the AquaticPrime.framework in the application bundle with his own. He or she might force all licenses to verify as correct or even hardcode a different public key inside so they can generate their own licenses. Therefore, Aquatic Prime is vulnerable to serial sharing (sharing the license file), and cracking, and a keygen+crack combo.

DES3 Protection Caution: Advanced Topic

This is a form of application protection that, while not widely used, is interesting to take a look at. DES (which stands for data encryption standard) is a form of encryption/ decryption that uses a secret key. One way to use DES3 in an piracy protection scheme is to use it for application integrity. For example, you could create a plist file that contains some constants as keys along with class names or selector strings as their values:

NP_SEARCH_FIELD: NPSearchField
DO_FILE_UPLOAD: doFileUpload

Once the application has been compiled and is ready to ship, the property list can be encrypted using the SHA1 value of the application binary. This can be calculated using the following command in Terminal:

openssl sha1 /Applications/MyAwesomeApp.app/Contents/MacOS/MyAwesomeApp

Then the property list can be encrypted using the following command:

openssl des3 -k -in Secrets.plist -out Secrets.encrypted

Then, put that file in the application resources folder and make sure the unencrypted property list file is not inside.

On the application side, it should calculate the SHA1 value of the application binary using a third-party framework (such as SSCrypto.framework) and then create an NSTask object that does the following command:

openssl des3 -d -k -in Secrets.encrypted -out Secrets.decrypted

Read the property list into the application, get the needed constant, and return to the workflow. Make sure to delete the decrypted file when completed. If the property list fails to decrypt, the constant will not be returned and cause some application functionality to cripple. Basically, if even one byte is changed in the application binary (such as, for a crack), the application becomes crippled. This will help to hinder pirates from cracking your application, but it does not prevent it whatsoever. It will also slow down your application quite a bit depending how many constants you use, because the decryption must be done each time it is loaded. So this method will hurt your real customers.

You may be asking, “how can this be cracked?” Basically, the pirate decrypts the encrypted property list file and replaces the encrypted one with the newly decrypted one. After, he NOPs (no operation) the decryption process, so the application essentially just loads the “encrypted” file into memory, and then converts it to a property list without decryption. Because it is already decrypted, this works fine and the piracy protection has been broken.

Conclusion

There are a number of ways to protect your application from piracy. However, when it comes down to it, piracy cannot be stopped. Whether you like it or not, if someone wants to steal your application, they will. On this note, pirated copies should not be considered lost sales. Most pirates had no intention of purchasing your application in the first place. Donʼt hurt your real customers. If your application is good enough, people will buy it. The best way to prevent piracy?

Make great apps.

He spoke of a changing industry where "creatives" were no longer stuck in the wacky room at some large corporate entity but were now responsible for crafting products from beginning to end. Forget consulting work, now anyone could create a thing and sell it on their own. Illustrators learning sales forecasting. Designers learning media buying. Writers building widgets.

How does someone learn new things like this?

By being curious.

The CEO of a company I worked at in the 90s was talking to me about their new website I had built. We talked about some tagline and copy adjustments and out of the blue he fired up an FTP client and dove into the HTML. He had 20 years of experience in sales and didn't know RAM from ROM, but he told me he read some web design tutorials and "knew enough to be dangerous."

He learned something new, on his own, just because.

Learn New Things

You've heard this story before: a "product guy" has an idea but can't do anything with it unless he finds a designer and a coder to make it a reality. Or how about this one: a designer has the grandest ideas and mockups for iPhone apps but has never written one line of code. Or a coder that makes interfaces that look like a FrontPage template. Or user experience professionals who can only make wireframes, not real designs.

What's the common thread throughout all these examples? A lack of curiosity.

Just because your business card says you do X doesn't mean you can't dabble in A, B, C or Y in your spare time. Designers should learn how to code a bit. Hackers should learn the fundamentals of good design. Business guys should learn enough about technology that they don't sound uninformed. Technology folks should learn about finance and economics. Web designers should learn the basics of print design. Print designers should learn how to make a webpage. Marketers should have a deep knowledge of how their products work.

If you do something and then hand it off to someone else, learn about what the next person is actually doing. Talk to them, read books, subscribe to blogs, be curious. Learn in your spare time. Have a side project that makes you uncomfortable. Force yourself to figure things out. Get just enough knowledge to be dangerous.

How I Learned About Design

I've been designing professionally for many years but I have no classic design training. I drew some things as a kid but never considered myself an artist. I learned and experimented and played and worked for many years to develop good design taste and it wasn't an overnight thing.

Here's how I taught myself about design: I read every single design book in my college's bookstore. I'm not lying. There was a huge, comfy, leather chair in the bookstore and there were 4 gigantic shelves filled with design, art and typography books. Every day after class I'd stop in, pick up a few books where I had left off, and retire to the comfy chair to poke through them. I didn't read every word, but I did look at every page and tried to absorb what I was seeing. It took the entire fall semester but I finished the entire section.

And when I was done I started reading programming books. And science books. And math books. And business books. And anything else that looked interesting.

Because I was curious.