I use each of the applications I am planning to highlight on a daily basis. If the developers of said applications should happen upon this blog post, I hope that look at it as constructive criticism of how to improve in future releases. Every developer has a different thought process when putting together their application, and I hope that a second opinion is welcomed.

The first application I want to highlight is the SiriusXM iPhone app. Anyone that knows me personally knows that I am a big fan and proponent of satellite radio and have been a happy XM subscriber for several years. When the company decided to release an iPhone app to allow streaming of most of the music and talk channels, I was quick to download it from the store and start using it.

As I’ve used the app over the past few weeks, I can’t help but feel frustrated by several of the weird UI inconsistencies that it suffers from. When you first launch the application, it loads a splash screen with the SiriusXM logo and a bit of status information on what the application is currently doing: checking credentials, loading content, etc.

I am not a fan of splash screens, but in this case I think it works because there’s no content to display in the application until it’s fetched from the servers out in satellite radio land. The only issues I take with the loading screen is the black status bar looks wrong and the upper-left corner being used to show a version number of the application. It looks incredibly out of place and reeks of something you’d see in a Windows product.

Once you are authenticated, the main view of the application loads. The app uses a tab bar with five items in it: Categories, Channels, Favorites, Shopping and Settings. This is where the app starts to fall apart for me in terms of usability.

The Categories tab lets you browse through each of the channels available to you by genre. The categories themselves are properly named and follow suit with what users see on their radios or the online streaming player. The group heading titles are in all caps though, which looks wrong and doesn’t match what Apple does in its own applications: first letter capitalized only.

Now things start to get really weird. When you click on the category you want to browse, it switches you to the Channels tab and shows you the channel listings for that specific category. Following typical iPhone application behavior, I was expecting to remain in the Categories tab and be pushed to a different table view that listed the categories.

The layout of the Channels tab is decent. It still suffers from the all caps section headers, but in terms of table layouts I have seen far worse. I do question why the designers of the app decided to create a custom disclosure detail button instead of using the system defined one. When you press the disclosure detail button it pushes you to a poorly laid out view that gives you the current playing information, a play button and the channel’s description. This is all stuff I’d argue should be attached to the now playing view (more on that later).

The Favorites tab is a listing of all your favorite channels. You can mark a channel as a favorite by clicking on the black & gray gradient area next to the play/pause button. The Shopping tab lets you add the currently playing song on any Sirius channel to your shopping cart so you can buy it from iTunes. This is an awesome feature and eliminates me having to write down what tracks I am discovering when listening to Alt-Nation or any of my other favorite music channels.

The Settings tab is the most puzzling of all. There are two settings and three other rows with help and legal information. Settings belong in the Settings app. The two settings that you can check are one-time settings that you will most likely never adjust again. The Help & FAQ information is unnecessary in an iPhone application as well. If your app requires you to have bundled support, you need to go back to the design room and make the application more intuitive for your users. Mobile applications shouldn’t require instruction manuals.

Now let’s focus on the main purpose of the application: playing music.

The music player is integrated into every other view on the screen. At the top, just below the SiriusXM logo is a view with the play controls, channel info and an arrow button. Tapping the play button is obvious. Tapping middle control flips to the Favorite/Shopping cart action screens. The arrow button is the most interesting part of the player controls. Tapping it slides the play controls to the bottom of the screen, hides the tab bar controller entirely and exposes a larger version of the channel’s logo. It’s a good looking view, but it’s really odd behavior for an iPhone application.

If enabled in settings, the volume control remains along the bottom of the screen, just above the tab view at all times. Unfortunately, the volume control overlaps the table views, so you can’t easily select the last items in each respective view. I would have preferred to see it attached to the rest of the playing controls along the top instead.

Let’s Fix The App

The SiriusXM app isn’t anywhere near the bottom in terms of quality applications on the iPhone. It shouldn’t require too much work to improve the usability and user experience of the application to make it more in tune with the highest quality iPhone apps.

I’ve sketched up how I’d improve the application. Apologies for the rudimentary nature of the sketches, but this is just a blog post. The goal is to give a birds eye view of how to improve the application’s design. Hire me if you want a fully designed UI.

The way I’ve redesigned the application breaks it into two views total: a third of what currently exists in the application. Most of this is by removing the tab bar along the bottom, but it’s also by adjusting how the applications functions in certain ways.

In place of the tab bar, the first view the user should see is a channel listing sectioned by the genre. The top section has the favorite channels as marked by the user. Most users have a few favorite channels, so having them front and center for the user to get at is better than having to load the application and tap over to a favorites tab.

The table cells of the channel listing remains mostly the same. I’d ditch the custom accessory indicator for the standard one included in UIKit, but that’s minor.

Once the user selects the channel they want to view, it pushes them to the now playing view. In many ways I am mimicking the iPod application, because users are attuned to how it functions. In the upper-right corner I put an info button item that will flip the channel logo area to show the channel description text. A user should also be able to double tap on the logo to perform the flip similar to iPod.app.

The channel, song and artist information is still along the top, but I removed the tapping action that was associated with it. Instead I opted to put a toolbar along the bottom of the view with two buttons. The heart icon that lets the user toggle whether a channel is a favorite. The shopping cart icon lets the user purchase the currently playing song via iTunes.

The current version of the SiriusXM app has the concept of a shopping cart so you can queue up several songs and purchase them at once. I waffled about how to include that in my remodeling. If I were designing it I’d ditch the cart totally and make each purchase instantaneous. Alternatively you could toggle the shopping cart icon to pop up an action sheet that lets the user choose to add a song to the cart, view the cart or buy all items in the cart at once.

I cleaned up the player controls by grouping them all along the bottom somewhat inspired by iPod.app as well. Since streaming radio doesn’t have the concept of fast forward and rewind, I grouped the play/pause button to the left of the volume control. It’s less use of space and puts related actions in the same user space.

If the user wants to go back to browsing other channels on the Sirius platform, they can press the arrow button to get back to the channel listings. The currently playing view will then be available by the new forward arrow button on the right side of the tab bar: another homage to iPod.

I think you’d agree with me that these layout and usability tweaks would offer users of the app a much more streamlined and iPhone intuitive user experience. I hope it also highlights an example of how with just a bit more work in the design room, you can find better, more suitable alternatives to using a tab bar control as the cornerstone of your iPhone application’s user interface.

Actually writing the code for the application isn’t the hard part most of the time, especially if you aren’t straying too far off of the default widget library. Where I found myself having the most issues was with how to properly design an application within the parameters of 320x480 pixels.

In terms of data-driven apps, there are three methods of designing your application: drill-down navigation with UINavigationController, using a tab bar and UITabBarController or a hybrid of the two.

If I had to pinpoint my biggest mistake in the development of FitnessTrack 1.0, it was the quick decision to use a UITabBarController as the foundation of the user interface instead single navigation stack.

When I made the decision, my thinking was that the application had four separate features, so it only made sense to separate them using the tab bar. What I found as I got further into the development of the application was that the bottom tab bar was incredibly limiting for where to place extra controls. With a tab bar, there are 2-3 spots along the UINavigationBar: leftBarButtonItem, rightBarButtonItem and titleView. If the pop navigation button takes up the left side and an edit button is on the right side, you’re pretty limited.

The other issue I was running into was how to properly save the state of the application. The application has four possible places to save application state, but is that the proper thing to do? If you look at Apple’s iPod app as an example, they only save the state of the recently selected tab and default everything else back to the root view controller. Joe Hewitt’s Facebook app saves the state of every tab, no matter what is visible. I opted to mimic the iPod application, but I can’t help but question whether it is the right solution. I think one could argue for or against both options. In the end, the issue would be moot if I had just not used the UITabBar.

Despite my frustrations with the control, I am seeing it pop up in more and more applications. The UITabBar is appealing to developers because it offers a quick way to jump between different sections of an application with fewer taps than a traditional navigation stack. In some cases, this works well. Tweetie, the popular Twitter client, is great because with three taps I can see my personal timeline, mentions and direct messages. Same with the Phone app. I can tap quickly to get to my Favorites, Voicemail or Recent/Missed calls.

In many other cases, the tab bar is a UI hindrance more than anything. AppStore, on the other hand, uses a tab bar where it’d be far better served using a single navigation stack. I believe Apple’s reasoning for using the tab bar on the AppStore (and iTunes.app) was wanting to put Featured applications front and center when the application first launches. I can understand that, but having separate tabs for Categories, Top 25 and Search feels wrong. Each of these three tabs perform the same basic operation: filtering data based on a specific criteria. Search is the process of filtering the store based on user-defined criteria. Categories and the Top 25 are also methods of filtering the store based on specific criteria as well.

Given use cases with AppStore, you can be viewing 4 different applications at once: one on different tabs. That’s extremely disjointed and potentially confusing. The application would be better suited by affixing the search bar at the top of a primary view and having a table that lists each section (Featured, What’s Hot, Top 25) and the subsequent app categories. This would allow the user to drill down in the store in a similar manner as the desktop version or search instantly without having to jump to a different tab.

The apps that inspire this sort of thinking are my most frequently used ones: Messages, Things, Birdfeed and Mail. Each one of them has an exceptional drill-down user experience that I think should be the gold standard for future iPhone apps. They are good looking, powerful and the user interface doesn’t get in the way.

Rather than taking the easy way and slapping a tab bar at the bottom of your UI, put the extra effort into the design process to see if it is possible to do the application using a single navigation stack. In most cases, I think the answer is yes. It may be a bit more work up front, but as your application matures (if it matures), you’ll find that the extra usable space along the bottom of your view will be much appreciated.

The problem with business cards is that they never fit just right in the badge, so I decided to make a custom insert this year.

If you want to make your own, just create a 3” x 2” image in Photoshop. I got the numebrs based off last year’s badge dimensions of 3.5” x 4.5” (thanks Casey Fleser for being a packrat). There’s a bit of wiggle room in the badge with the dimensions I used, but that also is in case Apple decides to shrink the badges even further this year. I’d rather not have to do a hackjob on site.

If you make your own badge, let me know!

In summary:

1. Hire a professional icon designer
2. Use illustrative imagery
3. Imitation is the sincerest form of flattery

Today I want to cover what your users do when they are in need of help. I was inspired to write this because I got some feedback about saying that a Mac application must use the Apple Help Viewer.

Help Viewer is the primary system for Mac applications to deliver assistance to users. Apple help files are built off of static HTML pages that are searchable, updatable (the data can be stored online) and able to support a wide range of digital media.

When I suggested that all Mac developers should have their help system interface with the Apple solution, Neil Lee gave me some grief about it. He says:

Even in Mac OS X 10.4 the Help Viewer applications is atrocious. The search barely works, you can’t print the entire documentation out (creating double the work for a developer that wants to provide printable docs), it’s not bookmark-enabled, and much, much more. I personally find it very awkward to use.

He says that search barely works in Help Viewer. That’s untrue. When you index your help files using the Apple Help Indexing Tool, the full text of your documentation is indexed as well as meta keywords, abstracts you embed in your files, anchors and the segments included.

One of the keys to making search suck less is to use a good set of keywords for each topic in your help documents. When I write documentation, I try to include every possible keyword I can think of that describes what the page I am writing is about. The more relevant keywords you have, the more likely your topic is going to pop up.

Obviously, there isn’t much a user can do about developer’s writing poor documentation besides complain. This is why I believe developers should outsource their documentation if at all possible (hey, hire me). Just like I said developers shouldn’t be designers as well, they shouldn’t be writers either. Outsourcing the documentation of your application has several advantages.

1. A fresh set of eyes: When you have someone new write the help for your application, you are letting a new user become adapted to your application, learn it’s workflow, and write according to it. Since you have seen it from it’s infancy to release, you may not be able to see the application from the eyes of a new user.
2. Professionalism: Hiring someone who has experience writing is a win-win situation for you and your users. You don’t have to worry about the wording and grammar of your help, and your users are getting an in-depth, understandable first line of support. If you have exhaustive, professional help files, it can help keep your support costs down in the long run.
3. Understandability: This may not apply in all cases, but I know that many developers are better at writing code rather than writing understandable help files. I am sure you have had the conversation where you try to explain a topic to a novice, and they don’t understand you: too much jargon is a common reason. Letting someone write from a user’s perspective rather than a programmer’s is advantageous.

Later on Neil says:

In 10.4 now that PDFs are so well supported (searchable, bookmarkable, etc.) I think all applications should switch over to PDF-based documentation. The two downsides to this that I can see is the lack of ability to include embedded content (like QT movies) and probably some increased file size. But besides that, it’s a superior option.

Wrong. Having every application use a PDF document means that there is little to no consistency in the design of the documentation. When you open the Help file for most applications that take advantage of Help Viewer they tend to have a uniform theme: a logo on the left side and main content sections in large letters on the right. From there, you can jump to specific sections of the documentation.

The biggest problem I have with using Preview and PDFs for documentation is search. When you search in Help Viewer, you are given a title and a relevancy score. With Preview, you are given a short snippet of text and a bold text of the words included in your search string. That is not useful at all in most instances. For example, in the PDF copy of my Oracle reference, when I want to find information about the DECODE() function, I get an output like this:

Now, compare that to putting in a keyword in Help Viewer, and the search results are far superior.

If Apple wanted to improve the search results in Preview to be more “Help Viewer”-ish I would be more open to the transition of PDF based documentation. Until then, developers need to embrace the standard help system Apple has put forth for their users.

• Excellent UI design
• Drag-and-drop
• Keyboard access
• Authentic Apple Help (ie. using Help Viewer)
• Other little things that are always overlooked (like setting a table cell editable on insertion)

I gave a few examples of these with Flying Meat Software’s VoodooPad. I highlighted their use of sample data for new users, the benefits of having a short application name in the menu bar and using a subtle registration nag rather than a timed window for your shareware products.

In today’s installment, I want to cover a more narrowed topic: toolbars. Many of the comments on the previous article discussed toolbar icons and what they thought constituted good icon design.

One of the things that sets Mac OS X apart from its Windows counterpart is its conservative use of toolbar icons. In a typical Windows application the user will be bombarded with stacked toolbars filled with small, non-descriptive icons. Rather than focusing on a few key functions that a user may commonly access, Windows applications tend to place all functions in a toolbar. And in the case that one toolbar has too many icons, have no fear: developers like to have several toolbars. I think Microsoft Word 2003 has almost ten toolbars that a user can enable!

In Mac OS X it is a completely different word. Instead of small icons, we have big icons. Below the icons, we also include a short description of what the icon’s function is for the novice user. Mac OS X developers understand that users are not going to need access to all of their application’s functionality in the toolbar. Instead, they choose to include their most commonly used functions in the in the toolbar.

Today let’s analyze one of my most frequently used applications: Panic’s Transmit. I spend a lot of time during the day transferring files from my Mac to a Web server, so I appreciate this application’s easy to use and intuitive interface.

When you first launch the application there are ten functions in the toolbar. Each one is something that many users will tend to use in their everyday work flow: a view menu to switch between list and column, an action menu with several “Finder-like” functions, create a new folder, refresh a folder, etc. The only one that I consider suspect is Synchronize, but I suspect that Panic includes it in the menu bar because it’s one of the big features touted in version 3.

One thing that I think almost all data-driven applications need to include in their toolbar is a search field. Transmit’s search let’s you search your local data or the server’s data depending on where your focus is. Apple has made it incredibly easy for developers to include search in their application thanks to the Search Kit API. If you are storing a lot of data in your application, let your users search it.

To achieve Mac Icon Zen and have a polished application, keep these guidelines in mind:

Hire a professional: You are a developer, not an artist. If you plan to release an application to the public, invest in a good set of icons for your application. There are several great designers out there doing amazing work. Find one, and work with him.

If in the off chance that you are a developer AND an artist, still get a professional icon designer. Spend your time perfecting your applications user experience and functionality. Let someone else worry with the artwork.

Use illustrative imagery: Your icons should help the user understand what their function is. In Transmit, the stop transfer button is a stop sign. The button to open the preview drawer is an image with a magnifying glass over it. You don’t want your user to look at your icon and wonder what it is or what it is used for.

Steal Apple’s Ideas: Don’t necessarily steal Apple’s icons, but steal their general idea. If you have an info panel in your application that is similar to the Finder’s Get Info window, you are probably going to want a blue button with an italicized i in the middle. The user understands the function of that button.

I think this might be one of the areas that Apple and I disagree in terms of their Human Interface Guidelines. They say:

Don’t reuse Mac OS X system icons in your interface; it can be confusing to users to see the same icon used to mean slightly different things in multiple locations.

If you are mimicking the functionality, use their icon. If you are creating a new page in a notebook application, use a pencil and paper for your icon. Even though Mail.app use the same thing to signify creating a new Mail message, I don’t think the user will get confused if they see a similar icon in your application.

Keep It Simple Stupid: When you are designing your icons, make them a one trick pony. Each icon should have a central focus in terms of functionality and design. In the pencil and paper icon I mentioned earlier, the dominant imagery in the icon is the piece of paper. The pencil is complementary. Don’t create an icon with a pencil, paper, pen and eraser to signify that you want to create a new page. Not only will your icon be overly complex, it will also look pretty lousy.

For an example of not so great icon usage, I am going to look at one application: Check Off. Yes, I know it’s my own application, but its icons suck. I admit that Check Off’s user experience isn’t the greatest, and that I need to eat my own dog food. Where can I improve?

Check Off’s toolbar has five functions: add new item, add new group, delete item or group, label and an action menu. The add item button is a plus, which isn’t such a bad thing. I don’t think it fits the design scheme of the other icons though. For creating a new group of items, I am using the icon of a folder. Not only is it not really descriptive of what its function is (when you add a group, it’s just a parent group in an NSOutlineView. Not a folder), but it also doesn’t have any sort of marking of what type of action it is. If it had a plus or something on it, it might be a little bit better, but not perfect. Because of this, it has to go. :-)

The delete icon is acceptable. It’s something a user recognizes and understands. Next to it, however, is a design faux pas. To signify that the user can create a label on their item or group, I am using the color wheel! When a user click it, he probably expects the Mac OS X color palette to open up and let him pick any color he choses. Instead, a menu is displayed listing the five choices he has available. Unacceptable.

Instead of the color wheel, I should create an icon similar to the one in the Finder’s preferences window that is in the shape of a label.

The final icon is a gear that displays a menu with several printing and exporting options. None of these options are available in the Finder’s action menu, so I am somewhat wary of using the gear. This is why developers need to hire professional icon designers to help with these issues.

One thing you will also notice is missing from the toolbar for Check Off is titles under the icons that describe the function of the button. Titles come along for the ride if you are using the NSToolbar class in Cocoa, but since Check Off is a menubar-based application, it doesn’t have such luxuries. Even so, each icon should have a short, descriptive title under it to help the user understand what the function is.

When choosing your verbage, you should almost always start with an action verb: Get, Delete, Create, Send, etc. The user is performing an action, so the first word they should see is is the action’s name. If we were redoing Check Off, it should include the following: Add Item, Add Group, Delete, Label, Action. Once again Action isn’t the greatest choice, but it’s hard to work with a menubar-based application. Returning to our “good example” Transmit’s default set of icons includes several action verbs: New Folder, Synchronize, Disconnect, Stop, Refresh and Preview. Most of this is common sense isn’t it?

Finally, developers need to put some thought into what can go into the toolbar. To avoid being like a Windows application, refrain from having an icon for every single function your application has. Also, don’t include every single function in your default toolbar. Choose five to ten functions (depending on the size of your application) that you think users are most likely to be referencing often. Tuck everything else away that they may want to have in the toolbar. If they want to access it, they can customize the toolbar. That’s why Apple made it that way.

Hopefully you learned something from all of this. In our next installment, I think I will make a case for Apple’s Help Viewer and why developer’s should embrace it.

• Excellent UI design
• Drag-and-drop
• Keyboard access
• Authentic Apple Help (ie. using Help Viewer)
• Other little things that are always overlooked (like setting a table cell editable on insertion)

I think that I have been sniffing too much of the polish, because I tend to frown upon applications that aren’t covered in it. Applications like Delicious Library NetNewsWire, VoodooPad and Transmit are four of the top applications according to my unofficial measurement of polished applications. Let’s just analyze VoodooPad and look at some of the nifty little features that I think make it a polished application. I pick VoodooPad because the other three get far more love in my eyes, so I want to spread it around. :-)

When you first launch the application it starts you out with some sample data to work with. The sample data is an explanation of what the application is and how to get started using it. Having sample data is more inviting than presenting them with a blank screen. The sample data includes a lot of the features that make the application unique: links to other pages in the wiki, embedded images and external links. The user can click around and see what the application is all about.

One other thing I like on the interface front is the small Buy Now link that Gus includes in the bottom right-hand corner. Rather than nag the user everytime the application starts (or every fifteen minutes like some applications), there is a constant, non-intrusive reminder at the bottom to support the shareware. Nice touch.

Looking at the menu structure of the application you will see the normal ones: the application name, file, edit, window, applescript and help. Along with that are format, page and plugin. Each menu is structured with relevant commands and the more frequently used ones are given keyboard shortcuts. One thing that bugged me about FrameVault is that every single function had a keyboard shortcut. If I mistyped a command, I was going to cause something else to happen.

One thing that all applications need to do is have a descriptive, but not too long application name window.

Good examples: VoodooPad, NetNewsWire, Safari, iCal.

Bad Examples: The Missing Sync For Windows Mobile, FmPro Migrator 1.91, Virex 7.6

The menu name should be short and descriptive. How could we correct the offenders?

• The Missing Sync
• FmPro Migrator
• Virex

They are short, don’t take up too much space and describe what the application is. I assuming Mark/Space has such a long descriptive name because they have three products called The Missing Sync (PocketPC, PalmOS, HipTop), but the icon for the application adds enough description for the person to know which device is syncing. As for FmPro Migrator and Virex, there is no need to put the version number on your application name. Save that for the about window.