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:
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
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?
VoodooPad is 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 dedicated user.
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 solo developer?
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 did.
Derrick Story 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
Copyright © 2009 O'Reilly Media, Inc.