This forum uses cookies
This forum makes use of cookies to store your login information if you are registered, and your last visit if you are not. Cookies are small text documents stored on your computer; the cookies set by this forum can only be used on this website and pose no security risk. Cookies on this forum also track the specific topics you have read and when you last read them. Please confirm whether you accept or reject these cookies being set.

A cookie will be stored in your browser regardless of choice to prevent you being asked this question again. You will be able to change your cookie settings at any time using the link in the footer.

Wishes for the editor
#1
The editor is great, it reminds vaguely of LabVIEW (which I am a bit familiar with). However, there is one (slight) bug: sometimes the horizontal lines of the buffers are not shown, although there are connections to it. These seem to originate in empty space. This obviously only is a graphics issue, the XML is fine and the experiments work.

In the editor my greatest wishes are:
  • support of "copy & paste". I know, this might turn out quite tricky. But to join two non-overlapping experiments (say "velocity from GPS" and "altitude from pressure" would be great. I know they might be joined in the XML files, but there I'd have to take care to copy the various bits & pieces to their correct portions of the file.
  • resorting the operators. Once they are connected, they cannot be re-arranged. Sometimes my experiments look quite messy, but tidying up just means re-creating from scratch.
  • This brings me to the third wish: "intelligent" disconnection of buffers. Currently, you need to disconnect a buffer at first before removing its source. Otherwise the buffer will remain in the xml (btw: why are they called "containers" there?), and re-creating this buffer with its old name will append "(1)", although the original cannot be found in the diagram. It would be nice to have sourceless buffers deleted automatically.
  • Buffers and their properties "clear" and "size" for me are the best candidates for causing errors (i.e. empty charts or even crashes). And I believe these problems might scare off unexperienced users. If there was some other way of dealing with the underlying properties, this would make things a lot easier for novices. 
  • When connecting an input to some buffer, some properties of the candidates are shown when hovering with the mouse over them. Unfortunately, the buffer size is the most dominant property, instead of the name. I'd think the latter to be a lot more helpful.
  • Is there a way to place comments in the diagram? The help texts are really helpful, but sometimes (especially in the standard experiments) I'd love to get info why something is done the way it is. E.g. that strange loop-like buffer "d" in the GPS-experiment or the use of "match" in the elevator.
Don't get me wrong. The editor is fabulous, just as is phyphox anyway. And christmas being just past past, my wish-list might not be fulfilled. But maybe, some time...
Reply
#2
When trying to program new experiments, some sort of debug mode would be nice. Attaching a "value view" to "count" might have some side effects, apart from cluttering the editor ...
Reply
#3
It's always great to see that the editor is being used. Please, let me first say a few things about how the editor:

We wanted phyphox to be as customizable as possible with the possibility to create your own experiment configurations including data analysis and to share those as modules with students. This was achieved with our XML file format. However, the customization should also have a low entrance barrier, which is why we created the editor, so that the XML code could be created without scaring of users who have never seen XML before.

One major problem of this (or rather the visualization that we have chosen) is, that the editor cannot fully represent the XML format. The latter has a bunch of buffers and executes "analysis modules" sequentially to manipulate those buffers. The current editor however, connects inputs and outputs of those modules and the buffers become somewhat hidden as they are only represented as the "connection". This in particular means that the same buffer cannot be reused multiple times in the editor and that there is no good representation for "clearing" data from a buffer or for data that persists across multiple runs of the modules.

So, in the end, if you want to create .phyphox files with all the features, I highly recommend to write the XML code directly (at some point this is also more convenient than pushing a mouse). Of course, we want the editor to be able to handle as many experiments as possible (at the moment only two of the experiments in phyphox cannot be handled by the editor), but the main purpose is to allow simple changes to existing experiments and creating simple setups.

Why am I explaining this? Well, while I agree on all of your points, we have a capacity problem and probably will not improve most of them in the near future, simply because other aspects of the app have a higher priority at the moment. We used to have a student assistant who made some big improvements on the editor (especially resorting the operators is almost ready and will be released with the Bluetooth update), but he is no longer working on phyphox.

So, at least for now, the editor is the entry for the more advanced users, who hopefully can handle a few rough edges and there are several aspects that affect almost all of our users on which we have to focus first.

Edit:
I have also merged your request for a debug mode here, because unfortunately the answer applies to this one as well.

By the way. We will open the source of the editor soon as well. At the moment it's a rather ugly mess, but maybe we find some other programmers who would like to improve it...
Reply
#4
That's fine with me. I don't believe in father christmas anyway :-)
Reply


Forum Jump: