How do you design a hybrid object? Or maybe better put, how do you evaluate the design of an object to know if it’s “right”?
I wanted to see if anyone has experience to have an informed opinion on this. Valentin, maybe you can clue us in on some of the design philosophy of Open Hybrid.
Here’s what I mean. Suppose I want to create a hybrid kitchen timer. I can foresee at least a couple of common use cases: level triggered operation, and edge triggered operation. E.g. “I want my slow-cooker to stay on while the timer is running” (level triggered), versus “I want to get a push notification when my timer finishes” (edge triggered). Accordingly, I could create an IO Point that writes out “1.0” while the timer is running, or an IO Point that writes a brief “1.0” pulse when the timer finishes. I could even create both.
- My common sense tells me “Create both, it would be the most useful that way.”
- My design sense tells me “Keep it simple. Pick one or the other, not both.”
- My engineering sense tells “Create the level trigger only. The edge trigger should be derivable from it somehow.”
But this is just one example. More generally, how can I decide which of a number of interfaces would be most useful?
You want to tell that your timer is still on so that it performs as a “switch on” as long as timing is going.
Your notification sender should say: If my input got switched from 1 to 0 then send a notification.
You should send the clean signal describing the action as accurate as possible from your origin object and do your data processing in your destination device. Because your origin never knows anything about your destination device other then where to send. (This alone is worth another discussion as well)
I feel like this is a very very relevant question and we should spend some time discussing about it. There are a lot of thoughts that have been build up but a clear guideline is missing in the moment. Mainly because the project published as it is missing some GUI elements that I am currently working on.
There are also already some more undocumented implementation parts in the code. Such as boolean (digital), floating (analog) and step values. For now everything is just a range of floating point values. We might spend some more time designing these guidelines next semester and continue the research on these.
We could discuss more on how we all progress what should be the case in your situations. I am sure man will come up that just need some sort of logical support.
I think it would be cool to have some basic operators like for example invert and some kind of if-statement. That would empower OpenHybrid with the ability to do some kind of “graphical programming”. invert for example could then be used to implement something like when my TV is running turn off the radio. With a little more thought you can probably come up with a lot more operators.
But I think it will be quite difficult to include those operators in such a way that they don’t have a negative influence on usability. What I can imagine is that whenever you start to draw a connection “virtual IOPoints” representing the operators appear and you can just draw a connection to them. But for this to work we would have to limit the number of operators because if we had too many it could easily get confusing.
Any thoughts?
Yes , @carsten it would be useful if there are elements like that . but how much more complexity will it add to the system ?
Right, I have also wondered about what affect operators would have on the system.
I definitely see the usefulness. Operators would give us the ability to make more objects compatible with each other, especially in the case where a direct IOPoint to IOPoint connection doesn’t work as intended. @Carsten’s TV/radio is one example, and I can easily think up a handful more.
On the other hand, deciding to add operators would bring up at least two new kinds of questions:
- How much complexity (if any) would be worth adding? “Invert” seems useful, but so does “threshold”, “rising edge”, “falling edge”, “delay”, “filter”, etc.
- Where would the logic reside? In the publishing object? In the subscribed object? Somewhere else?
The first question seems especially pernicious to me. The full toolbox of potentially useful operators seems overwhelmingly big. Ideally, we should do better than reinventing electrical engineering in software.
Yes I also think that the first question is the more important one. A connected question is:
- How can the operators be graphically represented without causing confusion? In some kind of hierarchy? Flat? As IOPoints or something else?
We could represent them as a special kind of connection " drag line " or “connector” points that are I/O points performing the desired function ?