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.

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.

If you haven't already read his article please do so, then pop back here.

Designers Don't Just Make The Pretty

A user experience designer designs the user experience, obviously... but is it really that obvious? What's the user experiencing when we say "the user experience"? On the web, there are many things that contribute to the user's overall experience using the website or application:

• Look & feel of the application
• Ability of the user to accomplish the tasks they set out to accomplish
• The overall perceived speed of the website or web application
• Expectations being met. If a user thinks X will happen and it doesn't, there's a gulf of execution

These are just a small sampling. So what's part of a quality user experience? Everything is.

The user's experience with your website or application isn't just what the app looks like or what happens when a user clicks a button. It's not just the workflow they navigate through to execute a task. It's everything. Everything that the user does and experiences from the moment they load up your website or application to the moment they leave it is part of the overall user experience. A user experience designer's job is very important and requires having knowledge of many things in order to be effective.

What Should A User Experience Designer Know?

Designing the user's overall experience is not the same as designing the user interface, it's a lot more than that. In my mind, a user experience designer's job includes user interface design, includes designing the workflow to complete tasks and accomplish goals, includes being knowledgeable about usability testing, includes being knowledgeable about accessibility and users with special needs, and includes having knowledge about how the underlying application architecture works.

The best user experience designers are the ones that bring in knowledge from multiple disciplines (design, development, psychology) and put it all together so that the user benefits.

For example, in my Twitter conversation with Lukas, I gave the example of a UX designer needing to know how Ajax works in order to use it effectively. If you don't know how Ajax works or how web server requests work, how can you decide that in a particular situation Ajax would be best for the user's experience? Lukas replied with this tweet:

That's a perfect example of ignoring the code for a better user experience; page refresh would be easier and quicker to implement.

As I pointed out in my next tweet, what Lukas said is actually not true — in many circumstances an Ajax request is literally faster to execute than a full page refresh. Refreshing the full page makes more HTTP requests to the server (to pull CSS & Javascript files, images) however an Ajax request is only sending back a block of text in many circumstances, so it makes far fewer roundtrip requests to the web server. In most cases, an Ajax request to send data and get data back is faster than a full page refresh.

How do I know that? Because as someone who designs the user experience for web applications, I know how HTTP requests work and how Apache responds to a browser's request, I know about what happens at most places within the roundtrip to the server, and I know about what code is executing server-side when I make an Ajax request. I need to know about these things in order to make the call to use Ajax in a certain scenario over a page refresh. Most often when I decide to use Ajax it's because it will simply be faster and will make the application appear more responsive to the user. A big part of the overall user experience is how the user perceives the speed of the application, so I made a user-centered decision to use Ajax because I know it will enhance a user's experience.

If someone only knows how Ajax works from a superficial standpoint ("something happens without the page refreshing"), then when the choice is made to use Ajax instead of a page refresh, that decision is made without full knowledge of how Ajax works, what it's good for, what it's not good for, how it affects application performance, how it impacts application caching infrastructure, etc. It's a decision made without full knowledge of the consequences.

A Master Designer Knows His Tools

Architects don't just draw blueprints, they need to know what the ground is like under the building, what types of weather the region receives, and what building materials work best considering all the variables. They don't just draw, the craft the entire structure, and need a deep understanding of materials and processes in order to effectively do their job.

Chefs don't just put ingredients together and hope for a delicious dish, they have a deep knowledge of food and how things taste to people in certain situations.

Potters aren't just sculpting clay blocks into beautiful forms, but also firing the clay to keep it in its shape forever. They need to know about glazes and temperature and the science of firing in order to create their works of art.

User experience designers on the web need to know the environment and medium too, just like architects, chefs, and potters. A web designer is someone who designs for the web and knows the HTML & CSS needed to make their designs into real interfaces. If they don't know HTML & CSS, then they're not really designing for the web because they're not designing for the constraints of the medium. So what happens when someone who considers themselves a web designer doesn't have an in-depth knowledge of the medium? They make poor decisions. Decisions made without full knowledge of how their decision impacts the overall user experience. Here's a scenario:

Designer A hands HTML & CSS developer B a mockup of an interface. It's a complex interface and every single corner of every box in the design is rounded and has 3 different borders on it, plus a drop shadow. Every typeface in the mockup is a font the designer just bought, not any default web fonts that users will have.

In this scenario, because the designer isn't familiar with the constraints of the web, they are making design choices that negatively impact the quality of the user's overall experience. To execute rounded corners on a box — one that will expand with the content inside of it — you need additional HTML markup, CSS, and images to make it happen. Multiple borders and border styles? That's more markup and images. Drop shadows? That's a whole bunch of extra transparent PNGs. Custom fonts? You're either using a Flash image replacement method of dynamically-generated images for each one.

Tons of additional markup, images, Flash files, and Javascript just to execute an effect that doesn't make anything better or simpler for the user. Many more kilobytes of data needed to be loaded by the user before they can see the page as it was intended. Additional milliseconds or seconds of load time just because a designer with no knowledge of the web medium didn't design with the environment or constraints of the medium in mind.

Does this mean you can't execute a beautiful interface on the web? Of course not, look at how many beautiful websites and web applications are out there that also work beautifully, too. But a graphically heavy website or web application that is bulky and slow? That has visual effects that don't better the overall user experience? That's not so beautiful, and that's not how you design for the web.

You Don't Gotta Be An Expert

To understand how an Ajax request works you don't need to be able to write the Javascript needed for an Ajax request by hand off the top of your head, or wax technical on Apache process handling, but you do need to understand it fully enough so that you can make educated decisions about its usage. Architects don't choose one material over another just because one looks cooler, they make the decision based on many factors like structural rigidity, price, regional scarcity, etc. They know enough about the material to make an educated decision about whether to use it.

A user experience designer on the web needs to know enough about the environment and the web medium to make quality, user-centric decisions. If a UX designer wants to use a complicated interaction paradigm like drag-and-drop, then they should know the programatic constraints of its usage on the web. Drag-and-drop on the web isn't like drag-and-drop in a desktop app, so you have to know why it's different, how it's different, and how to correctly use drag-and-drop in order to effectively implement it. If you're obsessed with your application's speed then knowledge about how many kilobytes of Javascript it takes to implement DnD is important. You also have to be knowledgeable about how an impaired person uses the web and how to make a drag-and-drop experience still usable for them. You have to know how to handle a situation where a user has Javascript turned off.

Making what seems to simply be a "design decision" never is. It's a decision based on numerous factors encompassing design, development, architecture, usability, and accessibility. A user experience designer's job is to make decisions based on the entire scenario and environment in order to be as effective as possible. Benefiting a user's experience in one aspect, while negating that benefit in another, is the result of not being knowledgeable enough about what you're deciding.

...But It Helps To Be An Expert

Having sufficient knowledge to make a good, user-centric decision is great, but having a more in-depth, advanced knowledge is the best scenario. If you're a user experience designer and you want to use drag-and-drop in an interface, it helps if you can prototype the full interaction to get a feel for the timing and overall experience of the feature. There are some things you just can't know about until you're using a real, live interface, and it's extremely valuable to be able to build a prototype of a real interface to flush those things out early in the design process.

As Apple's operating systems have evolved, so too have their paradigms for user interaction. In Leopard and in many newer Apple applications, animations and advanced user interaction scenarios are used as part of the overall user experience. If a UX designer at Apple has no idea how CoreAnimation works at any level, and they can't use an application like Keynote or Flash to at least prototype an animation effect, then they can't truly express their vision for an interface. In fact, Visual Interface Designers at Apple are expected to know either Flash or Keynote in order to prototype their interfaces. Wait... an interface designer is expected to know how to code ActionScript in order to do their job? Yup, and if you don't, you can't be as effective as other interface designers on your team who do.

Take a look at the folks who are creating cutting-edge Mac and iPhone applications — they're designers with intimate knowledge of how their interfaces are implemented and developed. Designers who are learning Cocoa so they can prototype iPhone interfaces since the key component of good iPhone application design isn't just the visual design, but the interaction. These are the folks who are most successful on the iPhone — the ones who know both design and development and are intimately aware of the constraints of both. Look at the iPhone! It's tiny, low-powered, and doesn't have a keyboard. The entire device is one big constraint, so you have to know what these constraints are to be successful on the platform.

What's A User Experience Designer Mean To You?

There are so many titles for what people do on the web nowadays it's just ludicrous. You've got interface designers, interface engineers, visual interface designers, UI developers, information architects and user experience designers. Then you've got usability engineers, usability testers, web designers, and web developers. With so many titles, and so many people whose skills span a variety of these separate disciplines, where does one know where a UX designer stops and a UI developer begins?

All I can discuss is what's made me more successful in my career, and that's learning as much as possible about the medium in which I work. On the web that means I design workflows, interaction scenarios, interface design mockups, full HTML/CSS/Javascript prototypes, and occasionally implement these prototypes into the backend and hook it up to a database. I started out designing for the web and knowing HTML and Javascript, then I learned CSS, jQuery & Prototype libraries, then PHP, MySQL and some Ruby. I continued my education wherever possible because it's impossible to be too familiar with something when you're trying to make the most educated decision you possibly can. The more information you have access to, real-life experience you can fall back on, and in-depth knowledge you have the better your overall decisions are and the better and more user-friendly your websites and web applications are.

You can't be too knowledgeable when making an important, user-facing decision. The more knowledge you have the more likely it is that you'll see a decision from all possible sides.

I'm new to Objective-C, new to Cocoa, but have been a hardcore Mac aficionado since 1996 when I got my first Mac — a Performa 6200 — so I have "Apple-ness" running through my veins which is extremely helpful. Creating a beautiful and successful application for the Mac usually means that it looks as if the engineers at Apple could have created something similar, so the expectations are extremely high as far as interface polish is concerned. I'm learning just how much effort goes into a beautiful Cocoa app, and it sure is a lot.

As far as the development process is concerned, it's a big crap shoot. I worked on piecing together the user interface components early in the development process so I could get a better feel for how the app behaves, but making the interface actually function can't happen until X is written, which is dependent upon Y code, which I'm confused about until I do an hour or so of Googling, so it's a chicken and the egg problem. Fortunately, I've been working hard on a lot of the application glue code so that in the next few days I'll be hooking up the interface and giving things some real-world usage.

I've been coding for a long time, but have never really learned C, so initially writing Objective-C was difficult because not only did I have to learn ObjC's syntax, I also had to give myself a crash course on pointers, header files and memory management at the same time. After being absorbed in the Cocoa development world for a few months, I've realized that reading other people's code is the single greatest way for me to get acclimated to "how things are" when developing for the Mac. How to structure your classes, how to load NIBs, the best way to store user data, all these things I learned by pouring over open source Cocoa code I've found online or in Apple's example applications. Seeing how other people have conquered similar problems is probably the best shot in the arm out there.

Finding Other Developers

One thing that has made a huge impact in my ability to learn Cocoa is having a group of people I know can potentially help me if I get too confused along the way. Here's a short list of people who have helped tremendously:

• My buddy Ameir, developer of Guidance
• Matt Patenaude & Laurent Baumann, the developer-designer duo behind Bowtie
• Todd Ditchendorf, developer of Fluid
• Chris Hanson
• Brandon Walkin, UX Designer at Marketcircle
• Ben Barnett, developer of Base
• Andrew Wilkinson, designer of Logbook
• Jonatan Castro Fernández
• Ruben Bakker, developer of Mailplane

So how did I find all these people? Mainly through being a Mac application connoisseur — downloading everything that comes out — and then finding the brilliant people that created them. Twitter has been extremely helpful, in fact I follow every one of those people on Twitter so I can try to absorb their offhand tips and tricks. Emailing people is good too — you'd be surprised how helpful and friendly people are if you just send them a nice email. I've always made an effort to email people out of the blue and commend them on the work they've done, and my Mac development experience has been no different.

So What Am I Working On?

I don't really believe in nebulous descriptions of work-in-progress, written to pique curiosity. I'm working on my first Mac application, an application that I've had in my head (in some form or another) since 2005, and I'm building it mainly to fill my own needs, but I'm hoping that it fills the needs of others, too. Like most Mac applications, you'll be able to download and use it for free, but additional features/functionality will need to be paid for.

I'm working hard on it, and details will surely be coming soon, but for now I think I should shut my mouth and get back to work! Nothing is worse than vaporware.

Spheric Realism

Before getting into the tutorial's steps I thought it'd be good to go over some key techniques for creating a realistic sphere.

Designing a nice, shiny ball has many applications and is a nice skill to have in your back pocket. When designing a ball that's meant to look as round as possible here are some things to keep in mind:

• What material is it? Glass, plastic, anodized aluminum? The material of an object is its most important attribute as that defines how it is supposed to reflect and transmit light in the real world. Most textures on shiny spheres are semi-reflective glass or metal, rarely do you see a rough metal used as the material.
• It reflects light inside too. Not only do you have to worry about the global OS light but you have to keep in mind that light gets reflected inside the sphere as well, bouncing around the walls. Depending on the type of material of your sphere and the transmittance properties it will look different. Opaque material lets no light pass through so there will be no internal reflections.
• Is it totally round? Designing a perfectly spherical ball is not necessary all the time, sometimes all you want is a mostly-rounded button or disk. These have similar properties as spheres but the edges will have light reflections and shadows rather than the top or bottom of the ball. Spheres don't really have edges to catch the light since, um, they're spheres!

Lots to think about! Don't remember high school physics and how a material's refractive index changes light passing through it? Don't worry, just follow along and we'll have you building spheres in no time.

Step 1: Draw Your Base Circles

To make the globe look three-dimensional, it'll take more than one crack at Photoshop's Layer Styles which means a little onion-skinning will be necessary.

We're designing our icon at 256px so get your new document open and use the Ellipse Tool to make a circle sized so that it allows for a shadow underneath it. We're applying two layer styles — Gradient Overlay and Inner Shadow — in order to get the basic lighting in place. The Gradient Overlay is radial and I used the mouse to move it down to the bottom of the sphere representing the light passing through the top of the sphere, reflecting off the bottom. The Inner Shadow was also positioned at the top to give it some initial radial shading.

I need to apply some additional effects to the base circle so I duplicated my previous circle, turned the Fill to 0%, and re-opened my Layer Styles. I gave this second circle an Inner Glow with Multiply blending (half opacity) and an additional Inner Shadow positioned only at the top with Soft Light blending.

Step 2: Lay Your Shadows

Before we add the final lighting to our sphere, let's position its shadow first.

I drew a small ellipse at the bottom of the sphere and filled it black. Next I converted it to a Smart Object and applied a 73px horizontal Motion Blur and a 12.5px Gaussian Blur. To darken the center a bit more since that's where the sphere is "touching" the surface I duplicate my previous shadow and shrink it down a bit.

Step 3: Circular Highlights

Realistic lighting and highlights can't be fully reproduced using Layer Styles, you'll need to draw some more ovals.

Draw a circle about 3/4 the height of your previous ones and align it a few pixels from the top of the main circle. Make sure it has a 0% Fill and give it a Radial Gradient layer style from white to transparent with the white directly on top.

Now convert it to a Smart Object and give it a 3.9px Guassian Blur to soften it a bit. This represents the main OS light hitting the top of our sphere. (Note: Others may have a different preference regarding how blurred they want their top highlight. Some people won't want to blur it at all. Do whatever you think looks best.)

To make the center of our top highlight a little brighter, let's duplicate the layer and shrink it down proportionally. Now we have two ovals at the top of the sphere representing our top-down lighting.

For the bottom-up lighting, duplicate your larger highlight you created, flip it vertically, and move it down to the bottom of the sphere. Change the Blending to Soft Light. Here's what it looks like:

At this point we're done with our sphere but we still have the lines to draw, so let's get to it.

Step 4: Draw The Network Lines & Hubs

The network lines proved to be a little tricky to get just right. Here's how I did them:

1. Use the Ellipse Tool to draw a circle that is approximately the same size as your main sphere.
2. Free Transform your circle to flatten it out a bit.
3. Rotate it a bit on its center axis, make it look like a hula hoop wrapped around your globe.

I hopped into the Layer Styles and gave it a 2px white stroke with Blend Mode of Overlay. I also gave it 4px Inner & Outer Glows both white. Doesn't look like much yet, but here's what we've got at this stage:

I'm going to use this loop as both a foreground and background network line, so I duplicated the layer and hid the second one for now.

I used my Eraser Tool with a big brush that's fluffy on the edges so I can keep the edges of the loop anti-aliased as it hits the sides of our sphere. On your foreground loop, erase the left side completely, and erase just enough right at the top and bottom of your loop so that it fades into the sides of the sphere. ow for the background loop, erase the right side and use the same technique for the top and bottom edges.

To make the lines look as if they're sitting on top of the globe more, I duplicated each layer, gave it a slight Gaussian Blur, and then nudged it a few pixels away from its twin. I could've achieved this look with an Inner Glow, but hey, there's different ways of doing what you want in Photoshop.

I've now done this a few more times (foreground and background loops) and we're done with this step.

Final Step: Adding The Network Nodes

At this stage I think it looks pretty good, but we're not quite finished yet. Where our network lines cross we need some glowing network nodes. Fortunately, these are really easy. Take your Ellipse Tool, draw the node, fill it white, convert to Smart Object. Then, give it a little Gaussian Blur and change the blending and opacity appropriately. We're done!

Our final icon is on the left. On the right is a slightly tweaked example showing what you can do by changing some Blending Modes just for kicks.

Download The PSD

Reading about Layer Styles isn't that appealing, so if you want to check out exactly how the objects look, download the PSD all zipped up right here: you're free to do whatever you want with it.

Realmac makes some of the nicest Mac software around, and you have to look no further than RapidWeaver to see the effort they take in crafting their application's interfaces and icons.

I recently downloaded the app and pulled out some of the beautiful, high-resolution icons they use within the application. I love the network globe icon as it's subtly different than the standard Mac OS X version, as well as the Flickr icon they put together.

Update! I'm not sure how I missed this one, but the icons and UI work for LittleSnapper was done by my very talented friend Wolfgang Bartelme. He's also got a new iPhone game out called Dashball that looks fantastic.

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.

Me: Thanks Miles!

(See more of Miles' work at Californian Design or follow him on Twitter.)

• Unfinished, in flux
• Creativity, making something brand new

When should you use the blueprint look in your icon?

What you use to represent metaphors in your icon design is completely up to you, however it's clear that most icons that incorporate a blueprint are indicating that "this application is used to build stuff" whatever that "stuff" may be. For Apple's suite of developer tools it means building other applications or widgets. For your blueprint icon it could represent building anything you'd like, but something that a user can actually build within the application.

Here are a few full-size icons that use the architectural sketching metaphor, oh, and can't forget about MacThemes' website!

Me: Hey Laurent, great to be chatting with you! I've gotten to know your brilliant icon and UI design work over the past year but still don't know as much about you personally. Where are you currently living? How did your interest in design — especially icon design — get started?

Laurent: Thanks for the chat Mike, I'm really glad you like my work! I'm currently living in Cannes, in the south of France. I had interest in drawing and design since as far as I can remember. After 4 studious years at a design school in Aix-en-Provence, I started as a freelance designer in print and web design. To be honest, it didn't work out very well, and I often had some free time, so I started designing for myself. My interest in icon design really started when I switched from OS9 to OSX. I had the idea of making a full system replacement set based on the bezel design (I think you can still find them somewhere on InterfaceLift). And since I didn't know how to create an icon, I started to search for some good advices, and found MacThemes and its early small community. I met some of the best icon designers here, and I learnt a lot from them. After some time and releases, I figured out that icon design was just something I loved, was not that bad at, and was comfortable with.

Me: You've designed some fantastic application icons as well as quite a few free system replacement sets. What would be a typical process for you when starting out a new icon design project? What are the differences between designing an icon set (toolbar or system replacement) versus an application icon?

Laurent: When I'm designing a free system replacement set, I just obey my passion for design. I'm haunted by ideas until I can't help it, and start sketching the first drafts. It's also a good way to try new stuff, to challenge myself (with a totally black and white system replacement for example). It usually takes me months to finish an icon set. For an application icon, it's different of course. In my opinion, an application icon is at the crossroad of logo design and illustration. An application icon concept, just like a logo, has to be understood in 2 seconds at most, while still providing enough details to be eye-catching even after a long period of time. I guess I would say that I'm less available when I'm designing an application icon, but in fact it really depends on the client ;-)

Me: Bowtie is a huge hit with the Mac design and GUI customization community right now, especially over at MacThemes where it debuted. How did the idea for the project start? Who else is working on it with you?

Laurent: I started working with Matt Patenaude on his application TuneConnect, then did some work for a small utility called Colors. At some point, I felt the need to rethink the whole iTunes desktop controller concept, because I wasn't satisfied with desktop coverart/controller in every software I worked on (mainly CoverSutra and Cover Stream). So I came up with a mockup and asked Matt if he would like to help me concretize it. Each time we were talking, I was changing the mockup, without being able to nail the controller of my dreams. I guess he got tired of me, so to speak, when he offered me to implement a fully themable html+css+js controller, so I could play with it by myself, try to implement some ideas (and letting him work on Façade and Architect, *laughing*). And it turned out that I started making tons of themes for it, exploring paths none of the other iTunes controllers did. We then found a fun name for the app, along with a playful icon, trying to stay in line with with the simple concept we both love now, and keep it that way.

Me: You've worked with Pieter Omvlee to define DrawIt's updated interface, and then designed the icon for the application *with* the drawing program itself. I've been playing with DrawIt for a few weeks and find it a lot of fun to use. How did your design process change when using DrawIt instead of your usual arsenal?

Laurent: DrawIt uses a radically different approach than my usual "arsenal", which is Photoshop in fact. I think the beauty of DrawIt lies in the simplicity of the UI, along with the "coherent" workflow you can have (objects creation on left, object position on center, and objects effects on right). When I was working in Photoshop, I often had to duplicate my layers multiple times, to achieve multiple inner-shadows for example. And effects like radial-blurs were so annoying to handle that I avoided them. In DrawIt, the CoreImage engine make everything live and non-destructive, along with very "layers saving". Last, but not least, I'm a Cocoa applications lover, and DrawIt blends deeply with my system than my usual arsenal…

Me: There's a lot of buzz about the two Mac OS customization apps you're working on, Architect and Façade. GUI customization fans have been waiting for these two programs for awhile and are really excited that they'll usher in a new wave of Mac OS customization and theming. I downloaded the beta of Architect and it looks awesome -- how's work on Façade coming? Could you explain how Architect and Façade work, and how they'll be working together?

Laurent: Architect is the "free, developer" part of the couple. It allows you to easily create a theme by drag and dropping your custom-made elements in place of system ones. A validation system insure that the format and the size are valid. A live preview system, called LiveAqua, allows you to quickly check how your elements go together. When your theme is done, you can release it as a bundle, the Façade theme format. Façade is the other side of the couple, intended for people who will apply themes. See Façade as an iPhoto, specialized for themes. It perform all the necessary backups in order to make switching system resources very safe, along with some more features I can't talk about right now :)

Me: You've designed the interfaces for applications like DrawIt, Architect, and a bunch more. What is your process like for designing a program's interface, and when the project is complete, what are the deliverables you send over? If you use Interface Builder, how does that fit into your normal design process?

Laurent: Designing a user interface is really different than designing icons. There is no "artistic" part in this job. This is more about laying out a good interface, and to constantly see it as it was the first time you were discovering it, trying to always make it simple and welcoming for the first time the user will see it. I'm very curious about other software's user interface, and I'm trying a lot of them, to keep up-to-date with (numerous) innovations in this domain. I'm not using Interface Builder, because switching nib/xib in projects is not a easy task (and you would have to link every actions and outlet again from the "early working UI" the developer often start before I ship him the final UI). The biggest base of a mockup is usually a collage of Apple apps screenshots, in order to look and feel like a regular OSX UI, then I'm drawing the custom elements, like I would do for an icon. I'm delivering complete mockups of every views of the software, as pictures. If the gradients and such are not drawn in code, I also need to slice every needed tiles and caps.

Me: Thanks, Laurent!

Now that I've got that out of the way, let's take a crack at doing our own version of the brilliant Billings application icon (designed by the extremely talented Cian Walsh) in Photoshop.

Step 1: Draw the basic shape

The Billings icon is meant to look like some sort of futuristic stopwatch (and perhaps EVE from WALL•E!) so the shape is essentially a stretched out circle. To get this shape, I grabbed the Ellipse Tool and drew a circle that approximated the dimensions of the top half of the stopwatch.

The full shape isn't a circle, so we've got some work to do to make it look how we want. Grab the Direct Selection Tool. Click directly on the object's path and drag the bottom point of the circle down to where the bottom point of our stopwatch object will end up being. This will warp the circle, but not to worry, you can reshape it by grabbing directly on the curve and moving it to where you want it to be. Manipulating the path's curves will force the bezier points on either end of the curve to adjust themselves to fit your adjustment. Tweak the individual bezier curve handles in order to fine-tune your shape, but remember to leave the overall shape smooth with no jagged points. I've got my stopwatch shape colored #e1e2e1 as my base color for the object.

Step 2: Draw the shadow

I like to work on the shadow early in the design process as it gets my mind into 3D mode faster, letting me better visualize the lighting of the object.

I find it easier to create drop shadows on icons via separate layers rather than Layer Styles because when trying to emulate perspective, the shadow's size needs to look like it's behind the object and therefore visually smaller to your eye. Feel free to use normal Layer Styles to create the drop shadow if you'd like.

Duplicate the layer you were just working on and move the duplicate behind your actual stopwatch layer. Next, give it a black fill and resize it down a little bit — proportionally — using the top-right handle. Rasterize the layer and give it a Guassian Blur enough to start making it look like a nice shadow. I also gave my shadow a Motion Blur from left to right to spread it out a bit more. Here's what we've got so far

Step 3: Initial shading on the base object

The shape we're drawing has some complex lighting so it can't be taken care of with just one Layer Style, it'll take a few layers overlapped on top of each other to finish the shading. In this step, we'll be roughing out the initial shading with a Gradient Overlay and an Inner Shadow.

The Gradient Overlay has Blend Mode: Normal, Opacity: 100%, Gradient: #fff->transparent, Style: Radial, Angle: -65°, and Scale: 117%. For radial gradients, the angle changes the size of the radial gradient. To get the placement of the gradient exactly where I want, while I was working on the Gradient Overlay I just grabbed and moved the gradient right on the object itself while the dialog box was still open.

The Inner Shadow has Blend Mode: Overlay #000, Opacity: 100%, Angle: 164°, Distance: 26px, Choke: 9%, Size: 24px. Just like with the Gradient Overlay, to get the perfect placement I grabbed and moved the shadow myself. This was important because to duplicate the shading exactly, there should be no shadow on nearly the entire right side of the object.

There's a lot more work left to be done, but here's where we are so far:

Step 4: Onion-skinning your way to realism

Most of the time your object will need additional shading details that just can't be created with a single group of Layer Styles — you'll need to layer a bunch of effects on top of each other to make it look how you want. Here's what a typical process is like:

1. Duplicate your original layer, name it something recognizable.
2. Drop your Fill to 0% if it's not there already. You want your effects to layer up and not block-out the original layer.
3. Add new Layer Styles and adjust your Blend Mode to accomplish the look you want.
4. To build up additional effects, start back at 1, rinse and repeat

Why is this necessary? Because Photoshop doesn't allow you to have multiple versions of the same Layer Effect on a layer. That means if you want an inner stroke, and outer stroke, and a center-aligned stroke on the same layer, you're out of luck. Multiple inner shadows? Sorry, no can do. You can accomplish a build-up of the same effect via this onion-skinning technique, but keep in mind if you ever have to change your initial shape you'll have to tweak all your duplicated layers as well.

I've got 3 duplicate layers on top, each with 0% Fill and a series of Layer Effects applied. Here's the list of layers and their effects in the order they're shown in Photoshop:

• Inner Shadow: giving a bit more depth
• Stroke: a white stroke to give the bottom corner of the stopwatch a small bevel
• Gradient Overlay & Inner Glow: the gradient overlay is a transparent -> white linear gradient from left to right, and a thin white inner glow around the entire object.

Step 5: Drawing the face of the stopwatch

Compared to the body of the stopwatch and all its shading, the face is much easier technically. It's comprised of only a few layers:

• Dark blue dial — an ellipse that's been tweaked for perspective, it has Radial Gradient for the center highlight, an Inner Shadow for the top left dark area, a Stroke for the thick blue border, and a Drop Shadow of white at the top.
• Minute/hour markers — just a bunch of circles drawn with the object tool in a circular pattern around the dial. Each has an Outer Glow applied.
• The time wedge — this was drawn with the Pen Tool and has a Gradient Overlay and Inner Shadow.
• The sheen — I duplicated the blue dial, shrunk it a bit, applied a Gradient Overlay, then chopped the bottom part off with a circular cut.

Finished!

There are some small tweaks to be made like darkening up certain areas of the icon for enhanced contrast, and adding the stopwatch button at the top right, but I think this is a good place to leave off. Some quick tips:

• If you're designing an icon for multiple resolutions, it's a good idea to stay vector as long as possible for easy scaling. I usually keep my layers as editable vector shapes with Layer Effects applied, and only rasterize if absolutely necessary. Also, if I rasterize a vector shape, I like to keep an original vector version around (hidden) if I need it later.
• Use the "onion-skinning" technique to get a build-up of multiple effects that can't be done in one layer style. Multiple inner shadows, multiple strokes & gradients are crucial when designing icons for maximum realism.

And that's it for now!

Step 1: Design The Button

For maximum flexibility, I'm going to be using vector shapes and Layer Styles. To draw the button, grab the Rounded Rectangle Tool and use a 3px radius. Draw the shape similar to what I've got below.

Hint: When you resize vector shapes, it scales each part of the shape to the new size which means your rectangle's corners will get stretched out. To keep the correct border radius, use the Direct Selection Tool to select the 4 points on the side of the shape you want to move. This will keep the corner radius intact.

The coloring for these effects comes straight from the iPhone's slider via a screenshot. I typically use both Gradient Overlay and Inner Shadow together to render my lighting effects. The gradient is for the overall light hitting the button, and the inner shadow (in this case, a thin white line at the top) is the highlight right at the top of the bevel.

Step 2: Design The Track

Here, we'll be designing the blue "On" state of the toggle switch. The "Off" state has the same shape but is a light grey instead of a vibrant blue.

The track has the same height and border radius as the slider button, so the easiest way to create your track object is to duplicate the slider button you just made. Select your Move Tool and have your slider button object highlighted. Hold down the Option + Shift keys and drag your cloned object to the left of your original slider button. Now, resize your slider track so that it's about 1.5x the width of your slider button and make their right sides line up.

Now it's starting to look pretty close!

There should be a shadow on the left side of the slider button, indicating that the slider track is recessed and that the button is closer to the light source than the track. Let's add that in the next step.

Step 3: Finish The Switch

To show the drop shadow to the left of the slider button, we'll go back to our button layer and add a Drop Shadow that's facing directly to the left — Blend Mode: Normal #000000, Opacity: 38%, Angle: 0%, Distance: 3px, Spread: 23%, Size: 2px.

The relatively high shadow spread is so that it will fill out a few pixels to the left of the object, eliminating the "leak" we'd get if we simply boosted the size of the shadow. If we increased the size beyond 2px, it would show the drop shadow above and below the slider button which isn't what we're looking for.

To finish it off we've added the "On" text and gave it a thin drop shadow to indicate that it's inset on the slider's track.

And that's it! Now you've got an iPhone toggle switch that you can use on your own projects.

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:

1. Download the application, find the main .app bundle.
2. Right-click on it, go to "Show Package Contents".
3. Navigate to Contents > Resources and find the .icns file for the app.
4. 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!

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.

Here we go!