The biggest accomplishment of today was implementing category-based navigation. More correctly, I had it replaced with the front page navigation. Until such time as I find a more meaningful replacement for what category-based sidebar navigation used to be, this will remain.
One of the biggest problems in design is choosing when to maintain continuity, and when to break it.
Continuity is important because it creates an order our brains could latch onto and rely on. Maintaining modes of operation – whether it's the pattern in which users navigate your interface, or shortcuts they'd gotten used to, or keeping focus on a particular element despite notifications – not only allows us to operate in a productive fashion: it also creates a sense of trust in your software.
This trust is difficult to establish and easy to lose. Like any regulation, it has to be enforced at all times: otherwise it loses its protective power. Trust in software requires that the developer not only tweaks the details well: it requires superb attention to the overall state of the software, and making sure all those fine-tuned details are fine-tuned to each other, not to an imaginary and disparate ideal states.
In terms of navigation, maintaining continuity means establishing exactly what the user is going to get from each part of the software. For my particular case, ideally, it means perfectly-context-based navigation:
- front page gives user the context most broad: all available categories, displaying a handful of most prominent projects
- category gives user a more narrow context: its associates projects
- project gives user the context most narrow: chapters, or separate parts, and the associated links
The front-page and project contexts have so far been the easiest to implement: they're clear in their intent, and are therefore simple to envision and build. The category context is somewhat more obscure, in that it can't do better than either re-implement a part of the front-page context (listing a handful of most prominent projects in the sidebar) or duplicate its own contents (listing all projects in the sidebar). Neither is an effective use of the virtual and mental space.
Duplication is not the worst offense, but it could lead to confusion by the way of assuming some displayed information is going to be irrelevant where it has been in the past experiences. This could lead to missing important details that would be where the "useless" information had been previously, creating friction where comfort and ease of use is required.
A better way to use the sidebar in the category context is add peripheral information: for example, links to the Mythos entries explaining or elaborating upon aspects of what the given category touches upon. (For the Games category, it could be "Why I prefer text-based games". For Writing, it could be "Visual writing".)
The "engine" for building the site from templates – the whole construct, including all the templates but excluding content – has been getting somewhat complicated lately. I am so far using 9 different templates to render every part of the site, and just as many partials (which are included into templates upon rendering of the usable site).
I'm no minimalist, but I do prefer simplicity and lean design: getting the most done with the fewest components of the least power. I enjoy efficiency, clarity, and a compact mental-space footprint.
While by no means extensive, for such a simple site, this feels like just a little excessive. I haven't done any analysis on that yet, but it seems as though I could cut out a template or two from the roster.
But then, I also remember that I get anxious over early implementations, as if their "dirty" status is a signifier of the final product, and try to "fix" it by reducing it to the minimal possible base. This ends up a hinderance more often than help: it takes away what would otherwise be a useful, meaningful designtation, preventing reusage or obscuring meaning of the piece of code. This is a counterproductive instinct this early in the development, and I must mediate it until the project – the site, in this case – is ready for launch: that is, until all of its features are implemented.
As far as Mythos is concerned, the biggest concern I have is regarding its structure and building a presentable interface from it. Right now, the supercategories (ending with 0) exist separately from categories, even though they're supposed to hover over, semantically and structurally.
The idea is to provide clear and stable structure to Mythos, in a way that's easily navigable and easily extendable. To that end, I've decided to use the Johnny.Decimal category system: it provides me with the right kind of structure. It makes for poor URLs (
/mythos/32/11 is not clear at all), but once you're within the medium of Mythos, it should be clear enough (you can navigate to either
32 Category or to
But, since URLs are necessary to navigate Mythos' Web interface, and since nesting categories (
/mythos/00/01/03) makes no sense, I needed a structure where access to each entry is no longer than
/mythos/category/entry. This means I needed to put categories separately from supercategories.
Rendering the navigation manually makes arranging components like this easily, but the programmatic templating approach requires a little more computational insight. Somehow, I have to make it clear within the templating logic that categories ought to be children of supercategories, semantically, structurally, and visually. So far, I've been able to prototype something that works just well-enough for a development interface. It's somewhat inconsistent visually and HTML-wise, and certainly isn't something I'm ready to publish yet.
What's more is that the templates as they are require assigning a special variable to denote the category's status as such (as opposed to being a supercategory). This should be able to compute itself somehow, but I haven't yet found a way to make flow naturally. Right now, I have to make two cases for templating: one for supercategory, and one for category and its associated entries. Ultimately, supercategory ought to list its categories, which in turn ought to list its entries, all in one single-case loop.