Comment by danielvaughn | Hacker News Reader

Comment by danielvaughn | Hacker News Reader

Parent Full thread

I've been working on a programming language for UI designers.

To put it simply, I think the trend towards no-code/low-code is misguided. The assumption behind these products is that code is slow, difficult, and expensive. I disagree - I think that "code" is merely a formalized written expression of what you want. It's actually the most efficient, easiest, and cheapest means to solving digital problems.

I believe anyone can write code if it's specific enough to a domain that they understand, so what I'm trying to do is create a hyper-domain-specific language around designing UI components. The goal is to have a platform agnostic base syntax, with "dialects" that can extend the language for any current or future platforms.

The idea is that designers could write in this language, and developers could build tools that will transpile this code into a consumable format for whatever system they're building for.

I have a very rudimentary demo site that's like halfway built: https://matry.design

edit - here is a simple example of what a component might look like in this language:

  component Button
    variants
      color bg: #007BFF
      text label: Click Me
      
    elements
      shape ButtonContainer
        text ButtonLabel

    style ButtonContainer
      fill: $bg
      padding: 10px

    style ButtonLabel
      content: $label
      font-size: 16px

I love the idea of this, but I just learned about xstate.js.

It was a eureka moment for me. Why was UI design such a mess? It’s because the UI vocabulary came from publishing and graphic design, but UIs are not static and describing them in that way will always fall short.

I’m convinced that any UI language needs to incorporate a visual state diagram editor to really make a dent in the space.

UIs are not fixed objects, but responsive object reacting to user intent.

Does your language incorporate anything like this?

One of the premises behind the language is parametric rendering. So nothing described with Matry is static.

The difference, however, between Matry and something like xstate is that the actual state is intended to be left to developers, because I’m trying to create an interface that allows designers to just focus on what they need to focus on.

So take something like dark mode. A designer might allow for a Boolean parameter that determines whether a component render in dark or light mode.

But as to whether the browser supports it, or whether the user has that mode set in their system preferences - that’s the developers responsibility.

That doesn’t fully answer your question but it’s a complex topic so hopefully that gives you an idea as to where my thoughts are going.

Designers absolutely need to focus on dynamic issues and state issues. Not all state is exclusively the developer’s domain.

There’s language, locale, time of day (which you mention), accessibility, screen resolution and those are just things off the top of my head that are implicitly exist as state in a designers head.

Then there’s the whole idea of transitions which are explicitly about state and in designers domains.

You can’t tell me designers don’t care about transitions. It’s developers who usually don’t care about that state.

And that last bit is my point. Let designers handle the state they care about. UIs will get better as a whole with it.

No what I mean, is that they only care about the effect of the state on the UI.

There’s a difference between determining the state, and deciding how that state affects the pixels on the screen. The former is the domain of engineering, and the latter is the domain of design. I’m not saying at all that designers don’t care about state.

I disagree. If the UI person could handle a hover-over by defining the state themselves then they and developers would both be happier.

The developer wouldn’t need to implement yet another boolean for something trivial and the designer wouldn’t need to waste time prodding a dev to finally get around to implementing it.

That state has nothing to do with logic or state about the functionality of the program. It’s state who’s entire purpose it to control a bit of the UI.

Kind of. A simple hover, yes. But even then, there are some interactions that are fairly complex, and require in-depth understanding of the event model in order to implement correctly. Like knowing which events bubble and which don’t, for example.

I hear you though, it’s definitely more of a chore for devs to have to define all that stuff. But on the other hand, the UI would otherwise just be done by the time of handoff, which IMO would outweigh those cons.

That’s why I like xstate’s visual state editor. Engineers and designers can both reason about and modify it in tandem.

I think most event models are conflating things much more than they need to be. By having clear point where the data model interacts with the UI model both sides have better clarity. Yes there are complex interactions, but designers also need to understand the model interactions to design the UI correctly.

If you have teams working on a single project and not communicating you’ll have problems no matter what tools you’re using.

Having worked a bit in a conceptually similar product, in my opinion the real problem is how you define the layout of your UI, not the individual components.

There is a sweetspot for nocode where you don’t try to be too general purpose. Concrete examples would be Excel, IFTTT, Airtable, and many of the startups that convert those into apps.

The sour spot is things like Bubble, which while being a fine product suffer from “ok now am really coding but with a clunky UI instead of a text editor” which is a problem inherent in making universal nocode solutions.

With this in mind I think layouts and connected components should be provided to non coding users as templates. E.g. a site where you log in and can show notifications etc. is a single template. You then extend and style that.

Yep. And I’m still on the fence about how to tackle that, but I’ve got some ideas.

My favored approach is to use what I’m calling a “this goes here, that goes there” syntax.

The idea is to give designers a conceptual framework that mimics how they understand layout, and allows them to describe positioning using a syntax that feels as close to natural language as possible.

Much easier said than done, of course. And there are good arguments for allowing the platform dialects to handle those more complex features (in addition to things like scrolling and animation).

My first impression is that this looks a lot like Kivy's "Kv Design Language": https://kivy.org/doc/stable/gettingstarted/rules.html

Ah interesting, wow it does look very similar. I’d heard of Kivy but never looked into it.

The language syntax is in fact inspired by Python; mostly because I tried to remove as many extraneous characters as possible.

Reply on news.ycombinator.com