I’m sure at least a few people have been wondering where we’ve been the last few weeks. We’ve been busy on a number of products, and we released one of them at the end of June. It’s called Clickframes,  and it’s a set of frameworks for building usable, reliable, scalable software faster, better and cheaper.  The original Clickframes concept was based on three observations:

• Good software requirements can be very useful.
• Most software requirements aren’t very good.
• Even when requirements are well thought out, they’re generally created in a format that limits their usefulness.

At ISG, we develop software using a design methodology that focuses on understanding user needs through interviews, observations and deep research. We learn as much about the problem space up-front, do as much work as possible to validate our designs with real users, and only then proceed with the implementation.  This approach works very well for us (and the one time we allowed ourselves to be persuaded to approach a problem differently the results were a lot more typical for the industry), but it requires a lot of agility. Clickframes helps give us that agility by turning static software requirements into a dynamic specification of how the application should work.

Here’s how it works: at some point during the design process we start building an application specification (or “appspec”), which is a description of the web application we want to build. The early iterations can be very schematic – identifying a couple of pages, perhaps a form or two, and a few buttons. As we learn more about the application we can extend the appspec to include additional detail, including specific requirements, security, and flows between different pages in the application.

That’s actually all pretty standard, so here’s where things get a little different. The appspec isn’t a Microsoft Word document, or a stack of index cards, or a drawing on a wall. It’s an XML file, and it’s maintained by the application’s lead designer. By managing requirements in XML, we can generate a whole range of useful artifacts on the fly. The most important is the Clickframes Interactive Preview (click the link for a sample from our Issue Tracker demo), which provides an easy to navigate HTML representation of the application. As requirements change the CLIPs can be easily regenerated. Clickframes also provides generators for conventional requirements documents (the system shall…) and a visualization tool that generates interaction maps of the application. Here’s the Issue Tracker example, generated from the same appspec as the CLIPs linked to above:

Once the design stabilizes, we move on to implementing the software itself. Clickframes helps here too. We’ve built code generators for three different web architectures – PHP, JBoss Seam, and Spring WebFlow (the latter two, for the non-technical reader who has stuck it out this far, are Enterprise Java platforms, and the first is a very common scripting language for web applications). This is an area where conventional prototyping tools break down – they don’t provide a bridge to development.  With Clickframes, the plugins give us a skeleton of the application immediately, and our developers and designers can go in and immediately start creating content and the final look and feel, rather than worrying about details like implementing edit checks on form fields.  If you want to see the Clickframes Issue Tracker demo, just click on the link (to log in, enter anything for the username and password).  This isn’t a complete application, by the way – it’s just the generated code, before being customized by a programmer.

We’ve spent a lot of time on the Clickframes code generators and on the architecture of the underlying applications. We’ve implemented a range of features we call “CodeSync” that allow us to regenerate applications even after the development team has started to customize them. This is critically important, because it keeps the requirements from becoming out of date. If a business user, or a a designer, wants a change made, they can have the appspec updated and the programmer can re-run the code generator. It creates a feedback loop that’s often missing.

The final step in the Clickframes project lifecyle is testing. Since we have a version of the software requirements that a computer can understand, we can use it to generate a suite of automated tests, as well as templates for test strategies and manual test scripts. It’s not magic – the quality assurance team still has to do some work, and we can’t automatically generate every single test, but we can save a tremendous amount of up-front work. And developers can have access to automated tests of the final application almost from the first day of development. It saves a tremendous amount of time.

Clickframes is software to streamline development of enterprise applications.  So how much would you pay? Don’t answer, because it’s free – we’re releasing Clickframes as Open Source Software under the LGPL.  You can download Preview Release 1, sign up for the mailing lists, and see some demo screencasts at www.clickframes.org, and you can find a lot of documentation on The Clickframes Wiki, including instructions on how to get started without downloading anything.  The Preview Release is out there to gather feedback – we’ll be releasing new versions at a pretty rapid clip over the next two months, with a goal of 1.0 by the end of the summer. We’re also rolling out some new web site features in July that will make it easier to explore the Clickframes model.

This has been a long road for all of us – we started working on Clickframes back in May of 2008, so it’s been over a year to get to this point. So give it a try and let us know what you think!

(And if you like it, or like what we build, give us a call – we’re always looking for interesting new projects).