I think I'll withdraw that point and move the bug-reporter one into its place.

Omni's usage statistics, which are going to be strongly biased in favor of early adopters and of the Intel Mac customers who get Omni products preloaded, show that the crossover point wasn't reached until late last summer. Even their PPC customer base is above 30%, and would be a black eye to ignore for years to come.

You shouldn't distribute untested software (at least without copious “It's beta!” warnings), so the solution there is to simply declare it Intel-only.

The civil solution is to spend a couple hundred bucks on a G4 from Craigslist. A big part of the reason that people like Macs is because they don't crumble into dust after two years. Software developers who make assumptions to the contrary deserve what they get.

Adobe notwithstanding, if you want to release an Intel-only app without a negative reaction before about 2010, your company name had better be Parallels.

More to the point, if all you have is an Intel Mac, and especially if all anyone you know has is an Intel Mac, then you're not going to be able to test your app on a PowerPC. You shouldn't distribute untested software (at least without copious “It's beta!” warnings), so the solution there is to simply declare it Intel-only.

(argh, what's wordpress's reply syntax?)

It's XHTML, but I want to change it to Markdown at some point. Last time I tried it, Text Control was broken with that.

That's definitely the correct way to do it, but a) the effort/reward ratio is likely very poor (and it may be impossible if your vector format is not rich enough to support things like Core Image or SVG filters), and b) my point was an example, not a specific problem to solve. If you want a harder example consider this image: http://www.infogirl.org/img/may05/forgetmenots.jpg

In general I would consider vector art to be appropriate for many application uses (it tends to match up with graphic designer's work like icons better than with painter's work), but I don't think bitmaps will be obsolete anytime soon.

Its benefits aren't as immediate as version-control: Version-control pays off the moment you want to bring back something you deleted, whereas a bug-tracker pays off months down the road, when you're trying to remember what that last feature you wanted for 1.0 was, or what that one guy reported with the bug that only happened when he clicked on one of the windows with his left hand. But it's the same kind of time-saver.

Also, maintain a blog about your product. It's a great way to keep your power users engaged.

Finally, everybody working in product development should read Kathy Sierra's "Creating Passionate Users" weblog. It's all about helping you help your users kick ass.

Vector art is great for some stuff, but for certain types of images it behaves basically as a really inefficient bitmap (consider, for example, a vector representation of static).

Hurrr?

If you mean no-signal-on-the-TV static, I'd recommend writing a Core Image filter that takes no input and sets the pixel to a random gray value. Then your “static” image will look properly staticky at any resolution. Remember, you want each pixel to be random, not each point.

Also I'm not sure what you mean by contextual menus. Use them? Here's how you do them if you want them?

Use them, and here's how. (It's a checklist, remember. Every list item is something to do.) Much like AS support, effective contextual-menu support is a great way to make your app more efficient for its power users.

I think I'll go add that to the list item, actually.

Also I'm not sure what you mean by contextual menus. Use them? Here's how you do them if you want them?

To add to 4: make sure you only ever read data structures that contains strings or locale-sensitive information from a plist, and not from inside the app itself. Not only does this make it easier for you (or users) to change something, it also makes them automatically localizable without needing to change the app. In my Monocle app, I'll be providing default search engines from localized plists, and so if I have translations for Japanese, French and Swedish users, they'll also get different base search engines. (Another lesson: Localization is *not* just about translation. It's about adopting to customs - date and time and currency format, text layouts and so on.)

I'll throw in extra tips that have more to do with the user/customer side of the story:

Have big ears: Listen to all feedback. Realize that people aren't trying to beat your app up when they're being negative, and that an app that's *just right* for a selection of people will make those people happier than an app that takes a swiss-army-knife approach solely in order to please the critics.

Say no: Make your users work hard to win you over. Don't implement every feature that's requested of you unless it fills a gap in your application without changing its intended goal. Think long and hard about adding features that'll extend your app's intended goal or even add a second goal.

Be swift: Do not pile up customer requests. Answer them right now. Even if you don't know the answer, let them know you're listening and that you'll be looking into it. Allow for a maximum of 5 to 15 minutes of research, depending on how much mail you get. If the fix is a quick fix on the current release, send a special build and ask "does this fix the problem? could this be done in a better way? is this what you had in mind?".

Follow up: This goes hand in hand with the previous tip. Follow up, follow up, follow up. Did that work for them? Have they seen the bug since the last email? Was it properly fixed in the build that claimed to fix it?

There are exceptions to these rules:

If you're a company with many, many demanding customers and a budget to uphold that are demanding a certain feature, without which they'll go to the competition, consider supporting the feature, but be wary of what it'll do to the perception of your app. Take Quark Xpress: it took long to get to Mac OS X and seemed bent on offering XML support (which InDesign had) instead of something that's more like InDesign. Now they're on their way out.

If you're doing consultation work, you should implement what's asked of you and try to straighten any wrong-headed constructions. There's room to get creative, but the room varies depending on the client. Often they'll have exact 'floor plans' of what you should build and a formal process to get through; in a big enough organization (or in a small organization with few enough friends) it's an easy step to toss the trouble-maker and get a new consultant. It's up to you to decide whether that's an organization you'll want to work for.