Flyosity: Mac & iPhone Interface Design Blog by Mike Rundle

I'm a power user; a professional software designer and developer. I use computers (specifically, Macs running Mac OS X) to do my job and I'm guessing that most of you are in the same boat.

Most people are not power users, they mainly consume content using their computer rather than produce it. When they produce content it's more casual: posting to Twitter, updating Facebook, writing personal blog entries and notes, uploading photos. Their personal computer usage may include the following:

• Chatting with friends
• Sending and receiving email
• Listening to music
• Watching videos
• Playing games
• Browsing the web

The iPad excels at almost all of those things. Some of those tasks can be done at the same time on the iPad (or using the same application) but some cannot, so building multitasking into the iPad seems like the logical way to fully duplicate how most people use their personal computers at the moment.

Most people who attended the iPad unveiling and are now writing about the iPad are misunderstanding its intended audience because they're not in it. Some smart folks — who happen to also be power users — see the iPad's potential and are trying to convince everyone else. This will certainly take some time, just like there are still iPhone doubters even after Apple sold 40 million of them.

The market for potential iPad users is tremendous, possibly larger than the iPhone's market. There are millions of PC users who are dissatisfied with their virus-ridden, clunky computers who just want it to work better for the simple things they do every day. They might want a MacBook knowing that it's easier to use, but the thousand-dollar price point scares them off. But wait! For $500 less they can own a piece of Apple technology that lets them do almost everything they currently do in a form-factor that's more convenient, mobile and beautiful. This is the iPad's intended audience. People who have a PC and use 10% of its features and software 90% of the time. People like my Mom & Dad who browse the web, read news, send email and watch videos. People like my cousin Jenny who chats with friends, uses Facebook and uploads photos. Regular folks. Consumers. People who use computers to stay informed, connected and entertained.

There are also many people not in the iPad's intended audience who want one, myself included. We'd use it as a secondary computing device; a casual, home-browsing entertainment piece. The iPad is perfect for this.

The iPad is not made for you, it's made for everyone else.

Categories: iPad iPhone

The underlying secret to beautiful user interface design is realism: making 2D objects on your screen appear to sit in 3D space with volume, surface properties and undulations that might appear in real life. These faux 3D objects have highlights and shadows just like objects on your desk might have, and they have textures that emulate real objects from glass to sandpaper and everything in between. Designing beautiful user interfaces has more to do with the why than the how.

Thinking in 3D

If you're trying to design a realistic-looking user interface element then you have to think about what that object would look like in the real world. What's the easiest way to do that? Look at it from the side. What would a button look like if you viewed it from the side of your monitor? Let's take a look.

Here's a button-shaped panel that's designed to look slightly raised and have a matte surface. It's thin, has a subtle convex shape, and has a small edge that goes around the outside. In a 3D space, the light source would illuminate the edges (slightly brighter on the topmost edge) and would not fully illuminate the bottom slope of the panel past the apex. The object would cast a small shadow since it's not raised off the surface very much.

Pastebot, the new app from Tapbots, has a table view filled with panels that look similar to the one from above. Let's see what it'd look like with multiple panels next to each other.

This looks like a realistic series of panels because of the Top Edge Highlight up against the Inset Shadow which, from the side, would look like this: <. The Inset Shadow appears because the light source does not illuminate that area but then the next panel starts and pokes out, catching the light and showing a highlight.

Design elements that we think look great are usually the ones that look the most realistic, as if they could be in front of us on our desk or on the wall. Paying close attention to how light would strike the object as if it were real is crucial to executing a realistic user interface element.

Designing The Material & Surface

In my internet globe icon tutorial I stressed the impact an object's material has on its overall look. Not accustomed to thinking about an object's material? Get used to it! It adds a new dimension to your design and keeps the object's realism in the front of your mind. If you're designing an interface element and can't immediately name what type of material you're emulating then how can you execute it with perfect realism?

I recently linked to some beautiful Dock replacements for your Mac and many of these illustrate how important the material is to your overall design. In one named Phantom the designer uses two different materials to make the Dock: a textured, grainy surface coupled with a semi-transparent glass edge. The textured surface seems like the back of a notebook pad or a heavily-used wallet whereas the front edge looks like a clear, solid block of lucite.

Apple has been using shiny, gloss-laden user interface elements in Mac OS X for awhile but recently there has been some chatter that they were gearing up for a total interface refresh using matte elements. This full refresh never happened but matte interface elements have been steadily making their way into Mac OS X for a number of years.

With the latest version of iTunes, many user interface elements like scrollbar sliders and buttons have been given the updated, matte look.

Apple's also been using the matte look in some of their Pro software, most notably Final Cut Server. In that application's interface, Apple's removed the gloss from nearly everything and kept convex buttons close to flat with only a slight highlight on the edge. Also, the icons on buttons are not set into the button (accomplished via a thin, white drop shadow on the bottom, a style used throughout Mac OS X) but instead sit on top of the button through the use of a dark drop shadow on the icon. The entire interface pane is slightly raised and looks like dark, textured steel, making the application look like the instrument panel to a high-tech piece of equipment.

Here's an assortment of icons that all show how different surface materials contribute to the overall look of the element:

Next time you want to create something shiny, think about what type of material you're really executing: is it plastic? Glass? Reflective aluminum? If you're designing a matte element, think about just how grainy and textured it should be. Paper or sandpaper? Cardboard or anodized aluminum like an iMac? Is there transparency? Are you emulating something in real life or creating a material that's more hyperrealistic?

Tips For Execution

It's one thing to look at beautiful interface elements, icons and illustrations and quite another to build them yourself. Here are some ways that I build designs using Photoshop.

Noise Layer
Matte interfaces are hot right now and one of the key elements of a matte surface is that it's not perfectly symmetrical, it has some texture and grain to it. The easiest way to accomplish this is by creating a layer of one flat color and then using the Noise Filter to add some texture. The key is to keep it subtle and barely noticeable.

Radial Highlights
The main light source comes from the top but that doesn't mean you can't introduce a secondary light source for emphasis. Below I've created a custom navigation bar for an iPhone application that uses a subtle radial highlight for added dimension and detail. The Blend Mode has been set to Overlay to brighten and saturate the overall color and the transparency has been knocked way down to keep it realistic. Also note the edge highlights to make it look more like a raised surface.

Creative Layer Styles
Layer Styles are a key part of my design workflow, I use them for everything. Usually I'll draw a vector object, set the Fill to 0%, and design the entire thing using Layer Styles. Anyone can add a Drop Shadow to something, but if you get creative with Layer Styles then it enables you to really transform what you're working on. For example, you can only apply one Stroke but you can emulate 3-4 different stroke styles through creative use of the Inner Glow and Outer Glow styles if you crank up the Spread and Choke sliders and turn your glows into solid lines.

Once you turn glows and drop shadow styles into solid lines you can achieve a lot of effects with minimal effort. Below are some Layer Styles applied to rounded rectangles that use 1px glows and shadows. The PSD file for the following examples is released under a Creative Commons license: Button Examples

Reality Is Subtle

When something looks "off" in an interface, it probably looks fake, like it wouldn't exist in the real world. How do you keep your interface elements looking real? Here are some things to always keep in mind:

• Keep it crisp. No blurry lines or edges.
• Always adjust opacity. Nothing is totally black or white, dark or bright. A semi-transparent black or white line, glow, shadow or shape goes a long way.
• Go vector when you can, it can be resized later. Don't Free Transform vector objects: use the Direct Selection Tool to move individual points.
• Experiment with Layer Styles. White Inner Glow makes shapes pop. Use Overlay blending mode to liven up and saturate colors.
• Drop Shadows will ruin your design if you don't do it right. Things should be right up against their surface which means using a 1-3px Drop Shadow size. And 0-3px distance. This isn't WordArt.
• To save a complex shape as a PNG or GIF, turn the layer into a Smart Object first, then Rasterize it. This preserves color blending modes.
• When using type within an interface element, it either sits on top (dark 1px drop shadow) or is inset (white 1px drop shadow), it's never at the same surface as a button or widget.
• Real-world objects rarely have perfectly square corners. Use subtle rounded corners to make objects look real.
• In real life, everything casts a shadow. Unless you're drawing vampires, if you intend your object to have depth and be resting on a surface then it better have a drop shadow, even an incredibly subtle one.

Categories: Application Design Tutorial

Beak was an experiment, a way for me to do something new and be proud of it. It was my first application for the Mac and my first time using Cocoa. I never took C in college, I had to learn the Cocoa APIs, Objective-C, and C all at the same time. It was, and still is, a great adventure, and the adventure is just getting started.

A Complete Rewrite

When I originally wrote Beak, I wanted to do things with the interface that I didn't yet know how to code. I took a shortcut and made most of the user interface a WebView, allowing me to design the UI in HTML & CSS with Javascript as the "glue" between the UI and the Objective-C application code. This allowed me to rapidly produce an application I was proud of without getting in over my head.

Only one problem, WebViews are a memory-hogging, slow-scrolling cop-out.

I didn't want to release Beak 1.0 and have it still use a WebView so I went back to the drawing board. I rewrote the entire interface using native drawing methods and I rewrote the entire backend, too, to be more scalable and flexible. Not one line of code is shared between Beak 1.0 and the current version 0.95. It's all new.

Oh, and there's an iPhone version, too.

Beak for iPhone

I never planned on building an iPhone version of Beak. One day, while struggling to build a scalable, elegant timeline view for the new Mac version (more on this down below) I got so frustrated I started a new iPhone project in Xcode and threw my models and backend code in there. Then, I spent about 2 hours throwing together a nice, custom UITableView and poof, Beak for iPhone was born. So why make Beak for iPhone? Because it's easy! The Cocoa Touch APIs are so thoughtful, new and elegant that it makes building applications a joy. Using AppKit to build complicated interfaces is tedious and complex but the newer components in UIKit for iPhone are fantastic. It's like going from eating cauliflower (AppKit) to cheesecake (UIKit): I'll choke down the cauliflower because it's good for me but the cheesecake I'll eat and love it.

Building a Timeline View in AppKit

80% of the total amount of time I've spent building Beak 1.0 for Mac has been spent on the timeline view. Why? It's not because I couldn't make up my mind in Photoshop, it's because it's hard to code! There are no perfect-for-this-problem, pre-built, drop-in components that let you build beautiful, one-column listings of boxes that support multiple heights.

For the iPhone there's UITableView, a staple of iPhone development. Every row is a UIView object that can be customized to your heart's content. For Mac, you have NSTableView, an antiquated slug of a component that uses NSCell objects instead of NSViews for various historical and performance-related reasons. NSCells are difficult to customize and cannot contain NSView objects (without jumping through hoops and introducing unnecessary complexity) which are the lifeblood of an interactive, engaging interface. Clickable hyperlinks inside of a span of text inside an NSCell? Good luck! Hover effects and Core Animation slickness? Yeah right! NSCell is like a mirage: it looks nice from afar but once you get up close and personal with it you wish you never saw it to begin with.

I think every native Twitter application for the Mac currently does something different for their timeline. Loren Brichter essentially wrote a UITableView port in order to make Tweetie's timeline and Steven Degutis has recently been working on an NSCollectionView-based timeline for his Twitter app. The new Echofon beta timeline is something different entirely with a completely custom text and layout manager that allows for hover effects on links as if it were a WebView. As for Beak I won't be getting into specifics in this entry but I'll just say that it's a totally custom NSScrollView with some fancy caching in the background. And, yes, it took me a long-ass time to come to this version after many, MANY other implementations.

Motivations & Business Ruminations

After lots of thought and back and forth, I've come to the following conclusions regarding the price of Beak for Mac & iPhone:

• They will be free. Gratis. $0.00. (Not open source, however.)
• They will have some beautifully-integrated and unobtrusive ads.
• You can make a small donation to remove the ads.

The price coincides with a change in thinking about my motivations for building Beak and I wanted to get some of these thoughts down, digitally, before they escape my head.

First and foremost, I'm building Beak for me. I'm a designer and developer who has worked on the web for a very long time and I'm desperate to build something more tangible and real. Beak fills this need. Beak also lets me be creative and have fun without worrying if it will pay the bills since I have a fantastic full-time job that does that for me. I'm not building Beak to supplant my full-time income, I'm building it because it's interesting and lets me learn new things.

Second, Beak is not competing for your Twitter application-purchasing funds. I want you to go out, right now, and buy Tweetie, Twitterrific, Birdfeed, Reportage, Birdbrain and every other beautifully-designed Twitter-related application for Mac & iPhone. Go support quality developers, it's extremely important. When Beak 1.0 ships the new website will have links to my favorite Twitter apps at the bottom. Why? Because they deserve to be purchased and supported.

Third, Beak is a side project and will not have every feature you love. I have some strong opinions about which Twitter API features should be included in Beak and not all of them will be there, because, again, I'm building Beak for me. Lists & Retweets are in Beak 1.0 but they've got a twist. Things I don't like about Twitter or that I think are pointless probably won't be included, but that's just because I'm going to work on what I want to work on, and lame features just aren't fun to implement. I'd rather sweat the details on the things I choose to include instead of half-assed features that have been suggested that I hate.

When?

When it's done! The screenshots at the beginning of the entry are taken from real, working versions of Beak 1.0 for Mac & iPhone, so if that gives you some insight into the timeline then so be it :)

Sign Up To Learn More

People signed up for the email announcement list will be the first to hear breaking news so please head there and sign up if you haven't already done so. Also, there is no alpha/beta testing going on at this time but if I need some guinea pigs in the near future you'll be the first to know if you follow me on Twitter.

Categories: Application Design Mac OS X iPhone

Design by Chris Messina

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.

Categories: Apple Application Design Mac OS X Tablet iPhone

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.

Categories: Apple Application Design iPhone