This one isn’t so much a recipe-styled “Howto” as it is a discussion piece regarding different approaches to designing and developing your application.
It was initially prompted by intinig’s question about an approach to Rails development
Database To HTML
do you suggest working on the database model before starting to rail?
This model was suggested
db → model, testcases → html
In this approach, you first create the database structure, then create the models, set the associations, etc. Next follows unit testing of the models, then functional testing of the controllers. Once the application “code” is solid, an HTML font-end can be applied.
DavidHeinemeierHansson suggested an alternate approach
In fact, the opposite approach, to quote:
Screens first. Figure out how the screens are going to work. Do the HTML. Then do just enough code to make those screens work. Rinse, repeat.
Start with the meat of the application
I always start as deep as possible.
Find the epicenter. As Jason is fond of saying when we do Building of Basecamp. It’s the main interaction that you want to start with
Do the MOST important thing the app should do first
Let the interface dictate
The Interface is the Software
The problem is that the specifics of the user interface dictates choices for the backend. If you do the backend first, you’ve constrained the user interface in subtle but significant ways
bq. Especially if you don’t already have specific data requirements. It’s easy to see requirements and relationships from your interface. Most of the time you should be able to take an interface and deduce the data layout from it, with reasonable accuracy (htonl)
I’d be interested in hearing how “the subtle but significant” limitations were actually discovered. It’d be hard to show examples, tho. In a before & after scenario of the same app done and redone, the after would definitely have been affected by other factors (learning better ways to do X) and would be Better regardless of initial design approach.
—monsto
Leave the trimmings for later
Don’t do the stuff AROUND your application. Forget about login, creating a new account, all that stuff. It’s not the navigation or the logo or pretty frames around it.
It was noted that this approach follows an Alan Cooperish philosophy, and that
the fusebox method FLiP (Fusebox LifeCycle Process) uses a similar model.
Fitting Them Together
“Database First” and DavidHeinemeierHansson’s suggestions actually fit together very nicely.
sketch the most important pieces-> db -> model, testcases -> html sketch the second most important -> db -> model, testcases -> html etc.
Sketching, wireframing, etc. is always a good idea, and can save a lot of time. You might be tempted to do this:
sketch -> html -> db -> model, testcases
But this quickly becomes:
sketch -> html -> db -> model, testcases -> html
Because often times there are minor (or major) tweaks that happen between the UI conception and implementation. Base the implementation on the UI sketches, and flush out the final HTML later.
The screen IS the application. Very much like the Fusebox methodology FLiP (Fusebox LifeCycle Process) (fusebox.org is not a good reference).
Fusebox is a framework that uses a pipes and filters approach to web development. FLiP is the process where the screen dictates the applications requirements.
Truth is, and in all likelyhood, the database will outlive the interfaces you use to interact with it. There are many databases out there that have seen many revisions in the front end that’ll interact with it. Today it’s html. Yesterday maybe was a Java client app. Before that maybe was some shell application.
category:Howto