The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be.
For example, you have an action that will ask some remote server whether the user has a permission to do something, and if it receives a positive response, it performs that action and only then updates the UI (and shows the error UI if the user doesn't have the permission).
With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
>For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code.
That's fine, but I don't count that as an interaction. In React, you would just define that as a prop and pass it to the buttons and the keypress event, so that would be ok. `setState` would not be ok (unless it only stays in the mockup and is not exported).
> With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
Why couldn't you just go into the code and specify the error UI? You still have JS/React available to you at any point. The GUI tool is just to aid with rapidly building stuff, not as a replacement. We're not talking about a visual programming language here.
And if handling error cases is expected, then the tool could provide an option for specifying error UIs.
> Why couldn't you just go into the code and specify the error UI?
Because usability professionals typically don't know how to code.
> The GUI tool is just to aid with rapidly building stuff, not as a replacement.
My point in this thread is that, with a tool like this, it could be.
I said elsewhere that mockup tools used by UI designers already have a development environment very close to this one, and only a good code generator is missing.
A mockup environment which can communicate logic to the devs, and not just visuals, is everything these professionals need to create specifications fully in software without resorting to natural language that the developer needs to interpret.
> The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be.
> With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
This also happens if you build the component in code, no? I fail to see how this is specific to a visual tool. A professional should take care of all cases, regarding of the medium of the tool.
> That's fine, but I don't count that as an interaction.
That was just the simplest example I came up with in ten seconds. For more complex examples of what interactions you can build purely with a visual tool that then spits code, see Apparatus [1] or Stop drawing dead fish. [2]
I can imagine building components easily in an environment like that. We already could do that in the Flash/ActionScript environment in a limited fashion, but the results were very limited (state could only be represented as a video timeline), and the platform itself was terrible.
>This also happens if you build the component in code, no? I fail to see how this is specific to a visual tool. A professional should take care of all cases, regarding of the medium of the tool.
If you want to do it correctly in the tool and tie the UI update to the "permission granted" response, that event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI.
So again, this breaks the isolation because the component in the tool now has to know about this.
In contrast, if you're writing the component in code, and find something missing, you can just go "oh, guess I'll just add that to the appropriate place".
I can imagine the tool exporting some kind of interface with a list of things it needs (project-wide, across different components), that the developers would then implement, but with that we're getting pretty far from existing real-world React patterns. It's also starting to approach the difficulty of just learning to code in the first place.
> That event (or part of a store, or however it's implemented) already has to be defined in code (even if it's just a stub) by the time you're making the UI.
That's a good point. A visual tool for building components will need a testing feature that can keep all those stubs. But isn't that just like Test-Driven Development?
> It's also starting to approach the difficulty of just learning to code in the first place.
Not at all.
In any design, you'll have to think about all the cases thoroughly and systematically; and any rational people can do that. But coding in a general purpose language has the additional requirement of having a mental model of the execution platform and conveying precise instructions; it's not enough to think in terms of the problem being solved. That makes all the difference to people without coding experience.
The syntax of programming languages is particularly tricky and difficult to learn. The people working with Chris Granger, the designer of Light Table, found that users of visual development tools find it incredibly difficult to understand scope. And coding in any modern general PL is all about scope.
You may think of this kind of visual environment as a particular Domain Specific Language. The users are coding in it, but the programming language is not general purpose, which makes it not "coding" as developers understand it.
> I can imagine the tool exporting some kind of interface with a list of things it needs (project-wide, across different components), that the developers would then implement
BTW, the mockup tools I'm talking about already offer that kind of interfaces to define the list of coding requirements generated by the user interface prototype. They cough up that list of requirements as a Word document or web page, though. Wouldn't it be best to generate those as placeholders in code?
For example, you have an action that will ask some remote server whether the user has a permission to do something, and if it receives a positive response, it performs that action and only then updates the UI (and shows the error UI if the user doesn't have the permission).
With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong.
>For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code.
That's fine, but I don't count that as an interaction. In React, you would just define that as a prop and pass it to the buttons and the keypress event, so that would be ok. `setState` would not be ok (unless it only stays in the mockup and is not exported).