Update after some first executions of my migrated experiment:
A first execution of my experiment as saved by the new editor showed constant NaN for one column in the exported CSV file. I easily was able to find the root cause of this error in the container tab in the new editor. While setting the focus to the browser tab to which the new editor was loaded I had apparently done some wrong mouse click(s) and was not only setting the focus to that tab but also the static tag for one container. After removing that unwanted tag the export data of the experiment looked good again (by values in OpenOffice and visually in QGIS). In the new editor displayed tags can be edited right away, in the old editor changing these tags required some additional navigation step into the container popup. On my screen I have in normal display mode 78 container tag checkboxes displayed at once in which I could accidentally set a checkmark. But on the other side this direct display of so many tags supported me nicely in finding the root cause for the NaN. In the old editor the search for that root cause would have needed significant more time, and probably I would have needed to directly analyze the XML file instead. I assume that with the new editor it is less often necessary to go into the XML file and do edits directly in that file. The "instant edit surface" of the new editor is much bigger, you can accidentally edit something, but at the same time the directly visible "debug surface" is bigger the same way. Support for debugging is of higher value to me than the danger to do a wrong click. The linear block display style of the new editor matches more with the XML format in the Phyphox file than the 2d display of the old editor.
The linear (vertical) sequence of the blocks gives a better idea on the sequence of the commands within an experiment execution cycle. In the old editor I needed to edit the modules horizontal position (pixels) in the XML file to exactly control that execution order (horizontal position from left to right). Taking away the 2d design time freedom helped in better understanding / controlling the runtime behavior. My experiment still seems to be able to use a container ahead of its (value) definition, which is a key feature for me to split and build up buffers as I need them for calculations and for export. If the container has no value defined (in my experiment) in cycle 1 there is no negative impact of this missing value and in cycle 2 the calculations are apparently working fine by accessing the container value computed towards the end of cycle 1. This is special, I believe, with Phyphox, you have got the linear execution sequence of the commands establishing your algorithm plus typically about ~200 (assumption) more of the same cycles before the next GPS data set arrives at the typical frequency of 1 Hz.
What I find a little irritating in fluently reading the coding in the new editor are the two different block styles I noticed. For some math blocks the output container is being displayed at the top left area of the block, whereas in other blocks the output container is being shown at the bottom to the right. While reading through the coding the eyes do some slalom. Don't drink and code, don't get dizzy. Maybe the output channels could get another color scheme than the input channels. This could help nicely in concentrating on the data flow at the Analysis tab in the new editor, which could compensate a little for the no longer available "data flow connection lines" from the old editor. But don't become too fancy with colors, color blind people should still be able to notice some differences (e.g. in brightness). Individual containers should not get their own colors, which my approx. 190 containers I would not be able to notice the differences. Highlighting the output channels with some light orange background color would be perfect for me personally in guiding the eyes through the data flow, just to give an idea.
In the old editor it was possible to select multiple modules at once and duplicate them, have not seen this in the new editor, where you apparently need to duplicate individually one block after the other. Actions on multiple blocks at the same time happen not too often and would contradict somehow the snap-in feature of the new editor. Moving around modules in the old editor was easier, in the new one it is necessary to first break the connection between blocks before rearranging them and connect them again. I believe abandoned modules in the old editor made it into the XML file, while abandoned blocks in the new one won't. Due to the 2d layout in was possible in the old editor to see more coding at one screen, but for large projects and a 30% zoom the actual benefit was limited.
I have not measured it but I estimate that I invested something between 120 and 170 old editor hours in my experiment. The migration to the new editor, reviewing and optimizing the experiment took me about additional 20 new editor hours. The old XML file has about 1500 lines, the optimized new XML file has now about 1400 lines (and approx. Analysis 1030 blocks). The performance and code complexity optimization would have been much more difficult in the old editor than they were with the new one. I'm quite happy that the development invest one year ago was not lost (context to explain the invest: the experiment is recording GPS data and derives certain values from this data, one experiment execution saves me about 6 to 8 hours manual work in OpenOffice). What I avoided like hell was to click on the big trash bins in the new editor's UI. For me, deleting everything would be not the main feature of an editor. If I ever should accidentally click on these icons I hope that the cool undo would save me. ... Ok, I was too curious and I clicked and I was surprised. It does not delete everything? But what is it? The log of the undo buffer?
Next step for me is now to set up a real physical experiment in which I have certain input parameters like distances and velocity under direct control. This way I can calculate myself the expected output of the experiment and I should be able to see if my Phyphox experiment would compute the exact same values as the physical theory. But this is beyond the new editor, which helped in a great way to get there. Thanks!!! Goodbye old editor's module connection lines, hello new editor's development efficiency.
A first execution of my experiment as saved by the new editor showed constant NaN for one column in the exported CSV file. I easily was able to find the root cause of this error in the container tab in the new editor. While setting the focus to the browser tab to which the new editor was loaded I had apparently done some wrong mouse click(s) and was not only setting the focus to that tab but also the static tag for one container. After removing that unwanted tag the export data of the experiment looked good again (by values in OpenOffice and visually in QGIS). In the new editor displayed tags can be edited right away, in the old editor changing these tags required some additional navigation step into the container popup. On my screen I have in normal display mode 78 container tag checkboxes displayed at once in which I could accidentally set a checkmark. But on the other side this direct display of so many tags supported me nicely in finding the root cause for the NaN. In the old editor the search for that root cause would have needed significant more time, and probably I would have needed to directly analyze the XML file instead. I assume that with the new editor it is less often necessary to go into the XML file and do edits directly in that file. The "instant edit surface" of the new editor is much bigger, you can accidentally edit something, but at the same time the directly visible "debug surface" is bigger the same way. Support for debugging is of higher value to me than the danger to do a wrong click. The linear block display style of the new editor matches more with the XML format in the Phyphox file than the 2d display of the old editor.
The linear (vertical) sequence of the blocks gives a better idea on the sequence of the commands within an experiment execution cycle. In the old editor I needed to edit the modules horizontal position (pixels) in the XML file to exactly control that execution order (horizontal position from left to right). Taking away the 2d design time freedom helped in better understanding / controlling the runtime behavior. My experiment still seems to be able to use a container ahead of its (value) definition, which is a key feature for me to split and build up buffers as I need them for calculations and for export. If the container has no value defined (in my experiment) in cycle 1 there is no negative impact of this missing value and in cycle 2 the calculations are apparently working fine by accessing the container value computed towards the end of cycle 1. This is special, I believe, with Phyphox, you have got the linear execution sequence of the commands establishing your algorithm plus typically about ~200 (assumption) more of the same cycles before the next GPS data set arrives at the typical frequency of 1 Hz.
What I find a little irritating in fluently reading the coding in the new editor are the two different block styles I noticed. For some math blocks the output container is being displayed at the top left area of the block, whereas in other blocks the output container is being shown at the bottom to the right. While reading through the coding the eyes do some slalom. Don't drink and code, don't get dizzy. Maybe the output channels could get another color scheme than the input channels. This could help nicely in concentrating on the data flow at the Analysis tab in the new editor, which could compensate a little for the no longer available "data flow connection lines" from the old editor. But don't become too fancy with colors, color blind people should still be able to notice some differences (e.g. in brightness). Individual containers should not get their own colors, which my approx. 190 containers I would not be able to notice the differences. Highlighting the output channels with some light orange background color would be perfect for me personally in guiding the eyes through the data flow, just to give an idea.
In the old editor it was possible to select multiple modules at once and duplicate them, have not seen this in the new editor, where you apparently need to duplicate individually one block after the other. Actions on multiple blocks at the same time happen not too often and would contradict somehow the snap-in feature of the new editor. Moving around modules in the old editor was easier, in the new one it is necessary to first break the connection between blocks before rearranging them and connect them again. I believe abandoned modules in the old editor made it into the XML file, while abandoned blocks in the new one won't. Due to the 2d layout in was possible in the old editor to see more coding at one screen, but for large projects and a 30% zoom the actual benefit was limited.
I have not measured it but I estimate that I invested something between 120 and 170 old editor hours in my experiment. The migration to the new editor, reviewing and optimizing the experiment took me about additional 20 new editor hours. The old XML file has about 1500 lines, the optimized new XML file has now about 1400 lines (and approx. Analysis 1030 blocks). The performance and code complexity optimization would have been much more difficult in the old editor than they were with the new one. I'm quite happy that the development invest one year ago was not lost (context to explain the invest: the experiment is recording GPS data and derives certain values from this data, one experiment execution saves me about 6 to 8 hours manual work in OpenOffice). What I avoided like hell was to click on the big trash bins in the new editor's UI. For me, deleting everything would be not the main feature of an editor. If I ever should accidentally click on these icons I hope that the cool undo would save me. ... Ok, I was too curious and I clicked and I was surprised. It does not delete everything? But what is it? The log of the undo buffer?
Next step for me is now to set up a real physical experiment in which I have certain input parameters like distances and velocity under direct control. This way I can calculate myself the expected output of the experiment and I should be able to see if my Phyphox experiment would compute the exact same values as the physical theory. But this is beyond the new editor, which helped in a great way to get there. Thanks!!! Goodbye old editor's module connection lines, hello new editor's development efficiency.