This series of articles loosely documents design choices and implementation issues I met during the making of the tln website. I learnt a few lessons along my improvised 9-week schedule, and I thought I could share them with fellow first-timers. I guess some technical points might also be of interest to more experimented developers.
Customizing the Zinnia blog application
Moving onto the Blog section, I decided to bring in a Django application called Zinnia. I don't care about a large majority of its features, but I wouldn't rewrite commonplace tags and comments logic. This application also readily provides a fine administration panel for adding articles. Documentation may sometimes be lacking, yet I was mostly able to quickly simplify the application the way I wanted, so I do recommend Zinnia for Django-powered weblog purposes.
Default configuration activated and displayed a lot of links to pages which felt distracting and/or useless to me, like retrieving a random article, filtering by author, filtering by week, etc. The first step to a clean customized app consisted in copying the templates I was interested in, from Zinnia's main templates folder to a zinnia folder inside my app's templates folder. Then I removed blocks and tags related to unneeded features. Finally, I pruned Zinnia's original collection of URLs into one short file. Note the 'zinnia' namespace at the end of the blog_urls patterns.
Trimming Zinnia features was easy enough, but extending them may require more dedication. The original archive widget from the blog sidebar aggregated its queries in a way which prevented monthly and yearly counts of articles, so I had to overwrite the archive tree with new custom tags. The last two tags, along with some other tricky business, enable displaying drafts or otherwise non-public articles to the admin (that is, outside the admin panel).
Designing user-friendly comments
Comments rely on an autonomous application which has to be installed independently. Zinnia overrides several functions in order to simplify integration. The Django docs actually sort of advocate against this module, but maybe don't move to Disqus right away if you care about privacy issues. At any rate, the Django Comments module works fine with Zinnia and Django v2.0.
Reloading the entry page on comment submission felt bulky, so I decided to confirm submissions in AJAX style. AJAX implies that the client browser make an HTTP request to the server while remaining on the same page (this is accomplished in here with request.open, request.setRequestHeader, then request.send). On receiving the server reply (which triggers request.onreadystatechange), it will check and react to the content (parsed from request.responseText). AJAX implementation is rather straightforward, considering I used to view it as a high-end feature. The only trouble came from encoding the form data into the x-www-form-urlencoded string sent to the server. Somehow there's no standard for this? I feel like I missed something here —please write a comment if you happen to know something that I don't. :')
I had to tweak the moderation system so that admin messages do not need admin approval before publication (duh). As I don't want users to feel my website spams them, I also added a mechanism for enabling users to stop following threads they'd previously subscribed to. It can be hijacked, but I couldn't find a guarded way to offer an unsubscribe option to unauthenticated guests.
The last comment feature which required some work was actually the comment box appearance. As per the AJAX work, user interaction should feel smooth. Popular websites have made user expectations ridiculously high, so it's become quite easy to frustrate people. Putting a spinner over the comment box until submission validation makes for a simple, nearly universal waiting room. There is also some more JavaScript hidden for resizing the comment box while simultaneously sticking to the bottom of the web page.
Updating the style
Regarding the blog style, I kept to the minimalist stance originated in the Critique section. I had some trouble designing appropriate positions for the sidebar, along with the color and opacity transitions, but there's not much to tell. Archive widget dropdowns are triggered by clicking on Unicode characters rather than small embedded pictures. When you use Unicode characters, there's a chance browsers default to secondary fonts. The Alegreya font does not support arrow symbols, so I use Arial for this, and I have to serve it through @font-face to reach certain mobile browsers.
At that time, I also fiddled with Gimp for designing the favicon out of my own writing. Eventually I would adopt it as the website logo, displayed on the homepage and the top-level navigation bar.