[daisy] workflow feedback

Marc Portier mpo at outerthought.org
Sat Jan 20 01:40:49 CST 2007



Bruno Dumon wrote:
> On Fri, 2007-01-19 at 17:16 +0100, Steven Noels wrote:

Uh, me trying to understand that this is more then a matter of style and
wording...

>> * 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.
> 

hm, not all features have to make things more complex, it's a matter of
implementing it the right way, I guess?


anyway, I don't want to make this a semantical discussion, yet I think
it is important that we all understand what is meant:

Thinking about these "save-sandboxes without workflow" make it sound
like an earlier requested feature about allowing (intermediate) document
saves within a session that do not cause a version upgrade on the server?

If memory serves correctly main use case for this is to be able to
survive browser crashes in the middle of your work. (In fact with the
advanced recovery of ffx 2.0 we should test if this keeps being an
urgent/valid use case?)

Sometimes this has even been requested across sessions, in which case it
was more oriented towards hiding that an editor needed more then one
version to complete his work (which I find a silly reason taking into
account we have a 'live/draft' switch)

> 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.
> 

I don't get these 'actions' it sounds like what our current menu already
does?  Were you referring to workflow oriented transitions?



As I understand there is already now a difference in user-actions between
* 'save' (as in version upgrade) and
* 'proceed/update' (as in entering the wizard to choose the workflow
state transition and leave a comment)

So actually what is asked for is maybe not 'save-sandboxes' (which we
have in fact: save now does upgrade versions without workflow being
triggered) but quite the opposite: an easy way to
  - save-with-workflow-progression
  - save-with-workflow-initiation


-marc= (hoping I'm understanding correctly and have helped understanding)
-- 
Marc Portier                            http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at                http://blogs.cocoondev.org/mpo/
mpo at outerthought.org                              mpo at apache.org


More information about the daisy mailing list