Back when I was doing design work for clients, it seemed like my work would get re-purposed by fledgling and not-so-fledgling designers every month. Sometimes I'd get a tip in my email about a theft that someone saw, or sometimes the offenders would link the assets right off my client's website, but regardless of how I found out about the theft, it'd piss me off more than anything else. I was the one who opened Photoshop, I cranked through iteration after iteration, I thought of execution details in the shower, I stayed up late at night, and then someone else just takes all that work and passes it off as their own. Sure, usually there were some slight modifications, but designers can always tell when someone else is using their design. It's sort of like a parent being able to identify their baby's cry while all the other babies are crying as well.
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.
At lunch earlier today I snapped a picture of the top of a Heinz ketchup bottle.
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 peopleallover 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.
This is based on speculation and my opinions on the future of Apple products. I know people at Apple but they don't give me any information.
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.
Before the iPhone came out, phones looked like this:
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.
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 TweetieoranyotherMacTwitterapp. 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.
Apple doesn't do business like other technology companies. They don't do any market research nor hold any focus groups. They spend money on advertising but far less than industry rivals and in spite of this their global brand recognition has increased year over year. When they first unveiled their aluminum, unibody MacBook Pro refresh, Steve Jobs and his industrial design right-hand man Jonathan Ive gushed over the new manufacturing process that made it all possible. They designed a brand new process because it was the only way they could execute this new design. I can't think of any other technology company that's ever done such a thing, let alone made it a focal point of a new product launch.
While other companies are fighting thin margins and are in a race to the bottom, Apple's margins are consistently high with iPhone margins nearing 60%. When you've sold over 50,000,000 iPhones with that kind of margin you're doing a lot of things right as a business.
Why Apple Wins
If someone is trying to understand why Apple products do well and they're putting them in a feature comparison matrix against competitors, they're already doing it wrong. When the iPod first launched it famously had "less space than a Nomad" but it ended up dominating the industry. The specs for Nokia's high-end smartphones blow the iPhone's away but their U.S. market sales are abysmal and almost non-existent. The iPad doesn't compare well against a netbook in a feature-to-feature lineup but it has over 2,000,000 sales in less than 2 months.
Apple's products sell because they focus on the overall user experience and how people actually use the device, from when they buy it in an Apple Store to the first time they open the lid on a MacBook Pro all the way through its lifetime. Apple treats each product as something special by itself; a treat for the person who bought it. Even the cheapest iPod nano has beautifully-executed packaging while other companies throw their most expensive products in a cheap, brown, cardboard box.
Apple products are easy to use. It's cliché to say this now, but people can pick up a brand new product like the iPad and figure out how to use it without getting frustrated. Apple's products work well. They don't get viruses and they don't get crapware automatically installed in the factory. Their products and user interfaces are beautiful and beautiful things just work better. When's the last time someone called a computer or phone beautiful that wasn't made by Apple?
The iPad was designed by people with taste, passion and opinions. It's an expression in minimalism and the missing features are a testament to Apple's philosophy just as much as the features they chose to include. No camera, no USB ports, no Flash, no multitasking (yet), no widescreen ratio, no keyboard. What it does do it does extremely well. Apple designers are curators. It's their job to say no, and they did, and many people bitched and moaned but they still sold an iPad every 3 seconds for the first 60 days.
Why Others Fail
When a computer company has over a dozen sub-brands that means no one is trimming the hedges, no one is editing, no one is caring enough to say no. Too many disparate decisions, too many hands in the pot. Too many committees, too much design-by-committee. Too many bland products without personality that don't get people excited.
Many companies are now planning to compete in the tablet space currently solely occupied by the iPad. They're planning to beat Apple by one-upping them, by adding features the iPad currently lacks, by being more "open" and more flexible. The problem is that no one is asking for this, no potential customers really care about "openness" or external USB ports on a tablet. People want things to work, work well, work quickly, and do the things they want it to do. Does the iPad do that? Yes. Is it fast, or more simply, fast enough? Yes. Does it have thousands of good apps available to download? Yes, and more are coming every day. Where are the gaps that a competitor hopes to fill? iPad customer satisfaction is at 91%. If a competitor wants to take down the iPad they have to beat 91%. Good luck with that.
Other companies fail because they don't know that details make or break a product. Most companies can get the big picture together — they can produce a thin & rectangular MP3 player, they can make a tablet-sized touchscreen device — but they fail on the details. The iPad has the best screen you can buy with millions of colors on a bright, sharp picture that's still pretty bright in daylight. Companies using OLED screens on a device you take outside have already screwed up an important detail. What's the main way you interact with a touchscreen device? By touch. I've used a Droid and a Nexus One and I can tell you neither of them have the screen reaction time of the first-generation iPhone let alone the 3GS. An iPhone has had perfect, fast touch recognition since Day 1. All Android devices I've used took a split-second longer than my iPhone to recognize when I touched the screen and I can tell you it's annoying, and it's definitely not how you beat the iPhone.
How To Beat Apple At Their Own Game
You can't, just like you can't beat Google at Search. You have to win at something else, something that your company is uniquely suited to do. This doesn't mean you shouldn't hire the most talented engineers and designers in the world, it just means you shouldn't go up against Apple on their own turf. The technology industry isn't a zero-sum game, there can be multiple winners. Win at something unique, don't worry about what Apple or anyone else is doing. Building great products that customers feel connected to is something every company should do.
Apple's differentiator has been quality for a long time; beautiful industrial design coupled with an elegant user experience. Independent developers building Mac OS X apps know how high Apple's standards are because to build a really great app for the Mac it should act and feel as if Apple made it. Some developers go above and beyond the HIG and produce beautiful, custom UIs that surpass what Apple might have built if they developed the same app. If you're working at this caliber then perhaps you're gunning for an Apple Design Award or have already won one.
When the iPhone App Store first launched, many of the first available apps were written by established, well-known Mac developers who were well aware of Apple's standards for quality. Few people had experience with Objective-C and Cocoa outside the Mac developer community so it was a given that Mac developers would be out in front, leading the way.
Now that the App Store is hugely profitable most iPhone apps are developed by newly-minted iPhone developers, not hardened Mac folks like when the App Store debuted. These developers are coming from dozens of other platforms to try and strike gold on the iPhone. This may be the first time they've heard of Cocoa or even used a Mac. If you haven't been using a Mac for awhile then you're bound to not really understand what makes an app "Mac-like." Here's a quote from John Gruber:
"Anyone involved in Mac software development is familiar with arguments over whether a particular app is "Mac-like". In the early days of the Mac -- the first decade or so -- the entire Mac community was largely in agreement about just what this meant. To be un-Mac-like was to be ignorant of the fundamental concepts and norms of the Mac OS. It was something you could spot in an instant -- software designed by engineers who just did not get it."
If you love the iPhone platform and want to build an app that feels "iPhone-like" then using Xcode and standard UIKit interface elements is a simple way to start. You'll subscribe to some iPhone development blogs, buy some Cocoa Touch books, and really dive into the new platform. If you really, deeply care about the user's experience then you'll probably hire an interface designer and tell him or her that you want your iPhone app to look as if Apple could've designed it. You'll sweat every detail including every icon, every widget, every pixel, every font. You'll cherish the first time you use your finished app.
If you're building an iPhone app because the iPhone is the hot platform and you're interested in cashing in then you might take a different path. You might be coming from another platform and another language and want to get started right away. You might not want to spend the effort and time to learn Objective-C, you'll probably want to utilize the skills you already have. Hell, you might not even own a Mac or even particularly like the iPhone. You'll probably search for ways to start building iPhone apps without using Objective-C and find some interesting "meta-platforms" that you can use. You care about the user's experience insofar as the user can access the features of your app without much trouble. You're not interested in fancy animations and other things you think are just window dressing, you just want your app to work. You'll cherish the first time you sell a copy of your app.
Using Xcode and Objective-C are not surefire ways to build decent iPhone apps, and using "meta-platforms" and other languages are not surefire ways to build crappy, non-Apple-like iPhone apps. Are they indicators about how much passion someone has for the iPhone platform and building quality iPhone user experiences? In my experience the answer is yes.
Steve Jobs wants Apple to be the arbiter of quality in the App Store, denying apps that are ugly, poorly-thought, lame, explicit or featureless. He can't say that in the Terms and Conditions so instead they're using carefully-worded language that excludes certain technologies associated with the kinds of apps he doesn't like. Steve Jobs doesn't want shit in his App Store. If you're a developer who may be interested in building shit, there's another platform right down the street.
Speaking from the point of view of someone who wants to build beautiful, high-quality apps for the iPhone and iPad: if you're too lazy to learn how to build iPhone-like iPhone apps using Apple-supplied tools then get the hell out of my App Store, too.
One of the largest remaining questions about the Apple slate device (aka, the iTablet, Mac touch, or my favorite, the iPod maxi) is its operating system. Why? Because the iPhone's main selling point is the App Store and last I checked, apps listed in the App Store only run on the iPhone OS. So does this guarantee the Apple tablet will run jumbo-sized iPhone applications on a larger screen? I'm not so sure. Here are some potential scenarios:
It Runs iPhone OS With Scaled-Up Apps
If Apple were rushing to get this product to market then this could be a possibility: iPhone apps scaled-up to fit the larger screen resolution of a tablet. Everything would look the same except everything is bigger — perhaps exactly 2x as large with a 640x960 resolution screen.
Advantages: If all UI elements are automatically scaled then nearly every currently available iPhone app would immediately be available on the new tablet.
Disadvantages: This seems like a half-assed solution. A tablet's screen resolution is much larger than the iPhone and merely scaling existing apps is a cop-out. It doesn't use the advantages of a tablet-sized device so why pay extra for a tablet-sized device? Also, the normal way to interact with an iPhone is to hold it in one hand in portrait orientation. The normal way to interact with a tablet-sized device is to hold it in two hands in landscape orientation. Most iPhone applications are made to be used in portrait orientation so if they're scaled to tablet-sized proportions and not rotated then you'll have to hold the Apple tablet like a Kindle and not like a normal tablet to use any of the apps. This isn't optimal for a variety of reasons.
It Runs Customized iPhone OS With Multiple Running Apps
If the resolution of the tablet's screen is 960x480 then you could potentially run multiple iPhone apps at once, side by side, on the screen all at the same exact pixel dimensions for which they were designed.
Advantages: Developers wouldn't have to rewrite their applications and users could finally run multiple applications at once.
Disadvantages: This still doesn't let individual apps take advantage of the larger screen resolution — they'd still be locked into 320x480. Also, this would only really work if the apps were all using portrait orientation so they could be tiled side by side when holding the tablet horizontally. If an application was built to be used in landscape mode then it'd throw off the other applications on the screen and would look cluttered and messy.
It Runs Customized iPhone OS For Usage On Larger Screen, No Third Party Apps To Start
This seems like the most Apple-like solution to me. When the iPhone first launched there was no iPhone SDK, there were only Apple-created apps. Developers were clamoring for an SDK and by the time it was introduced there was a feeding frenzy — it was a gold rush.
The apps included on this tablet device would be a small assortment of Apple-created apps like Mail, Safari, iTunes, etc. These would all have redesigned user interfaces that would use the entire resolution of the new screen. Imagine iTunes LP format on a beautiful, new, widescreen display or Mail with multiple-panels just like its Mail.app big brother on the Mac.
Advantages: Totally redesigned applications made for a larger screen open up a world of possibilities for user interaction and functionality. There's no doubt that the ones Apple redesigns (or, more accurately, re-develops) will be beautiful and will be a wonderful showcase and selling-point for the tablet.
Disadvantages: If Apple's trying to keep the tablet a secret then there will be no publicly-available SDK at launch and therefore no third-party, tablet-centric redesigns of App Store gems when the tablet first goes on sale. This is a big disadvantage but it could be downplayed in a few ways: 1) large App Store developers (EA comes to mind) would gain early access to the SDK and could rewrite some key iPhone apps to be included in the "Tablet-Only" section of the App Store at launch or 2) Steve Jobs announces the tablet and sets a launch date a few months in the future, just enough time for serious iPhone developers to get an early, tablet-centric version of their app completed for launch.
It Runs Mac OS X
An unlikely scenario is that the tablet simply runs Mac OS X at a smaller resolution than normal.
Advantages: Running full-blown Mac apps would be great in some ways, especially for the creative crowd. Developing for it wouldn't require any new SDKs and Snow Leopard already has multi-touch support built-in.
Disadvantages: No App Store, no access to the current 85,000 apps is a gigantic negative. Other problems include the fact that a finger is a lot larger than a cursor and Mac OS X interface elements are designed for cursors so expect a lot of misplaced touches.
It Runs Some OS X & iPhone OS Hybrid
This would be the best of both worlds but it'd be very tricky to get exactly right. Do you launch iPhone apps from the Finder? Do you launch OS X apps from Springboard? Do iPhone apps run in little simulator rectangles? Do you use AppKit or UIKit to code interfaces?
Advantages: The key advantage is that you'd still be able to access the full App Store catalog but also run full-blown Mac apps if needed.
Disadvantages: Jack of all trades, master of none. If the tablet isn't 100% focused on a singular type of application user experience then there will be problems. Tiny buttons on Mac OS X apps would be frustrating to hit but then when running iPhone apps UI elements are correctly-sized — the dichotomy would be very annoying. The overlapping APIs would also be really tricky for developers to figure out.
Other Tricky User Experience Issues
The form-factor of a tablet is fascinating because it surfaces so many user interaction dilemmas that haven't been totally solved yet.
For example, the simple act of entering text via an on-screen keyboard. When holding the device in portrait orientation then the on-screen keyboard could be essentially the same as the iPhone's in concept, but what about when you're holding the tablet horizontally with two hands? How does the keyboard work in that scenario? If you stretch the keyboard across the device's screen when in landscape orientation then your thumbs won't be able to hit the middle keys without stretching and reaching. This orientation works on the iPhone because the screen is only 480 pixels wide but what happens when the horizontal dimension of the screen is 800px or 1200px? This same layout just doesn't work.
One idea is to split the keyboard and have the left side anchored to the left side of the device and the right side anchored on the opposite end with a large, open gap in the middle. It might look funky but now your thumbs can easily reach the middle keys since they're physically closer to where your hands are located.
Another issue is how you watch movies. The natural angle of the screen is to be flat whereas a traditional laptop's screen is angled up which increases visibility. How do you watch movies on a 7-10" tablet screen that has no keyboard? I know how much of a pain it is to watch movies on an iPhone since I usually do that when I fly — most times I end up holding it front of my face with one hand for an hour or so. I imagine that the tablet will come with some sort of stand — either built into the back like a picture frame or external like a small wedge — because otherwise users will have a hell of a time getting it at the correct viewing angle for prolonged interaction.
Fascinating Time To Be An Apple Fan
The build-up to the launch of the original iPhone was unprecedented. Years of rumors, tidbits, second- and third-hand accounts all culminated with the famous Steve Jobs unveiling of three magic devices that were actually one iPhone. I remember where I was when I first saw the magic text stream across MacRumors' live feed and how I felt, it really was magical. I think I'll have the same feeling when the Apple tablet is unveiled because it's Apple and I can't see them launching something that's not incredible. It won't just be a device to surf the web in the bathroom, it will be a new way to consume media that will revolutionize many industries.
Update: Changed the blog entry title to reduce confusion.
The iPhone is one big constraint — no keyboard, small screen, few buttons — so designing applications for the iPhone is an exercise in building smart, simple software. Bloated apps on the iPhone? You won't find many. Most applications pick one feature or group of related features and centralize the product around that central theme.
When Apple began crafting UIKit, the set of APIs used to build the user interface for an iPhone app, they had to see into the future and predict what the most common application design models would be and make sure those could be accomplished easily. It may seem obvious to us now because we're so used to iPhone application design but the high-level navigation and interaction concepts available to iPhone application developers are really quite brilliant:
Dive deep into hierarchical levels of application information and then surface back to the top easily
Switch between different main pieces of functionality without losing your place on one when moving to another
Edit and adjust information without losing your place contextually
Display a list of information or choices
These three main interaction concepts correspond to three different types of View Controllers: Navigation Controllers, Tab Bar Controllers, Modal View Controllers and Table View Controllers respectfully. These are the building blocks for crafting iPhone applications.
Displaying Main Application Features
Displaying a list of available features of your iPhone application so the user can navigate through your app is a common practice. But given the variety of ways to display structured information in an iPhone app, which is the best way? What's the best way to present entry points to an app's main features? There is no best way but there are a variety of established patterns you can learn from.
Things, iStat & Birdfeed
Things, iStat and Birdfeed are three iPhone applications that have a variety (or variable number) of main views, too many to fit inside a Tab Bar Controller on the bottom of the screen. How do they deal with this? They use a Table View Controller as the application's main screen and list the main features there in a scrollable panel. Each table row would normally display a Navigation Controller once tapped.
Advantages: Main app features available in a simple, clean list design. Order & grouping connotes importance of features.
Disadvantages: No way to directly move from Feature 1 to Feature 2 if within Feature 1's Navigation Controller hierarchy, takes extra taps to get back to main screen.
Squirrel, Tags & Tweetie
Squirrel, Tags and Tweetie utilize a Tab Bar Controller as the main navigational pivot for the application. (Note: Squirrel & Tweetie have an initial view before their main Tab Bar Controller view. Squirrel has a vault passcode lock and Tweetie has a Table View of your saved accounts.) Typically when using a Tab Bar Controller each tab item would display a Navigation Controller and have a full feature hierarchy beneath it. When pushing & popping views within a specific tab, you can choose to hide the main Tab Bar to give your new view more room on the screen.
Advantages: One-tap access to switch between main application features. Switching back keeps your place within the Navigation Controller hierarchy (if used).
Disadvantages: Only works well when there are less than 5 main application views. If an app has more than that then the Tab Bar would typically show a More tab item as the 5th, and secondary application features would be tucked away below that tab.
ESPN ScoreCenter, Phases & Weather
ESPN ScoreCenter, Phases and the default Weather app are examples of a flattened navigational hierarchy where there's a single type of main view and a variable number of them showing. Applications using this design pattern are normally information-rich and designed to be utilities rather than applications you spend a lot of time in.
Advantages: Natural gesture interface for navigating between views, quickly display structured information.
Disadvantages: Getting from Card 1 to Card 4 takes a variety of swipes. No direct access between views more than 1 card away. Useful only for flattened (or nearly flattened) navigational hierarchy.
Follow The Leader Or Blaze Your Own Trail?
The application design patterns and examples shown above work with nearly-default navigational models that Apple has provided. They may customize the interface elements but the general interaction concepts are stock UIKit. There's nothing wrong with following standard Apple conventions for navigating around your app but what if you need to go beyond? What if you have a totally custom paradigm? The following are examples of applications that have defined their own interface paradigms.
Weightbot & Convertbot
Arguably two of the most tactile and beautiful applications available for the iPhone, both the applications from Tapbots have completely custom interfaces that center around a specific interaction point they designed from scratch. For Weightbot they use a horizontally-scrolling picker wheel and in Convertbot they have a mechanical, spinning dial for selecting units. There's a great behind the scenes entry at their blog about the making of the Convertbot dial.
Collage & Fortune
Tapulous has been making fantastic applications for the iPhone for awhile, and both Collage and Fortune are less well-known than their big brother Tap Tap Revenge. Fortune is a simple application that lets you crack open a fortune cookie and read the message but instead of going the simple route they designed a totally custom interface for what is essentially a fairly simple application. Simple concept + brilliant interface = winner.
Collage is a social picture-sharing app that redefines what a Tab Bar Controller paradigm can end up as. Their totally custom film strip interface and sliding, animating panels is some of the finest UI work you'll find in the App Store.
Beats
Beats by Bjango is a beat and key-matching app for DJs and musicians. There are a variety of custom elements but the main screen design emulates a Tab Bar Controller in the middle of the screen with the main content areas extending above and below this tab bar.
Postage
Postage by RogueSheep is an Apple Design Award Winner and has an iLife-feel to the entire application. Postage uses standard Apple UI conventions with a totally custom implementation that perfectly matches the app's postcard-creation workflow. An important part of Postage's interface is the custom horizontal slider letting a user choose a specific style or font from a group of choices.
Choose What Works Best
There's nothing wrong with using unmodified Apple UIKit elements and paradigms, in fact most of the applications in the App Store and those coming from Apple get along fine with the built-in interface paradigms and objects. Apple's built a solid framework to use when creating applications, but some app developers aren't fully satisfied so they take designs and interaction paradigms into their own hands. This was a showcase of some beautiful interface design decisions but be careful as it's easy to go overboard and screw things up.
A good rule of thumb is this: if you can't design something better than Apple, don't do it.
One of the most anticipated web-based applications of this past year was the debut of 280 Slides, a presentation application whose interface matches or rivals Apple Keynote. Beyond it having a beautiful (and desktop-like) interface was the architecture that powered the app. It wasn't written like other web applications, it was written using Cappuccino, an open source application framework that marries the elegance and sophistication of Cocoa programming using Objective-C with Javascript allowing Cocoa programmers to create web-based applications the same way they'd write normal desktop apps.
The 280 Slides interface isn't like normal web applications — it's designed to look like a desktop-class Mac application with typical Mac-like interface stylings, and more specifically, it was designed so that Keynote users would feel at home.
The extremely talented Miles Ponson designed the 280 Slides application icon as well as the entire user interface and was kind enough to answer a few questions I had regarding his work with the 280 North team.
Me: So Miles, how'd you get hooked up with the 280 North guys?
Miles: Well, almost a year ago, I got an email from John Hering about a UI project to design for developers who worked with the iPhone team. I didn't know a lot until I had a video conference with Francisco and Ross. and then I got really interested in designing the User Interface for 280Slides.
Me: For the application's interface, it sounds like it was important to make it look as "Mac-like" as possible, as if a Mac application suddenly landed in your browser. Have you worked on the UI for Mac software in the past? How did the process of designing a browser-based "desktop" application work compared to normal web-based design projects?
Miles: I started to design icons for desktop customization a few years ago, just for fun, and I really loved it. I enjoyed drawing my ideas and then share the shiny icon with everyone to enjoy. And then I started working more seriously for software developers, and open-source such as OpenOffice project.
I did not find any huge difference between a desktop and web-based app, simply because 280Slides is built on a powerful foundation, Cappuccino, that makes 280Slides amazingly behave and work the same way as a desktop class Mac application and therefore, makes the task of designing UI elements natural, as if it would be for a regular app. It worked the same for me. The toolbar icons are in 32 pixels, the buttons in 3 elements, etc... It's just great!
Me: When it came time to integrate it into the application, what was that like? Did you hand over PNGs or any HTML/CSS? How did you have to slice up the various UI widgets, if at all?
Miles: When the time has come to integrate everything, you have to slice the pizza, the buttons must be in 3 elements, left corner, right corner and 1 pixel wide middle, the HUD window was in 7 elements, the top-left, top-right, bottom-left, bottom-right corners, bottom-center and top center part, and body middle part. When it comes to slice all the elements, I got some sweat on the forehead and a load of tiny 1x30 windows open everywhere in Photoshop. The hardest is to keep track of all the elements, put them in assigned folders and make sure that you did not forgot a piece of the puzzle, hehe. I did not hand any kind of code over though. The 280 North team made an incredible job at coding everything.
Designing icons for Mac OS X is an intricate and painstaking process because the maximum resolution is so high, up to 512x512 pixels. At that size, Apple suggests that your icons be as photorealistic as possible, which calls for a lot of design talent. Icons for OS 9 and earlier versions of Mac OS X didn't need to be so incredible detailed as they were never shown at large sizes — letting a designer get away with some pixel imperfections here and there.
The current school of icon designers aren't typically at 1600% zoom in Photoshop placing each pixel precisely, but are using scalable vector illustrations and 3D renderings to produce the realism they desire. I've talked to many icon designers and although rendering icons in 3D is the ultimate way to get photorealism in an object (shading, lighting, perspective, etc.) many are still using Illustrator and Photoshop to work their magic. The last few versions of Photoshop have offered vector drawing tools similar to Illustrator, so now even Photoshop allows you to design nicely-scalable graphics which are very important when designing application dock icons.
I download applications all the time — normally to actually use the program — but sometimes just because I like to study the dock icon at full-size and see how certain lighting and shading scenarios were created. In case you're not aware, here's a quick way of viewing the full .icns file with the high resolution icons:
Download the application, find the main .app bundle.
Right-click on it, go to "Show Package Contents".
Navigate to Contents > Resources and find the .icns file for the app.
Open the file in Preview to see all sizes.
Shown above are some beautiful application icons I've seen recently. In numerical order is 1) Relationship designed by Icon Drawer, 2) Architect & 3) Bowtie, both designed by Laurent Baumann, and 4) CSSEdit.
I've spoken to Laurent and he's told me that he still works completely in Photoshop for all his icon work, even though his designs look beautifully photorealistic. The chess pieces in the Relationship icon look very real, so I'll guess that it was easier to accomplish that realism by using a 3D rendering app like Cinema 4D. The CSSEdit icon has some great hidden text on the bottom left if you're viewing it at full-size.
Seen any other great icon design work recently? Let me know!
I've been blogging since 2003, but this is my first "brand new" blog I've started in a few years. So why did I do it?
To learn, to teach, and to explore the realm of software interface design.
I've been working on my first Mac OS X application, and off the bat I learned that there weren't a lot of resources to show you the best practices of designing a Mac-like interface. Obviously there are the Apple Human Interface Guidelines, but when comparing the layout and positioning of similar UI elements in Apple-made applications like the Finder, Address Book, and iPhoto, I found that they were all slightly different. Sometimes, more than slightly different. Apple doesn't follow their own standards, so how was I to know what the best place for a particular button is?
When designing a Mac OS X application, I've found the goal isn't to follow the Apple HIG to the exact letter, but to make your app look "Mac-like". Here's a quote from John Gruber:
"Anyone involved in Mac software development is familiar with arguments over whether a particular app is "Mac-like". In the early days of the Mac -- the first decade or so -- the entire Mac community was largely in agreement about just what this meant. To be un-Mac-like was to be ignorant of the fundamental concepts and norms of the Mac OS. It was something you could spot in an instant -- software designed by engineers who just did not get it."
"In the last decade, however, accusations of "un-Mac-likeness" have largely degenerated into meaningless hand-waving. You still occasionally see UI mistakes that are genuinely un-Mac-like -- like, say, outright Windows-isms such as ordering dialog box buttons OK/Cancel rather than Cancel/OK -- but in most cases, when someone complains "that's not Mac-like", what they really mean is "I don't like that."
This blog will attempt to discuss what makes interfaces and icons "Mac-like" and how you achieve that look through articles and tutorials.
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 
The application design patterns and examples shown above work with nearly-default navigational models that Apple has provided. They may customize the interface elements but the general interaction concepts are stock UIKit. There's nothing wrong with following standard Apple conventions for navigating around your app but what if you need to go beyond? What if you have a totally custom paradigm? The following are examples of applications that have defined their own interface paradigms.
Collage is a social picture-sharing app that redefines what a Tab Bar Controller paradigm can end up as. Their totally custom film strip interface and sliding, animating panels is some of the finest UI work you'll find in the App Store.
