Musings from The Software Underground

Greetings from San Francisco! We tried to get to the keynote early but still wound up near the back of the hall. They wouldn't let anyone up until about 20 minutes before it started and then they only opened 2 escalators, so depending on where you were standing when the lines formed you either got up close or were near the back. No matter, the camera work of what went on on the stage was excellent.

The only things I can really talk about are items that were announced in the keynote. Tiger looks great, and has some great new features like Spotlight, Automator and a much improved iChat AV. Spotlight features system-wide super-fast searching of file metadata and file contents that we as developers can tap into easily. Automator is a way of easily automating tasks and building work-flows using applescript. I've been planning on improving AppleScript support in the next version of SQLGrinder and adding support to MacGourmet later, but with the new Automator, adding AppleScript support makes even more sense. iChat AV? Well, it's clear that no one can even TOUCH what Apple is doing with video and audio conferencing. This stuff not only works, it works in a polished, almost "produced for TV" quality.

Jobs also showed off Expose Dashboard and RSS support for Safari. Dashboard is pretty cool, and very much like Konfabulator, so much so that we walked out of there thinking Apple might have purchased it from its creators. Alas for small Mac developers everywhere, according to this morning's SF Chronicle, Apple did NOT purchase it from or make any deal with the Konfabulator guys, and boy are they pissed. Apple, you have $4.5 BILLION in the bank and you clearly decided to clone an application created by one of your small developers, and you couldn't even throw them a frickin' bone? A little unsettling. If there weren't any plans there to take Konfabulator to Windows XP, there most certainly are now.

Safari RSS support, on the other hand, might make you think that it would hurt the developers of RSS products, but I don't think that's true at all, I actually think it will enhance these products by making feeds very easy to find and view. After you start collecting feeds, I think anyone other than casual RSS readers will still need an RSS-specific feed management application, so I see this as a win-win for PulpFiction, NetNewsWire, etc., rather than a negative.

Finally, Jobs showed both the new QuickTime codec and debuted a much better iSync sync engine. The new QuickTime codec was absolutely INCREDIBLE. I can't wait to take advantage of the new sync engine, say in MacGourmet. Sync your recipes between laptop and desktop anyone?

Jobs also showed off amazing new LCD displays. I have been waiting to buy a 20" display and am happy that I haven't pulled the trigger yet. One unfortunate change is that they are completely dropping the 17" display. Your price of entry to Apple displays is now $1300, which is pretty steep. It would have been nice if the debut would have also included a drop in prices. The new 30" display however, is, in a word, AMAZING. It's way more display than I'd need as a software developer, but it actually takes what is essentially TWO video cards to drive it. Crazy.

While I can't mention anything covered under NDA, I'll say that there are new things that I saw that showed me I've been on the right track in some of my planning, and there are also new things that have given me a lot of great ideas.

(updated - I was incorrectly calling Dashboard "Desktop." )

Next week we will be at WWDC. This means that development will be on hiatus while we are gone. Though we will be online from time to time, expect that support will also be sporadic.

I personally can't wait to see what's in store for the next version of OS X. I'm also hoping that just maybe they will unveil some new "must have" device.

I expect to return from the conference recharged and ready to rock. MacGourmet version 1 is nearly done, and July/August are on tap to be dedicated to SQLGrinder, baring any changes. I haven't been able to keep the schedule I originally wanted because, well I had to take a development contract to pay some bills, and that takes a lot of time away from the Advenio product line. I'm eagerly awaiting the day when I can give up non-Advenio projects and work on our stuff full time, so register those products and tell your friends about them!

MacGourmet is now up to beta 3 and a lot of great feedback has been submitted. I've been adding every small enhancement and fix that I can for version 1.0, as long as they don't involve huge changes. Any requests that require a large amount of work will have to wait for a later version. Rest assured all feedback is logged and prioritized, and even if you don't see your request right away, you might see it in the near future. There are a lot of great feature requests that have come in, some that matched those I already had in mind, and some that I didn't, so that bodes well for future versions.

This is hopefully the first part of a series of entries on software design, from my point of view. The first topic I'd like to cover is what I call "The Art of Version 1" subtitled, "What Goes In and What Doesn't."

If you are not a developer yourself, you might not be familiar with all of the decisions that go into what features make it into the first version of a product, and to what extent those features are implemented.

I usually start a project by sitting down and coming up with a list of all the things I want to see in an application. This is often based on personal desires, and holes I see in other, similar applications, if there are already applications in the same space. I next will often make a roadmap, so that I can figure out what features might get done when. After doing all this, it's easily see that not all of the features can make it into the first version of an application.

Why is that exactly? Well every feature takes time. Some features take more time than others, and some features can easily be done in stages, as in: a simpler version at first, and a more advanced version later.

"Why not just fully implement every feature right at the beginning?" you might ask. The problem is largely a matter of time, and of priorities. There is a finite amount of time. Time to work on something, time to market, etc. A decision has to be made: how long will it take to fully implement EVERY desired feature? Is every feature even WORTH developing fully? This is one of the reasons you see applications released with simple, and often what I'll even say is incomplete, feature sets. Releasing an application, especially, a version 1, with simple versions of some functionality is often done precisely to solicit feedback, and to essentially allow users to "vote" on the features they want to see expanded.

MacGourmet has a few good examples of this process: shopping lists were something that I wanted to get into the first version, but I wasn't sure exactly how people wanted to use them. I haven't personally been a big user of shopping lists in the past (this will change I'm sure), so this was kind of a grey area in the design for me. After the first beta of version 1 was released, people were really good about saying what they liked and didn't like about shopping lists, giving me ideas about how to make them better in a future release. So, instead of spending a lot of time designing this piece the wrong way, and extending the overall development time of the application and release date in the process, a simple version is included, and feedback is received on that version. Later, a better implementation will be rolled out, but in the intervening time, the application has been tested, purchased (hopefully) and a user base created, all justifying spending more and more time and effort on the application.

This also brings up another point: It's a better business decision to release a feature-incomplete product sooner, rather than a fully-developed and possibly undesired application later, or in some cases, never. Even a feature-incomplete product provides a lot of feedback, and some revenue, two things that allow an even better version of the product to be released later. If you spend too long trying to make everything perfect, you'll often never release a product at all, or you'll release a very advanced product that isn't what a lot of people want.

One last point. Shipping a version 1 should not be an excuse for a shoddy release. Even if features haven't been as fully implemented as they might be later, maybe for the reasons described above, version 1 should still be tested as well as possible, it should be clean, and finally it should be stable. You still want to give a user a great initial experience.

So the next time you download an application that is version 1, after reading this you may understand a little better why "feature X" isn't there, or doesn't work "right." Chances are, all these features ARE there, at least in the head of the developer, or on their drawing board, and with feedback and registrations, you'll eventually get to see them.

Well a milestone was finally hit. It was time to push a new application into the sunlight, for all the world to see, whether it was ready or not. Today marks the release of the first beta of MacGourmet. Please try it out, and send us any problems or suggestions. As this is the first wide release of the application, there are bound to be issues, but early testing has hopefully shaken out a lot of the problems.

After the beta period, MacGourmet will be available for $24.95 from our online store.

The coolest features of the new application have got to be the web clipping service and the .Mac integration.

The web clipping service came about because I wanted an easy way to get recipes that I found on the web into the application, recipes that often didn't have good enough delimination in their html code to allow for parsing. The service allows you to grab the text of any recipe, and store it in your clippings list for later. Then when you are ready, you can simply double-click on your clippings and step through the text of the recipes, putting the parts of the recipe into their proper locations so that they import correctly. In testing, I've imported many, many recipes this way, and I think you'll find it pretty easy to use.

Integration with .Mac, you can see an example here, allows you to easily publish a collection of your recipes, wine notes and cooking notes to your .Mac account. This allows you to share great recipes you've found, or created, with others. In addition, you can also publish collections to WebDAV servers and to folders on your Mac. While the text and images of your items get published to the web, you can also include MacGourmet import files as well, allowing others to import recipes that you've published simply by dragging the "file" image off of the page and into one of your MacGourmet lists.

A note to users of SQLGrinder, I'll be spending a lot more time working to get to feature complete version 2.0, now that MacGourmet is to a public beta, so hopefully, at long last, the next version of SQLGrinder will also get out the door sooner rather than later.