Help me design the "Import Image" feature!

Pardon me if I don't really "get this", but...

So you're really not "uploading", but creating a pointer to image file(s) inside a folder on a drive somewhere?

When I pass an XML file to someone through email do I:
1) have to include a folder with these "extra" images
2) tell the consumer of the XML that they need to set up a folder structure just like I had on my machine ("x:/somepath/somefolder/") and drop the images in there before they can pull up the XML correctly.

A real case is sending an XML to a client to pull up and modify with changes, and sending it back. How do they "mark-up" a static .png? Seems to defeat the purpose of keeping the Mockup "alive" and changing.

Seems to me your going to sometime in the future be creating a "package" of stuff that equals the mockup project to be passed around. Especially when you get to the point where (hopefully) we will be able to "flow" multiple mockups simulating navigation.

I'm afraid I vote embedded -- my images right along side your UI Library -- even if that means size/dpi restrictions. After all what good is a hi-res Logo or Picture when all of the component UI's are (comical - I don't mean that in a bad way) illustrations. In fact I imagine a Stock Photo will look rather wierd dropped into the middle of the visualness of Mockups currently. Jarring at best.

What would be cool is to have s plugin that converts Logos/Photos to somekind of pencil illustration as I want my clients to "see" the functionality of the component layout, and not the "emotion" that color brings to the look & feel.

These are mockups. not coded pages (yet). There needs to be "distance" between the two. To me they need to remain looking like mockups, and not strive so hard to look exactly like the "final" results.

Does that make any sense?

Hey, maybe we're overlooking something on this. Where can the AIR distribution channel fit into all this discussion about packaging up "stuff" and sending it down the pipe to my customers?

What if I could email my client with a embedded link that when the recipient clicks on it, it opens up the AIR installer and moves my Mockup "package" (xmls, images, what-ever the future holds) onto my Clients machine (or over-rides a previous install of my project). Simple, clean, somewhat secure!

In my world, both parties have Desktop Mockup already installed, so the AIR runtime has to be there already.

No zip, no "XML + image folder" setup to explain.

I don't know. You tell me if that is even feasible.

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. ;)

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.

If unfortunate that your can't "piggy-back" on AIR's wonderful "pull" distribution/upgrade process. However, there are bigger fish in the sea to go after right now, I'm sure.

On custom controls...

I don't see how your not going to disappoint your Users when you introduce "custom controls". Here's why: you have provided very meaningful attribute functions for each one of your controls. You have set the bar pretty high about the configuration of each of these controls, and by rapidly responding to each customer's requests on expanding those attributes, the controls in place have a greater increased value compared to any User's imported "static" custom control with multiple label appending attributes (as you describe in your third paragraph above).

If I come up with a control that I think I need, and you provide a way for me to get it into the application, I'm not sure that's good enough. I now will want a palette of adjustment attributes to go along with it. Can you provide that "extra"?

If I were you, I would set this up as a additional "service" and charge accordingly. After all, two things we can guess about these "custom controls" are (1) you will have no idea what your Customers will request, and (2) there has to be a finite number of total controls that are appropriate for "skinning" a UI. I bring this second point up to point out that a large (?) percentage are already covered by your preliminary work.

My wish (for what it's worth)...I would really like for you to get to a point where you can crack the "linking up mockups" nut, so we can "demo" a working web site moving from one mockup to another via placed control "links"/"tabs"/"buttons"/etc. Then be able to package that up and send it to my Clients.

I know...I know... it's early. I promise I'll be patient. ;-)

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 ...

What is the "error" routine if the folder is missing or an image that is being used in a Mockup is not found in the folder any more? Will a "Red Check Box" appear or will a Mockup image control replace the position where the error image should be? (Note - this is after an image is previously import correctly, and also used correctly in your Mockup, but outside of Mockups program something happens to it)

Great tool Peldi!
I'm currently leading a team of designers for an enterprise 2.0 company. I've been keeping my eye on the tool over the past month or so, trying to make a decision about implementing it within my organization. This "image upload" feature is especially interesting because it has the potential to solve a "custom controls" issue I have.

Besides the complexity problems, most of those "high-end" prototyping tools take so long to catch up with the "modern web". For most of them, adding a "tab control" is the mos "modern" element they can offer. Our application is community driven and uses lots of the trendy stuff: flash confirmation messages, tag clouds, accordions, sliding trays, animated loading dialogs, web tree controls, modal widows which dim the calling page, rich text rollovers, rich drop downs, and the list of ajax, jQuery stuff goes on. This stuff is hardly rocket science, or even that incredibly new, but if you have a large mockup tool with tons of dependencies, it takes longer to add new controls.

One of the things that is really making me want to implement Balsamiq is the speed at which you are adding controls. I feel like every time I revisit the demo there are a few more goodies that we use in our application.

My big question related to this discussion is:

Can (and will) this rate of new elements continue?

If the answer is YES, then my desire for custom controls goes down dramatically. For example, we currently we make use of the "accordion" control (like the one in outlook), but at the rate you are going I would expect it to be in the app by the time you respond to this post. The ability to stay "moden" with rapid control development is one of the biggest selling points of this application. If I were on the marketing team over there I would even consider adding that to my messaging. Its really hard for a complex app, like Axure for example, to keep up with modern controls.

I would guess from my old developer days that making robust control customization will slow down the progress of native controls, and Robert makes a good point that the edibility of your "built-ins" has probably spoiled users and perhaps set a benchmark that would result in a complex implementation for user-created objects.

I can't say that I would be too interested in the aforementioned idea of custom controls being available as one-off requests for additional cost. Nor do I think it is necessary. At an organization like mine, that would require approvals and POs and frankly too much time. If there was a control missing that we needed, we probably needed it yesterday, and this image upload (although not ideal) would serve as the workaround (with hopes that the control would be there by the next design iteration).

It's true that you will never be able to anticipate every control a user may dream up, but you don't have to. There are only so many "proven" elements out there that you could implement nearly all of them, plus some of the newer trendy ones.

So for what its worth, I would recommend:
(1) Shoot for a really complete control set and keep the image upload functionality as light as possible.
(2) Stay as up to date with the design patterns, and current web trends as possible by continuously adding controls that reflect today's UIs.

On the image management issue I would PROVIDE options to the user! It seems your user community is going to always be split on this b/c you really have two viable options, both with very good trade-offs.

Single file portability vs. File size.
Depending on the environment in which your are collaborating one trumps the other.

Just let the user pick. I might be collaborating on a corporate network and I want to use an absolute path over the corporate intranet, or perhaps images I'm serving from the public internet.
That should be an option at the point of save, along with embedding the images, along with including the images with relative paths in some sort of .zip.

If you have read this far I suppose it does not hurt to make one final request that is slowing me from pulling the trigger and buying this thing....
Can you provide an option to resize controls by typing the dimensions (in addition to dragging). The drag to resize does not work well when I need to make a really long page. This is a show stopper for some of our mockups that show comment lists (like this one) where we need to illustrate how things will look with some lengthy l.ipsum population.

quick question on "imported images": will I be able to use an imported image as an icon on widgets? (for example, replacing the folder icon in the tree pane?

Thanks for working on this feature. I would find it useful as there are some custom widgets and controls we use frequently in our domain, but are not standard generic UI controls, which would appear in many mockups just as a dialog-box or radio button would.

I would want to:
1: Be able to specify items as editable text.
2: Be able to control scaling, much as you do for vertical bars, for example, following a scheme similar to Adobe's 9-box grid. So, for example, as I extend a custom window control, the top title area would not stretch downward.

Perhaps some of the first could be accomplished by:
1: letting people add an image, and then
2: letting people save a group as a reusable UI control (like a symbol in other apps)

I know, I'm sounding like a feature creep :)

Peldi, you can see how uploading static images has turned into uploading "private/personal" meaningful UI Components with the ability to magically have attributes that control their appearance. You're going to need to state the difference between static image upload (pictures, logos, graphics, etc.) versus how to get their own "custom" UI library component. You're going to need two separate procedures, and you'll have to quickly set the rules for both before the difference gets "muddy" and the distinction gets ignored.

I know the subject is closed, but I have to talk anyway. :)

On custom controls, I'd like to suggest a hopefully-quick option. For me, what I see the most valuable "custom control" is really an aggregate of existing controls (think navigation for an application, for example).

Grouping helps, but I can't edit the individual controls in a group. If I could group a set of controls, add it to a custom palette of some type, add it, and select the individual controls to edit (rather than needing to ungroup and regroup), that would be a HUGE time-saver for me when making multiple mockups.

Any way that you could upload a local file automatically to an online service (perhaps flickr or other picture/file service)?

That would save me time later when I want to share that file with others (without having to pack up the images into a zip)

Hi,

Great your working on the importing of an image in co-operation, i like that. But maybe you can extend this a little bit further to icons as well? I miss a lot of icons and i would really like to add them to the icon library. Just give people the option to upload an icon in three seizes (or one and you reseize it). It would even be better if you make it possible to let users make icons and let them store them on your website. It would be great to import the icons i chose from the site into my environment (or a set of icons). This way your icon set will grow rapidly as well ;-)

And concerning your question, i would link the images. A mock up is send in .png format and not the mock up itself. if i want to do that, then i should store the files in a webfolder like amazon or the box.

Michael H.

This is looking very promising – "Import Image" is one of the features that I am very much looking forward to!

I like your last thoughts on referencing an image and the mockup just maintaining the reference. However, include two reference types: local and URL. If the images are published through URLs then no packages or copies needed - just continue the external url link. But if the link type is local then follow your thoughts as above. You may even create two different library objects for the two different types of links.
I assume once either link type is placed the properties will be retained in the XML and those properties will enable resize - and hopefully crop settings. Tranparency is good if you image is really a background.

If a mockup is shared and a referenced image is not available (local file missing or URL no longer available) do as you say and fill with an "X" or "Image no longer available".
Finally, for local images support fully qualified image syntax and a relative syntax. This offers users their choice between simplicity (everything is with my mockup) or organized (my one copy of all of my images are in my image library).

It seems to me that this discussion is about two different topics -- the ability to embed (or link to) a picture and the ability to have a custom control. I think the picture tool is most useful for icons and the like and I think the option of sketchizing/auto-mogrifying pictures is interesting and would help make imported icons and pictures not be so jarring.

For custom elements, I think something else entirely is in order.

For custom elements, I think something else entirely is in order. I think you can do something that comes pretty close to providing custom elements that have the ease of use and functionality that the built-in ones do. Basically, I'd like to take a group of elements (or maybe a saved mockup) and turn it into a named custom element. I think you need a few things to make it practical to draw elements like the current set. I'll admit that I hate to suggest them.

1) Diagonal lines (or polygons)
2) Arcs
3) Triangles
3) Precision alignment (1-pixel movements instead of 2-pixel movements)

When you create a custom element, you get to specify three things:

1) A name
2) A scaling option, from this list (with some examples)

Fixed Size (YouTube video)
Resizable, proportionally (HDTV image)
H Stretchable
V Stretchable
H&V Stretchable
H Replicable (button bar)
V Replicable (vertical button bar)

3) The default text

Finally, here's how I would handle text.

* If there is only one text object inside the custom element, it becomes the editable text for the custom element. Comma or return causes replication for replicable custom elements.
* If there is more than one text object inside the custom element, the text is not editable (optional: allow them to pick which text object is the editable element; the others are static).

I think the linking is the way to go - seems to keep the app lighter, and most folks can create an image repository elsewhere that they can link to. For the confluence plugin, you might also consider linking to attachments within the wiki, similar to how the WYSIWYG editor allows you browse and embed attachments links via the "Insert/Edit Link" button.

Peldi,

This design looks good, and I agree with your last proposal about the link/embed discussion.

I hope we will get that feature implemented very soon!

Peldi, what about storing the picture inside of the .BMML file (or make it BMMLX like Office 2008)? The new .BMML would act as a zip file and store the xml and bundle the pictures. This is similar to how Office 2008 files work (.DOCX) and how OSX apps work (not news to you I'm sure).

Woot! Great to see this coming along. A few observations/suggestions:

1. Preview forces the image to expand to the preview size, which makes a small icon turn into a blocky mess. Preview should shrink-to-fit, but not grow-to-fit.

2. When exporting to PNG, the resulting image shows a gray-ghosty "X" paceholder behind the image wherever the imported image was using a transparent background.

3. Right now, import functionality is by way of the image component, but would also like to have it via button, icon, and icon-and-text-label. Basically, would like to have an import option everywhere you currently support icons, since external icons were my main reason for wanting this feature.

4. The last-used quick-select is a really nice touch.

Sort of off topic but I really had a difficult time finding the way to import/upload an image to my mockup. Convention told me to look at the "File --> Import" menu, though in this application it's the "Mockup" menu. I was expecting to see "Import Image" from there -- similar to how you'd place an image in Illustrator. Didn't find anything. I tried the "Edit" menu (that would've been weird) and of course didn't find anything.

So I looked... and looked, thought maybe there was a custom image control (which wouldn't be intuitive at all) and even dragged down the standard image but didn't think to look at the placeholder's properties.

I don't know if it's just me but I really had trouble locating this feature, everything else is extremely easy to find so far.

Maybe adding the menu option under "Mockup" to import an image would be helpful for other "slow" users like myself? I think that being able to import the image both ways wouldn't hurt...

Anyways, it's definitely what I was looking for and I'll be getting a PO to pick up a few licenses for my team.

Also: On linking vs. embeding I personally like linking best -- the way Illustrator/Photoshop links supporting files. Having a "package" with supporting files beingcluded would be very convenient as well.

I was just discussing the ability to import an image into a Balsamiq mockup with my team. I was pleased to find out that someone had requested this feature already!

Thank you.

Excellent!

Thank you for the reply!