[daisy] workflow feedback

[Bruno Dumon]

Thanks for taking the time to write out this feedback, some first
thoughts inline.

On Fri, 2007-01-19 at 17:16 +0100, Steven Noels wrote:
> On 22 Nov 2006, at 12:52, Marc Portier wrote:
> 
> > Hi all,
> >
> > Here is some feedback/suggestions/questions from my first use of the
> > workflow in 2.0-dev:
> 
> Adding onto that, I did my own review today. And I had some general  
> thoughts as well - after showcasing the current state to a willing  
> end-user victim (aka Customer).
> 
> Workflow in Daisy
> 
> Idea behind these notes: either workflow is useful or it sucks.
<snipped the cheap sucks-rant ;-) />

> 
> * Automated initiation of workflow process
>
> For workflow to become really user-friendly, document save sandboxes  
> really should be available. Which is a problem because they are not. :-)
> 
> Sandboxes create the distinction between 'save' and 'commit', whereas  
> 'save' saves a document version in a user-specific location (a  
> function of the Wiki application rather than the repository), and  
> 'commit' saves the document into the repository while creating a new  
> version. A commit operation is required to make new document versions  
> available for other users - saved versions only exist for the person  
> editing or creating the document version.
> 
> With this distinction, there is a logical point to introduce  
> automated initiation of a workflow process into the commit procedure.  
> When committing a document version to the repository, depending on  
> configuration/setup, either the user can select a workflow process to  
> be initiated (from a list of possible options, possibly pre- 
> configured depending on version properties), or a process can be  
> started automatically.

Regardless of the save-sandboxes which would also be very useful without
workflow, I think the more important point here is that the user should
be able to easily figure out what to do without special training.
Sandboxes at first appear to me as something which brings its own
complexities and hence make the learning curve steeper.

Since the document XSLTs have access to info about the current user and
the user's rights on the document, it would be easy to let these render
a panel on top of the document showing the most important relevant
actions, such as 'Edit' and 'Request publication', possibly with a link
to a 'quick help for authors' page.

> 
> * Configuring automated (or suggested) initiation of a workflow process
> 
> Currently, only the document ID seems to be used to parametrize a  
> workflow process. Depending on other version characteristics however,  
> more automatic configuration should be possible.
> 
> Some use cases.
> 
> 1) Based on document type. Depending on document type, a reviewers  
> pool is pre-selected. Newsrelease documents will be reviewed by the  
> tech department pool - product usage notes by the engineering  
> department.
> 
> 2) Other document properties. Depending on a document field value,  
> the due date is pre-set. A press-release with a field Priority set  
> with a value High gets a review due date within 1 days. A Normal  
> priority value sets the due date to current day + 4 working days.
> 
> 3) User characteristics. Depending on 'group membership', a pool is  
> pre-selected. My roles are 'user' and 'engineering', which means  
> review processes will always be initiated with the engineering pool  
> pre-set.
> 
> (sidenote: is the user/pool selection thingy hard-coded or  
> configurable? does it depend on the process definition or daisy  
> process meta model?)

It is the standard edit control shown for variables of type
'actor' (this is declared in the daisy meta layer).

Right now it is already possible to not ask the user for these things,
and simply let the workflow process decide on them, where the logic can
be implemented in javascript or java.

Also, this is mostly an issue for the very first task (the "start task")
of the workflow, since for subsequent tasks the variables can be
pre-populated by actions in the process definition. In fact, for the
start task we could do something similar, by starting a process before
showing the start task form, but without persisting this process
instance.

-- 
Bruno Dumon                             http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno at outerthought.org                          bruno at apache.org