Examples Templates Store Pricing Docs Turbo CSS Blog Introducing Turbo UI Named buckets Turbo CSS is Tailwind CSS on steroids Introducing Turbo CSS, the most advanced web-design language Calculate how much storage you use Better login system Collaboration settings Filesystem and Database are not cutting the problem space right What I'm working on 64bit File node IDs New how-to videos Creating buttons gets easier Introducing reusable components HTTPS by default Introducing the Boomla Theme CDN for faster pageloads Write your own website builder on top of Boomla On On composition Shared admin access A fresh config editor Building a multi-purpose theme A filesystem to replace your CMS New file link type: scope Mobile editing support Inline file wrapping changed Package sandboxing New PHP-like JavaScript engine [sjs-4e] Send emails to the website owner New JavaScript engine [sjs-4] A better editing experience New email service provider Glossary and other changes New panel changes Improved registration flow Boomla goes multiplayer Using local dev tools Why Boomla doesn't need Git File Panel Let's build a community Automatic updates Improved sjs-3 API New Frontend CSS modules Work offline with Boomla Faster page loads via caching Drag & drop supercharged Supporting CommonJS modulesĀ  Paranoid about loosing data IDE usability improvements Simple App install flow Meetups in Budapest Goodbye broken links Flow control from user space Customizing apps Contextmenu support for apps Deprecating the .Class file Hello Changelog Embedding 3rd party plugins Introducing Tools Installing apps just got amazing Public beta Host on our servers Simple deploy with push/pull Version Control for the Web 350M files on a 1TB disk 2 weeks in review
Control Panel

Creating buttons gets easier


The quest to find the right level of abstraction

I'm on a never ending quest to find the right level of abstraction for user interface elements.

If the elements are too low-level, we get lost in the details and the sheer number of choices we can and have to make.

If the elements are too high-level, we would need too many of them to cover all the edge cases - and yet we still couldn't, greatly limiting our options.

The trick seems to be to provide fairly low-level elements, like buttons, then assemble them into higher-level structures and also provide those as high-level "elements". Then we can start at a high-level solution, yet we can also "open the box" to see what's inside and reconfigure the low-level elements as needed.

Buttons 1, 2, 3

Seems straight-forward, so I created a button element a few months ago. But often we need more than one button, like one for a primary action and one for a secondary action. These should be next to each other most of the time, so we would need some kind of a button-group element to lay out the buttons in a nice way.

Horizontal container

But wait! We want to have elements that are useful in a variety of circumstances. Having an element just to lay out buttons horizontally seems too specific. There can be many other elements that need to be laid out horizontally, so why not create a horizontal-container element instead?

So I did. (Again, a few months ago.)

And it kinda works. But not like a well designed thing. I kept writing custom HTML for the important buttons placed on boomla.com. If it's not good enough for me, it probably isn't good enough for you.

Issues with the generic solution

  • Users could not figure out how to align the buttons (right, center).

  • They would often move out the button from the horizontal container which typically doesn't make sense.


  • Different screens need different button sizes. Small mobile screens need bigger buttons so you can hit them with your fat finger. Adjusting each button individually is a pain, it would be way easier to set the sizes on the container which would apply to each button in it.

  • Different screens need different layouts. Typically, you would use a horizontal layout on desktop but a vertical stacked layout on mobile. Often, the last button on the right is the primary button, while the first (top) button should be the primary button on mobile. That's reverse order.

These cry for a solution dedicated to buttons.

Introducing the button-group element

As a result, I decided to create a slightly higher level button-group element. It is optimized for the use-case of providing one or more buttons and nothing else. It's responsive, with way more options at various screen sizes than all the other elements. I'm curious how it will live up to the usability expectations.

For a start, I replaced the most prominent buttons on the Boomla home page and it worked like a charm. It was definitely a much better (faster) experience than writing custom code.

You should give it a try too - and please tell me how it worked!


you can follow me on Twitter