Difference between revisions of "Talk:Workflow example"

From Organic Design wiki
(comments)
 
(6 intermediate revisions by 3 users not shown)
Line 3: Line 3:
  
 
I've done some testing. All looks good except there is a problem with the definition of workflows. Seems that specifying each bullet point as a ''state'' makes sense but perhaps they should be Templates rather than normal articles. At least the #workflow parser functions appear to expect them to be. Seems logical to make them templates also. I can imagine situations where a set of states are shared by more than one workflow. I have used a subpage to separate this in my examples, (See [[Sandbox]]) but perhaps it is better to represent each state as the high-level thing that it is.
 
I've done some testing. All looks good except there is a problem with the definition of workflows. Seems that specifying each bullet point as a ''state'' makes sense but perhaps they should be Templates rather than normal articles. At least the #workflow parser functions appear to expect them to be. Seems logical to make them templates also. I can imagine situations where a set of states are shared by more than one workflow. I have used a subpage to separate this in my examples, (See [[Sandbox]]) but perhaps it is better to represent each state as the high-level thing that it is.
 
+
:There's no problem using the same generic words in many workflows because they can be categorised by the workflow name as well
 
An example is the ''work-in-progress'' state. This is a general idea in many workflows where we are allocating time to a job. Should there be a subclass for each of the different workflows in which this may be used? Seems a bit ugly but perhaps necessary in some situations.  
 
An example is the ''work-in-progress'' state. This is a general idea in many workflows where we are allocating time to a job. Should there be a subclass for each of the different workflows in which this may be used? Seems a bit ugly but perhaps necessary in some situations.  
 +
:I think thats more about scheduling and I'm planning on tying that in later, but I think the current way is only good for things that move through definite states over indefinite periods.
 +
In any case we need to get the display of the subpage down to it's ''leaf'' only so we see ''Lead'' instead ''Order/Lead''. This could be difficult to achieve, and as such may be a reason not to approach the problem using subpages. --[[User:Rob|Rob]] 19:08, 27 October 2007 (NZDT)
 +
:Good idea, I'll add that in now :-) --[[User:Nad|Nad]] 19:17, 27 October 2007 (NZDT)
  
In any case we need to get the display of the subpage down to it's ''leaf'' only so we see ''Lead'' instead ''Order/Lead''. This could be difficult to achieve, and as such may be a reason not to approach the problem using subpages. --[[User:Rob|Rob]] 19:08, 27 October 2007 (NZDT)
+
Looks like there's some development still going on. Here is some output from [[Template:Smile]]:
 +
<pre>
 +
{{#Workflow:Order|state=Order/Consultation/Contract/Work in progress/Lead/Debtor/Paid/Archive/Signed off/Consultation/Contract/Work in progress/Lead/Invoiced/Lead|size=25px}}
 +
</pre>
 +
Maybe this could explain the out-of-order problem. --[[User:Rob|Rob]] 19:50, 27 October 2007 (NZDT)

Latest revision as of 20:06, 2 December 2008

That old problem of not wanting the image to be clickable is showing up here - we need the image to just be in the background, but that's not easy to implement from a standard template, so it would have to be hard-wired. Rather than hard-wiring an image based on a parameter, I'll make part of the workflow frame have next/prev buttons so that it's obvious they can be changed and means the image can link like normal.

This is looking real good already. The forward/Back buttons are a good idea, you definately want ot be able to step in either direction in the workflow, not just cycle forward throught the sequence. --Sven 23:59, 26 October 2007 (NZDT)

I've done some testing. All looks good except there is a problem with the definition of workflows. Seems that specifying each bullet point as a state makes sense but perhaps they should be Templates rather than normal articles. At least the #workflow parser functions appear to expect them to be. Seems logical to make them templates also. I can imagine situations where a set of states are shared by more than one workflow. I have used a subpage to separate this in my examples, (See Sandbox) but perhaps it is better to represent each state as the high-level thing that it is.

There's no problem using the same generic words in many workflows because they can be categorised by the workflow name as well

An example is the work-in-progress state. This is a general idea in many workflows where we are allocating time to a job. Should there be a subclass for each of the different workflows in which this may be used? Seems a bit ugly but perhaps necessary in some situations.

I think thats more about scheduling and I'm planning on tying that in later, but I think the current way is only good for things that move through definite states over indefinite periods.

In any case we need to get the display of the subpage down to it's leaf only so we see Lead instead Order/Lead. This could be difficult to achieve, and as such may be a reason not to approach the problem using subpages. --Rob 19:08, 27 October 2007 (NZDT)

Good idea, I'll add that in now :-) --Nad 19:17, 27 October 2007 (NZDT)

Looks like there's some development still going on. Here is some output from Template:Smile:

{{#Workflow:Order|state=Order/Consultation/Contract/Work in progress/Lead/Debtor/Paid/Archive/Signed off/Consultation/Contract/Work in progress/Lead/Invoiced/Lead|size=25px}}

Maybe this could explain the out-of-order problem. --Rob 19:50, 27 October 2007 (NZDT)