Yo Dawg, I herd you like to eat your own dogfood

So we put Quplo in yo Quplo so you can prototype while u prototype.

And so we did.

Being developers, we know the difference between testing your own app and using it and there’s no other way to get that end-user experience than by taking it out for a spin. So, in the best tradition of eating your own dogfood, Rahul set off to build the Quplo marketing site with… Quplo.

The funny thing is that the current version of Quplo is actually built using an earlier version of Quplo. So Rahul is building Quplo using Quplo that was built using Quplo. Yo Dawg, time for a history lesson.

Quplo 1

Around 2006 I rewrote Q42‘s HTML editor, Lime – the Less Is More Editor. It integrated a WYSIWYG client with a proprietary .NET server framework featuring XSLT templating and direct control over pretty URLs. That little framework felt so flexible and eager to break free of Lime that it did just that. Quplo was born, or in retrospective: “Quplo 1″.

Quplo 2

The famous Hello World example in Quplo 2.

As a web development company, we used Quplo for many of our clients, causing it to evolve over time. But somewhere down the road it became this over-the-top do-everything-for-developers framework that none of us had foreseen and some parts just had to go. A rewrite was evident and, a little later, “Quplo 2″ was doing all the good stuff that Quplo 1 did while leaving out what we didn’t want it to do.

Quplo 3

In the meantime, Q42 had grown in number of employees and size of projects. Some of us were using Java Spring more often, ASP.NET MVC was coming out of beta and in order to get everyone at Q42 accustomed to the MVC way of working I set out to create a blend of MVC on one hand, and Quplo’s flexibility and extended use of XSLT (which most of us here have grown to love despite its verbosity) on the other. In early 2009, Quplo 3 saw the light of day.

We used Quplo 3 for only a few clients, and the last project I did with it was a personal one: Sarien.net. But that seemed to be the end of Quplo’s evolution, as Q42 didn’t have the resources to commit to both client projects and product development.

Every now and then some of us used either Quplo 2 or 3 when we wanted to quickly mock up ideas. For us, it was the ideal way to create a playground for HTML, Javascript and CSS without the hassle of setting up environments or overconfiguring XML files for ye-olde-hibernate.

And that’s when it hit us:

Quplo is for prototyping.

HTML prototyping that is.

After all these years of developing websites for clients, we know what a difference HTML makes to a client as opposed to a static visual or click-through wireframe. That’s also the reason why we wrote about how the terms wireframe and prototype tend to be misused and how we think it’s good for all of us to be clear about what apps are designed to do.

Quplo 4

So Quplo used to be a development framework built by a web development company. It took us some time to convince management of how Quplo was going to become a prototyping tool for designers instead of this flexible framework to build actual websites with. Designers you say, not developers? Indeed, not developers. Someone even coined the name QUPAND: QUplo is for Prototyping And Not Development.

Starting off one day a week, Rahul and I set out to build Quplo 4. It was going to be a prototyping framework with flexibility in mind, downloadable as a .msi installer and requiring you to have .NET installed, Visual Studio as your preferred editor and the willingness to undergo the pretty steep learning curve of XSLT and especially the concept of working with a declarative language versus imperative ones.

Summing up the requirements like that makes it seem like a dumb thing to do, but at the time we actually felt that it stood a chance. Quplo 4 was really starting to become a great tool, both technically and, in our opinion, in terms of vision. Our focus on designers as a target audience helped us to say NO to feature requests from our colleagues (who, being developers, suggested features like AppEngine support and SQL database connections and such) .

In the meantime, Q42 had hired a few interaction engineers to flesh out our technical team. The decision to do so was unrelated to Quplo at the time, as Q42 employees have a strong passion for UI from a technical perspective, and we figured that we (and our customers) would benefit from having people with a background in design to spar with us on user interface and web app behaviour. Now Johan, one of the newly hired interaction engineers, dogfooded the new XSLT-based, Visual Studio-requiring Quplo for one of our projects. It was a success. Quplo was used in conjunction with Photoshop and Balsamiq, and all three apps did what they were supposed to:

• Balsamiq gave early insights in what the interface was supposed to be like
• Photoshop helped the visuals to be fleshed out
• Quplo gave the customer the opportunity to try out mocked up functionality inside the browser at an early stage, mimicking a real world situation with browser quirks and differences.

On a side note, the customer signed off on the prototype instead of the static PSDs, which leapfrogged the infamous discussion about how certain fancy borders and other things that Photoshop is so good at look different in IE (6), Chrome, Safari, Firefox or you name it. Websites simply aren’t Photoshop documents, so agreeing to a PSD when the end result is supposed to be HTML just isn’t the brightest of ideas. We can all relate to that, but why is everybody still doing it?

Quplo made it possible for us to work more closely with the client than we ever had, and we hadn’t foreseen this use before. It saved us time, and helped the customer to understand what the website was really going to look like, in part because Johan didn’t just prototype the HTML but polished it to production-quality. It was “just” a matter of developing the website and reusing the HTML and CSS that were built using Quplo.

Since Quplo uses the concepts of layouts, pages and reusable parts to prevent writing redundant HTML, it actually matches the pattern seen in ASP.NET MVC with master pages, views and user controls. The Quplo prototype was being used to finalize the HTML and CSS, and the end result was “handed over” to the rest of the team that had it up and running in ASP.NET the same day.

This experience was extremely valuable, because we were actually using Quplo and not testing it.

Quplo 5

The whole .msi installer thing and XSLT learning curve kept us thinking about how the goal of Quplo felt right, but the means of how we present it to our future audience didn’t. So we had gotten pretty far into Quplo 4 when, one morning, I walked up to Rahul and said:

“Hey Rahul, Quplo is going to be an online service”.

He agreed. Instantly. It just clicked. No convincing was necessary and we started to prototype the online version. Or in other words, we started to prototype Quplo 5 using Quplo 4. Now technically we had to overcome some challenges like building a web-based IDE that had that desktop-quality feeling. But another challenge was to convince management of why Quplo had to go online, and how tough things were going to be when building an online service as opposed to doing projects for customers.

The famous Hello World example in Quplo.

You’ve probably figured out that management was convinced. Actually, we had them at “Hello”. Quplo taking the shape of an online prototyping service was the obvious thing to do, and as I write this we are on the verge of sending out the first bunch of invitation emails to our early beta testers. If you want to be one of them you can still sign up for the preview.

Finally, we really feel that Quplo is here to stay, and that it can really be helpful to you if you are involved in the web design or web development process.

Right now, it’s up to us to build the promotional website that explains all the above in catchier phrases and fewer paragraphs (yes, my apologies for the huge blog post). It’s great to eat our own dogfood by building this promo site for Quplo… using Quplo.

Quplo 5 that is