Hey steinar,
while creating the tutorials thread, i recognize something i recognize for most other workflow engines that i daily use as well:
It would be great if you could write and store different comments along with a workflow:
-) comment workflow (one comment per workflow)
-) comment processor (one comment per processor in a workflow)
-) comment saved instances of processors (e.g. each "template" for write text file processor)
-) comment any value of any processor (ok, this is unrealistic to implement but it would still be a good feature)
Please forgive the shortness of this request but i guess you understand and benefits and efforts of a feature like this very well and you work on the refactoring currently.. but maybe this is something you want to consider while refactoring
cheers,
emcodem
Workflow development: comments
Workflow development: comments
emcodem, wrapping since 2009 you got the rhyme?
Re: Workflow development: comments
Hi emcodem:-)
What would be the differenve between the current "description"-options in the nodes and the workflow, and the comments?
Saving comments for templates would be a good idea:-)
And the last request...well, I'm not sure about that one. It seems to be "a lot" but maybe you could give some "visualization'?
-steinar
What would be the differenve between the current "description"-options in the nodes and the workflow, and the comments?
Saving comments for templates would be a good idea:-)
And the last request...well, I'm not sure about that one. It seems to be "a lot" but maybe you could give some "visualization'?
-steinar
Re: Workflow development: comments
Hey Steinar!
i just listed all points that came to my mind that can take such complex inputs that they need commenting and versioning (didnt mention that)
You are sure correct that the current "description" field for each processor will suffice for extensive documentation, it is just hard to read in the little textbox , could use some scaling for longer text.
Regarding all textboxes, i don't think it will work to comment/version all of them, it is just too much work. The visualisation could/would look like just a comment in a word document or just a small "i" symbol. However as nobody that i know has this, i guess it don't make sense
What users could comment there is e.g. why they used the ip of a server instead of the name (networking troubles) or other interesting info that cannot really be documented anywhere else.
cheers,
emcodem
i just listed all points that came to my mind that can take such complex inputs that they need commenting and versioning (didnt mention that)
You are sure correct that the current "description" field for each processor will suffice for extensive documentation, it is just hard to read in the little textbox , could use some scaling for longer text.
Regarding all textboxes, i don't think it will work to comment/version all of them, it is just too much work. The visualisation could/would look like just a comment in a word document or just a small "i" symbol. However as nobody that i know has this, i guess it don't make sense
What users could comment there is e.g. why they used the ip of a server instead of the name (networking troubles) or other interesting info that cannot really be documented anywhere else.
cheers,
emcodem
emcodem, wrapping since 2009 you got the rhyme?
Re: Workflow development: comments
One thing that comes to my mind is that i did not really yet recognize the existing "description" field of a processor in the workflow canvas for documentation purposes:
It is not visible to the user that there is more than the few visible words contained in the description field. So if i wrote some exhaustive documentation in there in the "example workflows thread", most users would possibly not read them or they would have to doubleclick each processor to see if there is more description available than there is shown on the canvas...
When thinking about that, it comes to my mind that becaues of this i tend to keep the current description field as short as possible, hopefully fitting into the visible area after saving.
A possible indication could look like a colored bar on the bottom (with a simple rule like "if length of description > 250")
It is not visible to the user that there is more than the few visible words contained in the description field. So if i wrote some exhaustive documentation in there in the "example workflows thread", most users would possibly not read them or they would have to doubleclick each processor to see if there is more description available than there is shown on the canvas...
When thinking about that, it comes to my mind that becaues of this i tend to keep the current description field as short as possible, hopefully fitting into the visible area after saving.
A possible indication could look like a colored bar on the bottom (with a simple rule like "if length of description > 250")
emcodem, wrapping since 2009 you got the rhyme?