3 ms·

> I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. The idea is to hav

> I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. The idea is to have both. Finally this is possible thanks to reactive programming. UI designers make mockup tools that basically support that kind of rule-making with drag and drop, but that logic cannot be exported to the development environment, only the visual components. With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves in the prototyping tool, rather than having to write them down in English in a specification document for developers to re-write them in a proper language.

realharo 9y ago
>With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. When doing just the look of a component as a pure function (just the render function and nothing else), that can be achieved, but as soon as you allow the design to have side-effects, that isolation is gone. Unless that's not what you meant...
- TuringTest 9y ago
  > I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. A UI designer should be able to develop the interactions over a single component isolated. 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. In reactive programming, the effects of each interaction don't need to be represented as side-effects, but as output of events over a functional and composable "stream". UI designers can learn to think in that programming model, which is way saner than callback hell.
  - realharo 9y ago
    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).
    - TuringTest 9y ago
      > 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. [1] http://aprt.us/ http://aprt.us/ [2] https://vimeo.com/64895205 https://vimeo.com/64895205
      - realharo 9y ago

realharo 9y ago

>With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. When doing just the look of a component as a pure function (just the render function and nothing else), that can be achieved, but as soon as you allow the design to have side-effects, that isolation is gone. Unless that's not what you meant...

TuringTest 9y ago
> I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. A UI designer should be able to develop the interactions over a single component isolated. 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. In reactive programming, the effects of each interaction don't need to be represented as side-effects, but as output of events over a functional and composable "stream". UI designers can learn to think in that programming model, which is way saner than callback hell.
- realharo 9y ago
  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).
  - TuringTest 9y ago
    > 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. [1] http://aprt.us/ http://aprt.us/ [2] https://vimeo.com/64895205 https://vimeo.com/64895205
    - realharo 9y ago