Dan Wood: The Eponymous Weblog

Last week, Mike and I engrossed ourselves in WWDC. (Terrence was, and still is, on a vacation/family event and thus missed the whole thing. Alas!)

What a wonderful week! Of course we are under nondisclosure agreement, so I can't tell you anything else, so that's the end of this post.

OK, not really. A lot happened that wasn't under the veil of secrecy. (And what was protected isn't really a big deal - it's just the technical specifics of Snow Leopard that aren't yet public.)

The technical "curriculum" was great of course, but as many long-time attendees will readily agree, what was the most valuable was the interaction with fellow developers and engineers from Apple - in labs, in the hallway, over Twitter, over meals, and at the many parties. Compared to previous years, I feel like there were more people I wanted to chat with in person, after having connected in some way over Twitter in the last year. 140 characters is nice, but a handshake and conversation is much more memorable.

On the party scene, I especially enjoyed the sfMacIndie party on Sunday evening, put on by Chuck Soper (Whoops, I had to correct an accidentally typed "Super" there -- a very apt Freudian slip, since Chuck did a super job in almost singlehandedly organizing the event). The WebKit party was a blast as well, especially since the WebKit team members are so fun.

I talked to a lot of fellow developers about the marketing blog posts I had written just before the conference. It was nice to hear that it was appreciated. It was a bit disheartening how many indie developers are currently doing very little actively to "catch fish" (to borrow a metaphor that Daniel Jalkut used in a recent podcast). Hopefully some people will pick out a few of these suggestions and pick up some extra compensation for their hard work as programmers. (If you do, please let me know!)

Somewhat related to marketing, I was pleased to find that many developers -- including us -- are planning on going Snow Leopard in a big way. Ken Case of OmniGroup and AJ of MarketCircle mentioned they were going to start working on Snow-Leopard-only apps and updates, and we are going to be doing that as well. (Right now, Sandvox and iMedia Browser work on 10.4 and up; our next major versions will require 10.6.) With the upgrade cost from Leopard to Snow Leopard so inexpensive, it seems a no-brainer to target that version. There are so many advantages as a developer to use the modern Snow Leopard libaries. We've started digging in already and are looking forward to a day when we are no longer working on legacy systems like Tiger.

Oh, I heard that there were a bunch of iPhone developers at the conference as well as us Mac developers. :-)

All in all, a great event. Kudos to the engineers at Apple who put on such a worthwhile week!

In my previous posts, I mentioned Google's Website Optimizer. I got quite a few reactions to that, so I thought I'd follow up a bit.

First of all, I should say that I had heard of it for a while, but it wasn't until I read Always Be Testing did I realize how important and useful of a tool it is. If you are thinking about this, I recommend the book highly.

The goal that I am testing is this: do people download the program after visiting the main Sandvox page? The reason this is the goal is because it's the most obvious action for somebody to take. Sure, I could track sales, but that's a bit trickier. One problem is that about half of our users buy Sandvox from the store that is built into the application. It's just a webview, so it's possible that the cookies from the optimizer would carry through, but if the visitor was using Firefox — which many are — it's not as easy.

Plus, as you might expect, more people will download a free trial than will end up purchasing something. And this kind of testing requires big numbers to get any statistical significance, so a test with a higher base conversion rate is going to get some conclusive results a lot more quickly.

(So if the page you are measuring is not getting at least several hundred visitors and conversions daily, testing is going to take you a long time.)

A few months ago, I realized that all I really cared to measure for conversions was people visiting our website with a Mac. There's no point in measuring random visitors from other platforms. (About 16 percent of visitors to the main Sandvox page are on other platforms.) What I did was to use PHP and only include Google's JavaScript that you put at the bottom of the tracked and goal pages. Something like this:

<?php
$userAgent = $_SERVER['HTTP_USER_AGENT'];
if ((''==$userAgent) || (FALSE !== strpos($userAgent,'Macintosh')))
{
?>
	<!-- insert GWSO stuff here -->
<?php
}
else
{
	echo "\n\n<!-- No GWSO -->\n\n";
}
?>

I've tried to take notes over the months as I've worked with the tool to adjust our main Sandvox web page. It might be interesting for some folks to read about what we did. Here are handful of our recent experiments:

• Moved our Apple Design Award badge from the top of the sidebar to below the download/buy buttons.
• Various experiments in button colors and fonts. We used to have flat, dull, gray buttons. Brightly colored, glossy buttons did much better.
• Experimented with the font of our body text. I was expecting sans-serif to win, but Serif did better. Later, we did another experiment and the Optima font we used did slightly better.
• We did several experiments to tweak the headline and sub-headline for Sandvox.
• Our website used to be more greenish than blue. Blue did better. (We actually have an entirely new design in the works for release soon.)
• We tested whether to run a "box shot" as if the software were something you could pick up in a computer store (you can't) vs. the icon, and the icon won.
• How about a nice little perspective screeenshot instead of the icon? Nope, the icon still rules.
• We did some variations on our list of sandvox features: one or two columns, large or small icons, etc. Smaller icons and one column was better.
• We had a lot of "copy" that I tried just taking out, and it was better to have it gone. Sayonara!
• Would a bigger Apple Design Award badge convince more people to download? Nope.
• We originally had our "slide show" of websites built with Sandvox up near the top. I tried a smaller version above the download button in the sidebar, and also just move it way out of the way, and the version where the images were way out of the way did best. I guess people don't want images to get in the way of reading the juicy details!

Anyhow, the experiments continue. I'll probably have to start a bunch over again when we get our new design in place, since the new metrics and colors will probably impact some of the choices we made.

See you at WWDC!

This is part 3 of a three-part series. Part 1 and part 2 have been archived on the World Wide Web, for your convenience.

10. Make Launches into Big Events

In the past, I assumed that the best way to launch a product was to be as secretive as possible about the product until the big announcement. After all, that's how Apple does it! But, face it, we are not Apple. Apple is able to build up a fever-pitch frenzy by being secretive and letting the rumors fly. Indies, on the other hand, need to make their own buzz. You can build up to your product launch with gradual hints put up on your website, sent to your email list, mentioned on forums, "leaked" to rumors sites as Wil Shipley suggests, and so forth. Make sure to collect an interest email list so that people will be able to buy your program the moment it's out. Perhaps you can partner up others to help you get the word out about your upcoming launch, especially if you have an incentive for the readers of your partner's messages and/or the partner promoting your launch.

Hopefully your launch will not conflict with some other big event in the Mac community. If you start making noises about Launch Day, other developers will probably work their launches around you so as not to saturate the news cycle. Fortunately Apple is pretty good about warning us in advance when they are going to launch something big, so it's easy to work around their schedule as well.

(Today's MacUpdate promo bundle is an example of how not to do this. They could have built up a frenzy for weeks, the way that Panic did for their sale. Instead, they just issued a press release today. No anticipation!)

11. Keep up to date on the main Mac sites

Be sure that you always update your listings for your software on the main software tracker websites. The main listing sites are currently MacUpdate and IUseThis; you should get an account and list your software with each version update. You should strive to get your software listed with the Apple Downloads site: if your product is picked as a featured download, you will get a lot of downloads (and hopefully sales) during that time. Make sure to keep your software updated frequently so its listing doesn't expire! While VersionTracker used to be the king of these sites — we'd get huge spikes in Watson sales directly from VersionTracker back in the day — it's now hardly worth the hassle of registering now that it's been bought out by CNET.

12. Allow your software licenses to be sold and bought by third parties

There are a lot of other models besides a person buying a license for themselves on your website. Try to consider other ways people might buy your software. A simple change in your licensing setup might allow somebody to buy a license as a gift for another, for example. But how about people who want a piece of the action? While individual Mac users are likely to recommend your product to their friends as a courtesy, there are many consultants whose livelihood depends on setting up people's Macs and getting a cut of the sale. So ideally you would set up your selling system so that you could have affiliates (codes that allow you to track how somebody heard about your product so you can compensate the referrer with some percent of the sale). Another approach would be to have an online storefront that allows somebody to perform the transaction themselves to purchase your software on behalf of somebody else, while taking a commission.

Of course the biggest step of all, one which most indies are not willing to take, is to go into boxed product retail stores. You may wish to listen to the audio of the panel discussion that I put together back in 2004 for the O'Reilly Mac OS X Conference, "How to Run Your Own Software Business." Wil Shipley (Sorry to keep mentioning him here!) ranted eloquently about why this wasn't a good idea, especially in the United States, and I don't see any indications that things have changed at all since this conference. Unless you know something I don't know, I'd suggest ix-nay on the ox-bay.

13. Give away licenses liberally

Look, there are something like 20 million people running Tiger or Leopard currently. Of course you'll never reach all of them, but if you can sell your software to a few thousand per year — just a tiny fraction — you are making a living.

So again inspired by Shipley, think of how you can give away licenses of your software to some of the others (the other 19,990,000 people) and use that as leverage. If they write a blog review of your software, you may sell a few more copies to somebody else.

Another place to give away your software is to Apple employees. (Sure, some of them might have paid for your software, but if you can ignite a passionate response in somebody who works for Apple as a sales engineer or a genius at the Apple store, you will sell more copies. We know of many cases where people come into Apple stores and get sold on Sandvox for cases where iWeb won't do the job, for instance.) Contact the Third Party Promo manager for this. Give your software to consultants like members of the Apple Consultants Network. Offer discounts and free door-prize licenses to members of Mac User Groups. You get the picture.

Wow that turned out to be long, and I feel like I've just scratched the surface. Do you agree or disagree with these points? Any further insight you want to share? Add your comments and let me know what you think I should address further, or add your ideas that I didn't mention — maybe I'll find some fodder for another post. And be sure to tell me if you start using some of these ideas, and how it works out.

BTW, I'll be at WWDC (and the pre-WWDC sfMacIndie Party) in a couple of weeks — look for me sometimes wearing a Karelia T-shirt - no wolves, sorry! (See simulation picture here; the shirts haven't actually arrived yet!) If you'd like to chat about some of these ideas over coffee/beer/Jamba, I'd be more than happy to continue the conversation!

This is part 2 of a three-part series. Read part 1 if you dare! (By the way, I think today's big sale by Panic is a good illustration of point #1 from yesterday's post!)

5. Do Search Engine Optimization (SEO)

SEO — I'm not advocating any "black hat" trickery here — is the act of making sure that your website provides the content and structure that the people out there — who are looking for what you provide — need, in order to find you via Google (or its lesser brethren). I'm amazed at how few indies seem to be paying attention to this. I've been studying this for a while now (something that came naturally out of creating a website builder), and although it does require a modicum of understanding and work, it's not rocket science! It really boils down to three prongs: (1) making sure that your site is properly indexed by Google, (2) making sure that your website contains the words and phrases that people are likely to be searching for, and (3) getting lots of links from other websites with good reputations. (Having a useful blog that people will link to, and sending out free or paid press releases through PRMac.com is a good way to get this going.) Of course the nuts and bolts are a bit more detailed. If you are interested in learning more about this, we have found that besides Google's documents (which are of course very useful and accurate but don't tell the whole story), the company StomperNet has tremendous, well-tested knowledge that they have made available either for free or very little cost. Though their own marketing style is a bit too "slick" for my tastes, their information is first-rate. You can get their seven-part free course, and if that whets your appetite, you can get their full SEO course for — golly, gosh — one dollar. (Yeah, they are obviously making money on the "back end" here. Actually the magazine they are trying to get you to subscribe to is amazingly good and I'm very likely to stay subscribed to it.)

6. Tune your "Free Google Ad"

Yes, you can pay for ads in Google (we tried it — it wasn't worth it; there were too many PC users out there clicking on our ads and Google doesn't let you only serve ads based on the user-agent) but did you know that you get a free ad on Google for each and every one of your pages? I'm talking about the organic search results! By controlling what I am coining the "aspect" of your web pages — the title tag and the meta description — you have the opportunity to create a headline and description that people will want to click on when your website shows up in the Search Engine Results Page (SERP).

We recently added the capacity in Sandvox to control this when we realized how important this was. You get up to 65 characters for your title tag and 156 characters for your meta description tag before Google starts adding ellipses (which, according to StomperNet, drastically reduces the likelihood of people to click on your listing), so use them wisely.

Actually there's one other aspect of your aspect that you should consider — the URL of the web page, which shows up in green in your Google listing. If the domain name and path to your file name have words that are close to what the searcher was looking for, that's also a plus for their likelihood to click through and get to your website.

7. Optimize your Website

Last year I read the amazing book Always Be Testing. I was, uncharacteristically, moved to write a (glowing) review of it on Amazon.com. It really opened up my eyes to the importance of having clearly-defined action for visitors when they get to your site. By using Google Website Optimizer, you can perform experiments on your website and see which variation causes more people to take action — e.g., download your free software demo. Examples are adjusting placement of elements, adding social proof like testimonials, case studies, and award badges, changing colors and fonts, adjusting headline text, adding reassurances at the point of action, and so forth.) The book is a great guide to Google's software, and provides a number of suggestions for what to vary to improve your site. We have been constantly testing and improving our main Sandvox page since last September. If your website gets a decent amount of traffic, you can do this too. (In order to get statistically significant measurements, you need hundreds or thousands of visits, so it may not be feasible to actually run the tests if your website is just getting off the ground.)

Here's an example of an experiment I tried. I got a comment that it wasn't that obvious that our website was selling software, and we should have a "box shot" — a fake (but tastefully rendered) image of a simulated product box, as if our product could be found on the shelves. I found some decent software and created an image, which I then tested in contrast with the program's icon. The results came in pretty quickly — it was a failure. More people downloaded our demo when there was a simple Mac icon than when there was a box shot. (I'm only measuring visitors who are browsing from a Mac.) It might be that we inadvertantly gave the impression that it's not downloadable software, or maybe it looked too much like a Windows image!

One of the insights I learned from the book was that there are four types of visitors to your website. Those who are ready to buy, those who are interested but haven't decided, those who are just "window shopping", and those who really didn't belong on your website in the first place (e.g. the Windows user). It's good if you have actions for the three visitor types who count: as an indie developer, that might correspond to the following: a button to purchase, a button to download a demo, and a form to get on your email list.

If you have been paying attention, you may have noticed that the last three points are a kind of funnel — getting your website to show up in the search engine listings, getting people to click on your listing, and then getting your visitor to actually do something. Yes, I did that on purpose.

8. Give your customer choices

People love to make an order that fits them just so. Look at Apple's options when you buy a Mac through their store, for example. You can do something similar by offering a "Pro" edition of your application. (Or even a third ... uh ... "studio" edition ... read Predicably Irrational for some ideas why three choices is better than two.) Those who are on a budget can get your lower-priced offering; those with money to spend or the desire for power will go for the Pro version. (We have found that Sandvox Pro outsells the regular version by 2 to 1.)

9. Give away free stuff

Other products, add-ons, PDF "e-books", anything like that. If you haven't figured it out by now, people love free stuff. You can use them as incentives for people to join your list, or buy your product by bundling them in as bonuses, or just send out something cool to the members of your email list every so often as an unannounced bonus. You can have a free version of your paid product. If it's free, people will like you for it!

One more chunk to go. Don't forget to leave some comments with your violent disagreements or statements of love and solidarity, or anything in between.

Since I started being an indie developer for Mac OS X (FYI "indie developer" is the same as "Micro-ISV" in Windows-speak) in late 2001 — a long time ago, actually, when most Cocoa software titles available were ports from NeXT — I found myself wearing the "marketer" hat as well as doing programming. Back with Watson, I just followed my intuition and was met with wild success; with our current Sandvox, mac website builder, I think our success has come from a more thoughtful approach to the topic now that the marketplace is much more crowded.

Over the years, I've been learning more and more about marketing as it relates to the indie developer. Some of it comes from my own experimentation, some from maestros like Wil Shipley, and much from some excellent books as well as websites that, even though many contain a lot of good information, make me want to wash my Cinema Displays for a while after visiting them. (If you've seen those "Squeeze pages" with lots of Impact font, black and red text, and yellow highlighting, you know what I'm talking about. They must be appealing to Windows users; I think Mac users have a more refined sense of aesthetics!)

I thought I'd make a little post about marketing that may be of use to other indie developers. Well, it started out being little but it got kind of large, so I'm splitting it into multiple parts!

I have to say that we at Karelia are not yet practicing all these suggestions — though I'd love to be, it does take a while to actually implement some of these ideas — especially the first one I'll list here. We'll get there soon. In the meantime, these tidbits will hopefully be of use to you.

Before I dive in, I guess I should define marketing. To me, it's more about general promotion and getting people to want your software product. It's not about "sales," which I've never been very comfortable with, but instead, making sure that the people who might want to use your software know about it and its benefits, and once they have it, are happy users that are likely to spread the word to others. So for me, marketing is giving more value to our potential customers.

1. Sell — or plan for — more than one active product.

I've mentioned over the years that this is the one piece of advice I wish somebody had given me when I was just getting started as an indie developer.

From a purely technical standpoint, it would have forced me to build our back-end infrastructure (like customer database) in such a way that when we have a second commercial product in addition to Sandvox, it will be easier to bring it to market.

From a marketing standpoint, there are some great advantages to having a second or third revenue-generating product on the market at the same time. One is that every time you get in the Mac "news" for doing something interesting (like issuing an update), your company and all its products will benefit. For instance, each time we issue a new update to our free iMedia Browser, we get a bump in sales of Sandvox for a few days. Having more than one product also means that people who came to buy one item may also decide to buy another while they're at it, either spontaneously, or through a "bump" or "upsell" you do when they go to check out. ("Do you want Yogurt with your McSalad?")

Another advantage to having more than one product is that you can do "loss leaders" where one product, sold for very little, will bring people into your fold — see the next tip — where you then have the opportunity to sell them other products later. This is a technique used frequently by retail stores that advertise one item at a great discount but make up for it by the other things you purchase. MacHeist, I recently realized, is a perfect example of that, so if you have a product you can sell for next to nothing as a leverage for selling your other applications, it can be a long-term win for you as a developer.

2. Have an email list for customers and prospective customers

Back in the Watson days, we didn't have an email list so we had no idea who was trying or buying our software. There was no way to communicate with our entire community. We set one up when Sandvox was in pre-launch phase of Sandvox, so now we have a huge list of people who either bought Sandvox or are interested in our stuff. We can send out monthly emails with tips and tricks for the Sandvox and iMedia Browser, make sure people are up to date, and point out other cool Mac software that our subscribers will find useful. And when we have a new product, there are thousands of people who will be the first to know about it!

If you set up a mailing list, be sure to do all the right non-spammy things like confirm people's intention to sign up and give them an easy way to unsubscribe. You can sign people up the first time they launch your program (as a demo or a paid user), or from a form on your website, or both. (You will probably want to offer some incentive (like a free program or PDF) to entice people to bother to sign up from the web.)

(BTW, You can sign up for Karelia's Email List yourself. Don't be shy!)

Your mailings, whether they are frequent or infrequent, should at least be consistent, and provide some value to the reader. If it's just hype, your subscribers may not stay subscribed for long.

Here's a tip: If you have URLs in your email linking to your site, you are not going to be able to tell where they are coming from when you examine your server logs or use Google Analytics. We worked around this problem by creating a little home-made URL shortener script on our website. We found when using this that a large percentage of our site visitors are actually coming in from our mailings, a fact not evident before.

You can also use your email list to send out periodic emails directly to your new customers to follow up on their purchase. Give them tips and tricks, suggestions, and offers of help. Welcome them to your extended family!

3. Build an Ecosystem

I think I first heard Tim O'Reilly apply the term ecosystem as it relates to Software. If you can make your software part of a bigger universe of other developers or content providers, you will get a lot of marketing juice over the Internet, and find other benefits from time to time. I had designed Watson with an SDK, and it encouraged developers to jump in and build their own modules. (It gave the product more credibility and it may have provided some benefit to the developers — one of them landed his dream job at ESPN after writing a sports module; one has since become a successful indie developer, and one, Terrence Talbot, wound up becoming a partner at Karelia!) With Sandvox, our open design specification has allowed half a dozen designers to create — and in some cases sell, as part of their business — their own designs. (Check out our showcase these independent Sandvox designs, a website which is itself a marketing effort.)

4. Practice "Integration Marketing"

Integration Marketing, coined by marketer (or as I like to say, meta-marketer, because he is one of the many marketers who markets the art of marketing) Mark Joyner, is the act of finding and taking advantage of points where others can market your stuff, or you can market other's stuff. There are usually a number of opportunities for you in your contacts with your customers and prospects to promote useful and complementary products or services. Putting amazon.com affiliate links or Google ads on your own website are two obvious examples. With Sandvox, we have three web hosting partners that we refer people to, so that they will have a good experience publishing their website. (Without such ideas, Sandvoxers might still find a decent host by themselves, or they might just default to GoDaddy and regret it later!) It's topical and helpful, because it fits in with website building software. So yes, it's an additional source of income, but integrating with them is also adding value to our customers. We even added additional value by creating screencasts for each of the hosts, to walk Sandvoxers through the process of signing up for a domain name and hosting.

Of course, the important thing is to find good partners. You could do joint venture ("JV") partnerships with other indie companies, promoting their software (either for a commission, or as we sometimes do, just for what we like to call "good karma") and have them promote your stuff, which of course translates to sales that somebody else made without you doing any work. It doesn't have to be just Mac software companies teaming up with other Mac software companies. It really depends on what your product's domain is.

If you are looking for opportunities for integration marketing, a good idea is to build a process map of your own company. What are your points of customer contact? What flow do they go through in visiting your website, downloading, buying, signing up, confirming, getting follow-up emails, etc.? Where are there opportunities to reach your prospects and customers in a helpful way?

Note: if you are paying or receiving commissions/affiliate payments, there are various accounting/tax implications of this, so make sure you know what you are doing.

OK, that's all for now. In part 2 I'll have some things to say about websites and prices. Be sure to leave some comments here if you agree, disagree, or have some other thoughts!

Every year I try very hard to go to O'Reilly's Maker Faire, held at the fairgrounds in San Mateo, California. It's one of the highlights of my year, seriously. (I missed last year, but I was having fun in Europe, so that's OK.)

I haven't heard a lot of twitter about it this year, so I wanted to make sure people knew about it.

I'm personally not into DIY (other than software) but I love to see what others are working on. There are a lot of amazing creations, both "techno" and "retro" (or a combination of the two). Many items that have been to Burning Man and back. Lots of interactivity, too. The way I've described the event, especially since it's held at the fairgrounds, is as a "county fair for geeks." It is really an amazing event, both for adults (at least of the geeky persuasion) and certainly for curious kids.

I'll be spending my birthday there with my kids (and perhaps their friends) in tow. If you've never been, you owe it to yourself to check it out.

OK, I haven't been blogging much here. If you read this with NetNewsWire, my feed has probably been a deep shade of brown. Truth is, I tend to post pithy comments on Twitter most of the time rather than blog here.

But occasionally I have something interesting to share that goes beyond the 140 character limit. So here I am!

Ironically, this blog post is about Twitter. Specifically, how to use it as a tool to get references for somebody you don't know.

I posted a question a few days ago asking if anybody knew somebody who could help us with some system administration stuff. And I got a response, from somebody who was interested in helping us out.

Trouble is, I didn't know that person. Of course when hiring somebody you can ask you for references. But I thought I'd try something different — I figured out some references on my own.

I did this manually, but then fellow twitterer and Mac/iPhone developer Chuck Soper (@ChuckSoper) pointed me to a cool web service TweepDiff.

There are a number of options here, but the operation which will help with this particular case is to compare your friends with the other guy's followers. In other words, find out what people whom you follow also follow the other guy. Hopefully, anybody that follows this other person knows him or at least finds him interesting enough to follow.

With that list (after filtering out any institutional twitter accounts who auto-follow), I was able to contact some of my colleagues and ask what they think of him. And, lo and behold, I learned some useful stuff! In this case, it was positive....

Earlier this afternoon, Alex Payne announced on Twitter the availability of some new APIs, built by Matt Sanford that would allow programmers to make use of the searches and trends found at search.twitter.com

I checked it out, from curiosity, and immediately thought of an interesting use of this. Why not set up a twitter account that people can follow to hear about the "trending topics" of people's twitter messages? You could follow that account, and learn about the things which people around the twitterverse are talking about.

I was stunned to find that the account "trending" was not yet taken. So I set up an account and got to work on a quick little project.

And I mean quick. After just an hour or two of programming and setting up a simple database, I had my "bot" set up. Every five minutes, it checks the latest topics, and checks to see if anything is new. If it is, it posts each topic, along with a URL to perform that search on the web, as a new tweet.

It took a while to wait around for some new topics to come on the horizon, in order to verify that the automatic aspect was working properly. But, about three hours after the announcement, I announced this new account/service.

So if you use Twitter, give it a whirl — follow trending. It's fascinating to become aware, in real time, of what people are twittering about.

Also, if you are so inclined, you can follow me on twitter, and also Karelia Software. Fellow Karelians Mike and Terrence are also on Twitter as well.

At the job that I had before starting Karelia Software, around the turn of the century, our software engineering department had a fairly intense set of coding guidelines. Not just the formatting rules that people had to follow (e.g. no K&R braces, indentation rules, etc.) but also many guidelines that were about programming defensively. The idea was that you had to write code that was less likely to have errors in it, and was less likely to have errors introduced later on.

Although the guidelines were originally written for C++ (for old-school Mac development), a lot of the rules transferred easily to Java (as did the many of the developers!), and then, with me, when I went "indie," to Objective-C.

I don't have a copy of that document, alas, but I did manage to internalize many of those rules, so that it became habit for me (for the most part), and I've been able to add on to some of those rules to be specific to Objective-C/Cocoa programming.

A few days ago, I found out about the LLVM/Clang Static Analyzer — "Clang" for short — from a number of developers on Twitter (where I am "danwood", BTW, and a lot more active there than on this blog these days). I ran our codebase (Sandvox, along with the iMedia Browser and other bits of code) through the analyzer, and what I found was very interesting: Most of the bugs that it found, if we had better applied the guidelines we've been trying to follow, would not have been there. I consider this proof of the utility of these kinds of guidelines, which I'll list later on here.

See more ...

I make my living off the evening news
Just give me something-something I can use
People love it when you lose,
They love dirty laundry
— Don Henley, "Dirty Laundry"

So we are close to releasing Sandvox 1.5 over in Karelia-land. But there are a few exceptions and crashes that people are getting, and we're out of ideas on how to diagnose them. (Of course, they don't happen to us!)

So Karl suggested posting the backtraces and seeing if any of our astute readers (of the Developer persuasion) had some ideas. Can those of you not daunted by this prospect take a look and see if anything comes to mind, any thoughts that you might have to help track down the issues at hand? I have some good juicy backtraces with symbols, the trick is figuring out why these crashes or exceptions happened. (For the crashes I am just including the backtraces but I could upload the full crash reports if people want...)

I'd love to hear your comments in the comments section, or you can drop me a line: dwood at the venerable domain of karelia, in the kingdom of Dot Com.

See more ...

At Karelia, we will be releasing a couple of new bit of software, and I'm looking for people to try to break things!

Next week, we are planning on releasing a new 1.1.1 version of the standalone Karelia iMedia Browser. The many people working on this code — more on that below — have apparently fixed a lot of "crash" kinds of bugs, but I'd like to really see if that is true!

If you have a few minutes to explore this handy utility, could you download it here and exercise it a bit? See if you find any problems. There is a built-in feedback reporter and problem reporter so if you do encounter any issues, please report them so we can track them down.

While I'm here, I want to gush for a minute about the open-source community that has rallied around the iMedia Browser Framework, the guts of this utility that is being used in a number of applications. There are about a dozen developers who have contributed code to this, but I wanted to give a big shout-out to the folks at Plasq and Boinx for their amazing contributions of late. They are making this a more useful and stable bit of code on an almost daily basis.

In a few weeks, we are planning on releasing a new Sandvox, which we hope will have some amazing stability improvements over the current version. If you have Sandvox and you'd like to see what the new version has to offer, or you don't have Sandvox and you want to give it a spin, this is a good chance to kick its tires. We've had a few reports of "hanging" that we are trying to solve before we can certify it for release. (We've added a lot of extra logging to help us track down some of these issues.) So if you have a few minutes to try it out, I'd appreciate it! Download it here. And send in your feedback using the menu items from the Sandvox menu.

Thanks!

I've been spending the last few days, on and off, dealing with localizations of the new Sandvox version we are trying to get ready. Each time we have a new version coming out, I have to go through a lot of tedium and hassle to successfully get Sandvox updated and fully functional in several languages. It really could be a lot easier than it is now.

The current version of Sandvox has eight localizations. Besides English, it's in Danish, French, German, Italian, Japanese, Traditional Chinese (Taiwan) and Simplified Chinese (China). The localizations are done by some wonderful, amazing volunteers. (We may have to drop a couple of supported localizations for our forthcoming 1.5 version; we've lost a couple of our volunteers unfortunately.) The volunteers all use iLocalize, which is a great (but by no means the only) localization tool out there; if they don't have the program we get them a license for them to use it.

The ideal workflow goes something like this: When we are getting near a release, we send a private build of Sandvox out to these localizers. They each open the application bundle with iLocalize, and it figures out what strings need to be translated, keeping track of the strings that have already been translated. When they are done, they export the resources (.strings files, .nib files, and a few .html files) and email them back to us. Using a shell script, I copy the resources into a new directory structure that parallels our subversion repositories (since the topology of an application package is not the same as our source code). Another script copies the files into the corresponding places in our subversion repository, careful not to stomp on the .svn directories.

In an ideal world, that would be pretty easy. The problem is, a release is a moving target. Even though we declared we were "frozen" for strings about a month ago, little things crop up -- a bugfix may change a string or require a new error message. Or last-minute changes, like the debut of MobileMe, mean that we have to go through another round of localization. And frustratingly, we find that even after we have accepted a localization, merged it into our source repository, and built a new version, that new version isn't quite fully localized. Somehow, some strings got missed.

The worst problem in all this is nib files. Once we have localizations in play, a change to a nib (adding or repositioning a label, hooking up a forgotten outlet or action or binding, etc.) has to be propagated to all the localizations, or there will be a bug in your program when it's running under other languages. This means that the programmer has to go through and make the same change n times, or rely on the translator to know that they have to rebuild the translated nib from the English (source) version. (I'll assume that English is your source language for the rest of this article.)

It's very difficult to make sure that all our languages are really working when maintaining multiple nib files is so fragile.

".strings" files, though they are a lot simpler and just text files, are not without their problems as well. If you fix a typo in your English text, you have to make sure to fix that source string in all of your translated .strings files, or your source will not be found and show up as English in your otherwise translated program. You are not likely to know that there is a problem unless you can test every message your program will ever encounter in all its translations. (Peter Hosey's Localization Helper is a utility that can help with this a bit, though.)

The problems of dealing with translations are so great that several developers have abandoned localized nibs completely — CocoaTech has done this for Path Finder, as has Delicious Monster for Delicious Library. I'm sure there are others. The alternate approach is to have a single nib, putting in translated strings on-the-fly, and possibly resizing the views programatically to make the elements fit. (Languages such as French and German take up quite a bit more space than English!)

On-the-fly localization is a decent idea — we're considering it for our next major version of Sandvox to alleviate some of these hassles — but it's not without its drawbacks. You really have to prepare your nibs for the "worst case" scenario of elements fitting. There are some scenarios in Sandvox that I'm not sure how we could work around: for instance, some labels are so long in their translation that we have to split them into two or three lines to fit. This affects the horizontal positioning of everything else. If we left room for the eventual translation, then the English version would look strange. When you are aligning elements with each other (for instance, right-justifying several labels to the left of some checkboxes), you would need to move all the items that were aligned. Or, you just leave a lot of blank space in the English version — a feat that sounds like a good idea but is hard to accomplish in small elements such as inspector windows.

Solutions?

It seems that Apple needs to take Internationalization ("i18n" for those who don't want to type a twenty-letter word) a lot more seriously and integrate this directly into Interface Builder and Xcode.

Xcode is slightly aware of localized files, and Interface Builder and Xcode are slightly aware of each other, so I don't see why there couldn't be more direct i18n support built in.

Imagine if your localized files were just always synced with their original counterparts. If I adjusted a string in my Objective C file, the English .strings file could be automatically updated, and so would the translated versions (with a warning marking to indicate that somebody will need to check the translations.) If I deleted an English string, the corresponding localizations would be deleted too, since they wouldn't be needed. If I added a new string, the translated files would have entries for those new strings, marked as needing to be translated.

If I modified a nib, I'd only have to deal with the English nib. I could add a connection or binding, fix the spelling of an action's method name, etc. and not have to worry about the translated nibs getting out of sync. If I added or changed the contents of a textual label, then the translated nib files could be marked as needing to be translated or checked. If I deleted something, they would be gone in the translated nib. If I moved or resized something, the translated nibs might indicate a warning if the corresponding string is conflicting with something.

(I'm always finding that it's very difficult to see when a string has not been given enough room in a translation, and we're forever getting complaints that buttons in German are truncated. Not surprising, considering I don't speak the language and thus I can't tell at a glance if the text has been truncated! There needs to be big bold warnings that text is getting truncated in your nibs!)

Perhaps what is needed is an overhaul of the way that nibs are stored. Yes, i know that the .xib format in Leopard is new, but couldn't nib files be split into connections (one per nib, period), strings (one per localization), and layout (one per localization if needed), so that it's impossible to get the kinds of inconsistencies that we developers are always fighting?

Maybe we need more ways to lay out items in a nib so that automatic repositioning is easier, so you can avoid a lot of the headaches of multiple layouts to check. In the simple cases where a button is the only element on a "line" and you make the text wider, that's a no-brainer. But when you start dealing with groups of items side by side that need to align with each other, I don't think that there is enough information in the struts-and-springs model we use now to automatically "stretch" things appropriately to fit different languages automatically.

What do you think? Are there any tricks to localization that I haven't covered here?

If you agree that Apple needs to make localization easier and more integrated, please file a new bug and say "me too" to radar ID 6078830 ...