Last week we launched Layouts in Superblocks. It was a huge effort and one of the more challenging engineering projects we've done and we learned a lot along the way.

‍

So what made it so hard?

‍

Before Layouts, Superblocks apps were all built on a "fixed grid": a visual grid that UI components snap to when you drag them around – kind of like a pinboard. This is the standard layout mode for products in the internal tool builder space.

‍

It's standard because it's incredibly easy to use, so people can get started building apps really fast.

‍

But this fixed grid layout has several big drawbacks:

1. No "fluid layouts" like you'd normally expect from the web, where content moves around gracefully when things change size or are hidden
2. No true "responsive design" support, where content can stack vertically if there isn't enough horizontal room due to small browser window sizes (like on mobile)
3. Tough to get perfect alignment and spacing across all content with the grid due to the snap to grid points behavior

‍

When we started layouts, we knew we wanted to solve all these problems. But in addition, we had 2 clear design goals for the feature:

1. It had to live happily alongside the existing fixed grid layout. We didn't want to replace the grid system that got us to where we are today, as it's a great option for people just getting started with Superblocks.
2. It had to be very easy to use, even for people with no understanding of CSS at all.

So we wanted to dramatically increase power while maintaining extreme simplicity. No small task!

‍

It took a lot of long hours and hard work, but we think we achieved our goal.

‍

We have a number of customers who’ve adopted our new layout modes for nearly 100% of their applications and many customers have told us how easy it is to use, which is great to hear given how much more powerful these modes are.

‍

So what are the insights? What did we learn from building this project?

‍

Allow customers to incrementally adopt features when possible

Our feature rollout and adoption was very smooth as a result of allowing customers to continue to use the existing fixed grid layout they already know and incrementally adopt the more advanced layout features as needed.

‍

We didn’t have to prepare for in-depth user onboarding due to a huge forced change in fundamental UX - users could instead play around with the feature while feeling safe knowing they can choose when and how to adopt the new modes in their applications.

‍

A default of simplicity, and superpowers when you need them.

‍

For complex UX, there’s no substitute for prototyping in real code

While we did some interaction design on pen and paper and in prototyping tools, prototyping interactions on top of our real codebase provided the most value at early stages of the project. 

‍

It’s very hard to know how a feature’s UX will feel when you’re testing it outside of your actual product. By prototyping on top of our product early, we were able to identify interactions with other existing features that needed to be fine tuned to provide the best possible UX - allowing us to work on these things in parallel instead of all at once.

‍

CSS is great, actually! But it can be easier to use

We ultimately decided that maintaining (mostly) a mapping to CSS concepts felt right. Our Vertical Stacks, Horizontal Stacks and Fill parent Width mode are all mapped to simple flexbox concepts. This makes it pretty easy to understand for experienced front-end developers. But we wanted our layouts feature to be easy for people that aren’t familiar with CSS.

‍

So we did 2 things:

1. We maintained all of the dead simple drag and drop interactions we have with our fixed grid. This meant you could drag and drop to move components around or resize them, even inside of our new layout modes.
2. We used naming conventions that are easier to understand. For example “Vertical alignment” and “Horizontal alignment” instead of “justify-content” and “align-items”. And we update the naming as appropriate depending on the layout orientation.

‍

This made flexbox style layouts much more accessible to a broad range of builders.

‍

Some concepts can often be made easier to use, but it doesn’t mean you need to throw everything away.

‍

There’s a lot more we can talk about with this project, like the Cassowary incremental constraint solving algorithm we used for managing autosizing, or how we kept a large React-Redux application performant while managing automatic sizing of many components on the screen at once. But we’ll cover those in follow-on posts soon.

‍

‍

‍