We’re kicking off a new project today. Starting from scratch, we’re going to build a small web application and document it in real time. Typically, the development of new products start out in a bubble, but the goal of this project is to keep everything out in the open- from the ideas to the code to the mistakes and issues along the way.
Our intentions are to offer a behind-the-scenes look at our own way of doing things and to allow anyone interested to take part and contribute. It can be an opinion, suggestion, idea or scathing criticism of our approach. Hopefully it’ll be an interesting process, perhaps even insightful (for you and us.)
So what’s the big idea?
Often it seems that trying to nail down a grand vision right from the start leads to a never-ending cycle of pampering an idea, which never actually leads to anything real. Ze Frank aptly called this “brain crack” and sang a song about it (with lots of profanity, so it’s probably not a good idea to blast your speakers if you’re at work.)
With that said, we still want to set out in a reasonably good direction. We haven’t firmly decided on anything yet but we do have a few ideas that we’d like to share.
Our ideas revolve around the problems and difficulties of showing off how a web application actually works. With Scopings, our own product, we usually do one of three things. We give a live demo using an online meeting tool (GoToMeeting), point people to the section of the site that details the features, or offer login credentials to a demo account.
An online meeting requires scheduling (and re-scheduling), which takes up a lot of time. You can fit more of these in a day than in-person demos but you’re still limited to a handful. It’s also really hard to gauge the difference between genuine interest and politeness over the phone.
Summaries, graphs and lists of features are always pretty drab. Everyone wants to see the application in action (otherwise it’s still only smoke and mirrors.) That’s what makes demo accounts great but the problem is that there’s no tour guide. It makes a user need to do some work- to figure out where to click, what to look at, and think about what exactly is going on.
The fourth option (which we don’t have for Scopings) is a screencast- a video walk-through of the application. Creating a screencast is no small task, especially to make a good one. Many are pretty awful because they’re limited by their very nature. They’re in a small box, force you to watch from start to end and still don’t let you interact with the actual application.
So what’s a better approach? We’re not entirely sure yet but here’s a few of our ideas:
- A guided tour of the actual application that’s interactive (almost like a Choose-Your-Own-Adventure book.) No smoke and mirrors!
- A simple way to record the tour that simultaneously creates a great demo and a series of how-to’s.
- Plus a live version, so that you can see exactly what a user’s looking at, point out things on the page and have a quick chat if they need some more help not covered by the how-to’s.
So what’s next?
We’ll need to decide on a direction first (which can be entirely different than what’s described in the previous section.) Next, we’ll begin structuring the project- all of the bits needed to follow along and contribute to the vision, design, mockups, code and the discussions/debates that inevitably arise with any project. (For example, the first would probably be about whether or not the entire project should be open source.)
So chime in if you have an idea or want to be a contributor or want to define what exactly an official contributor would do. We’re open to everything and we’re going to keep the whole process open. Get in touch any way you prefer- , phone or comment. We’d love to chat.
( if you’d like to receive our email updates too.)