Wednesday, December 13, 2006
Are you planning on doing a public beta for T2 by the way?
Let's start with some history... I got the idea for Bee Docs' Timeline from a Mac Lawyer discussion group that I was hanging out on about 2 or 3 years ago. I decided to take on the project, spent a few days drawing timelines in Adobe Illustrator and two weeks later, released my first beta of Bee Docs' Timeline.
For the first beta (which was an extremely rough version), I only invited people from the Mac Law discussion group to participate. They gave me their e-mail address if they wanted to join and each and every Friday I released a new and improved version to the beta group.
As the software reached my own milestones of stability and functionality I expanded the invitation to more and more people. Eventually I sent out press releases telling people about the beta. When the software was about a month away from its final release, I no longer required that people sign up for my e-mail list, instead anyone could download the beta from my website or sites like version tracker.
Bee Docs' Timeline was in pre-1.0 development for about 6 months and by the end of it I had several hundred people on the e-mail list and hundreds more who downloaded it without officially signing up. Each week's release generated dozens of e-mail suggestions and bug reports. The process was lots of fun and highly collaborative.
For T2, I also want to involve customers in the creation process but I want to try something new. One thing that is different is that I now know, based on hundreds of customer e-mails, phone calls and blogs, what people as a whole would like to do with Bee Docs' Timeline that they can't do now. I also know which of those things I am going to tackle in T2. The trick to T2 is going to be how to provide the new functionality while increasing ease of use, which everyone wants but nobody every asks for (especially those who try the demo and don't end up buying).
I'm also dividing my time differently with T2. Instead of doing design, development, and testing on a weekly iteration, I am slowing the cycle down. I am doing most of the design up front this time. This allows me to focus on the integration between all the new features. It also gives Apple time to stabilize Leopard before I get too deep in coding. It may also allow me to hire outside help for some aspects of the development.
Consider this blog the first part of the process. I'm tossing out ideas here about basic design, features, pricing structure, beta, icons, etc... The reason I am doing that is so that I can get feedback.
I'm a little concerned about other developers copying my design ideas, so I'm being a guarded about some of the design specifics. I'd rather be completely open, even to a very detailed level. So, I'm thinking of starting a separate private blog that I could invite select customers to join and provide design feedback. It wouldn't be for people to tell me everything they've always wanted but rather for things like "Out of these two alternatives, which do you think would be the easiest method to add a new event" or "In which menu would you expect to find the event import feature?" The private blog would be invite only and I would want those invited to commit to regular participation, not just lurking to see what's coming.
After the design is complete. I'll spend a month or two (or three) implementing the design. As soon as it is stable (ie, won't screw up your data or your computer), I'll release it for other folks to try. Probably the private blog readers first and then expanding the circle of users like I did in the 1.0 beta. There will likely be a month or two of polishing the application while there is a public beta before the commercial release. There will likely also be some polishing after the public release in the form of point releases too.
To the readers of this blog, please let me know what you think of this plan. If you agree that this is a good strategy, I'll work out a process for choosing the "design team" participants and get it set up right away.