I think this is a wonderful idea. To allow a user to config aspects of a hardware interface in the web user interface is great.
But we need to think about a very strong simplicity aspect.
Right now the web interface is already a bit overloaded compared to 0.3.1.
How can we build it that it does not add more complexity to hardware interfaces that do not benefit from it?
Metaphorically, when we create interfaces, we should kind of aim for that in the very best case we would be able to explain it to a 9 year old kid.
If we can create a very low entry barriers, we can get more people on board.
From one side we can archive this with thinking carefully about the existence for every button.
For example I spend days on eliminating extra function calls in the Arduino IDE just to find the this very simple solution: "I am a developer(), I want to add() two IO-Points. I read() A and B and write() C and D.
I think that a simple web interface to configure a Hue Light interface is a big advantage.
It is very complicated for an average person to dive in to the server code and program a Hue interface.
On the other side, who is the person we build the developer functionality for?
I could also imagine that the biggest problem is the complex setup of the server.
What if you just open a webpage and you have everything at hand?
This would allow us to share more generalized code.
We could take inspiration from processingjs with some of our function calls for inputs and outputs and it would allow many many product and interaction designers in the world to program Hybrid Objects right in the browser.
@valentin So if we implement the ace code editor ,then it will allow the user to program the I/O of the hardware independent of which hardware it is ?
for example , the user programs the I/O from the java-script editor and then firmata controls the hardware ,is this what you meant ?
@V_Mohammed_Ibrahim Yes in some way.
What we have right now is a simple API to implement new hardwareInterfaces.
So to say we already have a simple hardware independent API to the VIRTUAL side of your Hybrid Object.
This is the same thoughts for example Arduino used and which made it accessible for all the design schools. They abstracted a lot of c code in to a simple API.
What is relevant to me is that designers who have not much experience in programming are able to write programs for it. I can teach a simple blinking LED example with Arduino to someone that never programmed before, within a view hours. That is so powerful!
If we can generate something that has such a low entry barrier then we will enable product designers and beginners to playful experiment with the platform and eventually build physical designed objects. Objects that we could never imagine. Since we just provide a simplified API, a more advanced programmer should be able to leave this API aside and use node.js as it is.
If we have a configuration webpage, we allow a user to change a view predefined parameters, but we do not really invite to program their own creative ideas.
I do not see the open hybrid developer tools in the server as an end user interface.
Its purpose is to support the maker, designer and programmer to build hybrid objects.
A foundation for this building is code.
The end user should only power up a Hybrid Object and interact with it physically supported with the reality editor GUI.
I think it is a good idea to create such an abstraction layer because - as you said - it would reduce the barrier for new developers who wouldn’t have to bother with hardware specific details. I see the main advantage in the abstraction of the GPIO communications. But I think it might be quite complicated to abstract other hardware interfaces apart from the GPIO ones because I don’t think that we can simply assume that all operations will only be reading/writing numerical values.
Obviously your focus is the microcontroller/GPIO part but I think we will have to think about other applications as well (or only abstract GPIO). Otherwise we would artificially limit the possibilities. Just take the colour of a lamp for example it would be possible but quite awkward to represent it numerically. The need for more complex datatypes we cannot yet foresee will probably come up while new hardware interfaces and use cases are being developed.
@V_Mohammed_Ibrahim I named firmata more as an example for a hardware API then something we should use 1 by 1. I think it is interesting to look at what are all the functionality of firmata, like operating servos and so on.