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:
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.
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.
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?
We sometimes get asked for downloadable versions of our Mockups documentation to go along with the online version we publish on our support site. We now publish the Mockups Docs in PDF, and additionally in the ebook reader formats EPUB (for iBooks) and MOBI (for Kindle). It's nothing fancy, just a version of our Documentation that was prepared in Apple iWork's Pages.app, and exported in all of these formats.
Since we took the time to figure out how to do this, we thought other small companies who may want to do the same may save some time by seeing the notes we took when we set up our templates and migrated our content. These steps are only useful if you're using a Mac, obviously.
Download our eBook
If you want to get an idea of what we've published, you can download the eBook for the Mockups for Desktop Documentation in the following formats.
EPUB
For iBooks app for iPad, and other ebook readers that support the EPUB format.
MOBI
For Amazon Kindle and other eBook readers that support the MOBI format.
Notes about downloading
Instructions for installing the EPUB and MOBI files vary depending on your device.
iPad: On iOS 5+ iPads, press the links to open, and you'll be prompted to Open in... the appropriate app (EPUB for iBooks and MOBI for Kindle).
Kindle: On Kindle devices, download the MOBI file and sync with your USB cable.
Download the Template
We learned how to publish to EPUB using the Apple article, “Creating ePub files with Pages”. We used a sample template they provided and modified it to suit our needs. Then we used a tool called Calibre to convert our exported EPUB file to MOBI, to make it available to Kindle users as well.
You can simply open the file and select the menu File > Save as template... to save it on your Mac to ~/Application Support/iWork/Pages/Templates/My Templates/.
Writing and Editing
Set up your workspace:
Styles Drawer should be visible. If it is not, select View > Show Styles Drawer.
Inspector Should be visible. If it is not, select View > Show Inspector.
Use Layout mode. View > Show Layout.
Start your file
Start by opening a new blank document by select File > New from Template Chooser...
If you added the eBook.template file above, you will see it under My Templates. Select it and click "Choose."
Set up title page
With the first page selected, check the Layout Inspector > Section tab. "First Page is different" should be checked.
Change the title and subtitle.
To add a new image select the image box. Select the menu Insert Choose... (or use CMD+SHIFT+V) to place a new image.
Change the author and edition text if necessary.
Table of contents
Leave it alone, it gets generated automatically.
If for some reason you have to force it to update, right-click the TOC and select Update Table of Contents from the context menu.
Adding Content
Chapter title
Insert the cursor at the start of a new chapter and select the Chapter Name style from the styles drawer. Enter your chapter name or paste it via Right-click > Paste and match style.
Headings
Use the Heading style for headings, Subheading style for subheadings.
Body
Select the Body style. Start entering your content.
If you've worked on the content outside of pages, select the content you want to paste, right-click at the insertion point and select Paste and match style.
Images
Use Insert > Choose (CMD+SHIFT+V) to insert images at the insertion point.
Images must be inline to work properly in EPUB an MOBI format, so be sure to check the Wrap Inspector. Make sure you have the "Inline" radio selected images they flow with the text. Check "Object causes wrap."
Use a hard return after images.
Use the Caption style if you want to place a centered caption below an image.
Lists
Put each list item on a new line, select the entire series and select the list style (bullets, numbered).
Use CMD+\] to indent.
Code
Code Blocks: Use this style for blocks of code. They'll be shown in a block with a fixed-width font and yellow background.
Inline Code: Use this style for code that's shown inline in a paragraph. They selected code will be shown in a fixed-width font and yellow background.
Chapter Breaks
After the last line of the chapter select the menu Insert > Section Break. This will start the next chapter on a new page.
Header/Footer
We use the header and footer for the PDF version only, since EPUB and MOBI will strip these out, and use the document properties instead to get this information.
The header shows the Document Title on every page except for the title page. On the Table of Contents page, double-click in the header to replace it with your document title.
The footer shows the page number. You can leave this alone.
Exporting and Testing
First, save your Pages document, obviously. For PDF, simply select File > Export PDF. Follow the instructions below for exporting EPUB and MOBI formats.
Exporting to EPUB using Pages
Select File > Export.
Select the EPUB tab, and enter title and author information.
Check the "Use first page as cover image" checkbox, and click Next.
Ignore the warning about floating images, because you set the image wrapping properties if you followed the instructions above.
Save.
You have a few options to test in iPad: 1) Email the file to self as attachment and open to iBook, and 2) Open iTunes, drag to Books on left side of iTunes window under Library and Sync.
The process is pretty simple. Add your EPUB file to Calibre.
Click Convert.
I make sure that Output format is set to MOBI, and I add our company name to the Publisher field. I leave all other settings at defaults and click OK.
After the file is converted, you can right-click the eBook in the app and choose Open Containing Folder to browser to the file on your file system. It's saved to the ~/Calibre Library/ folder.
If you attach a Kindle you can copy the MOBI file to the Kindle.
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:
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:
We've gotten a few requests to provide masking in Mockups for those times when you want to partially obscure an object. Mockups doesn't currently provide a masking feature, but some people demonstrate the effect by flanking a center area with solid rectangles, so I thought it might be helpful to illustrate how they do this.
The idea is to:
- layout out your background (window and gray canvas) and middle levels (images)
- create the mask by flanking an empty space in the middle and grouping the mask elements
- bring the mask group to the front.
If you lock the mask group, then it also becomes possible to select the elements behind easily.
You can download the Mockups file for this demo from this page in our public Tips and Tricks project on myBalsamiq: Creating a Mask Effect. Download to play with it and see how it's made.
It's a bit of work to lay out a wireframe like that. It's kind of a brute-force method, but it might do the trick until we provide a masking feature natively. Oskar Austegard's iPad with open viewport is another good example of this technique.
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.
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.
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.
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.
Text components are interesting in Mockups. We have a lot of wiki-style syntax for formatting, and a lot of people have been asking to extend this to do things like insert icons into them. It's tricky because while a lot of us want icon insertion, this is one of those things that'll take some time to support with the current text engine.
Knowing how to exploit the characters available to you with the font you're using in Mockups can help you with some simple use cases. An example that came up today was that a user wanted to insert icons into the combo box, but didn't want to have to overlay icons on the component. I added a feature request to our queue to support selection in Combo Box, but in the meantime, you want to get work done, and you may not like overlaying components.
Here's a possible way to do it. This technique might only work for Desktop, and your mileage will vary if you're sharing your Mockups files and using config files for specifying an alternate font.
On my Mac, I used a dingbat pasted from character viewer, with tabs (Alt+Tab on Windows, Option+Tab on Mac) to create the leading spaces. The output looks like this:
That should work for the default font, or for system fonts.
To view the character map in Windows, go to Run and type in charmap.exe.
The UX Blog is where Mike and Leon talk about the user experience of our products, showing you what we're thinking and how we're evolving. We share tips and tricks to help you use Mockups better and faster and talks with you about addresses your UX needs.
PDF
EPUB
MOBI
