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

Original Concept

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

Building The Main Slider

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

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

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

Adding The Tappable Topics

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

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

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

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

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

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

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

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

Conclusion

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

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

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

Apple doesn't do business like other technology companies. They don't do any market research nor hold any focus groups. They spend money on advertising but far less than industry rivals and in spite of this their global brand recognition has increased year over year. When they first unveiled their aluminum, unibody MacBook Pro refresh, Steve Jobs and his industrial design right-hand man Jonathan Ive gushed over the new manufacturing process that made it all possible. They designed a brand new process because it was the only way they could execute this new design. I can't think of any other technology company that's ever done such a thing, let alone made it a focal point of a new product launch.

While other companies are fighting thin margins and are in a race to the bottom, Apple's margins are consistently high with iPhone margins nearing 60%. When you've sold over 50,000,000 iPhones with that kind of margin you're doing a lot of things right as a business.

Why Apple Wins

If someone is trying to understand why Apple products do well and they're putting them in a feature comparison matrix against competitors, they're already doing it wrong. When the iPod first launched it famously had "less space than a Nomad" but it ended up dominating the industry. The specs for Nokia's high-end smartphones blow the iPhone's away but their U.S. market sales are abysmal and almost non-existent. The iPad doesn't compare well against a netbook in a feature-to-feature lineup but it has over 2,000,000 sales in less than 2 months.

Apple's products sell because they focus on the overall user experience and how people actually use the device, from when they buy it in an Apple Store to the first time they open the lid on a MacBook Pro all the way through its lifetime. Apple treats each product as something special by itself; a treat for the person who bought it. Even the cheapest iPod nano has beautifully-executed packaging while other companies throw their most expensive products in a cheap, brown, cardboard box.

Apple products are easy to use. It's cliché to say this now, but people can pick up a brand new product like the iPad and figure out how to use it without getting frustrated. Apple's products work well. They don't get viruses and they don't get crapware automatically installed in the factory. Their products and user interfaces are beautiful and beautiful things just work better. When's the last time someone called a computer or phone beautiful that wasn't made by Apple?

The iPad was designed by people with taste, passion and opinions. It's an expression in minimalism and the missing features are a testament to Apple's philosophy just as much as the features they chose to include. No camera, no USB ports, no Flash, no multitasking (yet), no widescreen ratio, no keyboard. What it does do it does extremely well. Apple designers are curators. It's their job to say no, and they did, and many people bitched and moaned but they still sold an iPad every 3 seconds for the first 60 days.

Why Others Fail

When a computer company has over a dozen sub-brands that means no one is trimming the hedges, no one is editing, no one is caring enough to say no. Too many disparate decisions, too many hands in the pot. Too many committees, too much design-by-committee. Too many bland products without personality that don't get people excited.

Many companies are now planning to compete in the tablet space currently solely occupied by the iPad. They're planning to beat Apple by one-upping them, by adding features the iPad currently lacks, by being more "open" and more flexible. The problem is that no one is asking for this, no potential customers really care about "openness" or external USB ports on a tablet. People want things to work, work well, work quickly, and do the things they want it to do. Does the iPad do that? Yes. Is it fast, or more simply, fast enough? Yes. Does it have thousands of good apps available to download? Yes, and more are coming every day. Where are the gaps that a competitor hopes to fill? iPad customer satisfaction is at 91%. If a competitor wants to take down the iPad they have to beat 91%. Good luck with that.

Other companies fail because they don't know that details make or break a product. Most companies can get the big picture together — they can produce a thin & rectangular MP3 player, they can make a tablet-sized touchscreen device — but they fail on the details. The iPad has the best screen you can buy with millions of colors on a bright, sharp picture that's still pretty bright in daylight. Companies using OLED screens on a device you take outside have already screwed up an important detail. What's the main way you interact with a touchscreen device? By touch. I've used a Droid and a Nexus One and I can tell you neither of them have the screen reaction time of the first-generation iPhone let alone the 3GS. An iPhone has had perfect, fast touch recognition since Day 1. All Android devices I've used took a split-second longer than my iPhone to recognize when I touched the screen and I can tell you it's annoying, and it's definitely not how you beat the iPhone.

How To Beat Apple At Their Own Game

You can't, just like you can't beat Google at Search. You have to win at something else, something that your company is uniquely suited to do. This doesn't mean you shouldn't hire the most talented engineers and designers in the world, it just means you shouldn't go up against Apple on their own turf. The technology industry isn't a zero-sum game, there can be multiple winners. Win at something unique, don't worry about what Apple or anyone else is doing. Building great products that customers feel connected to is something every company should do.

Apple's differentiator has been quality for a long time; beautiful industrial design coupled with an elegant user experience. Independent developers building Mac OS X apps know how high Apple's standards are because to build a really great app for the Mac it should act and feel as if Apple made it. Some developers go above and beyond the HIG and produce beautiful, custom UIs that surpass what Apple might have built if they developed the same app. If you're working at this caliber then perhaps you're gunning for an Apple Design Award or have already won one.

When the iPhone App Store first launched, many of the first available apps were written by established, well-known Mac developers who were well aware of Apple's standards for quality. Few people had experience with Objective-C and Cocoa outside the Mac developer community so it was a given that Mac developers would be out in front, leading the way.

Now that the App Store is hugely profitable most iPhone apps are developed by newly-minted iPhone developers, not hardened Mac folks like when the App Store debuted. These developers are coming from dozens of other platforms to try and strike gold on the iPhone. This may be the first time they've heard of Cocoa or even used a Mac. If you haven't been using a Mac for awhile then you're bound to not really understand what makes an app "Mac-like." Here's a quote from John Gruber:

"Anyone involved in Mac software development is familiar with arguments over whether a particular app is "Mac-like". In the early days of the Mac -- the first decade or so -- the entire Mac community was largely in agreement about just what this meant. To be un-Mac-like was to be ignorant of the fundamental concepts and norms of the Mac OS. It was something you could spot in an instant -- software designed by engineers who just did not get it."

If you love the iPhone platform and want to build an app that feels "iPhone-like" then using Xcode and standard UIKit interface elements is a simple way to start. You'll subscribe to some iPhone development blogs, buy some Cocoa Touch books, and really dive into the new platform. If you really, deeply care about the user's experience then you'll probably hire an interface designer and tell him or her that you want your iPhone app to look as if Apple could've designed it. You'll sweat every detail including every icon, every widget, every pixel, every font. You'll cherish the first time you use your finished app.

If you're building an iPhone app because the iPhone is the hot platform and you're interested in cashing in then you might take a different path. You might be coming from another platform and another language and want to get started right away. You might not want to spend the effort and time to learn Objective-C, you'll probably want to utilize the skills you already have. Hell, you might not even own a Mac or even particularly like the iPhone. You'll probably search for ways to start building iPhone apps without using Objective-C and find some interesting "meta-platforms" that you can use. You care about the user's experience insofar as the user can access the features of your app without much trouble. You're not interested in fancy animations and other things you think are just window dressing, you just want your app to work. You'll cherish the first time you sell a copy of your app.

Using Xcode and Objective-C are not surefire ways to build decent iPhone apps, and using "meta-platforms" and other languages are not surefire ways to build crappy, non-Apple-like iPhone apps. Are they indicators about how much passion someone has for the iPhone platform and building quality iPhone user experiences? In my experience the answer is yes.

Steve Jobs wants Apple to be the arbiter of quality in the App Store, denying apps that are ugly, poorly-thought, lame, explicit or featureless. He can't say that in the Terms and Conditions so instead they're using carefully-worded language that excludes certain technologies associated with the kinds of apps he doesn't like. Steve Jobs doesn't want shit in his App Store. If you're a developer who may be interested in building shit, there's another platform right down the street.

Speaking from the point of view of someone who wants to build beautiful, high-quality apps for the iPhone and iPad: if you're too lazy to learn how to build iPhone-like iPhone apps using Apple-supplied tools then get the hell out of my App Store, too.

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.