Balsamiq

New Keyboard Shortcuts Cheat Sheet

We've updated the Mockups Keyboard Shortcuts cheat sheet to reflect new shortcuts in 2.2.

You can view the HTML table or download the printable PDF here.

Preview the Mockups application chrome redesign

Hi, everyone. This year we're working on some projects to polish Mockups, and we want to give you a preview of one of them—the redesign of the application interface or app chrome.

Application chrome refers to the user interface elements of the application window outside of the canvas. This includes such things as the menu bars, toolbars, progress bars, ui library browser, dialogs, and inspectors. Essentially what we're doing is polishing the design of Mockups itself.

With the release of myBalsamiq, we've started introducing some new interface elements in the app, especially the app bar. The chrome design hasn't changed much since Mockups was released, but with myBalsamiq, the accretion of elements has become noticable, and the changes more drastic. We wanted to refine this area, see what could be cleaned up or removed, and prepare for the future.

Goals

Now is the right time to focus on these:

• Fix usability issues related to visual design (contrast of scrollbars, for example).
• Making the myBalsamiq editor chrome match the design of the html views.
• Create a coherent design language and style that works across the Desktop, myBalsamiq, and plugin versions.
• Create an aesthetically pleasing experience that we want to look at every day.
• Prepare for desktop/myBalsamiq integration, and Mockups for Desktop Pro(jects).

On the surface you might say it's just a re-skinning of the chrome, and you'd be right. We're starting by cleaning up the current functionality.

If you look closely at the design for mybalsamiq you'll also see that the interface includes a project (and symbol library) browser sidebar. As we move towards our goal of bridging Desktop and myBalsamiq, some of the design elements of the myBalsamiq editor will make it to the Desktop app.

Preview

Here are some design comps of what we've started implementing. Click to view larger.

Desktop App Preview

myBalsamiq App

Interface elements
For the documentation fans out there, here's a closer look at some of the design elements.

That's a quick preview at where we're headed. We hope you'll agree that the direction we're taking is a sensible one at this time. As always, we welcome your feedback with open eyes and ears. Leave a comment or email me at mike@balsamiq.com.

We know we have a long way to go. Every day we take another step.

You can try the pre-release here on the web or download the latest 2.2 candidate here. Bookmark that page and check it daily! ;)

Mocking up physical objects

Who says Mockups is only made for interface design? Tennis player and Balsamiq friend, Gabriel Coch posted some great images of a cool chair made from recycled tennis balls.

Here's the concept he illustrated in Mockups.

And the finished product.

Looks pretty darned comfortable too! Love it, Gabe!

Balsamiq Interview on IATV

We took some time out to talk to Jan Jursa on the IATV podcast. Peldi, Jan, and I discussed Mockups and myBalsamiq, wireframes and prototyping, and what's happening right now with our little company.

You can listen to the podcast at IATV Radio. It's Show 6 recorded on Feb 19, 2012. Our interview starts at 16:05.

Test the Custom Icons Feature

We've had a lot of people request a custom icons feature in the past. People want to add their own icons to the app and have them appear when placing icons on the canvas.

With Mims Wright stepping in for some Mockups development, we've added this feature to the pre-release version of Mockups and are looking for some users to give it a try. We've updated the Icons Documentation to reflect this coming change.

Note: This feature is only available in pre-release version at the moment, and requires you that you use the pre-release to test this out.

Quick Start

Now when you add an icon, you'll see 2 new tabs for Account Assets and Project Assets (if you're working on a saved file).

If you select one of the tabs, you'll see an Add (+) icon. Click it and an image dialog will open so you can add icons individually.

Now when you add an icon, you'll see your custom icons in the tab you've added them to.

Front-Loading Your Icons

There's a method for power-users who want to front-load the app with all of their custom icons, by saving filenames starting with icon_ to either the account assets or project assets folders.

I did this on my Mac by downloading the free 32x32px Doodlekit icons, ran them through the free NameChanger app to prepend files with icon_, and moved them to my Balsamiq Mockups/assets folder. They now appear in my icon dialog like this:

The words you use in your filename after icon_ are used as the searchable keywords in the icon dialog. So the example above shows airplane because the filename is icon_airplane.png. You can string together a few labels to get synonyms in there, e.g. if the file is named icon_bag briefcase portfolio.png, all of those words after icon_ will be searchable.

The Steedicons also look like a perfect complement to the rough, thick style of Mockups. This blog entry at tipsblogger lists some more hand drawn icon sets that might be useful for this feature.

Send Us Your Feedback!

We're looking for your feedback and any bug reports. Play with it and let us know what you think.

If you want to try the pre-release, you can install it here:

http://balsamiq.com/products/mockups/next

After you've played with it, if you want to roll back to the stable release, simply go to the download page and re-install using the Update button here:

http://balsamiq.com/download

Thanks!

Mockups font takes it first steps

The first version of the Mockups font is now out in 2.1, and I think we have a good start at eliminating the clipping issues we had using Comic Sans on Windows and Chalkboard on the Mac. In case you missed it, you may want to check out the Font FAQ before you decide to update to 2.1.x.

We still have a long way to go, and have a good to do list for things that need improvement. Some characters are rendering poorly below 12pt, our kerning pair metrics are not quite functional in the app, and the baselines are still a little off. We're also missing a few unicode characters that I'm going to add. We'll continue to improve it with incremental releases.

For people looking for a way to get special characters into the app, I created a Mockups Glyph Viewer showing all the glyphs the Mockups font supports in Mockups 2.1 and later. The Mockups glyph viewer is only viewable on Webkit/Safari 3.1 or greater, Google Chrome 4 or greater, Firefox 3.5 or greater, IE4 or greater, and Opera 10 or greater. You can copy / paste characters from that page and insert into a text control in the app.

Again the link to view the glyph viewer is here: http://balsamiq.com/support/font/glyph-viewer

More to come.

Why We Aren't Doing Interaction in Mockups

Opinions matter

Every so often we'll get a request to add features that would change Mockups from a sketchy wireframing tool to a prototyping tool. When these requests bubble up, I take the time to explain to people what Mockups was designed for, and often point them to our Manifesto, which discusses this and other beliefs we hold as a company.

We have a tutorial that illustrates various methods for designing for interaction, and shows where Mockups fits into this picture. It sometimes helps to share this, because occasionally I'll discover that the person asking is not aware of these methods for specifying interaction. More often than not, they're satisfied to have this information.

Mockups is primarily an application for describing interactive behaviors with static pictures, and this statement doesn't always sit well with people who believe that deliverables have to come very close to the real product in order to communicate the design. We have a different opinion.

The debate: sketching vs. prototyping

There are arguments on either side of the debate about whether or not you have to use interactive prototypes to describe interactive behaviors. On the prototyping side, the argument is that you can't communicate interaction without working prototypes that resemble the real thing. But animators and film makers have communicated motion with static drawings for as long as these media have existed, and at least in early-stage ideation, many still do. The same holds true for designing interaction.

Probably the most important reason we stick to this mode of design early on, using sketch-style static documents, is that doing so keeps us focussed on exploring ideas until the right design emerges from the volume of alternatives we consider.

BIll Buxton makes another point about the value of early-stage, low-fidelity design in Sketching the User Experience. Buxton believes that iterative sketching has a dramatic impact on risk, exploration and innovation.

"Jumping in and immediately starting to build the product, even if it does get completed and ship, is almost guaranteed to produce a mediocre product in which there is little innovation or market differentiation. When you have only one kick at the can, the behaviour of the entire team and process is as predictable as it will be pedestrian."

We believe this. Moreover, as a small business, it's of utmost importance to us to find the right design early. Selecting a wrong design that we would need to pivot on later could cost us and our customers in time to ship, in usability, and worse of all, relevance.

There is no silver bullet

I watched and participated in theoretical discussions about what the "ultimate IA/IXD tool" could look like on IA mailing lists. A lot of that discussion ended up with people going in separate directions:

• sticking to wireframing in graphics tools
• doing full-on prototyping with heavier graphics tools
• using some hybrid and manual approach: focus on ideation and then jump to building/prototyping in the medium of intended use (html, flash, etc.)
• wireframing and prototyping purely with HTML (manually or using an MVC framework)

Mockups undercut the different approaches that evolved out of that time by focussing on one thing, suggesting that you don't need to do it all in one tool. Instead Mockups focuses on sketchy wireframing and at most, static click-throughs. I saw it as a logical evolution of tools like Denim, rather than a continuation of the process past wireframing. Your use of Mockups should end when UI decisions are selected, so you can build.

I was one of those people who clamored for a holy grail UI design and prototyping tool for designers. But looking back, I was the first to jump ship after trying different prototyping tools. They depended more on spending time learning to use the tools and less on producing more ideas.

I felt like there was a possibility of using these tools, but in all of my attempts, what worked for me was to build my own tool from frameworks to do HTML prototyping. That approach seemed fine, but in the end I abandoned it, because I found that I was faster at sketching and wireframing. It was back to pen, paper, and wireframes. Then Mockups came along.

I want to focus on ideas, not design artifacts. Can interactive design be demonstrated more effectively with interaction? That depends on a lot of things. I think the better question is, for exploring design ideas and finding the right solution, is interactive prototyping necessary?

Why we aren't designing Mockups for rich prototyping

We in no way underestimate the value of prototyping. We also do not want to go there with Mockups for now. I'm taking the time to explain why because I take this issue seriously, and I sympathize with the desire for interaction in the app. I also apologize because I know what I say doesn't get you what you're asking for, if you're asking for interaction right now. But I have to tell you, that once I gave up on the idea of being able to both wireframe and prototype in one tool, I felt more free as a designer, and am able to work faster and smarter.

Having used it for a few solid years now, I think we're doing the right thing in keeping rich interaction out for now. I don't think we're precluded from going there some day, but Peldi's vision is clear, I support it, and I agree with the reasoning behind it.

As an early user, I asked for interactive features because I was used to working in separate modes to design, specify, and prototype: sketching, wireframing, and building. I wished for a way to move more fluidly between each mode. What I never stopped to ask was, "why?" Why do I need interaction for exploring design ideas? The answer is that I don't. Now I strongly believe that having it all in one tool comes at a cost in terms of complexity. I don't want to incur that cost, and that's one good reason to keep Mockups from going there.

We believe Mockups is effective as it is because rough and simple sketches are great for generating ideas. We don't want to compromise the application with features outside of that main purpose.

More is less

With each new feature that is added below the surface of our application, the iceberg gets heavier. My main concern having used many complex prototyping tools out there was that if I didn't get it in 10-15 minutes of use, I had to read the manual. Once I had, I thought, "Why would I want to invest myself in doing this?" To me, it's bad enough that I can't just tell someone what to build by just sketching on paper.

Mockups cannot turn into a knob-heavy surface, like an airplane dashboard. Can we design it more elegantly to stick with the zen-like approach of working on one thing at a time that characterizes Mockups now? Probably. But now is not the time for us to even consider going down that path.

I've been told in certain situations, that interaction is the pitch. It depends on who the audience for the design document is. In some cases, I know it's hard to sell what people can't try or can't see. But for many people out there, there are ways to make that pitch creatively without compromising your project.

Will it benefit you for Mockups to become a heavier piece of software rather than a focussed experience? I don't think so. We have a vision to keep it as simple as possible now. We still have a long way to get there. We have bugs to kill, we have problems to fix. These, in my opinion are way higher up the list than demonstrating state changes at this phase of design communication.

This debate will go on, but that's what debates are for. In the end we want to build, and if we get to the end goal of making Mockups what we consider a polished tool and the ideal experience to match with the vision in Peldi's manifesto, I think we'll be in a better position to see where to go next.

Do what works for you

There are many ways to communicate design. There is no right or wrong way. We say, ignore anyone who says that your method is wrong. We've heard arguments on either side of the wireframe vs. prototype argument repeatedly. We won't try to sell you on our side, we'll just tell you what our opinion is, because we believe in it strongly.

We would never make absolute claims about what's right versus what's wrong. There is room in the world for many points of view. We think you need to do what works for you, and if your opinion differs from ours, we'll point you to software that fits with yours. We do have a strong point of view, however, that is based on the belief that early-stage ideation is effective at low-fidelity, and that is represented in our product.

Speed Wireframing a Click-Through Prototype using Symbols

There's so many ways to use Mockups. I rarely do click-through prototypes, but if I have to, then I count on Symbols and links to make it painless.

This speed-wireframing video shows you how to:

1. set up a menu (linkbar in this example) and create a symbol from it
2. place instances of the symbol in all of a project's wireframes
3. override the symbol instances to show selected link
4. edit the original symbol to set the links and update all the instances
5. and then demonstrate it

It's quick and easy. Want to know more about how to do it? Ask us!

New Tutorial on Specifying Interaction with Mockups

We've aded a new tutorial in the support section to suggest some best practices for specifying interaction using Mockups.

Software designers and developers designing for the screen have an arsenal of well-known practices for communicating interaction in static documents. Many of the techniques have been borrowed and adapted from motion designers, filmmakers, and animators.

Read the tutorial to learn more about doing interaction design with Mockups.

Tip: Adding color to components with no text color property

Mockups can seem like an iceberg. There's so much beneath the surface in terms of advanced features. The features that seem to be hidden are learnable, but we don't surface them until you are ready to use them.

The app is designed this way on purpose to make only the properties available that are necessary for quick ideation. This tool is made for low-fidelity, and we're trying to protect designers, ourselves included, from getting precious. We believe that giving you fewer choices when you're ideating lets you focus on the ideas rather than the presentation, so the necessary attributes are properties, and sometimes the optional ones are available if you know how to use them.

One typical component that we hide text color properties on is the Arrow / Line component. Labeling is an option and most likely rarely used by the majority of our users. But if you wanted to color the text, all you would need to do is add the color macro to the input. So for red, use the hexadecimal color value #f0000 like so:

{color:#ff0000}text{color}

Let's look at that a little more closely:

There are other text formatting rules you can learn by checking out the Basic Text Formatting section of our documentation.