Help me design the "Import Image" feature!

  • Idea
  • Updated 5 years ago
  • Implemented
Archived

This conversation was archived and is no longer visible to community members.

Hi there, so as I mentioned before, I want to take the time and get the highly requested "Import Image" feature right.

I'd like to try a little experiment and co-design the feature with whoever is interested, using this forum, enhanced with a little Mockups-magic.

Last night I started mocking up the feature, and here's what I came up with:


The XML for this mockup is here: http://dl.getdropbox.com/u/41723/impo...

I would love to hear your opinions on it, and, even better, see an alternative design to discuss.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
  • excited to collaborate on this!

Posted 6 years ago

  • 2

Michael Matti

  • 22 Posts
  • 0 Likes
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.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
A small update: I moved the "image name" text-field out of the "file/web/flikr/archive" box, as it doesn't change based on the box's selection:



Michael, thanks for voting for "relative path linking", that's my favorite option as well (unless someone convinces me otherwise).

Robert Myers

  • 9 Posts
  • 0 Likes
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?

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Robert, thanks for your input, this is exactly what I was hoping would happen when I chose to put this out in the open instead of making a judgment call myself.

Re: relative paths: you got it, and yes, it's not ideal. One thing you could do is keep all the images in the same folder as the XML file, compress that one and send it back and forth. I agree that it's an extra step (or two), rather than just sending a single file. BTW, this is how Illustrator works when you place assets in them (they have a dialog that says "repair", when one of the images is missing or the location is wrong).

Another option would be for me to copy images to the same folder as the XML when you upload them (or maybe an "mockup_name_images" folder). This way you'd know to send the XML and that folder full of images - this would make things a little more "standard", while keeping the XML nice and small, and human readable. This option reminds me a bit of how iTunes copies any MP3 you import to its own library structure.

I could also add a "package mockup + assets" command under the "Mockup" menu, which could create the .zip for you (at least I think I can do this), and add an option to the import dialog to select these zip files as well - this is a bit like JAR files work in java, or AIR files, for that matter.

The drawbacks of embedding (assuming I can code it, which I still don' t know), are that the XML file becomes much bigger and full of binary data (i.e. crap). But the convenience of having one self-contained file is pretty huge - this is part of the value of Word files and PDF.

I haven't made up my mind on this topic yet, at all. Is it going to be Illustrator, iTunes, JARs or Word? ;) Let's discuss some more!

Your post also has a second feature idea in it, which I think is killer: take any image you upload and give people an option to "sketch-ize it". I don't know if I can pull this off (I'll look around), but it would be awesome, for all the reasons you mention. I think it'd have to be a checkbox in the Import Image dialog though, as I don't think you'd want to do it with every image (sometimes people want to import images to show "here's the UI we have today", for reference).

  • 0 Posts
  • 0 Likes
don't know if you are aware of this - but Office 2007 files and ODF files just follow the zipped XML+resources model. Change a .docx or .odf extension to .zip and open it up and see. Definitely a good model to follow, very flexible and extensible.

Robert Myers

  • 9 Posts
  • 0 Likes
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.

Michael Matti

  • 22 Posts
  • 0 Likes
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

  • 22 Posts
  • 0 Likes
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

  • 22 Posts
  • 0 Likes
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.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Ok, leaning towards the jar/air/zip approach for now (Robert, I doubt I'll be able to generate AIR files, but zip files I might)

I would like to get your opinion on another subtopic, which is "custom controls": I would like, for the sake of simplicity, to just bundle the feature together with this one. Basically you draw your control and upload it as an image. If you want text on it, you place a label or paragraph on top of it.

Another option would be to add something to the image import dialog which lets you select "no text" or "single-line text" or "multi-line text" for the image you are uploading, but then you'd have to give users a way to specify the top/left/bottom/right padding for the text...yuck.

What do you think? Remember less is more, less is more, less is more. :)

Michael Matti

  • 22 Posts
  • 0 Likes
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.

Robert Myers

  • 9 Posts
  • 0 Likes
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. ;-)

Michael Matti

  • 22 Posts
  • 0 Likes
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.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Robert, Michael, very good points about custom controls. I think I'll just do the image import for now, and people will place a label / paragraph over them. If they group them together, it should also resize ok (without stretching the text).

Robert, regarding "grouping and adding interactivity": I hear you, it will happen eventually. My concern is that I want to keep Mockups' UI incredibly easy to use, and adding interactivity is a slippery slope (just look at some of the high-end prototyping tools out there...so many buttons...scary stuff). Anyways, I will do something similar to what we're doing here when I start thinking of that feature, so hopefully you'll provide your input there as well.

Ok, I consider the "custom controls" subtopic closed...for now :)

Michael Matti

  • 22 Posts
  • 0 Likes
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:

import_image_file

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

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
That is great Michael. And yes, now that you mention it we don't need the name field anywhere...for files I can use the file name, same from files that came from URLs (I'll just trim the name at the end). So scrap that. New mockup of the whole thing coming right up.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Ok, here's the latest, incorporating the feedback so far (unless I forgot something that is):



XML here: http://dl.getdropbox.com/u/41723/impo...

Thoughts? This is starting to look pretty good I think.

Michael Matti

  • 22 Posts
  • 0 Likes
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 ...

Robert Myers

  • 9 Posts
  • 0 Likes
On the "file" Import Image box -- will you be able to select more then one image to import at once?

Robert Myers

  • 9 Posts
  • 0 Likes
How do I select over and over again the same image that is already in the folder (such as a Logo) in multiple Mockups? Do I place a "blank" image control on my Mockup, and then in the attributes dialog have a way to "walk the folder". Do I always have to have gone through the Import Image process first? Then use the Image in a Mockup? Could I not "walk" to the image anywhere to select it to be used, and then perhaps on the save the XML gets saved in it's folder, and the image gets copied to it's folder for future "pointer" usages? I may not be thinking this out all the way -- just starting to think about the work-flow behind selecting/using the images.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Michael, yes on all tweaks.

Robert: no, only one selection at the time.
re: loading the same image in many mockups: the tree in the import dialog will remember the last folder you used. And yes, imported images will get copied to an mockup-id-images/ folder next to the mockup's XML.

Robert Myers

  • 9 Posts
  • 0 Likes
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)

Robert Myers

  • 9 Posts
  • 0 Likes
Is there an inside Mockups way of deleting images from this folder if no longer used?

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
The image will go to a "broken image placeholder" state (like browsers do), and in the property inspector it will say "file_name (image not found)". You'll then import again to fix it.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
regarding deleting images: images that are in that folder that aren't used in the mockup always get deleted on "save", like it says in the mockup.

Robert Myers

  • 9 Posts
  • 0 Likes
Oh, did not realize that there was going to be a different folder for *each* mockup that uses an image.

Michael Matti

  • 22 Posts
  • 0 Likes
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.

gregorE

  • 0 Posts
  • 0 Likes
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.

Michael Matti

  • 22 Posts
  • 0 Likes
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. :)

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Hi GregorE and thanks for the detailed post!
Regarding the accordion: that's been there since launch.
Regarding the rate at which I add controls: yes it can continue, and I intend to stay up-to-date as much as I can. Adding a control takes me between 10 minutes and 3 hours, so it's not a big deal for me to keep adding them. I _am_ shooting to provide a complete set as much as possible, like you suggested.

I'll tell my marketing team ;) about your suggestion, I'll see what they can do. :)

Re: image management: you are right that users will probably need both..let me mull it over some more (I don't like where we are with the design so far...too complex to understand).

Regarding the "size by numbers". Would the ability to just drag down "forever" solve this need as well? I suppose this is really only useful for Browser controls, so I might add the "size by numbers" option in the control's property inspector....or even just make the default height of a browser window much bigger...let me see.

gregorE

  • 0 Posts
  • 0 Likes
Thanks Peldi. Can't believe I missed the accordion when I went to look for it. I suffered from my own mantra that "users are stupid". I must get around to doing a usability test on the temptation to scroll past the leftmost option when a large horz scroll is presented. Anywho, the "quick add" is my friend now.

Re: Size by numbers, your assumption is correct, I'm struggling with this for the browser window control. Easier dragging below the fold would be a viable solution, but there is something to be said for the precise sizing of your workspace.

  • 1 Post
  • 0 Likes
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?

  • 0 Posts
  • 0 Likes
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 :)

Robert Myers

  • 9 Posts
  • 0 Likes
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.

Travis Jensen

  • 3 Posts
  • 0 Likes
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.

Michael Matti

  • 22 Posts
  • 0 Likes
This sounds like a great idea. I've gotten into the habit of keeping a "storage shelf" mockup file open -- it holds a collection of hybrid (grouped) controls, which sit there for copying, as needed, into the project's various mockups. After copy 'n' paste, I have to ungroup the hybrid in the target mockup, edit its pieces, then regroup if realignment is needed. It would be a big help to be able to edit sub-items directly, using the same click capture (focus) logic applied elsewhere in the application. If we had this along with those relative-path simple image imports, my day-to-day needs would be pretty well covered.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Hi there, sorry if I haven't had time to get back to this thread for a little while.

For the "embed vs link" issue, I am leaning towards what I consider a simpler approach. It's simpler to code and simpler to grok for users, I think:

- images are simply linked, wherever they are. They are not copied anywhere. If the image is moved or deleted, I prompt to "fix the link", just like Illustrator does.

- if you need to share a mockup with images, I'll add a "package mockup for sharing" command which will copy all images to an "images" folder next to the XML, update the references appropriately and zip the whole thing for you.

As for the "templating" or "reusing control elements" threads, let me read it again.

Adam

  • 106 Posts
  • 0 Likes
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)

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Adam, sounds like a great idea. I'd like to get the basics done first, but I can probably add an upload button to the Flickr tab later.

Michael H

  • 5 Posts
  • 0 Likes
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.

Giacomo 'Peldi' Guilizzoni, Official Rep

  • 2122 Posts
  • 153 Likes
Interesting idea. For now, if you need a specific icon, let me know and we'll add it: http://getsatisfaction.com/balsamiq/t...

Brady Brim-DeForest

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

  • 0 Posts
  • 0 Likes
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).