Team Nylon : Interface Driven Architecture Proof Of Concept (Design File / Code / Demo Application)
As I posted earlier, I am prototyping a small task management application (a glorified To-Do list in ColdFusion, if you will). I am doing all the design and prototyping up front as dictated by (what I understood to be the message of) Clark Valberg's presentation at the last NY CFUG on Interface Driven Architecture. What I have below is the design file (PNG for Adobe Fireworks program), the source code for your viewing pleasure, and the actual ColdFusion prototype demo.
Design File
The design file is available in Adobe Fireworks PNG format. This design file consists of about 9 frames which map out roughly what I want to be seeing in each page of my application. I am not completely sure how large a design file should be when it comes to prototyping, but since this ColdFusion application is so small, I figured it wouldn't hurt to design them all out.
Prototype ColdFusion Code
The demo source code is available as a ZIP file. Once I was happy with where the design file was, I started coding the prototype. The prototype happens to be done in ColdFusion (for rapid development), but it could have been done in anything. The prototype is meant to be a "throw away" application that is merely a tool to help align the client's goals with the developer's goals. In my code, I use the Application.cfm ColdFusion template to include the HTML header and the OnRequestEnd.cfm ColdFusion template to include the HTML footer. I just found this fast an easy (but is not how I would implement the final application architecture).
In addition to CFIncludes and Pre/Post processing files, I do some minor ColdFusion scripting to create some test queries (no database involvement) that were used to create my data tables and data forms. It's just easier for me to do a CFLoop over a query than it is to hard code a bunch of values. The point though is that I have not done any ColdFusion code that would potentially back me into any corners. There is no business logic in the ColdFusion code... no model, no controller, no nothing. It just fast and dirty prototyping of views. Remember, the client doesn't care how anything is implemented, they just want to know that it works and that it accomplishes what they need it to accomplish.
Demo Application :: Team Nylon (A Kinky Solution by Ben Nadel)
The demo application prototype is available here. Now that the demo is finally up and running, I can get the management's feedback as well as other co-workers who might one day use the application. The great thing about the prototype is that most any change suggested would take minutes if not seconds to execute because no real coding has been done. And, the over arching point of the whole IDA methodology is that we would rather get it correct during prototyping where it takes minutes rather than getting it wrong during development where it might take hours and days to change.
Skinning The Application
As I started to demo this to a co-worker, he expressed early concerns with the drab look and feel. As an exercise in design and skinning, I came up with several other color schemes. You can switch between the different color schemes (skins) using the tiny links in the very top-left corner of the application. I have design files for that if anyone is interested, but they are basically just minute graphical changes. If you look at the code though, you will notice that the entire look and feel is determined by a single CSS include in the HTML header. Cool stuff!
I am not sure if I want to pick one skin, or leave the ability to choose in the application. It's so easy to implement, I figure I might as well just leave it in.
Reader Comments
This is a very interesting blog entry. The thing is that I totally disagree with user interface driven design and I believe it should be avoided at all times.
When you start designing software from a visual point of view you hide all the actual functionality that needs to be build. E.g. designing a simple screen with a couple of input fields doesn't say anything about the functionality of of that screen. It only "implies" a certain functionality.
I've worked on projects where an estimate (hours) was made based on a number of screen with inputs. Unfortunately the estimators didn't anticipate all the type checking and feedback dialogs, oeps. On top of that a couple of these projects were financial calculators with a complex calculation model behind. Basically, you can't make an estimate of build time based on visuals.
You will probably say, oh but you should use it all the time. Only when it is appropriate. If you work in a visual design shop (a.k.a creative company) you work with people that only can handle visual stuff and they fall asleep with you start talking about a feature list, requirements, specs etc...
I also have very bad experiences with building prototypes. Once you've build a prototype then from a management point of view the application is finished so why do you need to start over again? Very dangerous...
I've been working in the industry for over ten years now and I can tell that user interface driven design does not work.
pan, prototyping is not a silver bullet. There is still an art to doing it effectively. Just because your estimators forgot to estimate the time to doing validation, doesn't mean prototyping is bad. It means your estimators are ignoring crucial areas of the application.
Personally, I'm against the idea of throwing away a prototype. In an application that has a user interface, the user interface has to be built at some point, so why not build it first and get immediate feedback. To me that's an ideal prototype. It should contain visually finished screens that will ultimately be used in the final app.
Are you adding CF/SQL to your prototype? Sounds like a working application to me, not a prototype.
Steve, I didn't compare making estimates and making prototypes.
Concerning estimates, I do not believe in "user interface driven design" because I believe it results in making bad estimates.
Concerning prototypes, I think you should be very careful with building prototypes, especially who you are showing the prototype to because before you know it, it takes a live on it own.
I personally believe in feature driven design with a strong iteration supported development process.
I disagree with pan69... I just finished a huge project for a portal site with interface driven development... with actually almostthe concept as mentioned in the blog above.
of course first there was system-api written with the basic functionality the application should provide to any UI-Client if it is HTML or flash or whatever...
next we did all the userinterface design, thus we could discuss design with managers. people tend to understand an application much better with some design in front of them , it's much more creative...
third we did the prototype... no cfml inside!!! really not. it easier to share with others if you do only have html-prototypes. We used a dreamweaver template for header and footer.
the good thing about the html-prototype these days... there are great to develop and experiment with AJAX-stuff inside the prototype templates. Once you are ready with your js-code you take it out and put it in external files...
last the protoype template were moved into the fusebox-application, backend-api was maybe modified since requirements have changed but the template integration was painless since you don't have to care anymore about UI issues.
at least for me that concept of ui-driven development worked out excellent.
@Daniel,
The guy that I last heard all this from was Clark Valberg, and he actually builds his Prototype in Dreamweaver with templates, I believe. I, on the other hand, have been a Homesite guy for years and happen to not know a single thing about Dreamweaver, so clearly, the templates are out for me. I am hoping to learn more about Dreamweaver (purely for prototyping) so that I can get the same "include" functionality but without using ColdFusion.
@Pan69,
I think because up-front design is such a different work flow for many people there IS going to be some transitional issues. Like you said, people are going to have bad time estimates (at first) and people are going to need to understand that the prototype is NOT 95% of a working application.
@Steve,
I agree that the prototype is not purely throw away. I think that has more to do with how you develop it though. If you work with some sort of template driven app like Dreamweaver, then it might make horrible CSS and layout choices. However, I do all my prototyping by hand, so the CSS and layout is pretty much exactly the way I would have it in the final product. So, for me, transitioning to the final app would consist partially of just moving files around and organizing better... then going in and really creating functionality. But certainly, the architecture of my final app will be much different than the prototype.
I'm in total agreement with Steve Nelson. BTW Ben, look into using "template properties" if you're prototyping in dreamweaver. They're booleans, embedded in the template. The idea in using them, is to create different layouts which can be turned on/off using the template property window. I could send an example if you need one.
Jeff,
I do not use Dreamweaver, so I have no idea what you are talking about. But I am looking into using it for prototyping eventually.