This past week, I finished up my third project with Django. The first two were fairly simple: a website to show results from a software build tester and a registration form. Both of these didn’t rely on any authentication or give the end users any serious Create/Update/Delete interface. The build tester was essentially read-only, and the registration form was write-only. In both cases, I made use of Django’s instant (and very nice looking) admin interface to let me manage records, though. That is a feature you can’t talk up enough.
For this latest app, I had a much bigger goal. A new physics experiment I’m working on has no good place for storing internal documents and memos. On moderate to large collaborations, the document server is in many ways a more important communication tool than face-to-face meetings. It is definitely essential for recording knowledge between the generations of graduate students, postdocs and faculty who come and go on a long-term experiment.
Normally, I would be all in favor of using an off-the-shelf program, but several things turned me off to that. First of all, if you ever thought that the world of Python web frameworks was crowded, you should try searching for a “document management system” (DMS) on Google. Worse, the buzzword bingo really makes it hard to understand what these programs actually do. I figure if I were to add “enterprise” to my search query, the information content of the product descriptions would go to zero.
So I was pretty disoriented when I went looking for a DMS. After sifting out the commercial offerings (we don’t have that kind of budget), the remaining open-source alternatives always seemed to me to be lacking. That’s not to say they were missing features. There were so many bells-and-whistles, my head spun. The problem was that they made fundamental assumptions that differ from the way we work. A common assumption was that there would be only one file attachment per document, whereas frequently we like to just upload several related Postscript plots with a small text description. On top of that, the extra features (”workflow”) we didn’t need got in the way, making it more awkward to use. I’m sure there are people (and more importantly, people who pay big bucks) that need this stuff, but we don’t and it increases the cognitive load on the user who has to remember what it all means.
These concerns are not totally hypothetical either. My current experiment uses an old system built on Lotus Notes, a very “enterprise” ready product, and it drives us crazy. New users are confused about how to use it, old users can’t find anything, and it takes a dozen clicks, most of which are not obvious, to achieve any simple operation. I have less contact with the site maintenance side of things, but that also seems to be extremely cumbersome. After fighting with it for years, and hearing “Oh, I bet the document is in there somewhere. Good luck finding it” more times than I can count, I developed some opinions on the topic of DMSs.
Over the Christmas break, I thought about our needs, and they boiled to three basic activities:
- Upload files
- Find files
- Download files
That’s it. Anything that enhances these tasks is a feature, and anything that interferes with them is an anti-feature.
The conclusion is probably obvious by now: strong opinions + useless existing products + programmer hubris = roll-your-own solution. I’ll go into detail on the experience in future posts, but the punchline is that with Django and Python, I was able to create a DMS that directly addresses our needs in 24 programmer-hours and half a case of Mountain Dew. And that includes time required to learn the deeper mysteries of Django which I had not needed before. The finished app is 1550 lines of Python (of which I only had to write 1200) and 750 lines of HTML+CSS. That’s it.
(Once I can figure out how to make the app portable enough to be useful to others, I’ll post a copy.)
