Account Assets are gone


#1

In B3 we decided to remove the concept of global account assets.

They were hard to set up, hard to use, hard to understand, rarely used, and generated a lot of support requests and bugs.

They were mainly used for custom icon sets, but also sometimes for shared Symbol Libraries.

Removing the concept allowed us to greatly simplify both our UX and our codebase, resulting in an easier-to-grok and more solid application.

So, if you were using account assets in 2.2, what should you do now?

What we are suggesting is to create project templates instead.

  1. Create a new project
  2. Save the BMPR in a shared location (dropbox or network drive or attach it to your wiki…)
  3. Load up all of the icons or symbol libraries you want your new projects to have

Now, when you want to create a new project starting from the template, simply duplicate the BMPR file (or open it and use Save As…), and it will have everything you need in it.

We realize this doesn’t solve all of the use-cases, but it should solve most of them! :smile:

Let us know what you think, and if the template option doesn’t work for you, please tell us why, in as much detail as possible. We are listening!


Image not found when importing BMML into 3.0
Please keep the cfg file
#2

I’d like to second @Taimar’s comment in the other thread about the loss of this feature - I understand completely the reason behind removing it but perhaps the way my company had intended to use it will illustrate that it has value. Maybe there’s another way to meet the requirement?

We plan to make Balsamiq available to a team of users working on different internal web design projects, using the same framework - each project will share the same company logo and page structure etc. but the content will be customised to suit different departments. I had hoped to keep the company-wide images in the Account Assets folder so that if branding changed, we could update it in one place, and ensure consistency between projects.

Using a project template will make sure each new project uses the correct images, but this doesn’t support the scenario where we need to make a global change to several ongoing projects. Presumably we will just have to issue a new icon/symbol and hope that everyone makes the update!


#3

That’s correct. Does this happen often in your experience? We can always add features to support this, but I would like to really understand how important this is. The hope is that “internal bmpr templates” will take care of 90% of the pain…I guess we’ll see! :slight_smile:


#4

It hasn’t happened yet - but there were indications in a recent company update that it is going to happen at some point this year, which is why I’d looked into how we’d manage it :neutral_face:

The ability to share and update images across projects was a nice feature, but I’m sure we’ll manage without!


#5

Another reason for having one global location for assets, icons and symbols is that individual project files are all going to be larger because they all have to store their own copies of those items that are being shared and which any specific project might not actually be using!

There’s also the situation, similar to what @Jess_Readhead says, about being able to update shared assets and have them automatically update across all projects that use them. For me, it’s mostly about shared Symbols as I frequently tweak exactly how a symbol is put together having to go back and individually update the symbol I’ve changed in every project that includes the symbol will be very time consuming. Not to mention the fact that, once lots of projects exist, it becomes more likely that one might be missed and not updated, leaving the now-obsolete symbol layout in place.


#6

Jenni, welcome to the new forums! :smile:

Re: the BMPR file size, it’s true, though the mockups and assets shouldn’t take much space…

Re: your shared symbols, I am curious about them. Can you describe them a little more? What kinds of controls do you have in them? We haven’t seen shared symbol libraries being adopted very much, other than those downloaded from MockupsToGo for control types we don’t have in the app yet (like Android and the like…)


#7

Just as an example, I created a template where I just “sucked in” all the icon files I regularly share across projects - they are 128x128px PNG files based on FontAwesome that are available for download. Some of the images are duplicated with different names since FontAwesome uses aliases when used as a web font (e.g., the same image is saved as “icon_gear” and “icon_cog”). The result is 515 individual asset files.

The first thing that happened was that when I selected all 515 file the application crashed.

After going through and selecting in alphabetical batches (so all the images named icon_a* followed by icon_b*, etc.) the size of my otherwise blank template file is 2.87Mb. On the other hand, if I just select the BMML files for a few of my existing B2 project folders they come in at just 1.43Mb, 1.14Mb, 957kb.

Next I started from the template and imported just the BMML files from the project that came in at 957kb. This also brought in one image asset that is 433kb. The final project file size: 4.21 Mb. This is slightly less than if I simply added together the size of the blank template, the BMML files and the image asset (which is 4.26), but consider now that each and every project file has at least an additional 2.80Mb hanging off it, even though I would never use all 515 icons.

Now you might say that I could always delete the icons I don’t use, but since it appears I can only send assets to the trash one at a time, even if I used 25 or 30 unique icons, it would still be incredibly tedious to delete upwards of 480 individual icon asset files.


#8

I use symbols as a form of reusable design pattern language. It’s talked about a little in the Balsamiq Champions interview that Leon did back in 2013 (http://blogs.balsamiq.com/champions/2013/05/28/jenni-merrifield/)


#9

What if we improved the native icon set? Then you wouldn’t have to import any custom icons…or only a few…thoughts?


#10

Well, one reason I use the FontAwesome based icons is that there are so many individual images available, so improving the native set certainly wouldn’t hurt. They have a lot of images that you might not initially think would be needed yet I’ve found myself taking an image ostensibly meant for one thing and using it to represent something else.

That wouldn’t help me with the need to keep shared Symbols in sync issues though.


#11

Yes, improving the native icon set is certainly very welcome but it wouldn’t help me completely, either.

I work in a in-house design team and use Balsamiq for many many
projects. All these projects have some common and very unique (= product
specific) icons and other UI elements. They were just there for me once
I placed them to Account Assets folder. Now… I can’t imagine having a
single resource file containing all the needed custom assets (and
icons!) and… duplicating it all the time.


#12

I agree that improving the basic iconset would be nice, but there will always be the need for custom icons.

Speaking for my situation, we currently use about 600 small icons (16x16 icon_.png) to use inside trees, buttons, lists, tabs. We also have about 200 large icons (*.png) to use as watermarks or thumbnails. Since they are very specific to our products, there is no way for them to become part of a basic iconset. Our small icons are front facing and our large icons use a 3D perspective, that’s why we need separate images.

If we use your strategy to copy all those assets over and over inside all our project files, we will waste a huge amount of disk space.

Here is a suggestion:

  1. Keep the old global assets folder as a repository
  2. As soon as you insert an asset from that folder, it will get copied in the project’s assets.

Therefore, you still have access to your huge library but you grow your project file on demand. That way, if a project uses 15 icons from the global assets, only those 15 will get incorporated inside the project file.

And if I need to change a global asset, then I can live with the minor pain of re-incorporating in inside the projects that are using it.

To summarize: Use a global assets folder as an import repository. As soon as you add something, it becomes a local asset.

Cheers!


#13

It would be great if you could make Font Awesome a native part of the app. Personally, that has everything I need and because it is used with Bootstrap, it’s doubly useful.


#14

Have to agree that making it possible to somehow include and select icons from web fonts would be an awesome “nice to have”. One advantage of this over requiring the import of PNG files is the reduction in file size (one font file is going to be way smaller than 250 PNG files at 128x128px). Another is the “perfect resizability” of a vector font.


#15

I love this idea and have put it on my list to investigate it further. One drawback so far is that those icons are not very “sketchy”…but if you guys use them already, maybe it doesn’t matter much? Right now we have two sets of icons, one for each skin.


#16

There are some other icon fonts with sketchy looks - for example: Jolly Icons and Dot Com. If the system let you “install” and use any web font for icons then it would be up to the user whether to go with sketchy or not-so-sketchy icons. :slight_smile:

Out of curiosity, how are your current icon sets maintained? Are they implemented like a font?


#17

For me the main thing is also just wanting to always have “our” icon library available. Built-in access to existing icon libraries would be nice, but your current support for importing custom icons is the right direction.

The project template file idea is workaround, but a clumsy one in real life: You have to remember to always start by duplicating that file, rather than just opening Balsamiq. Or - if you open the template directly - you have to remember to “save as” immediately, otherwise your changes will pollute the template.

One solution might be to elevate the concept of a template document, the way Word and Excel do. Opening the template would be like creating a new project and would force you to “save as” rather than saving over the template. It wouldn’t have to be a separate file type - could be something as simple as a convention that files with the word “template” in the filename are treated as such.

The obvious next step would be to allow users to choose a default template to use any time you start a new project (which you can also do with Word and Excel). This template could live on my own drive, in a Dropbox folder, or on a shared drive.


#18

Specifically on the question of whether it matters that font awesome icons are not so sketchy. For me, it has not been an issue, probably because icons are quite small, so the overall mockup still has a sketchy look.

One of the advantages of working with a web font is that I can be very specific with my suggestions. Every project is different of course, but on some projects, I’m feeding projects directly to developers, and they are very happy when I can tell them “use this EXACT icon from font awesome here”.


#19

I didn’t test this, but can’t you set the read-only flag of the file system? Mockups should ask you for a new name for the project.


#20

I use account assets to load Font Awesome icons, I’m also the maintainer of a small project that makes it easy to download them with instructions on how to use them in Balsamiq.

I think it’s a big loss if you have to set them up for every project you start (almost 3 mb of files) every time you start.

I can see the downsides with the current implementation though, the files don’t live in your project and if you share a mockup that person will probably miss your custom account assets. Also reducing complexity in your code base is worth something :smile:

I guess I’m +1 for improving the default icons, my use case for using FA is the larger number of available icons, plus that they translate easily as we also use FA in our application.