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?

I think I understood the following, and I agree. 1. Keep it as simple as possible 2. Minimize resource usage as much as possible 3. Tie HW activation to config setup - don't show Arduino config if we are on a Pi, etc.

Yes!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?

Is there a way how we could expose a javascript interface to program the hardware Interface code?Kind of a Javascript IDE Arduino Style?

If there would be a Javascript IDE in the Web Interface that would allow to program an activated hardware interface that would be kind of cool.

I could even imagine that on some point we would just switch to firmata for the arduino and create a universal javascript interface for programming GPIO on what ever platform we have in mind?

There is another very simple programming tool that designers use and that is building up on javascript.http://processingjs.org

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.

If we bring in another intermediate, so to say split the given API in a VIRTUAL and PHYSICAL API but more or less completely complementary, then we can use our hardwareInterfaces as another abstraction layer. It would allow a developer/designer to program platform independent code for what ever hardware and GPIO he wants to. Since we have the generalized API in Javascript, his code will work with any hardware interface. +- some small modifications.

This will make it highly simple for a unskilled programmer to build some javascript code for the hybrid objects.

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.

valentin:

But in the end, all we do with these hardwares is:

switch on/off or PWM outputsread digital or analog signals on an input.

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.