Better BMML/Plaintext Support


We use Balsamiq in distributed teams with a variety of source control tools (legacy svn, git, …). While we really like the new version, we can not use its format because it is binary which does not play nicely with source control.
We need better support of the old BMML format, i.e. directly opening and saving in Balsamiq 3 instead of having to import/export & unzip every single mockup all the time.
Since using source control is project critical for us, we have to refrain from using the new version until a better workflow with BMML (or a similar plain-text format) is available.


Thanks for the note @richard - question for you so that I can understand better: how do you deal with other binary formats like PSDs or office documents etc when it comes to SVN etc? Would a bmpr diff tool solve the issue for your team?


I had the same concern with the new format. The solution for us: just check in more often and provide some description about the changes.

Disk space is not an issue, as the files are reasonable small and bandwidth to distribute it globally is available.

So with some discipline on our side (with the change description), it works in our environment.


Thank you @peldi and @andi for your replies.

Regarding other binary formats: they also cause some concern. We try to eliminate the hassle with PSDs on an organisational level but of course this is not quite sufficient.

Regarding a diff tool: We already have diff tools in place which integrate into the normal repository workflow. While a bmpr diff tool would solve a few problems, other problems might arise from it (i.e. Linux support - we use Balsamiq on a multitude of plattforms). Our existing diff tools work great, why add another one?

Regarding andi’s input: Our problem is mainly concurrency. Of course we could create a single BMPR file for each mockup, however this would defeat the purpose of the new format (and still concurrent edits would break something).

In general: we like that multiple mockups can be in one file, the problem is that the binary format. A better integration of the legacy BMML format would help us a great deal.


I agree. Finally having project support is great, but would be better for development teams if it worked more like Visual Studio projects: folder based with a designated project file defining what’s in the project, project settings, etc. This would allow any existing source control + merge process to work just as well with Balsamiq projects as with .NET projects, iOS projects, Android projects.


I’m surprised this discussion died. Seems to still be relevant almost two years later.
With regard to the binary format, according to this thread the format is really SqlLite, which might change the dynamic of how the file is perceived, saved, versioned, diff’ed, processed, etc.


A diff tool is still on our radar, @TonyG. It’s something we are planning on looking at after we finishing porting our apps to native frameworks.

I know that a diff tool doesn’t solve all the problems in this thread, but if you tell me what you’d like to see, I can totally pass it along to the team. :slight_smile:


My requirements are the same as @richard, the OP. I’m at the point now where I have lots of mockups in a project, and multiple backups of the project files. Alternate views aren’t a replacement for versioning. I might find out days later that I modified a symbol which then caused an issue in some mockups. I may need to go back and see what the originals looked like, maybe copy some pre-issue component, and then paste it back into the current version. I might accidentally remove a mockup or some component and then need to look back to see where it was removed so I can recover it. Sure, I keep backups but the more complex the projects get the more I dread the time if/when these scenarios will play out.

Diffing SQLite is precarious but there is a tool for it. Others have asked about diffing SQLite, including this helpful Q&A. And this is the latest draft of using external Diffing tools with Subversion. Of course SVN isn’t the only DVCS, I’m just providing an indication that the concept isn’t unique.

Rather than trying to build something unique into Balsamiq, I recommend collaborating with others to make use of tools that already exist. The value-add of a diff tool in Balsamiq is that you’ll probably strive to render differences in an attractive form. But internally you need to find the differences first with some kind of diff engine. That is what this thread is about - the engine, not the rendering. The OP and I want to diff outside of this product.

With regard to my thread about documenting the Balamiq SQLite schema, I dare say that if you do that, it won’t be long before one of us writes a utility to generate new BMPR files that we can view in two side by side instances of Balsamiq to find our own diffs. Once again, you don’t really need to do anything except tell us how it works.



As a simple example of the kind of data we need, I just looked at the SQL in a BMPR file. On the left side is a new label dropped to a single mockup in a new project. On the right is that same label with the text changed to “aaaaaaaaaaa…”. Given the data here, a competent developer could extract the JSON and rebuild it into a new “Diff.BMPR” file where the two controls are shown side by side. And following on with my notes above, this could be setup as an alternate external Diff utility for any VCS. This isn’t rocket science. Put a gun to my head and I could have a solution in one day that people seem to have been sweating about for years.


Ahh, I see Tony. That makes sense.

We are kind of heads-down on shipping native versions of our web and desktop apps right now, but this is something we can talk about once the dust settles.

Thanks for the detailed example, my friend. Helped me wrap my brain around it. :slight_smile:


Plain text support or something that would allow us to integrate with our revision control tools on a per screen basis would be great.