One of the features that has always been planned for MagicBrush-Photo has been the ability to upload or publish images to Picasa and Flickr.

Right now I’m in the midst of incorporating this feature into the release plan. The GData APIs for cocoa are making this straight forward enough, but the tricky part is making the experience fit in with the overall Mac user expectation.

For instance, a user has a reasonable expectation of being able to store their account information for Picasa or Flickr in their keychain.

Once you can authenticate to either site, you need to present the complex behavior of the web application in a simplified manner. Should users be able to only upload? Should they be able to view previously uploaded images (to ensure they’re not duplicating things)? Should they be able to edit tags and descriptions for images already uploaded, or just when they initially upload them? Complexity grows quickly.

Stay tuned to see how MagicBrush-Photo handles these. If you are interested in helping beta test these features, give me a shout.

MagicBrush-Photo was stalled slightly at version 1.1.5. I knew what I wanted to add by way of features, and had a development branch working, but unfortunately my “paying job” was consuming more of my time and energy than I planned.

An Aside

I should probably caveat that I’m not your typical programmer (at least I like to think I’m not). I’ve got a full-time non-programming management job at a fortune 500 company within the IT organization. For the past year I’ve been loaned out on a special project team doing a bunch of neat things within a couple of our markets. I’ve run the gamut from launching new products and services to implementing different business model pilots and a slew of other cool things.

It’s been fun (mostly), and a lot of hard work.

But it has seriously diminished my free time to program and enhance my software. At the same time, Leopard has been released, and the niche I had targeted is beginning to transform into a very competitive landscape. It would be easy to back off and let MagicBrush-Photo languish.

But that’s not what I want to do.

Why I Program

1. I like to solve interesting problems.
2. I like to have control of how I work.
3. I like the Macintosh platform.
4. I like the idea of “not working for the man”.
5. I like being able to keep my coding skills fresh.

While my morale regarding GreenWave Software was a little down early in the year, I’ve found it helps to remember why I enjoy programming in the first place. I don’t get to use this set of skills much at work (and frankly don’t think I would enjoy it if I had to code in a corporate environment).

When I stop and think about these reasons, I find I am more focused on moving the needle with MagicBrush-Photo and a few other projects I have in the hopper.

Now, back to coding

Developers are told repeatedly to “ship code to real users” and get feedback. How does this translate into the customer experience and their update cycle?

What do you think?

I’ve decided recently to move away from packaging up point releases and instead ship more frequent updates via the Sparkle+ framework. This will allow me to keep my motivation and engagement up, but could impact the user who will see more frequent updates. Which is a better approach for customers? Post a comment or ping-back with your thoughts.

On a related note

I’m working on several new features in MagicBrush-Photo that will be developed incrementally over time. In parallel there are bug fixes and minor tweaks occurring within the code.

In a multi-developer group, a more rigorous release plan and management would be a given (I hope). But for a single developer, do I really want to spend time maintaining branched code (current and development) and merging things back together for a release?

I’ve decided to not keep code merged and instead created a framework for setting a flag within the preferences of the application to enable development/partially complete features. This way, I can send a stand-alone script to testers to turn-on features within the current release.

Hopefully, these two changes in my approach will help me drive some significant new features more quickly to the users of MagicBrush-Photo