Seems like a somewhat unfortunate naming when one of the leading design prototyping tools are called Sketch (<a href="https://www.sketchapp.com/" rel="nofollow">https://www.sketchapp.com/</a>).<p>Looks pretty cool, though.
Looks cool - should I be concerned about the terms and conditions? "However, by posting Content using the Service you grant us the right and license to use, modify, publicly perform, publicly display, reproduce, and distribute such Content on and through the Service. You agree that this license includes the right for us to make your Content available to other users of the Service, who may also use your Content subject to these Terms."
I like how this encourages designers to think about all the states of a UI component.<p>I understand that there are designers and design orgs out there with the discipline to be detailed in their design to cover all states of a UI element. There are also many designers that just design for the happy path. For the latter, we need to ensure they start to think about edge cases for what they are designing.
As a developer, I feel like the target market are product owners or managers that want to pretend to have bigger product insight than is viable for their role. At the point where you're building these complex mockups featuring real logic and real code you might as well code it out. If it takes you much longer to release a test build than make a prototype in this cluttered UI then you should be working on your tooling.
Looks great! Probably even has applications for anybody prototyping a Finite State Machine, which are very common. Also, I'm not aware of any intuitive FSM design tools which one can "get" in a 5 min tutorial.
This is really nice and looks great. The diagram is super useful and I could see myself using this for the rough planning of an app. That being said, I feel like like the use cases are super limited unless you flesh it out some more. There needs to be a way of encoding more information about state, maybe scoped variables that you can modify on events or something!
As a UX Designer with limited coding abilities this looks very interesting. I tried to describe a little feature that we will need to build soon. That was pretty straightforward, but I also felt very limited as there was no way to comment anything in the spec.<p>But it can be really helpful to think through all the states that the application can be in, something I often neglect. Not sure if I will automatically think through the non-happy paths, but it might help.<p>With a more fleshed out syntax, I could very well see myself using this. But I don't see myself using the Javascript / prototype part, if I actually to that I could probably just create a prototype in Vue.js, which then also would describe all the states. I would focus on the spec part and make that more powerful.
This looks fantastic, excellent job.<p>It's tough to find the right balance between an initial design and an actual plan is user interactions, especially without having to go down the whole prototyping path.
As a product person. I personally feel if the designer should know how to code so they can skip this tools process. It seems to add more unnecessary complexity to the design process for those designers who know how to code and understand how to fix issues as they arise.