Crossing the impossible

How we came up with the first common language for designers and developers?

TL;DR

Building applications is a team effort between designers and developers.
Current tools and languages favour either one or the other and we are working hard to change that.

Today, a lot of time is spent in siloed efforts that end up in hand-offs of assets from designers to developers and have very little in common with real applications.

Countless hours are spent in prototyping throwaways and in translating visual requirements into interfaces. There is a better way, design as you build using our simplified language.

Don’t give up creative control over the UI and the UX once mockups enter the development stage. Lead successfully with understanding how things work!

ViewsDX provides a universal language to both, developers and designers. It’s a new concept based on one common environment, few compromises and redefined collaborative experience.

A good few years ago, together with Tom Parandyk, we started UXtemple as our space for doing experiments. We had tonnes of ideas and wanted to get things out there as soon as we could. However, as a designer, Tom could put mockups together much quicker than I could code them. If we wanted to produce a long-term value, we needed to cross boundaries and we needed to do it fast. We needed to design as we built.

Around 4 or 5 years ago, we tried going 100% visual. We built an online editor that would allow us to build apps directly in the browser. I would code reusable blocks and Tom would apply and configure them at will. Trying to compose blocks quickly became a nightmare because the basic blocks had to be both: generic as well as specific, and that just wasn’t possible.

Then, we thought that React was easy enough to learn and tried to convert Tom into a unicorn directly writing React components. It was a constant battle with syntax errors and remembering details. That way of coding was rather rigid and it certainly wasn’t forgiving. One typo and any newcomer would be scratching their head for a while, searching for the right solution.

As it tends to be the case with extremes, none of those two approaches worked. So we sat to rethink how to build things together.

Views is our third try at truly working like a team without boundaries and silos — we call that DX. And it seems that we hit on something 😉.

Our vision was to allow designers to write simple code using a blocks structure and style them with CSS properties.

Here’s how you would do it in the VERY first version:

{
  "blocks": [{
    "block": "Text",
    "props": {
      "style": {
        "color": "deepskyblue"
      },
      "text": "Hi there!"
    }
  }]
}

If you’re a developer, I know what you’re thinking. Cool! An array of blocks, block is the type it renders and props configure it.

Now, if you’re a designer, I know what you’re thinking too. Are you mental!? What does [ { mean and why oh why do I have to write them backwards after a while.

I know. It’s mad, isn’t it? That’s bad language design. As a matter of fact, it’s not even design at all! The truth is, we were trying a crazy concept and we wanted to see, with the least effort possible, if it made any sense to invest time on it. Thanks to the crazy early supporters that put up with it!

The first stab at a better language happened around September/October 2016. The same view then looked like this:

blocks:
- block: Text
  props:
    style:
      color: deepskyblue
    text: Hi there!

We went straight for YAML. Being free from explicitly closing sections (the whole { } thing from above) was such a blessing and way less error-prone!

Then we realised that every view could just be one block, like a main folder, and hold other blocks inside. We took advantage of our layout system and our Horizontal and Vertical blocks. We iterated and got this:

- block: Vertical
  blocks:
  - block: Text
    style:
      color: deepskyblue
    text: Hi there!

Now every View had to start with only one block. Cleaner structure from the beginning since a Vertical is just a container, much like an art board in Sketch or Illustrator.

However, even though this was much more appealing to non-technical folks, we still had some issues with it. We basically spotted two big problems for newcomers: indentation and punctuation. Both were adding complexity to the language. It was easy to forget the rules and make many syntax mistakes, resulting in ambiguous errors. So we set ourselves on a course to remove them out of the equation.

The momentum was on our side!

When we removed the punctuation characters (dashes — and colons :) our View looked like this:

block Vertical
blocks
  block Text
  style
    color deepskyblue
  text Hi there!

Much better. The code’s readability grew exponentially. Now we could see the pattern. Can you see it?

Block names always start with a capital letter and properties always start with a lower case letter.

Vertical
  Text
  style
    color deepskyblue
  text Hi there!

There’s something more on that pattern, though. Because block names and properties are inherently different, it meant that we could totally remove the keywords block and blocks. As a matter of fact, because our Views represent visible elements, we could take this one step further and embrace styles at the top level — they are only CSS properties after all.

We got this:

Vertical
  Text
  color deepskyblue
  text Hi there!

Absolutely beautiful, wouldn’t your design eye agree?

Remember our goals above? We had two: remove punctuation (check!) and remove indentation, and that was a challenge worth taking!

We reviewed our grammar:

• blocks start with a capital letter, like Text,
• props start with a lower case letter, like backgroundColor.

With that in mind, it was safe to assume where the blocks start and their properties finish. Let’s review another example:

1  Vertical
2  backgroundColor deeppink
3  Text
4  color deepskyblue
5  text Hi there!

In the View above, our blocks are at lines 1 Vertical and 3 Text. The props of the Vertical are at line 2. The props of the Text go from lines 4 to 5. Because Text is right after the Vertical props, it is inside of it.

So, what if we wanted to add an Image below the Text (that is already part of the Vertical)?

1  Vertical
2  backgroundColor deeppink
3  Text
4  color deepskyblue
5  text Hi there!
6
7  Image
8  source https://files.usepages.today/uxtemple.com/banana.gif

You will notice that line 6 is empty. That’s totally on purpose. The indentation was handy because it allowed us to tell the level of block’s nesting. Without it, we had to get creative 🙂. Normally, empty lines have no assigned function or meaning and it felt like the perfect candidate for separating blocks.

The key to understanding how this grouping works is that each new line breaks away from the previous group. Use empty lines to move your blocks from one group to another.

To recap, the (simple) rules are:

• no empty lines — part of the block above;
• one empty line — one level up the block directly above;
• two empty lines — two levels up the block directly above; etc.

Here’s how it works in a more complex example. Let’s group our Vertical inside a Horizontal and add some Text next to it:

0  Horizontal
1  Vertical
2  backgroundColor deeppink
3  Text
4  color deepskyblue
5  text Hi there!
6
7  Image
8  source https://files.usepages.today/uxtemple.com/banana.gif
9
10
11 Text
12 text I'm at the same level as the Vertical at line 0

How does our new Text know that it belongs to the Horizontal and not to the Vertical at line 1? The empty lines at line 9 and 10 do it.
Line 9’s empty line breaks away from the Image at line 7. If we were to write a new block here it would put it under the Vertical at line 1 but that’s not what we want.
Line 10 being empty helps us achieve our goal because it stops that Vertical's group and gets our Text at line 11 under the Horizontal.

There’s more to ViewsDX grammar and how our editor will help you even further but this post is already too long so we’ll leave that for another day.

We’d love to hear your thoughts on the evolution of the View’s grammar. Signup and we will notify you as soon as we deploy ViewsDX’s public beta.

PS. I totally blame DX for this! 😁