Two nights ago my vacation started. I've set aside two weeks of time away from work, away from software training and IT consulting. I'll be spending part of it with a friend in Seattle, and the other half at home. You would think that I'd be thrilled for this opportunity to relax, to unwind, to recharge for the next round of professional tasks. You'd think that.

Instead, I'm absolutely dreading it.

Years ago I would spend the days and weeks prior to a vacation imagining what I would do with my reprieve from the working world. I'd often use it as an opportunity to make a push in the development of one of my current projects. If I were lacking an "active" project, I'd start one anew. The end result was to work myself into a blissful creative exhaustion.

Thinking about this, there was really only one time this actually worked. Over a decade ago, after months and months of thought and design, I spent three wonderful days attempting to write a video game. 

It was early in what became a five year effort. At the time I was creating a MYST-clone set in cyberpunk world of virtual reality. I was coding in C++ on MacOS 7. I started with almost nothing, but ended in a small program that would navigate a single stationary node of the game world. It responded to interface events, displayed graphics with special effects. I can't remember if the program was able traverse multiple nodes, but it was certainly an accomplishment with my developing programming skills.

By Monday night of the three day weekend, I was exhausted yet nearly euphoric with success. I was amazed how much I accomplished in those 72 hours. With only a little bit more time, I thought.

I didn't realize how much more I had to do. I hadn't externalized the data in files. It couldn't play integrated video. There was no plot, no story, nothing but a few slides rendered in a consumer-grade 3D modeler. To call it a "game" at this point is quaint, maybe a bit amusing to me today. 

I'm two days into my vacation, and I still haven't decided how to spend my time. Mostly, I've frittered away each day watching videos, surfing the 'net, and wishing I were going back to work tomorrow. Instead, I'm packing a messenger bag and a new carry-on rollaway for a 1300 mile flight tomorrow afternoon. 

And I'm dreading it.

The Windowlight theme made some progress this weekend despite my limited time. Since my last, hastily written entry, it dawned on me to check out drupal's themeable functions. While these functions solved some of the string-replace hacking, it's far from the proper separation of data and presentation I would prefer to see. 

This weekend I focused on two particular aspects of the new theme: breadcrumbs and error messages.

Breadcrumb trails are today considered a standard website UI element. They allow you to quickly navigate deep hierarchical structures by providing you a series of links that refer to "parent" pages. From my own experience, I know that no complex website should be without a breadcrumb trail element. In my previous theme efforts of Citylights and Starlights,  I had left the breadcrumb trails provided by drupal relatively unmodified. I was still new to theme development and as a result, did not put as much thought into their value. 

This time, however, I wanted to improve the deninet UI experience, and proper breadcrumb trails are essential. After some research at the venerable listamatic, I came up with a preliminary design. Implementing it in drupal, however, proved far more difficult than I had expected. The HTML provided by drupal wasn't ideal for this sort of modification. Unaware of the theme functions, I resorted to some ugly hacks to even try to get it to work. Even then, it wasn't as good as it could have been.

As I was clicking through Stumbleupon in a zombish attempt to stay awake, I ran across this article from Janko at Warp Speed. The article lays out how to create http://apple.com style breadcrumbs using some simple CSS. While my opinion of apple has suffered lately due to their poor attitude toward iPhone developers and 3rd-party systems, I still find their software UI standards to be the best around. Drawing upon the article and the theming functions, I set about coding a new breadcrumb widget.

During the process I began to find it difficult to find a spot to put the thing in the web design. I eventually narrowed it down to two locations. One was over the main header graphic, the other at the top of the content area. After some debating, I settled for immediately above the content area. It's closer to the text, meaning less mouse travel for users. Even with the issue decided, something felt wrong. It wasn't just mouse travel, but scrolling.

Previous versions of the theme had the header graphic taking up a majority of the screen space. This forces the user to scroll downwards just to see what a page is about. In other words, the graphic was unnecessarily dominating the design while contributing little to usability. For this reason, I shorted the header area by several hundred pixels. This reduced horizontal scrolling and tightened the overall feel of the theme.

Also, Windowlight will feature the return of something not  seen in the current Starlights theme -- the Denizen Entertainment logo. The "brick" didn't seem to have a good place in Starlights. I was also away from the notion as deninet as a organization toward that of a solitary effort. The logo didn't feel appropriate at the time, but I've grown to miss it more and more. Staring at the earlier versions of Starlight also felt...lacking. There was a distinct sterility I wanted to correct. Placing the logo in the corner of the content area was the obvious choice for placement, as it's be the standard location going back to deninet 2.0. Sizing, however, was a concern.

I didn't want to make the logo appear too small. A small logo almost seems apologetic. Too large and the logo would dominate the page. I wanted it to be just right, present and quietly proud. After some trial and error and encouragement from a friend, I selected the size you see in the image. Interestingly, it also solved some positioning problems with the breadcrumb trails. 

As I was working with the new theme -- testing it out on different pages -- I also began to find another problem. The breadcrumb trails provided by drupal aren't particularly effective. More times than not, I would find the trail to be "home > Current page", a nearly useless configuration. After some searching, I located the Custom Breadcrumb module, which allows you to control your breadcrumbs. Combined with views, I believe the usability of the site can be greatly improved.

Today, however, I wanted to cover a different series of issues. For a while now, I've wanted to customize the status and error message boxes provided by drupal. In previous themes, I've simply styled them without seriously examining their usability. In deninet 4.0, I made a special effort to create friendly error pages. (This incidentally, also spawned one of my favorite error messages ever: "Uncaught FeatureNotImplementedException, explaination: programmer lazy.") Drupal provides two kinds of error messages, status messages and error messages. The only difference between the two in Drupal's default presentation is that of color. Status messages are green, error messages are red.

I felt this could be improved through the use of the theme functions. I created a override that interpreted the error type as it is sent to the theme engine. Then, it would either print "The following action has been performed", or "The following errors occurred" in addition to a list of what actually happened. It was easy to add an additional line at the bottom to suggest to the user how to react to the message.

Oddly enough, I spent most of the day trying to get the background of the message boxes just right. Originally, I wanted to include a simple icon. As I began working on it, however, I felt I wanted to give it more than a simple solid-color background. Windowlight has a recurring theme of stripes throughout its UI and I felt that the same could be used here for a subtle, but aesthetically enhancing effect. The stripes were easy enough to produce, but the message boxes still lacked an icon.

There was no easy way to add one without adding enough div to the message. While I could easily do that, I stumbled upon another problem. I had wanted to identify status messages with a round 'i' icon, and errors with a triangular or octagonal '!' icon. As you can see, 'i' and '!' next to each other are kind of difficult to tell apart. After some more thinking, I decided to go with large, subtle text in the upper right corner of the boxes.

The theme is shaping up. Whenever I go back to the production site after working with the new theme all day, I shudder a bit. Hopefully, the new theme will be ready soon so I can focus on competing the 6.0 features.

As a departure from previous site upgrades, I'm stressing a high amount of usability in deninet 6.0. By nature, I tend to be a UI snob, preferring to tweak and tune aspects of the user experience that would make everything easier and more intuitive. While this is commendable, Drupal itself is not making this easy.

Creating a strong UI experience was a key aspect of deninet 4.0. I was able to tweak nearly everything in the experience. Form organization, buttons, site layout, and so on. At the bottom of nearly each page was a two column section labeled "Where to go", providing links or actions for the current page. Each option was explained with clearly written text. While I made the blunder of using javascript links as opposed to standard Submit and Reset form buttons, I loved the site I had created. Deninet 4.0 was a clear evolution from versions 2 and 3, and easily the most refined deninet experience yet created.

While working on deninet 6.0, I pulled up my archives and reviewed my ideas from that period. I began to think, Wouldn't it be nice if we could provide the a strong UI experience for the next version? The biggest problem, unfortunately, was that tweaking that experience is no longer a simple matter. All versions of deninet prior to 5.0r were build on a custom content manager (or no content manager at all). I had maximum control of each individual page. If I wanted to implement a particular feature or change the presentation of a page, it would simply be a matter of making the necessary code changes. 

Now that we are using Drupal, things aren't nearly as easy. For example, I recently had an idea to modify the Create Content page to be a table of icons and friendlier descriptions as opposed to the current definition list of links. To my annoyance, there appears to be no way to nicely modify this page short of ugly theme hacks or module development. Web searches show that few people have even considered such a thing. I'm not even sure it is possible to write a module to modify the page. It's possible to supplant the entire page with a custom one, but without hooks into the content types, it would be no better than a static page. 

Block and breadcrumb themeing is particular annoying, as both are provided to the theme as a scalar variable containing HTML. If I'm unhappy with the output, I have to resort to string or regular expression replacements that would execute for each page display. If that doesn't work, the only means available to me is complex string manipulations and HTML parsing. As someone experienced with PHP development, I'm sensing a serious lack of separation between the data and presentation layers.

It's possible I will have to accept what I can when it comes to UI in deninet 6.0. As long as I continue to use Drupal to power the site, I will need to continue researching just how far I can modify it. 

It's been some time since I've written software on my own time. The last project I attempted was the ill-fated Yin content manager. Before that, it was Gazelle and the Internet Idea Database. I decided to stop so I could focus on developing Paper Girl. Now that I'm starting script-writing, one would think me mad for starting a software project at the same time.

One reason I decided to put down software development was that I didn't want to divide my time between two projects. A major undertaking like a content manager would take too much of my limited free time. This was the motive for switching to Drupal over a year ago. In essence, I wanted to "out-source" the content manager, so I could focus on what was important to me.

When I did switch to Drupal, every possible functionality was covered. I had blogs, users, forums, and image galleries. One function was the management of webcomic content. The Webcomic Module was designed explicitly for that purpose. The module had some bugs at the time, which I reported to the author. Eventually a new release came out that resolved these issues. Unfortunately, the module was seriously lacking in a number of different ways. I ignored these for the time being. After all, I wasn't going to draw comics any time soon, was I?

Eventually, I uploaded the few comics I have produced over the years. The original 24 episodes of Novella: College Journal Manga remain to this day, the only Webcomic managed content on the site. I never bothered to create a top-level link out of a sense of personal shame. I am a much better artist today than I was back then.

A year ago, Drupal 5 was released. In addition to several feature enhancements, the module API was changed. This necessitated rewriting all modules in order to use them on the new version. I was hoping that the Webcomic module would be among them, but I've come to the conclusion that the project has been abandoned by its maintainer. This leaves me with no upgrade path for those 24 episodes and any other future content. That is, of course, unless I decide to fashion my own solution.

Since I switched to Drupal, I've wanted to learn how to write modules. Developing my own version of the Webcomic module provides me a ready excuse. The Manga module will be my implementation of a webcomic content module. My plan is to first replicate core functionality of the Webcomic module. This includes basic content management, image uploading, and sequential browsing. Drawing from the Webcomic module, I've implemented most of these features already, learning how the module system works as I go along.

I spent most of this afternoon implementing image management in the module. This brings it to 75% functionality compared to the Webcomic module. I suspect a few more days of work will close that gap. I've decided not to implement the module directly in Drupal 5. I want to replicate as much functionality from the Webcomic module as possible before attempting an upgrade.