[Framework-Team] testing plone.app.workflowmanager

[Nathan Van Gheem]

Thanks Lawrence,

I played with all the libraries you suggested.

jsplumb is the obvious choice IMO. I'm going to start playing around with
how the layout might work--I have some ideas.

On Thu, Sep 13, 2012 at 6:58 AM, Laurence Rowe <l at lrowe.co.uk> wrote:

> On 13 September 2012 02:19, Nathan Van Gheem <vangheem at gmail.com> wrote:
> >>>> Maybe we can generate some kind of state chart graph for them?
> >>>
> >>> If graphviz is installed, there is a button activated that'll generate
> a
> >>> graph for you. Or do you mean something different?
> >>
> >>
> >> Will people have graphviz installed? There are JS libaries that can
> >> visualise things like this, which may be better.
> >>
> >> My overarching thought is that we should start with:
> >>
> >>  - A list of workflows (including existing ones, shown, but readonly)
> >>
> >>  - Buttons on each like "copy", "delete", "edit" (see the new
> p.a.theming
> >> UI for this)
> >>
> >>
> >>  - Once you open one up, some kind of in-HTML representation of states
> and
> >> transitions and how they relate to each other (like a directed graph).
> Maybe
> >> that's a graph drawn (in JS on canvas, say) to show states and
> transitions,
> >> and you click on each to bring up an overlay with editing options. You'd
> >> have an "add state" button next to this map to add a new state, and
> maybe an
> >> "add transition" button when editing a state, which would let you
> choose an
> >> existing transition, or create a new one". Bonus for some kind of
> >> drag-draw-an-arrow thing, but not necessary.
> >
> > I actually went down this path long ago when we were thinking through
> this.
> > This visual representative workflow UI is nice for small workflows but
> for
> > complicated workflow, it really breaks down and becomes difficult to
> > handle--hence, using the ordered list of states and transitions. I'll
> think
> > about it though. Perhaps there is some sort of hybrid way we can work
> out.
> >
> >>
> >>
> >> I think the mental model required to understand "there's a list of
> states,
> >> and there's a list of transitions, then once you've built those two
> lists,
> >> you link them together here and here, and then you have workflow" is
> really
> >> confusing.
> >
> > I do agree with this... It's a nasty, complicated UI when you're
> introduced
> > to it. I guess we never really tried to shy away from nastiness as we
> were
> > only ever targeting power users.
> >
> >>
> >> The two feel very disparate (also in the ZMI version of this, of course,
> >> and to an extent in the code behind it all). I'm compelled to try to
> draw it
> >> out on a piece of paper when I look at it, which is probably not quite
> >> right.
> >>
> >> If we managed to get something to pull it all together, then I think the
> >> rest of the feedback is all just about details of layout and text.
>
> I browsed around for something that could produce a suitable graph,
> but its difficult to find a library that combines both automatic
> layouts with something suitable for displaying a state machine
> digraph. The options seem to be:
>
> - liviz.js. This is a straight cross-compile of graphviz to
> emscripten, as a result it seems rather heavy.
> http://ushiroad.com/jsviz/
>
> - d3.js. Really powerful library but I can't find a way to make it
> layout multiple edges between the same nodes (eg. reject, retract)
> sensibly. http://d3js.org
>
> - dracula. Has layout support, but again seems to fail with multiple
> edges, they get rendered along the same curve.
> http://www.graphdracula.net/
>
> - jsplumb. Handles multiple anchors per node to support multiple edges
> well, but no automatic layout ability (perhaps that could be ported
> from dracula as they both use the same underlying raphael vector
> library.) Really cool drag and drop state machine demo:
> http://jsplumb.org/jquery/stateMachineDemo.html.
>
> The thing that really complicates a graphical editor is that
> transitions may be triggered from multiple states and may have 'remain
> in state' as their destination, so we can't just treat transitions as
> a different sort of node. Treating the edges as simple connections
> rather than transitions might work. On making a new connection, an
> overlay could be shown allowing the user to pick from a valid existing
> transition or give the id / title of a new transition.
>
> Automatic layout for complex workflows is never going to be very
> satisfactory. Maybe we just need to let people drag and drop and save
> the layout as a property of the workflow.
>
> Laurence
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.plone.org/pipermail/plone-framework-team/attachments/20120916/78e67762/attachment.html>