Current Portfolio:

The Constant Rebirth of the To Do List

Wednesday August 11th 2004

I've optimistically joked before that when it comes to this website, there is never an end in sight. In reality though, my poor excuse for a sense of humor couldn't be closer to the truth. Any end I see always ends up as a mirage--with myself left stranded and wandering in a desert of code and dreams.

By the "end" of course I mean that One Day I will visit and think about this site only from the content manager's perspective, but never as it's designer and developer; that I will look at its guts, and gaze at it's image, and not find another corner to tweak and 'improve.'

Yet for some things in life, there never is an end. Well, at least until everything Ends. We'll always want to hear more music. I'll always want to enjoy a good sunset, or a good wave, or a good laugh, one more time. A hundred more times. . . And since my profession is so mingled with my hobbies (while simultaneously being so distant), this site has fallen from grace into that inspirational, cavernous hole that is my Future.

And to say this, is to reveal the existance of its To Do List. What design element did I want to revisit today? What feature did I see on someone else's site and now want to recreate for myself? Albeit loosely assembled, there is always a simple text file on my desktop, a la "ideas.txt", and it is never 0kb in size. . .

The problem with this blatently limiting method of record keeping is that it doesn't lend me the opportunity to elaborate the idea, to expore it. Instead I'm forced to log it somewhere up in my head, which just becomes more crowded and muddled with each passing day. And as long as they stay in my head, they won't be going anywhere else. So I'm letting a few out, just to see what comes back to the roost. . .

  • Spell Checker

    Dunstan has one, and I want one too. I've already downloaded an article about PHP's capabilities of it, so at least I know where the tools are. Yet I've still got to figure out just how to wield them properly. The problem is, this dips into a deeper, more elaborate item on this list. . .

  • HTML-embedded Text in Posts

    Here is a prime example of the very few sort of attractive capabilities "real" blogging softwares can offer. I allow for HTML tags to be included right now, but I'm not quite sure how to both do that and count words, allow for code display, verify that the text is valid, and other tiny enhancements that would make my admin area much more usable.

    The more I think of it, and from what I recall of other inspirational blog sites out there, what I need to do is come up with my own mini-tag set for applying certain styles to the posts, and then encode all instances of the angled brackets. This would allow for program code to be displayed without difficulty, and I can still style elements within the body of my post.

    As for a syntax, perhaps I could turn to my familiarity with Lasso bracket code, and use '[' and ']' to surround my custom tags. . . or is this to complex? Eris uses Textpattern and Textile, which uses much simpler character patterns to recognize stylings. And being a full-fledged web publishing tool, perhaps I should see what I can learn from it. . .

  • From Dynamic to Static

    At first I thought it was an amateur idea--'static' was sooooo yesterday. If you've got content to regularly update, I had always believed, then you needed to store them in a database so that you could access them at any moment. . .

    But it's taken me this long to realize when a site really needs to be real-time current, and when it is actually just a normally current site. Think minutes versus days. Or seconds versus weeks. Unless I've got users interacting with users, or gigs upon gigs of ever-changing and -growing facts, there's no need to unnecessarily load a server for every 1 or even 1000th visitor to my site.

  • PHP Introduces XML to XHTML

    So here's where it really gets complicated. I think that I want to move my entire website from mySQL to XML. Posts, comments (on The List too), picture galleries, everything. Unfortunately, this will probably double the amount of work done up front, since I'll need to create the PHP code that will create/update the XML that will be used by even more PHP code to create/update the XHTML. The big picture idea is to create the XML and XHTML files at the time of a record update or creation, so that the heavy load is placed on the server only once. Or as an alternative, only create the XHTML the first time the page is requested.

    This idea intrigues me, actually. I'm basically talking about faking a sort of "cache" feature. If a page is not found, attempt to find the data needed to create it. Once it's created, it'll remain for the next request. This also means, of course. . .

  • Mod_Rewrite That URL

    This is the biggest reason why I want to move my site over to Total Choice Hosting. Still not sure to what length I'd use this, but it seems like a good thing to know.

  • Calendar Interface

    This too speaks of grander ideas, but screw it, why not shoot for the moon. I have yet to tackle any sort of calendar application for the web, not with javascript, nor php, nor asp, nor a partridge in a pear tree. And since I've been in this biz for rougly 5 years now, it's obvious that I've been avoiding it. Ugh.

    Ah yes, and the grander idea to which it speaks? Well, it's all about how I've organized my site. When reorging it back 6 months or so ago, I wanted to use URLs that were 'bookmarkable' and readable. And since I didn't have the ability to parse my URLs (see previous To Do item), I built out a file structure to match the structure of how I presented my content. Which was first by 'work' or 'play', and then by various subcategories of these. Any pages within these categories would then be pulled from the database. This didn't make it a perfect world, but it made it an acceptable one.

    But then I got neck-deep into the blogging community, and I started to take notice of their URLs. And I noticed that everything is in /Archives/Year/Month/Day/Post_File_Name.html formats. Interesting, but obviously this is a structure applicable almost exclusively to blogging sites. . . Which of course this is, yes, but don't mind that--remember, this is supposed to be about the greater good of my skills and experience. I don't want to create and market blogging software, I want to create and market a content management system. Ooooooooh.

    So anyway, I'm not sure what to do about this twizzler of a riddler. Ultimately I know I can build a calendar interface regardless of how I structure the content, but I want everything to work smoothly, intuitively, and with the least strain on the server.

And these are just the beginnings of the list. . . Yes, my sights are obviously set quite high for this site. But for me, this is my playground, this is my castle, this is where I can foster and grow and explore where I want to go, not where my career is forcing me to go. By day I may code Lasso and wade my way through the thick of Dreamweaver, but by night I dream of structure, symantics, style, logic, design, art, literature, creativity, expression, history. . . and how I can bundle them all together in one pretty little package. . .

Archives