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.