Michael Matti's dashboard

Michael Matti started a conversation in Balsamiq on July 30, 2008 19:18:

Nice plug at InsideRIA

My feed reader includes items from InsideRIA, and ten minutes ago this headline came up:

Handy Mockup Tool for RIAs

Yes, it's all about Balsamiq. And yes, he certainly liked it.

Michael Matti shared an idea in Balsamiq on July 30, 2008 13:34:

Request: Shading and gridline options for datagrid/table

For straight-up slickness, the Mockups datagrid component is my favorite: so much gets generated from so little effort on my part. But I've just been bitten by its baked-in formatting. After several weeks of creating specs with lots of Mockups snapshots, we now have live builds coming out of the engineering group. The design uses datagrids, and the builds have switched to alternate row shading that starts on the first row instead of the second, despite the fact that our design standard calls for second-row style.

When I pointed this out, and cited the standards doc, engineering pointed out that all the new mockups show first-row shading.

Sigh.

Guess I should be grateful they're following my guidance so closely ... just need to give more consistent guidance.

Right now, the Mockups datagrid/table component has hard-wired vertical lines and alternate-row shading that starts on the first row. I propose keeping those defaults, but adding two combobox controls to the properties panel, for simple modifications:

Row Shading: Odd (default) / Even / None
Grid Lines: Vertical (default) / Horizontal / All / None

I'm hoping this is another of those relatively simple tweaks. By keeping the defaults as-is, it wouldn't mess up the rendering of datagrids already in use. And the added options would let the component mimic a good range of table styles.

Any pitfalls? Thanks ...

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

Peldi has amazing turnaround times ... that accordion component you've wanted is already there in the app. As predicted, it's been added even before he's replied to this post. :) – Michael Matti, on July 29, 2008 19:16

Michael Matti replied on July 29, 2008 16:41 to the problem "Text positioning and curly braces" in Balsamiq:

A followup discovery: place a downward-opened horizontal curly brace at the very top of a mockup, with the rest of the components positioned below. Then export a PNG snapshot. The resulting image will have the text portion of the curly brace cut off -- the capture algorithm sees the top of the image as the graphical brace part, not the text. Possibly related to the text positioning mentioned earlier?

Shoving everything down about an inch allowed a workaround.

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

Like Robert, I'm pondering that different-folder-for-each-mockup paradigm. Seems like it would be easier file/folder maintenance, especially if dealing with something like a standard library of icons, to have a single images directory that branches off the directory that holds the XML sources. I just checked, and the project I'm working on has 40 XML sources, and more than half would be dipping into the same set of images, if they were available. One sub-directory holding the set would be better than 25-odd sub-directories and replicated images. – Michael Matti, on July 29, 2008 15:20

Michael Matti reported a problem in Balsamiq on July 29, 2008 04:09:

Text positioning and curly braces

Two text issues I've just noticed: First, the property panel for curly braces displays an empty (null) text size instead of the true default, which is 13 points.

That one's trivial. The bigger deal is when you create a horizontal curly brace, flip the brace to open downward, and enter enough text to cause line wrapping. No matter how you resize the component, the text flows from immediately above the curly brace and winds up overwriting the graphic -- and beyond.

The same thing happens with vertical curly braces, but that orientation generally gives more wrapping room, so it's easier to cope with. The text flows from just above the point of the brace instead of centering itself against it.

By the way, been using these a lot for "inline" annotations, while reserving sticky notes for editorial asides. The two components work well together that way ... sort of like two different voices.

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

I like that the command button's "OK" is now labeled "Import". Under the Flickr tab, since you already know you're hitting Flickr, I'd treat the top part the same way you're handling Web search: use the label "Image Search:" flush left, leave the search input field blank (no prompt inside), have it stretch full width, and label the search action button "Go".

I think that's really it, except for building it ... – Michael Matti, on July 28, 2008 11:38

Michael Matti replied on July 28, 2008 03:58 to the idea "Help me design the "Import Image" feature!" in Balsamiq:

Finally had a chance to spend a little time on the original topic of this thread: design ideas/alternatives for the import image feature. I focused mostly on the dialog's file import tab, since that's the one I'd spend most of my time with (glad it's the first and therefor default tab). My main concern with the original design was that it seems to spawn a dialog from the dialog when the user clicks the upload-from-disk button. I'd really like to avoid being tossed to a client-side file picker if we can integrate file selection into the dialog itself. Don't know that much about AIR, but it seems that should be possible, and it would make the from-file import tab much more consistent with the experience of uploads from Flickr. Here's a PNG of my mockup; the XML is at mysite.verizon.net/mmatti/mockups/import_image_file.xml:



As you can see, the user just browses local files/folders from a tree control, selects one and sees an instant preview, and they're done. Or ought to be done -- I've been wondering about the purpose of that "Image Name" field in the tabs. Is that really needed, since a filename is delivered by every source, and (with the exception of Flickr) be just as meaningful as anything the user would type in? Certainly, if I'm linking to local icon image, the name is already fairly descriptive and I'd be annoyed having to supply an "internal use" version each time.

Hope this helpful, one way or another ...

A comment on the idea "Suggestion: radio and checkmark items in menus" in Balsamiq:

Sounds fine to me, so let 'er rip. Thanks much ... glad that one was pretty easy. – Michael Matti, on July 28, 2008 00:55

Michael Matti shared an idea in Balsamiq on July 27, 2008 19:27:

Suggestion: radio and checkmark items in menus

This last week I was working on menubar specs, and found myself needing two things the menu component doesn't include: radio-button style selection groups, for a forced choice between mutually-exclusive items, and checkmark style items, for options that user toggles on and off. Radio-button items are generally grouped by separators, and of course we've already got a separator shortcut in the menu component. Checkmark toggle items can appear anywhere, and Mockups for the Desktop uses them for the View menu.

What I'm proposing is a pair of shortcuts for prepending bullets or checkmarks to rendered menu items. Maybe a lowercase "o" followed by a space, and a lowercase "x" followed by a space, since those would be unlikely ways to start the actual text of a menu item.

I can think of one complicator, as far as extending the existing menu component this way. Right now, the left-hand margin of a rendered menu is pretty narrow -- there isn't enough room to squeeze in a bullet or checkmark, so that would have to be widened to preserve text alignment.

Reasonable? Practical?

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

A small refinement for that ImageMagick recipe, after more tinkering this morning. This version preserves background transparency and crisps up the edges:

mogrify -edge 1 -type grayscalematte -path mono icons/*.png – Michael Matti, on July 25, 2008 22:15

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

Good point, Robert ... the "components" we upload will be scarcely worthy of the name, compared to the configurability of Mockup's built-in components. Really, we're just talking about images-bigger-than-icons, with maybe some text slapped on top. I'd rather just have the image upload option, however it's implemented, and if text labels are needed, I'd slap on a Label component, create a group, and be done with it. Other features feel more important for the moment. – Michael Matti, on July 25, 2008 16:03

A comment on the idea "Help me design the "Import Image" feature!" in Balsamiq:

I think most users, if they have the skills to draw their own controls, would have the skill to overlay text on top of it. The problem is with resizing the custom control -- it's one thing to have the image get some blurring and distortion, but the text would also be distorted, and that would really look bad.

Sounds like we're talking about two types of image import: 1) Relative file ref pointers to image-only items such as icons, along with the previously-mentioned jar/zip export option. 2) An "import component" feature, that has some way of binding the imported image to a text field that can be positioned centered (overlayed), top, bottom, etc. When the user resizes the image, the text portion re-positions accordingly but doesn't distort. – Michael Matti, on July 25, 2008 15:31

Michael Matti replied on July 25, 2008 03:21 to the idea "Help me design the "Import Image" feature!" in Balsamiq:

Back to the main subject of embed-versus-relative-link: from what Robert has described, it sounds like our different preferences hinge on different roles/responsibilities. In my situation, I'm the officially designated UI guy, and the only one running Mockups. The stakeholders don't have the app handy -- and trust me, they won't to want to buy it, install it, and learn how to use it in order to provide feedback. They just want to see annotated mockups from me, which they critique as we steadily refine the design. Hence my heavy use of the Export PNG Snapshot feature.

Sounds like Robert, on the other hand, has more of a collaborative relationship with clients, where they fire up Mockups to tweak and tune his designs directly.

If both scenarios are in play among the product's users, the best option for added images might be "package mockup+assets", which gives the benefits of not directly embedding images, but automates bundling of the images to ease transfer when needed.

Michael Matti replied on July 25, 2008 01:58 to the idea "Help me design the "Import Image" feature!" in Balsamiq:

About this sub-topic of sketch-zation -- there's a way to do this right now, outside of Mockups, using ImageMagick on any platform. For a couple of years I've used the Silk icons at www.famfamfam.com/lab/icons/silk/ for mockups and live prototypes. There are a thousand in the set covering a broad range of tasks, and they're completely free to use. But they're so polished they don't fit with the rough Mockups aesthetic, and (as Robert pointed out) early exposure to visual refinement can mislead the client.

So, let's assume you've downloaded and installed ImageMagick. Let's also assume you've downloaded and unzipped the Silk set to a local directory. There will be a child folder called "icons" that holds the 1,000 PNGs. Create a sibling folder alongside "icons" and call it "mono". Then, from a command prompt in the parent folder of icons and mono, type this (changing the forward slash to a backslash if you're running Windows):

mogrify -edge 2 -type grayscale -path mono icons/*.png

Might take 15 seconds or more to run. When finished, take a look in the mono directory for your 1,000 slightly roughed-up and monochrome icons.

Now all you need is a way to load them into Mockups. ;)

Michael Matti replied on July 23, 2008 13:21 to the idea "Help me design the "Import Image" feature!" in Balsamiq:

First off, love the idea of collaborative design of a design tool, using the tool itself for collaboration.

Will take a crack at a mockup in a day or so, but I'd like to comment right away on the question in the first sticky note, about linking versus embedding. I think linking using relative paths is a good way to go, since I haven't found myself sending mockup XML to any stakeholders. I've been sending them PNG images, often as e-mail attachments -- which is why I asked about a fixed canvas size option earlier, to ensure consistent sizes.

With relative paths, people can still send mockups as XML if they send along a zipped folder of the extra images. Relative references are pretty easy to understand, especially if your users have any experience with Web site design/structure -- which I suspect they will.

Would rather keep the product and its data files lean, pointing to local images I can manage via folder hierarchies, than stuff them all into the app.

Thanks for tackling this so quickly, and for taking feedback from the very start.

Michael Matti reported a problem in Balsamiq on July 21, 2008 20:52:

Text color selection oddity

Here's a minor issue, but worth fixing at some point.

Select a component that supports text color, such as text area or icon-with-label. Notice the default text color: black. But look at the properties panel for the selected color: it's white.

Now, open the color selector and click the white square in the palette, as if you really want the text to be white. Text color remains black.

Go back to the palette, select black (or anything other than white) and your text will reflect the new color. At this point, you can go to the palette once again and get white to work.

Seems like the coordination trouble would be fixed if the default palette selection matched to the default text color, and started off aimed at black.

Perfectly usable as is, but puzzled me for a moment.

Michael Matti asked a question in Balsamiq on July 18, 2008 17:18:

Possible to do fine-grain resizing, as with moving?

There might be a way to do this already, and I'm just not seeing it: You know how, when a component has snapped into position, you can nudge it by just a pixel or two by using the arrow keys? I've been trying to do the same thing in a resize context, widening or narrowing an item by just a little bit. But I can't figure out how to do that. Shift-arrow causes big-increment moves, and ctrl-arrow is the same as arrow -- does a move, not a resize.

I might be missing a simple trick. In case I'm not, this would be another request to add to the roadmap: ctrl-arrow allowing fine-grain resizing.

A comment on the discussion "Product Roadmap for Balsamiq Mockups" in Balsamiq:

Yeah! Now _that_ looks tool-tippy ... sort of like an upside-down dialog balloon. Please pass along thanks to your wife, if that's her handiwork. – Michael Matti, on July 17, 2008 16:22

A comment on the discussion "Product Roadmap for Balsamiq Mockups" in Balsamiq:

Peldi - Thanks for adding that tooltip. It's good, but I think it could be even better: right now, it's sort of slimmed down version of the callout control, minus the yellow tinting. That makes it hard to identify as distinctively a tooltip on the page. To make it more tool-tippy, I'd have a clearly defined point at the left end, maybe out and up at a 45-degree angle (aimed northwest, if this were a compass). Sort of like the tips of the comment ballons used on this site. Another approach would be a superimposed mouse pointer arrow, just off to the left, since tooltips come up as a result of mouseover hovers. – Michael Matti, on July 17, 2008 13:24