Our intention from the beginning has been to build the site on our beloved Drupal, making it not only a case-study in IA and design, but also technology “best practices”. Of course “best practices” can be somewhat of a misnomer, as it obliterates any concept of diversity in practice which may vary (legitimately) based on the specifics of an individual organization and process. But none-the-less, we have evolved a fairly streamlined, development model, and further, and in-house version of Drupal, affectionately known is KID (Knectar In-house Drupal), which we use as a starting point on all Drupal project builds. This is discussed extensively elsewhere (or will be!).
But acknowledging the reality of the development time-line on KID, which we expected to take 4-5 weeks, and at the same time, having the sense that we couldn’t really afford to wait on that, I made the difficult decision to build out the site in a static form for the sake of getting earlier exposure.
Finally, the other reason for the static build-out, in addition to getting our revised site design and content up earlier, is that this work would make the process of development easier (in theory), as we would have an exact model to base our system build on. While this approach is often something of a luxury, as in our experience, going straight from design (e.g. PSD) to themed system is somewhat more efficient than building an interim static build. Nonetheless, it’s a nice thing to have as a reference, and by this point, will have fully supplanted the need for a wire-frame as it contains vastly more information (though by no means all!, since it doesn address any adminstrative, user, or functional rules).
For the static build, I used PHP includes to nice effect, such that most global changes to the XHTML/CSS can be made in a hand-ful of include files rather than in n pages. I can imagine a still more effective psuedo-dynamic site model that would make better use of includes. Or perhaps a more elaborate rudimentary psuedo-CMS, not database-driven, but more like schema driven, using perhaps micro-formats, XML data source, and modest ad hoc PHP functions. I’m resisting the urge to explore this road much more than this comment, out of a need to honor the goals of the static build, that is, to get the site up quickly, and move on to the true development stage.
I also discovered the lovely DISQUS service, which was fairly easy to implement, although somewhat buggy. But what’s great about this, is that will nominal development effort, I not only opened up otherwise static pages to commenting, but allowed cross-platform sign-in, making commenting, I would think, more appealing to the global Twitter and Facebook networks with a fairly painless sign in (as compared to signing UP, again).
One note on the static build. Unfortunately, as powerful as the IA model is, almost, in direct proportion to this power, is that it is proportionately arduous to build out in a static manner. If every project has multiple internally referencing tags, that means that there are this many pages and links to build and check! Luckily, my past as an Excel VBA dork has allowed me to automated a lot of the more mundane script building tasks. I’m sharing an arbitrary version of this spreadsheet here.