Previously I was hosting the downloads on my Web hosting account at NearlyFreeSpeech. I never ran into any downtime issues with my NearlyFreeSpeech account, but the negatives should be fairly obvious.

1. If your Web server does indeed go down, your downloads probably won’t be available on third-party sites like Apple Downloads or MacUpdate either.
2. Depending on the popularity of your application and binary size, bandwidth could become expensive.

As part of improving Second Gear’s Web experience, I decided to move my downloads offsite to a dedicated content delivery network (CDN). A CDN has the benefit of having servers all around the world and dynamically shifting customers to servers closest to them to offer an optimal, speedy download experience for all.

I looked at a variety of different CDN solutions, but the two best I found were Amazon CloudFront and SimpleCDN. For the basic needs of Second Gear, both CloudFront and SimpleCDN had negligible differences in terms of pricing and performance.

In the end, I chose SimpleCDN because I preferred their administration panel and reporting mechanisms. SimpleCDN breaks down downloads on a per-file basis, which lets me track how often Check Off and Today are being download each day, week or month. If you are already using Amazon S3, you may find CloudFront a better choice. I’ve been on SimpleCDN for a few months now and it’s barely broken a sweat, though my downloads are three times faster than before. Don’t believe me? Give it a shot.

• Download Today
• Download Check Off

It is impressive that in under a year Apple has built an ecosystem of software that is so popular that there has already been over a billion downloads. With thousands of application choices, it seems like every niche (no matter how miniscule) is being filled by someone.

Many people keep dozens of applications on their iPhones at a time whether they use them frequently or just every once in a while. At last count, I have about a dozen non-Apple pieces of software officially on the phone, with hundreds of other purchased or free versions downloaded and in storage via iTunes.

I buy applications for a variety of reasons. For one, I like to try out new software that I hope will fill a void that I have during my day. As an iPhone developer I also like to try out new software to see what trends and ideas fellow developers are following. It’s a great way to gain inspiration for your own projects and see what does and doesn’t work in other products.

Despite all these downloads, 90% of what I download doesn’t stay on my phone for more than a day or two. There’s usually a few niggling issues that I run into with the application that I can’t overcome or I can’t be bothered to look at its poorly laid out user interface. I’m well aware that I’ve earned my Mac Snob merit badge by refusing to use poorly designed software.

One of the more troubling trends I have noticed with the iPhone software is the predominance of feature bloat. Many applications that could be exemplary solutions for a problem are instead crammed with excess features that take away from the nut of the application.

Applications designed to get movie show times are now tacking in support for Netflix queue management and DVD release dates. What could have a home run experience for tracking my golf game is instead crammed with buttons to see my previous rounds, graphs of my distance, course maps and more. These supplementary features, while possibly adding another bullet point to justify your 99 cent price tag, are taking away from the overall experience the customer has with your application.

One of the primary reasons for the bloatware trend is that mobile software design is still in its infancy. Though platforms like Palm, Windows Mobile and Symbian have offered applications for your smartphone for many years, it wasn’t until iPhone that it actually became a primary focus for many developers. Most of these developers come from a desktop background where there’s more space to expand the waist of an application to fill every possible void that may exist. With mobile design, however, the focus should be on what the bare minimum you can leave in to give your application a purpose.

AppStore reviews are also partially to blame for the bloating of iPhone applications. We’ve all read the notoriously bad reviews that seemingly over entitled folks post when they feel they aren’t getting enough bank for their 99 cents. Far too many developers are quick to implement every feature request in hopes of turning every “FAIL! 1-star because it’s missing…” review into a 5 stars. Face it. It’s never going to happen.

Brent Simmons wrote an excellent piece about these types of folks a while back and it still resonates with me today. Trying to please 100% of the people who download your software doesn’t scale and leads to a product that may be rich in features, but is lacking in usability and ease of use.

When you sit down with your sketchpad to design your next million dollar iPhone project, think about what your application needs, but put extra focus on what your application doesn’t need. I am more likely to use your iPhone application if it does 1 thing and does it incredibly well without having dozens of auxiliary features getting in the way. Embrace the constraints of the 320x480 screen you’re filling. You may not have as many buttons and bulletpoints as the next guy, but you also won’t have the mobile equivalent of Office 2010.

Ever since the iPhone SDK was announced back in March of 2008, the predominant term I have seen to describe AppStore and iPhone software development in general is the term gold rush. The prospects of building the next Trism or Classics has led these new age prospectors (the 08 and 09ers if you will) to stake their claim in every known software niche on the store.

The gold rush mentality of AppStore has always left me with an uncomfortable feeling because while I do have a desire to make money off my software project, it is by no means my primary goal. My primary goal has always been to have fun doing what I’m doing and to pursue interesting projects. The fact that I get paid for doing what I love without having to rely on a traditional employer is a bonus.

As the iPhone Gold Rush of 2008 settled, I decided to start working on my first iPhone application. It was a project I’ve had in my head for a while and had actually started to do a bit of work with on Mac OS X. As I worked on the desktop version I began to realize that the first requests I would get from customers out of the gate was the desire for an iPhone version, so I decided to pursue that first.

Fast forward 93 days and a few thousand dollars later and I have a 1.0 ready to ship to Apple for approval. I login to iTunes Connect, enter all of the relevant application name description information as required on the first page of the Manage Your Applications screen and press Continue. After a bit of churning I am greeted with:

The Application Name that you provided has already been used. Please provide a unique Application Name.

At this point I should let you know that throughout the development process I have done countless searches of AppStore, MacUpdate as well as the US Patent Trademark Office to see if there were any matches for the name I had chosen: there weren’t. Even as of this writing there is nothing that references any piece of software on any platform with the name I had chosen.

I contacted Apple to plead my case and after a silent 2.5 day period, they get back to me with a more friendly way of stating tough shit. I can’t say I was surprised given what I’ve seen as an interested bystander on the whole AppStore process.

What I’ve learned from this ordeal is that iTunes Connect allows you to partially register your application name at any time during the development process. As long as you enter the name and fill in all the relevant fields with any sort of data, you can stake your claim on any given name. The key is the “Upload binary later” field.

This in essence allows for the AppStore equivalent of domain squatting and hijacking.

If you are an iPhone or Mac developer with products in the pipeline, it would be in your best interest to partially complete the iTunes Connect application registration process as soon as you think of a name for your application, or just to stake the claim on your Mac OS X application titles.

It is possible that there is something out there submitting an application of the same exact name as mine at the exact same time as me, but that seems like quite the coincidence.

In the end, the name I had chosen for my application wasn’t the most clever or innovative title ever created, but it is frustrating that after over 3 months of referring to the project by the name that it has to be changed because someone is squatting on the name in iTunes Connect.

Stake your claim.

I was incredibly interested in Bento for a tracking solution, because of those reasons. Bento is an application that I have wanted to use for quite a while, but never really found a use for it in my daily workflow. I opted against using it because it was somewhat limiting should I ever (god forbid) have to jump back into client development full-time. I need to be able to share my bug queues with clients, and that’s not exactly feasible with Bento.

Even though Bento didn’t work out for issue tracking, I have adopted it to manage my PR list. I’ve never really kept track of my correspondence with various members of the Mac media, because I couldn’t find a solution that worked well for me. I tried 37Signal’s Highrise initially, but passed on it because it seemed like too much tool for too much money when all I really need is a pumped up AddressBook.app.

My goal with PR tracking is to have a database of the people I correspond with, their contact info, a few notes about previous things we’ve worked on together and a listing of URLs emails.

For that, Bento fit the bill great. I created a fairly basic database that let’s me keep track of all this information. You can see the fruits of my labor below:

[](http://carpeaqua.com/wp-content/uploads/2009/02/bento1.jpg” alt=”bento1.jpg” class=”right)

What is great about Bento versus just setting up something on my own using PHP/MySQL, Core Data, FileMaker or a variety of other solutions, but Bento was the one that had the least amount of friction. Now whenever a member of the media emails me, I can search my database for their contact info and create a new record as necessary.

While the database is in its early stages, I am already seeing the benefits when I am contacting Web sites to ask them to review or write about Today. I added a boolean field so I can quickly see whether a user has reviewed Today. I now have a Smart Collection of media sites that have and have not posted a review on their site.

Bento isn’t the perfect solution for what I envision my no frills CRM to be, but it’s the closet I can get without opening up Xcode and creating the management tool of my dreams.

I recently added a field to the Second Gear store asking how people heard about Today and the overwhelming majority are coming over after reading the Macworld review. I never made it into the magazine (or any dead tree monthly for that matter) unfortunately, but there’s always 1.5 or 2.0 for that.

While I’m not an expert on this whole Indie game, I can certainly offer my thoughts and perspective after seeing through a 1.0 launch and trying to nurture a product through its infancy.

Sales numbers are like that first line of cocaine. My first months sales were through the roof and far exceeded what I had in mind. While I’m now seeing on average about 35% of what I was seeing those first few weeks, I can’t help but shake the desire to boost my sales back to those 1.0 launch numbers. It’s an addiction to try and find ways increase sales each month. Which leads me to…

Release early and release often. My goal with Today was to get out a point release each month that added new features. The main reason for this was because I shipped a foundation 1.0 that I wanted to expand on. The secondary reason is that I wanted to have the opportunity to have several opportunities to get the application promoted on the news and download sites. Needless to say, a 1.0 is much sexier than a 1.3, but there is always a tiny bump in the numbers.

You have enough problems without rolling everything on your own. If I could change one thing about my venture into the Mac software business, I would have not invested the time and effort into building the Second Gear store from scratch. I knew I didn’t want to use a service like eSellerate or Kagi since I had an established merchant account, but the Potion Store would have been a better fit out of the gate. I have a laundry list of features I need to add to my custom store to be feature-complete and up-to-par with Potion, and I don’t think I’ll ever actually get to them. I’m instead hoping to invest a weekend into converting my store’s database to Potion Store and adding support for ActiveMerchant to the codebase so other developers can use something besides Paypal or Google for payment processing.

Advertising is hard and an expensive lesson. I’m a mediocre software developer, but I’m an even worse businessman and marketer. Trying to promote my product is the one area that I’m looking to improve on going forward. There are millions of people out there that have never heard of Today and trying to find methods to reach them that don’t break the bank is difficult. Running ads in the magazines is certainly out of my budget at this time and the few ads I’ve run banner ads on have brought in a few sales to justify their expense.

With my advertising I tried to think outside the box a bit and decided to run a few spots on a popular Mac podcast. Bad idea. While the podcast certainly has a large listenership, it’s not the type that is going to have access to their computer and actually go to your site and purchase your product. Podcasts are also hard to track conversions and referrals on. Bad idea. No cookie for me.

Localization sucks. If you can’t localize properly, don’t do it. When I launched Today 1.0, I wanted to quickly get it localized into a few extra languages to hopefully spread its appeal internationally. The ever-helpful Daniel Jalkut shot me an IM suggested I hold back on that because localization sucks. I’m glad I heeded that advice. I am presently localizing Today in German and French thanks to two excellent users of Today, but I don’t think it’s the right way to do it.

While the application is localized, the Web site and support is still English. If I could do it over (and afford it), I’d gladly outsource my localization and international sales to a third-party who specializes in selling native software in their country.

Think of what you can sell your app for, and add $5. Prior to the release of Today, I was incredibly concerned with finding the sweet spot for pricing the application. I settled on $15 because I was just imagining the horror of the TUAW and Diggtards bitching about a $20 price tag. I haven’t had but a few freetards bitch about the price in my four months, so I can’t help but shake the feeling that I’ve left money on the table.

If you think your application is worth $25, charge $30. My 1.0 was a $15 application, but my 1.3 is definitely worth the $20. I’m considering raising the price of Today to $20 with the 1.5 release. I’m going to be seeking out advice on this one prior to launch.

Learn to say no to your customers. The customer is not always right when it comes to your software. You are going to get a ton of excellent feedback and ideas from passionate users, but you are also going to get some ideas that just don’t mesh with what you’re trying to create. I have had numerous requests to make Today show more than a single day in advance, which would completely defeat the purpose of the application and leave me searching for a new application name.

Rather than leading on a customer by saying you’ll consider a feature in the future, say no if you know you’ll never do it. If you are honest and give a valid argument against it, they’ll most likely respect your decision and appreciate the honesty.

Now that we’re nearing the end of the summer, I’ve put Today on the backburner a bit to focus on a second application for a few weeks. It’s hard to live off $15 licenses, so always have that next great idea in the back of your mind. Once you’ve got the idea, don’t forget to make time to actually build it. 1.0 is a bitch.

I actually was inspired by Buzz Andersen’s use of it as his primary method of support, but also had my own ideas behind it.

1. If there is ever a case where I’m out of town or just too overwhelmed to look at the support queue for a day or two, having a community of Today fans on Satisfaction makes it easy for them to answer someone’s question if need be.
2. Satisfaction has a great feature that let’s people rank their favorite ideas. If you see someone has posted about a feature you’re interested in already, you can just click a button to say you like the idea as well. It made it blatantly obvious that I need to implement calendar filtering in Today asap!
3. I think people are a lot nicer if they know others are going to be reading their message. I’ve only had one snarky post out of almost 100 thus far, and the crowd chastised him for it.

For single-person shops like mine, services like Satisfaction help ease the burden of wearing all the hats. Now if only they could find a way to eliminate support requests entirely.

Here’s a few other Mac developers that are taking advantage of the service

• Buzz Andersen (PodWorks, Cocoalicious)
• Todd Ditchendorf (Fluid)
• Gus Mueller (VoodooPad, Acorn)
• Fraser Speirs (FlickrExport)

I’m a big fan of foundation releases. In other words, release the bare minimum you possibly can to constitute a 1.0 and then let your users help decide the direction your application ships.

When I shipped 1.0 yesterday, I had 5 feature ideas written down. Now that thousands of people have downloaded and tried the application, I have increased that number 5x. More importantly, it’s great ideas that I never thought of myself.

Doing solo development can leave you in a bubble. Don’t worry if your application isn’t 100% perfect (Today certainly isn’t). Just ship what you can in 60-90 days and let actual, paying users help shape the direction of your product. A year from now, rather than having a 1.0, you’ll have a 2.0 that is so much better.

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.