4 ms·
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
by solarmist 4y ago
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.
- danielvaughn 4y agoKind 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.
- solarmist 4y agoThat’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.