This is a group of features, they are conceptually tied together, but could be split in two or three features requests depending on Vuo’s team developpement strategy.
A. GUI nodes library, like controlP5 for processing
The GUI elements would have input ports, to be able to be controlled by anything else (hardware is obvious), and provide visual feedback.
B. A preset system, as in Max
This stores all values of the current GUI set. Reference: http://cycling74.com/docs/max6/dynamic/c74_docs.html#preset
C. An easy Save/Load mechanism.
Could be tied to the preset system, should probably be.
The Kineme save/load plugins where very useful, but re-injecting loaded values was a source of headache, not always easy. Vuo has a flow control though, so i tend to believe things would be a lot easier anyway. Reference: http://kineme.net/release/FileTools/11
This an area where QC fell unfortunately very short, as visual artists are reluctant to dive into Xcode and Interface Builder. Since Vuo process is not framerate dependent, and natively provides multi-windows, this makes totally sense. And even more, given the fact that mobile platforms are already on your roadmap.
It would totally change the status of what could be done with Vuo. We could build tools. From visual compositions to self-sufficient software, targeted at other users. Software that could itself be used to produce something else. Vuo would become a fully fledged software development IDE.
It would give the ability to a developer/designer to create a dedicated visual interface to edit and store as many states of his program as needed. This is very useful for media installations, as well as for live performance.
As an example, we have an installation project and must manage 40 different states of 50 layers over time, including audio and lights. All kinds of data are necessary, including colours, size, position, duration, sometimes text strings. Can be done in QC, but things are getting ridiculously hard coded at some point, given the fact that there are no presets tools. There’s no way to create a dedicated editor without diving into XCode. That was of course not meant to be in the first place.
It could also lead to more interaction between the lead developer / designer and other designers who are not developpers themselves (or are still in the learning curve). Could attract new users by introducing them to Vuo through that kind of collaboration.
Vuo could then also be used for sketching OSC / MIDI / UDP / HTTP interfaces, that controls software or hardware. Live performance? Robotics? Science labs?