[daisy] workflow feedback

[Bruno Dumon]

On Sat, 2007-01-20 at 08:40 +0100, Marc Portier wrote:
> 
> 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?

in general, that's true indeed.

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

The feature-wishes I associate with the term save-sandboxes are two
things:

 - automatic backup copies during editing, both to survive browser
crashes (I've been lucky so far: never occured to me while editing) and
to serve as a more extensive undo (no luxury given that custom DOM
manipulations break the editor's undo, and besides I find the 'local
history' feature of intellij very useful from time to time)

 - experimenting with writing in the comfort of privacy or without
interrupting the normal updates of a document (a bit like a user-private
branch): for example you might try to work on improving a document
without being sure it will ever succeed, or you want to write up
something new that might never turn out to be something. Alternatively
one could of course do these things simply on one's own PC, or by
handwriting ...

And now a third case could be the ability to trigger workflow
initiation, though I'm not yet convinced about it. Especially if you
want to work with multiple persons on the document, then putting it in a
private sandbox won't help. Maybe having more version states besides
draft/live could help (like in Min's mail: 'for approval', ...)

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

It's indeed exactly what the current menu does, but customised to the
context of the current document and user. Otherwise, it is hard to know
(and easy to forget) for a user what he's supposed to do to get e.g. a
document approved.

This also reminds me that we should probably auto-display any open
workflow processes or tasks for the current user when he views a
document.

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

yep, this 'easy way' is basically what I was proposing with my custom
menu thing. Whether it's by having multiple save buttons (which will
lead to people opening the editor just to press a different save button,
like they do for changing the draft/live toggle now) or a quick menu on
top of the document.

> 
> 
> -marc= (hoping I'm understanding correctly and have helped understanding)

yes, thanks a lot.

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