RE: UI for authoring SCXML documents

Thanks for the feedback everyone. The responses below mirror my experience. One analogy is ETL tools. I’ve used graphical ones before, and when you’re doing basic stuff – like the tutorials – they look great. But once we got into real production ETL flows, the graphical view often took more time to understand compared to an equivalent XML representation – e.g. in something like Apache Camel or Spring Integration – because the graphical view hid so much code in each of the boxes.

It seems to me that it’d be common to run into the same problem with SCXML machines. Based on previous experiences, I expect to use the <script> elements for many transitions, as I’ll often need to invoke application-specific code. Viewing the XML of that machine in a text editor makes the code very obvious, and I think it naturally blends in with the other state/transition/etc elements. But in a graphical view, it’s very unlikely that that code would be immediately visible – I’d basically be working at different levels of abstraction in the graphical view, whereas everything is at the same level in a text editor.

In any case, it’s great to get this feedback as I start working with SCXML more. Here’s the project I’ve started - https://github.com/rjrudin/ml-scxml - and Jacob, a big thanks for all the test cases you put together at https://github.com/jbeard4/scxml-test-framework , I’ve been using those as a guide to better understand the spec.

One final note – this is a nice MarkLogic-based search interface for w3.org emails, it’s what I’ve been using to find SCXML-related information - http://markmail.org/search/?q=list%3Aorg.w3.www-voice


Rob

From: Michael Bodell [mailto:bodell@247-inc.COM]
Sent: Wednesday, July 29, 2015 7:37 PM
To: Jacob Beard; Rob Rudin
Cc: www-voice@w3.org
Subject: RE: UI for authoring SCXML documents

Let me chime in as a +1 to both the ask and the answer.

I think much of SCXML should be very approachable from a text editor quite productively, similar to what Jacob describes.  And most of the SCXML state machines that we use in production (and we use quite a few in real world deployments) are either written by hand or written by code (which is written by hand and essentially a combination of some hand written states plus some states driven by template like patterns across generic publish time domain data which infers certain states and transitions).

But I also have found when trying to evangelize for SCXML in various contexts that there are large community of potential users who are, for lack of a better term, freaked out by raw text editing of anything, much less angle-bracketed XML.

One thing that I think would be very useful (and some of Jacob’s code and tools move towards) would be the equivalent of JS Fiddle of SCXML (https://jsfiddle.net/ for those not familiar).  JS Fiddle lowers the bar to integrating HTML + CSS + JS to see both the code view of all 3 of those, but also the visualization result, complete with the ability to then run the content.

If there was an equivalent for SCXML with a state machine content, data model, visualization, and ability to inject events and execute all in one browser pane I think that would be quite valuable.  And if there were SCXML interpreters that were well positioned to run in the standard web browsers (I.e., JS based SCXML interpreters like SCION) as well as the visualization tools ready to generate visualization in the browser (like SCHVIZ), then I think that would be handy.

An early version of that is available, of course, from the links Jacob provides: (http://goo.gl/wG5cq)

A lot of people, again based on evangelizing SCXML to those not yet familiar with its power, want a fully bi-directional GUI drag and drop SCXML editor.  I think that is mostly unrealistic and hard to get right, since once your state machine becomes non-trivial, the data model logic and conditional information means you’ll be attaching code snippets all over your visual representation which clutters it up and will either be ignored (turning your state machine visualization into a mostly useless simplification) or so detailed that you essentially have SCXML code again.  But if someone does create a good solution to this problem, it will be popular!

From: Jacob Beard [mailto:jake@jacobeanrnd.com]
Sent: Wednesday, July 29, 2015 3:50 PM
To: Rob Rudin
Cc: www-voice@w3.org
Subject: Re: UI for authoring SCXML documents

Hi Rob,

I have done some work on automated layout:

https://github.com/jbeard4/scxml-viz

https://github.com/JacobeanRnD/SCHVIZ


SCHVIZ is bundled with the microexpresscion SCXML orchestration server: https://github.com/JacobeanRnD/microexpresscion


My philosophy has been that full graphical editing environments are hard to get right, and that SCXML can be edited productively using text/xml editors, with automated graphical layout tools used to visualize the document.

I’m planning to package SCHVIZ into a stand-alone command-line tool. It should be released in a few weeks.

If you have any questions or comments, please don’t hesitate to ask. Thanks,

Jake

On Jul 28, 2015, at 10:09 PM, Rob Rudin <Rob.Rudin@marklogic.com<mailto:Rob.Rudin@marklogic.com>> wrote:

All – I’m working on an implementation of SCXML for MarkLogic (http://www.marklogic.com/), and I’m curious if SCXML users have UI-driven tools for authoring and managing SCXML documents, or if they are largely edited by hand using text/XML editors.

Related to that – has consideration been given to some sort of integration between BPMN and SCXML such that the output of a BPMN tool could be transformed into an SCXML document? I don’t know enough about BPMN to know if this is feasible, but it just seems like SCXML could use some sort of UI for making it easier to author/manage SCXML documents.

Thanks,
Rob