Dan Wood: The Eponymous Weblog (Archives)

We at Karelia have been recently going through a bunch of our source code, pulling out the general-purpose stuff apart from the Sandvox-specific stuff. Some of this is worth sharing.

Fellow Karelian Mike Abdullah has written a nice class that extends Core Data in a nice way. It's called KSExtensibleManagedObject. Check it out.

When we were exhibiting at Macworld Expo last month, we got the idea to make a screencast to show how we used Sandvox to create our Karelia Software website because several people said they hadn't realized our own site was built with our product. Hey, we "eat our own dogfood" but I guess it's not obvious!

We didn't act on it right away — the thought of doing a big production like we did for our Sandvox Introductory Screencast (We hired Clickable Bliss to make that for us) was a bit daunting. I was really hoping for a tool that would make it easy to create some informal screencasts from time to time.

Last week, Vara Software, an indie company based here in the Bay Area, introduced ScreenFlow. I immediately gave it a try, and I was quite impressed. It's a Leopard-only application (so plenty of good visuals and animation effects) and it is very nice. I dove into it for a couple of half-days, and I managed to create a screencast pretty quickly. It's not as polished as our main screencast, but I was able to get it looking pretty good!

After having a few false starts in which I struggled trying to narrate while going through my script, I read one piece of advice about how to make a screencast. Technology aside, the advice was: write the script, read it, and then "shoot" the screencast while listening to the voiceover track. I was much more relaxed after splitting the job into the "audio" and "video" portions.

The contents of this screencast are more about "showing" than "doing" since we have an already-built website. I was able to work in a couple of edits to the site within the screencast, most notably the insertion of a new entry in Karelia's Weblog highlighting the new screencast. A bit self-referential, if you ask me!

Post-production was where I needed to make the most intense use of ScreenFlow, to add in the title cards, remove flubs in what I said or what I did, and try to synchronize the words with the action. I could definitely feel that ScreenFlow was a "young" application (Vara just released 1.0.1 while I was in the process of editing) but I'm sure that most of the shortcomings I found (especially in manipulating the tracks) will be addressed soon.

I was very impressed with the ability to do transitions. The approach is quite unlike, say, iMovie, but it's pretty intuitive. I was able to whip up some nice graphics using Acorn and import them into my screencast at the beginning and end. There were a number of cool features that ScreenFlow provides that I didn't even take advantage of; perhaps I'll try them next time around.

I think the resulting screencast came out really well, especially considering how quickly I was able to put it together. I'm looking forward to doing more screencasts in the future with ScreenFlow. Anybody have any suggestions for what Sandvox topics to cover?

We have about 200 help pages for Sandvox, available at docs.karelia.com; also available from our Help menu. We recently added a feature, inspired by some Apple pages, in which there is a link to provide feedback at the bottom of each page. (See this page as an example.)

The link goes to a web-based form that allows the visitor to enter their opinion of the referring page. It's powered on the back-end by a simple PHP script that converts the form submission into an email message to us.

So far we have gotten a handful of good comments, but there are a couple of adjustments we had to implement to make this viable:

• Prompt people gently that they will need to enter their email address if they are expecting a reply. We've gotten several submissions from people who use the form as a kind of tech support, hoping that we'll answer their question. It's hard to reply if they don't include an email address!
• Spam-avoidance. We've had pretty good luck with honeypots. (I'd rather avoid a CAPTCHA if possible.) Essentially, we provide a couple of extra inputs that the spam-bots will probably fill in with spammish content. These inputs are not visible to the site visitor, so any submission with these fields filled in is very likely to be spam. Without this deterrant in place, most of our submissions have not been exactly relevant to the Sandvox....

I'm glad we added this feature to our documentation. Someday, I might change the link at the bottom of the page to do some "Ajax" magic and reveal a comment form right there on the same page, so that the visitor can see the page that they are commenting on, rather than taking them to a separate form. But that's #87,454 on my list of things to do.

Yesterday, I was interviewed by a couple of folks who are doing a project about the "indie" Mac software community. Many other people I know have also talked to them. I look forward to the report that they are working on.

It was interesting to reflect about the business, and the community that we have. This community is great — we "see" each other on Twitter (where I've been active for a while), iChat, email, and even in person at conferences like WWDC and Macworld Expo. It's something that certainly didn't exist when I "went indie" and started writing Watson and its unpublished predecessor, Museo, back in 2001.

There are dozens of well-known, successful independent Mac developers now. More seem to be taking the plunge each and every day. It's easier to do now because of the community, I think. Of course it also means more competition, and it's harder to get a quality application noticed amid the quickie applications. VersionTracker and MacUpdate are so full now that they are not particularly useful anymore.

There's one thought I expressed yesterday, which I'll reiterate here. Consider it advice for budding Indie software developers. If I could go back in time and give myself some advice, I'd say to plan for having more than one application, and incorporate that into your development and company infrastructure. Even if you are a one-product company for quite a while (as we have been, though I hope that will change soon), it will be much less painful to grow into a multi-application company. I'd even go so far as to work a "dummy" second application into your workflow, just so that you can easily work with a second real application should you ever have one. The "behind the scenes" aspects of the company, such as the structure of your source code repository, your building scripts and utilities, your payment processing methodology, your customer/mailing list databases, your techniques for looking up lost license keys, your online help documents, and so forth, will scale better if you plan for it early on.

Today I had the unfortunate occasion to use FileMerge to compare a lot of source code files These files had been checked into our Subversion repository in separate branches, and we were having trouble merging, so we wound up having to deal with this by hand.

Almost immediately I noticed that just about all the source files were marked as different from each other, even though we hadn't made any changes. What was up with that?

See more ...

People who are used to weblogs know exactly what those little orange RSS (or XML) badges are for ... you drag the link into your newsreader to subscribe to the feed.

But not everybody may know what the heck those little things are. For the nonprofit that I work with, our home page is actually a weblog, complete with an RSS feed. But is the average surfer going to know the power behind the little orange icon? The page that results from clicking on that link would look like pure gobbledygook to the untrained eye!

So I did a little bit of JavaScript trickery to pop up an explanatory window should somebody happen to click on the icon. (Try it below, assuming you are viewing this on your browser!)

See more ...