Note: I no longer blog here, and have not posted here since the mid 2010's. (😱) Please check out the homepage, which probably has links to more recent projects, photography, and (perhaps someday) writing. Below is the original content of this post:

Maneater Open Beta (Lessons Part 4)

Over a year and a half since I became involved with the online side of the Maneater, I finally feel that this new site project has fought its way out of the jaws of vaporwaredom. Following one false start after another and over a year of high hopes and dashed dreams, I think we have finally accomplished something.

Without further adieu, here is the current URL at which you can test the new Maneater site:
New Maneater Site

Things of note

Also, the site is currently one issue late on content, because updating the currently live site is already a time-consuming process.

Things I'd change

The way I programmed the site is (in hindsight) pretty sloppy. I set up multiple applications that all rely heavily on one another, which is a pretty big sin against the modular philosophy of Django. I should have lumped in most of the staff, content, and publishing information into one overall Newspaper application.

The stylesheet is still under consideration because I haven't yet had the time to tinker with it.

Some of the metadata (like "published date") is extremely redundant. Though perhaps it's just me being picky, but I don't think you need to set the date of an article if you're already attaching said article to an issue (which has the date set).

Ah, and I've got a long list of things that I'll be adding to this in the coming days. I'll port over parts of my todo list and notes when I get around to it.


Notes on searching

The one complaint I've noticed the most about Django is the lack of good search functionality. At the time of this writing, even the Columbia Missourian seems to have lost their search functionality.

Django only has limited capabilities in contains() -- which uses a wildcard LIKE statement on what you enter in -- and search() -- which uses MySQL's fulltext indexing but isn't very customizable. Fulltext (for those who don't do database work) uses real search algorithms instead of just looking for the exact thing entered. It also provides a guess to accuracy, so you can sort by the most accurate items -- you don't get this when you're doing a plain ol' LIKE statemenet.

My personal gripe with search() is that it uses boolean searching which isn't necessarily what a user should be using by default on a search box. I feel that the boolean capabilities are an advanced thing that only the diehard would really be using -- you know, "putting things in quotes" to search an exact phrase ... putting + or - in front of words to find articles that have one word but not another. Not to mention that for plain searches (no quotes, no + or -), boolean searches seem to be less accurate since it uses a much different algorithm than the normal "natural language" fulltext search.

So I resorted to a custom solution based on this whitepaper, revolving around a custom manager to handle searching however I wanted.

Creating a view around searching was also a bigger challenge than I originally thought. In the one day of staffer beta testing, I already got a handful of complaints regarding being able to search for staffers or photos. And being able to sort by date instead of accuracy -- it's not convenient to get a lot of articles from the 1990's when you're looking for something you vaguely remember reading last week. And then the issue of paginating large sets of search results.

I think we have a pretty robust search engine, that even demanding journalists should be able to find what they need. But that's coming off of the uncustomizable, date-sorted search that we have on the old site. And the lack of search on the Missourian site. (If anyone working on that site is reading this, I'd love to talk sometime.)