As part of our new appreciation for start-up organizations and their love of Django, we thought we’d share how we approach the concept of rapid UI prototyping.

Early stage start-up companies often need a proof of concept to help convey the vision of the new business model. Yes, there is the cocktail napkin approach and certainly there is value in wireframing the functionality, but something a little more polished can be of tremendous value as these organizations try to attract capital.

In most cases, the need is to “throw something up” on their newly registered domain on a free (or near-free) shared server – very similar to a movie set town, all façade and no substance.

This is often done by the traditional method of creating stand-alone HTML files served by the Web server software, or pasted into a flimsy CMS on a Go Daddy-ish dashboard. Additional pages are created by copying the layout from one page to the next. Maybe if you’re lucky you can try setting up SSIs or some other include method. Finish up with some dummy data and you have something to click through.

The problem is that this kind of prototype is throw-away. It will have to be recreated within a proper environment and within the appropriate programming framework. Wasted money.

More recently, we’ve been doing this differently. Still the same effort, but the end result is a fully functional Django project, ready for back-end coding.

We start by spinning up a small, inexpensive (but expandable) cloud server and creating a new Django project. This begins by creating a GitHub repository and adding a requirements file, static files directory and so on. The site doesn’t need a production-ready database at this point, so we just use sqlite. Then we add the following into the URL config:
 

url(r'(.+\.html)$', 'django.views.generic.simple.direct_to_template'),

Update: Randle Taylor has written up a nice class-based version of this for Django 1.5 and up.

This provides a wildcard pattern to quickly create HTML files in the project template directory and have them served through Django. Now, we can use the real Django template language in the HTML files – extending a common base template, using template filters, etc. – but without the extra burden of creating views or specific application URLs.

The end result is the same rapid UI prototype, but instead of nothing behind the curtain, there is a skeleton Django project, fed by a GitHub repository and sitting on a small cloud server, ready to accept Django application programming and grow into a production site.