Peldi
Giacomo 'Peldi' Guilizzoni - photo © Matt Snow
I recently had the opportunity to talk to Giacomo 'Peldi' Guilizzoni -- ex-Macromedia/Adobe software engineer -- about his new company Balsamiq and the hugely popular Balsamiq Mockups application. I've started using Balsamiq Mockups on a number of projects myself and its proven to be a very useful application, definitely worth checking out!

 
How did you get the idea to create Balsamiq Mockups? Was it the type of application you were looking for yourself or noticed a market for?

First off, let me thank you Peter for the opportunity to answer your questions. I have been following your blog for years! :)

I think the idea for Balsamiq Mockups took shape over the years. As a developer, I had to write many feature specifications, and the more I wrote, the more I noticed that the process we followed had many gaps in it which could be improved. For instance, we would always design a feature on a dry-erase whiteboard first. While this had just the right amount of low-fidelity to encourage discussion and iteration, it was also a bit painful: first you had to go around the office stealing markers that worked, then if you needed to stretch a rectangle you had to erase an edge and redraw it further out, and sometimes the end result was so messy that you'd come back to a whiteboard the next day and were unable understand what the heck that mess of lines and squiggles really meant.

The next step in the process is to transform the whiteboard drawing into a digital form. The product manager on the team, who is ultimately responsible for the feature design, usually doesn't know Photoshop or Fireworks, so the job always ends up in the hands of the designer or the developer. The designer will go straight to Photoshop and spend hours and hours making the mockup pixel-perfect, with nice gradients and transparency everywhere. The developer will often code the feature (again, hours and hours) and take a screenshot when done.

Both approaches are bad news, as the initial whiteboard design is almost never the best one. Then the screenshot has to be embedded in the spec somehow (it used to be a painful ftp process until we started using a wiki as intranet).

So then feature review time comes around, and flaws in the design are uncovered. The designer or the developer (or both), having already spent many hours on the initial design, resist making changes. So you end up with a compromise, which in the end means software that's not as good or usable as it could have been. Everyone loses.

Clearly there was a need for a low-fidelity, fast, collaborative, digital wireframing tool. If it was integrated with the wiki, even better.

I didn't really do much market analysis before jumping in, other than a quick Google search for wireframing tools. The few that I found were either too complex or too crappy, and none integrated with wikis, so I saw a spot. I certainly did not expect Mockups to be such a hit, at all. I got lucky!

 
Was it immediately clear you wanted to use Flex and AIR for the application given your background or did you also look at other technologies?

I didn't even consider other technologies. Flex is what I know, and IMHO there's nothing better for writing applications such as Mockups (lots of graphics, not a lot of text). I had written the whiteboard for Macromedia Breeze years ago, so I knew I could write a simple image editor again. Plus I wanted my app to work in the browser (to integrate with our wiki), and Flash is clearly a no brainer in terms of penetration.

The choice to port Mockups to AIR came a bit later, during my private alpha/beta program. I thought of making a Mockups AIR app as the answer to the "what if I'm offline" problem, not as my main money-making application. But lo and behold, lots and lots of people still like to buy and install applications on their desktops...working in the cloud via the browser is still something only a few people do. Plus over time I am starting to think that hybrid, "fit client" applications might be the future...Microsoft's "software+services" mantra might actually be right in the end...we shall see.

 
Clearly Balsamiq Mockups is a great way to work on mockups, how would you compare it to prototyping with lets say Fireworks?

I have to admit that even though Fireworks is my favorite image editing tool, until a few months ago I had no idea you could use pre-made UI symbols to wireframe applications with it - which is bad because it would have saved me a lot of time, and good because I might not have built Mockups had I known... ;)

The problem with Visio, Fireworks and other such tools is that they are designed to let you create ANY kind of diagram or graphic, they are very generic. Mockups' strength comes from its incredibly narrow focus. Take adding a scrollbar to a DataGrid for instance. In Mockups it takes ONE click: the scrollbar is added in the right spot at the right size, and the DataGrid columns shrink a little to make room for it. Try doing that in a generic tool! :)

 
What do you have planned for the future with Balsamiq Mockups? Are you considering adding support for exporting the mockup to MXML or XHTML, collaboration features perhaps?

Let me talk about code generation first: in short, I'm staying as far as possible from it. I save mockups in XML, so theoretically someone could write scripts to transform my markup to MXML or XHTML or whatever, but it's not a problem I am interested in solving, for three reasons: first off, there are far too many languages and frameworks I could export to, and each is constantly evolving (maintaining the exporters would be a huge headache). Second, I think the "from image to code with one click" holy grail might not actually be attainable: do you know any developers who would happily start from automatically generated code? It's like admitting that the machine is better than you! What about dealing with the roundtrip from image to code and back while iterating on both? Ouch. It's a very, very hard problem, which I'll leave to people smarter than me to solve. Third, and most important: I don't think there's a big pain there. Recreating a UI from a low-fidelity mockup is not where the time is wasted. Coming up with the right design (structure), coming up with a beautiful visual design, and then coding it properly are the real time sinks...laying out controls based on a wireframe is easy enough (in Flex Builder, Interface Builder etc).

As for Balsamiq, I have enough work to keep me busy through 2009 at least. I have some client/editor features planned like the ability to link mockups together (help me design it!), adding support for 'Projects' (i.e. groups of related Mockups), and a host of little improvements here and there like the ability to double-click groups in order to edit their contents.

The bulk of the work though will be server-side. I am working on a hosted subscription-based version of Mockups with collaboration features built in. Then I am working on letting users load and save data to the cloud (think Google Docs, Basecamp) from the desktop app (the hybrid approach again), not to mention the 4 or 5 server-side ports of Mockups to other wikis / bug tracking and content management systems that I have in the pipeline.

Overall, 2009 is going to be so much fun, I'm so excited! I have recently hired my first employee (@balsamiqMarco on Twitter) and it's an awesome feeling, we are definitely still in the honeymoon phase and ready to take on the world! ;)

 
How did you experience going from Adobe to your own studio developing your own software? Are there things you learned from the old days as a software engineer, do you think you have a different perspective on software development now?

Everything I know about making software I owe to working at Macromedia and Adobe. Ok, maybe not everything everything, there might be a 10% that came from reading lots of business/software books, but you get the idea. I was so lucky to have so many great mentors there, from Jonathan Gay and Robert Tatsumi to Nigel Pegg, Dennis Griffin and many, many others. If you want to be surrounded by nice, well-rounded people who are smarter than you, go work at Adobe.

The transition from Adobe to Balsamiq was not easy. Macromedia was my first real job after school, and 6.5 years is a long time. Leaving was not easy, at all. I loved my job there and loved the people I was working with, we did great work and I was happy to go to work every day. A big part of the decision to leave was personal, wanting to move back to Italy with my family and our toddler. Starting my own company was my dream since college, so I thought it was a good time to give it a shot. So far, I'm having a blast, I'm loving every little aspect of it, from the coding to the customer support.

I recommend it! :)

 

Posted
AuthorPeter
CategoriesAIR, Interview