Balsamiq Query Language? Platform Extensibility?


#1

I’m seeing a lot of requests for global operations. Here are a couple examples of challenges that I’ve faced, in addition to the common text search/replace requested many times.

In a project for a website I have a browser container on every mockup. It’s positioned at 20,20. I’d like a way to reposition “the browser at 20,20 and all controls that appear within the scope of that control” to 1,1? By “scope” I mean any control that intersects with the base control regardless of it’s front/back Z level. This would include a Comment control that’s half on/off the browser.

Or … “Shift the x,y for all controls by -19,-19”?

Within each browser I have a consistent header position. To establish consistency through the entire project, I made the browser a symbol, added the header, and in each mockup removed the browser and header controls and replaced them with an instance of the new symbol. That’s a huge hassle. It would have been easier to have had a query to say in effect :

  • select all mockups, and in each mockup…
  • delete all Browser controls
  • find Title controls within 0,0 to 900,150, delete
  • add MyBrowser symbol
  • position MyBrowser instance to 20,20

Is this the beginning of BQL … the Balsamiq Query Language?

To my understanding from this thread, we’re now working in SqlLite rather than BMML, no? Maybe it’s time to expose a definition of how that’s structured. Then even if there is no official BQL, we might be able to create our own external libraries which use queries to do global operations like this.

As a developer, a few years ago I already create a utility that manipulated BMML for myself. (I really should have published that.) But now I would still relish the idea of creating and using (and selling?) external tools to manipulate Balisamiq project files. This would be a huge gain for Peldi and company as it would establish a sort of third-party market/community around the platform rather than taking on the burden of making every change internally to the product. Consider this request for text variables, which could easily be implemented externally, but it’s been on the ToDo list for Balsamiq for a couple years.

To get moving, perhaps we could have a separate area to discuss internal structures, and maybe come up with an API which can be implemented by anyone to manipulate the files? Balsamiq doesn’t need to accept responsibility for third-party products. And there is no vulnerability here. Balsamiq can be like any other product that offers extensibility, which most of us use and understand. If the company doesn’t want to participate in this there actually isn’t a need. Any developer could really look at the files, work out the structures, and then create custom tools, just like I did for BMML. But encouragement and nurturing from Balsamiq would be much better in the eyes of Marketing and the community perception of such initiatives.

I understand that the product is supported on multiple platforms and that this isn’t a global solution. People on different platforms will still be looking for specific functionality. But until some functionality is available for everyone, why inhibit everyone from having features that they could probably get much sooner?

How about it @peldi? :smiley:


Better BMML/Plaintext Support
#2

This is a very cool idea, @TonyG, and well written. It’s definitely exciting to think about.

My worry would be that it starts to blur the line between “starter tool” (which is where we like to be) and “full-fledged prototyping app” (which we’d like to avoid).

We built Mockups to be messy - like you were sketching an idea on a piece of paper. Things weren’t meant to be precise, or pixel perfect, they were just supposed to convey an idea. That’s been the focus of our app since its inception, and it’s been a tug-of-war between that idea and expanding features ever since.

The BQL feels like a prototyping feature, not a sketchbook feature.

That being said, we will definitely talk about it. Every feature is one good conversation away from implementation, and, regardless of the outcome, I bet this will spawn a good conversation. Thank you for that. :slight_smile:


#3

Thanks for the enthusiastic response, @Brendan.

About the lines… I totally get the product ethos and completely agree. As a designer and a developer I appreciate where the blury lines are, where we need to set expections in sketching, and transition to prototypes before moving to actual implementations.
What I’m talking about here is from the perspective of the designer who just wants to manipulate the environment faster to get a better sketch. Frankly I just found out a few minutes ago that v3 has the awesome button to convert from the sketch skin to wireframes, so you know I’m still talking completely on the sketch side of the fence.
This isn’t about what we do with the final sketch (fancy presentations). It’s about how we can save some time getting there. Take another look at the notes and you’ll see that.

I’ve been thinking about this extensibility concept for a long time. Soon after my first introduction to Balsamiq in 2009, I wrote code to manipulate the controls. Seven years later my daily effort leads me to the same conclusion: There is an easier way to do things, and it would really be nice to get better use of what’s already there in the box, rather than just letting the resource go untapped.

Also please note what I said about the company not even needing to “support” this or build anything in. One needs to see this from a broader business perspective and not technical. No product changes are required. Just provide acknowledgement and moral support for the initiative of others to build on what’s already there. Openly describe the database schema in the docs (and be perceived as heroes) (easy to do since the docs are now open-source), rather than letting some rogue developer in the field pick through your SqlLite and publish a third-party document, as though it’s something the company doesn’t want. (No, that won’t be me but soon enough, it will be someone.) That scenario needlessly sets up a wall with a small (?) segment of you client base (all developers so can’t be that small) purely on an opinion that this might not be something that other people want to do.

Given all that, there must be a company thought about responsibility for use of functionality like this in the field. But this is no different than any other plugin mechanism: WordPress and Drupal plugins, Minecraft mods, MS Outlook and Excel addons, and extensibility for almost every other product we use these days… The providers of the core never need to accept responsibility for what is done with extensions. They just need to provide disclaimers, advise the user base that all such tools are subject to doing unexpected things, and that backups are highly recommended.

Thanks for your time.


#4

I hear you, Tony. And it’s something we have been doing slowly over the last year or so.

We haven’t publicized it much (because it’s fairly technical), but we do have some BMPR Reference Docs. I’m not sure if that has all the information you need, but it should be a good place to start.

If there are other things we can write to help, it’s something worth discussing. Let me know what else you’d like to see.


#5

Wow, thank you Very much for that link, @Brendan. I’ll go do my homework and come back to this (in a couple months given other obligations?). I encourage anyone else interested in this kind of thing to do the same, read the material, and lets see what we can do with it.

Brendan, this is the point where I suggested that a forum dedicated to the topic might be helpful. :wink: