In Case You Missed It: New Hidden Powers in Balsamiq Mockups 3

Finally getting to work on features that have been on the back-burner forever is a great way to rejuvenate developers and reward long-time customers.

After a slow year of public releases in 2014 while we re-wrote our product from scratch, 2015 and 2016 have been chock-full of updates (4 major releases, 31 minor ones).

I thought it might be useful to recap some recent new features we really enjoy that you might have missed. In this post I'll provide some back-story on the "Quick Draw" and Transform control features from our 3.2 release.

You can see them in action here:

These were ideas that had been in the back of our minds forever that we finally implemented. It felt good to get them out there. Read on for the story behind them.

Background

Anyone who works in software has a list of ideas that start with "wouldn't it be cool if...?" These ideas often take a long time to make their way into the product, if they make it at all. Some possible reasons:

  1. They're just plain hard or time-consuming
  2. Customers aren't actually asking for them, making it hard to justify the work (though they may be complaining about problems that these ideas would solve)
  3. Stability and performance issues and "must have" features take priority

With our 3.0 release, Balsamiq Mockups settled into the usable and useful product that we originally conceived it to be. This freed us up to start working on some exciting "wouldn't it be cool if..." features.

We want to collapse the time between when an idea forms in your head and when you see it on the page.

We use Balsamiq Mockups internally a lot, so we are always looking for faster and more efficient ways to wireframe. Our standard for getting into the flow is paper and pen, after all. Our 3.0 release was designed to be simpler and more powerful. Our 3.x releases have been focused on speed. We want to collapse the time between when an idea forms in your head and when you see it on the page. That's what motivated us to build the following features.

"Quick Draw"

Balsamiq Mockups 3 brought more visibility and simplicity to things like Symbols and assets. But the core workflow of adding controls to the canvas remained similar to previous versions. For a long time we envisioned a workflow that would allow you to build up your wireframes before even having a concrete plan for the UI details.

Starting with an outline

Ideas don't always come fully-formed. We thought about drawing outlines on the canvas, like you would on paper, to create a skeleton for an idea that was still being developed. We already had placeholder controls in the UI Library, such as the rectangle and image controls, and lorem ipsum text in a Text control, but using them still required dragging onto the canvas and then resizing them.

What we really wanted was a way to "draw" directly onto the canvas.

What we really wanted was a way to "draw" directly onto the canvas. We decided right away that freehand drawing with a mouse is non-optimal. It's imprecise and forces you to slow down quite a bit when you do want precision (such as connecting lines to close a gap). So we moved on to click-dragging, holding down the mouse button while dragging (they way you "lasso" multiple controls in many drawing programs, including ours).

After some experimentation and discussion, we decided that holding down a keyboard modifier key while click-dragging was a sufficiently intuitive way to "draw" on the screen. We used the "R" key for drawing a rectangle, the most generic control in our palette.

Better placeholder text

Our next thought was to make it easy to add placeholder text to your mockups using this method. But our existing headline and paragraph controls didn't lend themselves to it well. They were a fixed size and optimized for resizing only after you'd entered text in them. Again, we wanted to quickly be able to add a placeholder without having to think about content.

Our solution was to add two new controls - "Line of Text" and "Block of Text". These were features that had been requested many times over the years. "Greeking" text is often used in wireframing to create placeholder text without using recognizable letters that would distract viewers.

New controls make it easy to show placeholder text

Putting it all together

With these new controls added to our UI Library we could now assign modifier keys to them and allow users to draw them onto the canvas. We used "T" for the block of text and "Y" for the line of text (a.k.a. headline).

Here's what it looks like:

We immediately fell in love with this feature. It felt like something we'd been missing all along. We are always striving to make our tool simpler, more "basic" even, and this felt like a great way to "add less" to our tool (without making it more difficult for people who didn't use it). In other words, it met our criteria for "hidden powers".

Transforming Controls

For speed and efficiency, our new drawing feature had one major drawback. When you decided what to replace the placeholders with, you would have to delete them and re-add specific controls. This was a step in the wrong direction. So we added one other major "wouldn't it be cool if..." feature that had been on our back-burner. One that seemed out of reach at times due to the complexity.

"Wouldn't it be cool if you could swap out one control for another?"

It went something like this: "Wouldn't it be cool if you could swap out one control for another?" A key part of wireframing is iteration: discussion, changing your mind, trying something out to see how it feels. A common example is building a form and then deciding that a text field should be a drop-down box. Not a big deal to delete it and replace it, but across multiple mockups, projects, years, it adds up.

Yes, but how?

But, and here's the tricky part, what should the logic be to transform one control to another? Changing a text input to a combo box? Definitely. A rectangle to an image? Sure. A tree control to a list? Or an accordion? Hmmm...

Peldi likes to say that he loves mundane, repetitive tasks of all kinds. How about mapping each of our 70+ controls to each other one, deciding whether it should be transformable to that control? It required persistence and expert knowledge of the product inside and out, clearly a job for Peldi.

His spreadsheet ended up looking like this:
swap-control-tableA boring chore for an intern? Actually, it was done by our CEO.

With that laborious task complete, we started the work to build it.

Getting it right

In the spirit of "hidden powers," we didn't need it to scream for attention. It's not something you should be distracted by when you're in the flow. So there's no big button in the UI that says "Click Me to Transform!" Just a subtle arrow in the Property Inspector and an item in the right-click menu. There's also a handy keyboard shortcut (CTRL/CMD + T) for when you're ready to start using it regularly.

Check it out:

Finally, we decided that some controls could even transform on their own. Like turning a placeholder text control into a real text control. So, if you type into a block or line of text control it automatically transforms to a paragraph or subtitle control. Neat!

See it here:

Summary

These are two of our favorite recent features, but they're not the only ones that we've added to help you work faster and more efficiently.

In 3.1 we introduced Alternates and Background Music. 3.3 provided the ability to organize mockups into groups, like this:

"Nested" mockups

And we finally made arrows that work the way you expect!

Earlier this year we also added the ability to automatically generate Site Maps based on the mockups in your project. This was another "back-burner" project that we really enjoy using.

Deciding what to work on

One of the hard things about software is that it's never finished. Our 3.0 release felt "complete" yet we knew we could continue making meaningful improvements (not to mention the hundreds of small enhancements and bug fixes). However, we resisted adding features that didn't feel central to the purpose of our product or that would make our product harder to use.

Instead we chose features that we were excited about and that we knew our long-time users and fans would appreciate. Sometimes that's just what feels like the right thing to do. We are grateful to our community of bug reporters, support callers, and forums users who have provided feedback and guidance along the way.

We are now hard at work on another very exciting project, native versions of Balsamiq Mockups! Stay tuned!

How We Got Here: The Road to Balsamiq Mockups 3

The release of Balsamiq Mockups 3 was the biggest release in our history since the original product launch in 2008.

For this release we took a leap of faith and went nearly an entire year without releasing any real product updates (in comparison we released about once a month in 2013). At our annual retreat last year after not releasing any feature updates in nearly six months Peldi had to reassure us that we were still doing the right thing and to stay the course.

And fortunately people were still buying our product.

We also made up for the lack of Mockups for Desktop updates with big improvements to Mockups for Google Drive (yay, Sax!), and lots of updates to myBalsamiq and our website, documentation, and blogs.

This post is all about how we got to Balsamiq Mockups 3. It was a windy, bumpy road, full of changes in direction, fits and starts, delays, and uncertainty about the final product. (So, in other words, a pretty typical software development project.) But when we neared the end it all came together rather beautifully in a way that validated our organic and intuition (rather than market)-driven approach.

2011-2013: Mockups “Pro”

Long before any planning or design started we referred to the next generation of our product internally as “Mockups Pro.” This was convenient because we all agreed that our next major version would be Pro, even though we had different ideas about what “Pro” actually meant. Pro was either an abbreviation for Projects (bundling multiple files and assets into a single project file) or Professional (a separate, more feature-rich version of our product for heavy users) depending on who you talked to.

In late 2013 Peldi decided Balsamiq Mockups version 2 was stable and feature-rich enough to start something new.

Mike had already been working on a UI overhaul as a side project and kicked things off with a comp to give us some inspiration.

The “Pro” idea and Mike’s vision of improving the appearance and standardizing the interaction provided the fertile ground for us to start our next adventure.

We knew that the next version was not just about adding features or a fresh coat of paint.

But we knew that the next version was not just about adding features or a fresh coat of paint. So we began with some important questions that kept us focused throughout the project.

From a wiki page created in 2013:

  1. How we can evolve it [Mockups] without breaking from what’s become “the ethos of Mockups?” There is a definite character we want to hold on to, while maturing it. People want that.
  2. What things should not change on the surface?
  3. What things should not change about the experience?
  4. What things are so effective that they create “Flow” when using the app?
  5. What are the things that contribute to a sense of effortless and ease (and effortless effort), as if “the wireframes just make themselves?”

These questions and some heavy discussions lead us to a set of design principles and the following guidelines for our next project:

  1. Stick to our basic identity (that had made Mockups successful in the first place)
  2. Make it easier to use (especially by reducing friction around pain points)
  3. Introduce professional and power-user features without overwhelming the UI

And, with that, we moved on to…

2013-2014: Mockups 2.5

We knew that before we got any further we had to settle the “Pro” debate once and for all. Should we create two separate versions of our product, one for occasional users and another with more bells and whistles for “professional” users?

We started out thinking that we would. For a long time we maintained a separate feature tracking project for only “Pro” features. It contained every “wouldn’t it be cool if…” big idea that customers and employees had suggested over the years.

But something was holding us back. I think it was more a gut feeling than anything else, largely coming from Peldi and Mike. On a wiki page called “Future of Mockups User Experience” Mike summarized Peldi’s concerns as follows:

Peldi had a simple vision for Standard [the non-Pro version] that he was excited about. He isn’t excited about a tool that essentially comes close in appearance and function to graphic design tools like Photoshop or prototyping tools like Axure.

Clearly a more powerful tool could be both useful and profitable, but was it something we were excited about building? Fortunately, our decision to remain small and independent allowed us to ask this question rather than just thinking about what would bring in the most money.

Then there was this action item further down the page:

Go back from the start and ask “why did we think of doing a Pro version in the first place? What are the things that just don’t belong in Standard? What problem are we trying to solve with Pro?

This question of “what problem are we trying to solve?” has frequently shown us the way in times of indecision. And this time it reminded us that Peldi’s original vision hadn’t really changed - to help rid the world of bad software by allowing anyone to quickly and easily visualize their product ideas.

This question of “what problem are we trying to solve?” has frequently shown us the way in times of indecision.

So we decided to channel our efforts into building an update to Balsamiq Mockups that retained the current core functionality and ease but alleviated pain points and cruft that had accumulated as the product had grown.

The Pro label disappeared and the project was dubbed “Mockups 2.5” (the current version was 2.2) since it felt like a big, but not HUGE (e.g., full of new power-user features) update.

Mike created some quick comps that didn’t look radically different from the existing version at the time, Mockups 2.2.

Our focus narrowed to a few specific targets addressing our customer’s biggest frustrations:

  • Support for bundled project files instead of separate files for each mockup
  • Improve the usability of Symbols
  • Redesign the UI layout for a better editing experience (including figuring out what to do with the floating “property inspector” window/widget/thingy that bugged everyone so much)

We made a list of additional features that we'd then work on in "follow up releases."

After many rounds of iteration we started building it and had a working build ready in a relatively short time.

Here’s an early demo from a test build.

Mockups 2.5 was nearly ready.

But were we?

2014: "Panels" + "BMPR" = "B3"

Indecision returned as we reviewed our concepts and requirements. What should this release include? We discovered that there were so many things that we were excited about building into the product. Auto-save? Yes! Project notes? Yes! Preferences dialog? Still no. JSON instead of XML? Yes! Default font settings? Yes! Trash? You get the picture...

It was starting to sound like a pretty big project. Too big for a “minor” (a.k.a. “dot”) update…?

We left that question alone and went back to something more certain. We knew that we wanted the UI layout to have the mockups on the left, the canvas in the center, and the UI Library and Properties on the right. So we just started calling what we were working on Panels because of the UI “panels” on the left and right.

Our high-fidelity "vision" comps gave way to detailed high- and low-level wireframes describing interactions, flows, and layout as we fleshed out more details.

Peldi created a video walkthrough of some of his mockups for the Panels UI.

Notice how effective a simple click-through wireframe deck can be when accompanied by someone walking you through it? This is an example of the design workflow we promote. We generally don't see the need to create high-fidelity, fully interactive prototypes to convey our ideas and this project was no exception.

We generally don't see the need to create high-fidelity, fully interactive prototypes to convey our ideas and this project was no exception.

Peldi, Andrea and Michele were also deep into cleaning up the code at this point, looking at everything we had written in the last 7 years. They consolidated, removed and beautified code until it was actually readable and much more efficient. The clean slate gave us the energy to think more ambitiously about both the back end and front end.

This included a rewrite of our file format to accommodate the exciting new things we wanted to add. Marco and Paolo were borrowed from other projects to help. This spawned architecture diagrams, flow charts, and developer mini-retreats. Meanwhile, the UX team was discussing the toolbars, menus, icons, etc...

Finally, near the end of 2014 we started playing with test builds and trying it out internally. We called it "B3" (for Balsamiq 3). We'd talked about dropping "Mockups" from the product name for a while, since nearly all of our customers just called it "Balsamiq." Plus, what it creates are more accurately called wireframes than mockups. But it turned out to be a pain to change the name for a variety of reasons, so we called it Balsamiq Mockups 3. Although now we were more relaxed about just calling it Balsamiq in conversation. 😉

Late 2014: Ready for Feedback

We all felt that we had built something that was both more powerful and more elegant than the current version of Mockups. But we had no clue if our customers would feel the same way. It wasn't only a question of would they like it, but would they like it enough to switch, which would include learning some new things and, not insignificantly, converting their old files by importing them to the new format.

As we had done in the past we reached out to some of our long-time champions and friends for a closed beta test. We also conducted a formal usability test with help from Mike Heraghty at User Journeys. This uncovered a lot of technical and usability bugs and gave us some great qualitative feedback, including what to expect from people’s first impressions.

After a few more rounds of fixes and tweaks we felt like it was ready for a bigger test. On February 2nd, 2015 we announced the public beta and opened up our new community forums to talk about it.

While it was hard to take some of the tough feedback, the overall feeling of connecting and communicating directly with customers was energizing. For the old-timers at Balsamiq it took us back to the early days in the GetSatisfaction forums around version 1.

And the public beta lead to some great improvements in a short amount of time.

For example, the UI Library and Properties panel sharing the same space that we thought was so clever? It turned out that our customers didn’t agree. So we moved the UI Library back to the top.

Other notable additions during the public beta were Font Awesome icons and the Project Information panel, which included highly-requested settings for changing the default font and selection color.

Releasing without beta testing first would have been a disaster.

We are so grateful to all of our beta testers for their time and patience. Releasing without beta testing first would have been a disaster and we feel so fortunate to have customers who wanted to help us make our product better.

Release!

March 10th, 2015: Release day! There were some hiccups, as expected, but it generally went very smoothly. And we had all-hands on deck to respond to issues that showed up upon releasing to a broader group of users. Two weeks later we released an update addressing most of them, followed by three more updates over the next few weeks.

Less than two months after the official release, we don’t know whether Balsamiq Mockups 3 will be a success for us. We know that we enjoy using it ourselves and that many of our customers do too. But we are hopeful because we followed a process that has worked for us in the past: a mix of passion, focus and openness that feels intuitively right to us.

If I had to distill from this entire process a few lessons we’ve learned from building this and other products it would be these:

  1. Build something you’re excited about
  2. Define the problem you’re trying to solve early on
  3. Involve your customers in a meaningful way at some point in the process

We’ve come a long way since 2.0. Thanks SO MUCH to all of our loyal (and new!) customers. We want Balsamiq Mockups to be a product that you love to use, so please let us know what we can do to make it even better!

- Leon for the Balsamiq Team

We're thinking of making geometric shapes non-markup. What do you think?

UPDATE: We've implemented this change. Thanks to everyone for the feedback!

We're thinking of making a potentially big change to the Geometric Shape controls to make them not markup items. We wanted to discuss the change and get your feedback before we do.

About Markup

As you may know, Markup controls are a special kind of control that can be toggled to be visible or hidden. Things like callouts, sticky notes, and geometric shapes can be used to annotate your Mockups wireframes, and then hidden so that you can focus on your wireframe when your designing or demonstrating.

About Geometric Shapes

Geometric shapes were originally created to offer people controls that can be used for flow charting, and after discussion in the forum, ended up as Markup items when it was implemented. Now, however, we're beginning to think that they shouldn't be.

Why the change?

Many people use geometric shapes to create controls or other design elements, and in these cases, we don't think of them as markup items--the kind used in flow charts.

One type of issue that we see in our support forums every now and then is that people will open Mockups and it will appear that some of their controls have disappeared. This is because they're using geometric shapes as I describe above.

The fix is to toggle Markup items on via the menu View > Show Markup, or using the Show/Hide Markup icon in the upper right corner. Once you learn that they're markup items, you know this, but we feel it's confusing if you have to learn that.

We think now it makes more sense for geometric shapes to be non-markup controls and here's why:

  1. Flow charts have a right to exist without being invisible if they're created on Mockups, don't they. Why would you want flow charts hidden? We don't really remember the argument that called for it.
  2. The "my controls disappeared" problem report usually has to do with geometric shapes being hidden when "Show markup" is not checked. Making them non-markup controls fixes this.
  3. Judging from problem reports mentioned in #2 above, it seems that a significant number of users have become accustomed to using geometric shapes to supplement the UI library controls. My guess is that more people use geometric shapes for design than use Mockups for flow charting.

How are you using Geometric Shapes?

If you have a compelling use case that describes why you would want geom shapes to be markup by default, please tell us now. We think this is the right direction to be going, and will make fewer problems and less confusion. What do you think?