Hi @BenjaminMoser , I had a think about this, and you are right that this possibly is a unique use case, because it isn’t adding anything in terms of doing anything to the data or making things work better.
It’s visual feedback from the workflow about how the workflow itself is progressing. In a sense it’s a bit like “breaking the fourth wall” in the theatre, where the cast member acknowledges that they have an audience and starts talking to them 
My initial thought was that having the loop start or end nodes provide such feedback made sense, but whilst any loop can tell you how many iterations it has performed so far, not all loops know how many more they have to go.
Table Row to Variable Loop Start, for example knows the currentIteration and the maxIterations so it could theoretically provide visual information at the beginning of each iteration about % completion, but many of the loop nodes do not have this prior knowledge and so it require a calculation to be done (assuming such information is even calculable).
I did look at components with some kind of visual feedback such as a bar chart, but they quickly become far too heavyweight and either the drawing of a small chart takes too long so it never displays, or its presence greatly slows the loop; the last thing you want when the whole point is that the loop is likely taking a while already, hence wanting to be able to continually observe progress.
The other thing about either monitoring a component or drawing a graphic is that on each iteration the component/node is reset and this might therefore cause a potential “refresh flicker” or worse,when what you really want is a continuous display.
One feature of the Node Annotator is that changing the node’s annotation to provide the graphic (using some emojis that happen to look like graphics) is quite lightweight in its execution. The other feature that was useful here is that it has the option to not reset the caption even though the node has been reset. That was crucial to having it look relatively smooth in operation, like it was actually drawing the progress bar. If you turn that off, it resets on every iteration prior to drawing and the effect is not optimal!
So actually I think that even for a built in solution, I’d go for the option of placing a “progress/feedback” node on the workflow much as I’ve done with the component idea, and have it adjust it’s caption.
Given that we can see from Nodepit’s Node Annotator that the pieces are all avaliable without requiring new functional complexity, I don’t really feel the need for a complex alternative mechanism.
Using emoji for the graphic is a little clunky. It would be better if we could also change the font size of the node annotation in this situation to reduce the width whilst retaining the visual information.
-
I’d prefer this to be available as a node rather than a component simply because components remain “second class citizens” without there being a “component palette” within KNIME. The hub is good but it’s still a less efficient context switch to go grab a component than it is to use a node.
-
Sure, if we are blue sky thinking on this, then maybe a side panel in KNIME that gave progress bars for all loops might be nice but you’d still have to provide a way of configuring it for loops that didn’t know the “maxIterations”, and feels like overkill.
, I was inspired to learn some usage of Annotator related nodes. This is the effect on Mac.
. This all brings back fond memories of programming animations on early 8 bit micros!
.
