Process, state, and form interaction design considerations

[Damon Torgerson]

Hi,

I'm interested in how you design for the interaction of a ruote process and the state of a document/form. I've built a simple application that manages the processing of an application form. Given the simplicity of the process, a state machine attached to the form probably would have sufficed. However, an opportunity exists to provide the same application to multiple customers with tweaks to the process (and form), so rather than hard coding the state machine, I decided to leverage Ruote and support multiple process definitions.

As the participants do their work, I present them with a working queue. In that working queue, I present some details from the form (e.g., applicant's name, etc), and a button to "perform work (task)" wherein the participant is usually required to perform some offline tasks. The "perform work" task expresses the next workitem in the process (e.g., "Verify Address").

E.g., 

Name  City               Next step

             John   Vancouver   Verify Address 

             Fred    Seattle          Verify Income

As I present a fair amount of information from the form in the working queue, I've been thinking about attaching state to the form and just presenting the form in the working queue.

E.g.,

Name   City               State

             John     Vancouver   Form submitted     Perform Next Step 

             Fred      Seattle          Address verified   Perform Next Step

Storing state with the form seems redundant but the approach would eliminate the need to perform a join on the form and the workitems (e.g., I have to get the updated form information to present in the working queue).

Given the ruote and process experience on this list, I was wondering what your thoughts are on when you might combine a state machine with ruote. In the simple example above, would adding state to the form simply be redundant? What other considerations should I...consider?

Regards,

Damon

 

 

[John Mettraux]

On Sat, May 05, 2012 at 06:20:49PM -0700, Damon Torgerson wrote:
>
> Given the ruote and process experience on this list, I was wondering what
> your thoughts are on when you might combine a state machine with ruote. In
> the simple example above, would adding state to the form simply be
> redundant? What other considerations should I...consider?

Hey guys, feel free to answer to this thread, we all faced this at some
point. Please help Damon.

OK, personally, I like to use quaderno
http://jmettraux.wordpress.com/2010/09/22/quaderno/ to do forms with ruote.
With or without using quaderno, I tend to have a matrix process/user/task to
decide which form to present to a user given a workitem and the process it
belongs to. It looks like a routing system.

Now your idea of having separate forms and form data as resources sure sound
good. If you need to enforce some behaviours on state change, then, yes, a
state machine might come in handy.

Using a workflow engine is orchestrating resources.
Using state machines is choreographing resources.
Both can be used together, there are pluses and minuses on both sides.
There is state without state machines.
Workflows and state machines break or go out of sync, resources stay and the
show must go on.

If the data stays in the form then it's probably better not to duplicate this
data in the workitem. A reference/link to the form is sufficient.

Not sure if this answer will help, I hope others will chime in.

Cheers,

--
John Mettraux - http://lambda.io/jmettraux

[Damon Torgerson]

On Saturday, May 5, 2012 6:47:04 PM UTC-7, John Mettraux wrote:

On Sat, May 05, 2012 at 06:20:49PM -0700, Damon Torgerson wrote:
>
> Given the ruote and process experience on this list, I was wondering what
> your thoughts are on when you might combine a state machine with ruote. In
> the simple example above, would adding state to the form simply be
> redundant? What other considerations should I...consider?

Hey guys, feel free to answer to this thread, we all faced this at some
point. Please help Damon.

John, thanks for your willingness to help me with the basics. I really appreciate it!

 

OK, personally, I like to use quaderno
http://jmettraux.wordpress.com/2010/09/22/quaderno/ to do forms with ruote.
With or without using quaderno, I tend to have a matrix process/user/task to
decide which form to present to a user given a workitem and the process it
belongs to. It looks like a routing system.

Quademo looks interesting and relevant for me. How/where do you persist the form data?

 

Now your idea of having separate forms and form data as resources sure sound
good. If you need to enforce some behaviours on state change, then, yes, a
state machine might come in handy.

Using a workflow engine is orchestrating resources.
Using state machines is choreographing resources.
Both can be used together, there are pluses and minuses on both sides.
There is state without state machines.
Workflows and state machines break or go out of sync, resources stay and the
show must go on.

Orchestrating vs choreographing is an interesting metaphor that I've seen a bit in the process community. For a simple sequential process, then it appears to me that the line between ruote and a state machine might get blurry.

[John Mettraux]

On Sun, May 06, 2012 at 09:30:00AM -0700, Damon Torgerson wrote:
>
> On Saturday, May 5, 2012 6:47:04 PM UTC-7, John Mettraux wrote:
> >
> > On Sat, May 05, 2012 at 06:20:49PM -0700, Damon Torgerson wrote:
> >
> > OK, personally, I like to use quaderno
> > http://jmettraux.wordpress.com/2010/09/22/quaderno/ to do forms with
> > ruote.
> > With or without using quaderno, I tend to have a matrix process/user/task
> > to
> > decide which form to present to a user given a workitem and the process it
> > belongs to. It looks like a routing system.
>
> Quademo looks interesting and relevant for me. How/where do you persist the
> form data?

Well, most of the time, in the workitem itself.

Ah, a note about the form / routing system (no quaderno involved) in a Rails
context, it follows this schema usually:

app/views/forms/_{task_name}.haml
app/views/forms/{participant_name}_{task_name}.haml
app/views/forms/{participant_name}.haml
app/views/forms/default.haml

where default.haml is the default form (only development mode) it's used when
there is no specific form for a participant name / task name pair.

> > Now your idea of having separate forms and form data as resources sure
> > sound
> > good. If you need to enforce some behaviours on state change, then, yes, a
> > state machine might come in handy.
> >
> > Using a workflow engine is orchestrating resources.
> > Using state machines is choreographing resources.
> > Both can be used together, there are pluses and minuses on both sides.
> > There is state without state machines.
> > Workflows and state machines break or go out of sync, resources stay and
> > the
> > show must go on.
>
> Orchestrating vs choreographing is an interesting metaphor that I've seen a
> bit in the process community. For a simple sequential process, then it
> appears to me that the line between ruote and a state machine might get
> blurry.

If you only have sequentials processes and enact them by having a Process
resource and a [different] state machine for each instance of it, then yes,
it's very blurry.

http://www.engineyard.com/blog/2011/ruote-and-flow/

Of course, I may be [very] wrong. Ruote is just routing workitems among
participants, for the rest, please be creative.