Here is a possible scenario of a scaffolding metaphor applied to a typical workflow. An interaction designer or information architect sketches out an interface using fluidIA. The first time around a generic text label is used for a particular element area – say the header. A day later, as more thoughts emerge about the header, some more states are added and new buttons inside the header are sketched out. This in turn, in certain areas gives enough information for the designers and developers to start thinking about layouts and CSS styles. The designer and front end developer then begin styling certain sections as the information architect continues to move on to refine other areas needing further thought. The emerging CSS attaches to the fluidIA objects and is accessible in the prototype view. This way, the wireframe begins acting as a guiding scaffolding which layers over “real” code. The “real” code emerges underneath and does not have to be limited to CSS, but can also be in the form of database calls, server side code, custom Javascript code and HTML. As more of the “real” code emerges, bits and pieces of fluidIA scaffolding fall off and give way to what will remaing for a release. If uncertain, developers could always look back at the scaffolding or request areas needing further support from the information architect – enabling greater mutlidisciplinary collaboration.
great idea. what if you integrated with other web services for the programming and design parts. like, you could use aviary for the design and mozilla's just-announced bespin for code. bespin could integrate very tightly with fluidIA, since it is open source. love this whole idea, by the way.
Possibly. I'll have to look at Bespin. :) I'm not sure how popular Aviary is though and if people will use that instead of local Adobe installs. Maybe.
[...] is about flexibility. FluidIA objects can become guides or scaffolding like objects which can be toggled or replaced by either images or real code. Sketching on paper is still more [...]