Interview with VoodooPad's Gus Mueller
by Derrick Story
Wikis used for online collaboration have become popular tools for developers
and corporate workgroups. The notion is to provide an easy-to-use workspace
where people can post their ideas, or quickly add information to the
ideas of others. The fewer the barriers, the more productive the environment.
Session by Mac OS X Innovator Contest Winner Robb Beal:
Implementing Ubiquitous Drag and Drop in a Rich Internet Application
Rich Internet apps on the Mac face unique drag-and-drop challenges. One of the major issues is that they need to acquire additional context before accepting or dealing with dropped items. Robb Beal, Mac OS X Innovator Contest Winner, leads this session that features some of the UI issues that he encountered while creating Spring's ubiquitous drag-and-drop experience. Robb will also be a special guest at the Mac OS X Innovators Special Event on Wednesday night at the Conference.
O'Reilly Mac OS X Conference
October 27-30, 2003
Santa Clara, CA
August Mueller had the notion that this concept could be useful on a
personal basis, too. After all, don't most computers make it difficult
to keep track of small bits of information? Why do you have to launch
this application to do this and another to do that?
Mueller's personal, desktop wiki for Mac OS X. As you add bits of data
to the environment -- notes, addresses, URLs, applications, pictures
-- VoodooPad automatically links all of this information together to form
a World Wide Web on your desktop. Plus you can export this information
in a variety of ways, including to your iPod.
Gus Mueller entered his application in the first Mac OS X Innovators
Contest, and although it made the final cut, it did not win. He continued
to improve the application -- adding the export-to-iPod functionality,
for example -- and entered it again in the second round. This time, he
hit pay dirt and won the U.S. category.
Unlike some of the other winners I've recently interviewed, who
birthed their applications in a collaborative environment (such as the
creators of Audio
Hijack Pro and Hydra),
Mueller did most of the heavy lifting on his own. So it goes to prove
that there's no one best way to build an award-winning application.
Here's the approach Gus Mueller took for creating and distributing VoodooPad.
Derrick Story: So Gus, how's VoodooPad doing? What kind of feedback
are you getting?
Gus Mueller: VoodooPad is doing really well -- I'm working right
now on the first beta for 1.1, where I'm adding a handful of new features,
including the ability to edit a custom "remote wiki." The feedback I've
been given has been excellent -- everyone who has written me has had good
comments about VoodooPad and great ideas that they would like to see added.
Almost too many good ideas -- I find myself adding things that I really
should push off for a later release just because I'd like to use those
features today :)
DS: When did the lightning bolt of inspiration first strike about
your award-winning idea? Was it in the shower, on a walk, during conversation ...?
GM:I began work on VoodooPad last January, I think -- I don't remember
the exact moment when, but I remember why. I had been using my own web-based wiki for years to keep track of information that I needed access
to between home and work. However, I thought it was horrible to have
to type all of the information into a browser. Doing it that way wasn't very
intuitive, and it definitely wasn't Mac-like. So I figured a desktop
application would work better, especially if it supported drag-and-drop
and had key commands.
DS: Then what did you do? Work up a prototype, get some help,
let it ferment? How much time passed between when you had the initial
inspiration and the first working prototype?
GM: I think the general idea had been brewing for a little while,
but it probably only took a couple of hours from when I sat down to
actually do it until I got a quick prototype. Usually when I have an
idea, I start a new project right away and begin hacking it out. Most
of the time the only purpose of the project is to see if I can do something,
so they usually just get thrown away or sit there forever without me
touching them again. With VoodooPad, I found that this was an application
that I had been wanting to have for a while, and I became its first
VoodooPad wasn't the only mountain that Gus Mueller
DS: Do you have a mentor? Or maybe someone who helped you overcome
the technical hurdles involved with bringing your idea to life? Tell
us about that person and his/her role.
GM: I didn't really have a technical mentor, unless you count
the Cocoa mailing lists as one :) I did however have one person who
gave me some really good feedback when I asked for it, which was just
as important. My friend Joe Heck is awesome at testing applications --
I sent a little note to him to try out VoodooPad so he could let me
know what he thought. He sent back a huge email with bugs and suggestions
and screen shots pointing out problems -- which was a big kick in the
pants I needed. I knew that there was going to be some hard work involved,
but his reports really opened my eyes as to how much.
DS: How many people did you tell about your idea during the development
phase? Was this something you kept under your hat, or did the Mac community
at large know you were working on this?
GM: I put it out into the wild right away for people to use, once
it was stable enough. This had its good points and bad points. The good
was that people would try it out and let me know about problems that
I had not yet discovered. More importantly, they gave me ideas that
I could put in to the application. The bad was that there were still
bugs in the app that people found, and I continuously worried that
VoodooPad might be building up a bad reputation. Was it going to be
known as a buggy application, or would people change their perception
of it as I worked the kinks out?
DS: That's interesting. Now that you have a version out that you
feel confident about, what do you think about this approach? Would you
do it the same way again? Or next time would you hold on to the app
a while longer before the beta release?
GM: I think it was/is a pretty good approach for this application.
Putting out semi-frequent releases during development forced me to make
sure everything was working like it should. Question #5 of the Joel
Test is "Do you fix bugs before writing new code?" I think it's
a really good question to ask, so I would try my best to fix all of the
bugs that I knew about before each "alpha release." It may not really
sound like an alpha application that most people are used to, but to
me, it just means that all the major features aren't done yet.
I've got an idea for another application to work on after VoodooPad 1.1.
I think I'll keep quiet about it a while longer than I did for VoodooPad,
mostly so I can compare the differences in development styles. I'll
let you know which I prefer after that one :). Oh -- and just so my customers
don't freak out, I'm not finished with VoodooPad releases. Just take
a look at the feature requests on my flyingmeat.com web site -- I've got
a lot more work, and many more releases after 1.1.
DS: What was harder, developing the application to the point
that it was ready for public consumption, or the "sales, marketing,
distribution" side of the equation?
GM: I think developing the application has been the hardest so
far. There are so many little things to get right and to remember to
do for each release -- and I'm not even done yet! I haven't really done
anything with marketing, although I expect that to be just as hard as
development. I do look forward to that aspect of development, since it'll
be something new for me to learn.
DS: Would you ever consider working in a collaborative environment,
such as the group formed by the Coding Monkeys, or are you more of a
GM: I would definitely consider working in a collaborative environment
for future projects. I've worked on teams before where the momentum
gets going and it doesn't seem like anything can stop it. When I worked
for the central IT group at the University of Missouri at Columbia, I
was working on a project with a group of about five other people doing
something that people told us couldn't be done. We skirted the red tape,
flew by the hurdles, and got the project done, and people loved us for
it. I think when you get a good team of developers that are driven and
focused, you can do anything.
DS: What are the advantages and disadvantages or both approaches,
as you see it?
GM: The advantage of going solo is that I don't have to explain
to anyone but myself what it is that I'm thinking. I can come up with
an idea, and pretty much stay focused on it without any major distractions.
I'm the creator and I have a vision that I don't have to compromise
on. Also, I don't have anyone else to blame when I find a bug. The disadvantages
are that I can suffer from tunnel vision and don't see the obvious things
that need to be added. Export to iPod or HTML? Paste in images? Services
menu? Those were all feature requests, and now in hindsight seem obvious
to me that they needed to be added.
The advantages to a collaborative environment, as I see it, are that you can
spread some of the work around, and maybe get it done faster if everyone
is working in sync. You can have code reviews and have someone point
out a problem that you didn't see -- you won't suffer from tunnel vision
as much. You can slack off a little bit (and let someone else code!)
and not feel as guilty because of the nagging thought that users are
waiting for a release. You can blame your bugs on someone else, too!
Some disadvantages I see are that the programmers' visions might not
always be in sync with each other, and can cause conflict. A good spec
up front could probably resolve that situation. If I were to pick between
going solo and going with a good small team that communicated well with
each other, I would pick the team every time.
DS: What will you do differently, and what will you do the same
on your next big project?
GM: As I mentioned earlier, I think I'll work on my next project
longer before I let people know about it, or at least use it. As far
as the same, I would still have an open beta period, although probably
not as long as it has been for VoodooPad.
DS: What one piece of advice that you've learned during the process
would you pass on to other Mac developers?
GM: Don't underestimate the amount of work that goes into a real
Macintosh application. Or any application, for that matter. I know I
is the author of The Photoshop CS4 Companion for Photographers, The Digital Photography Companion, and Digital Photography Hacks, and coauthor of iPhoto: The Missing Manual, with David Pogue. You can follow him on Twitter or visit www.thedigitalstory.com.
Return to the Mac DevCenter
Return to the Mac Innovators Contest