Every once in a while, I feel obligated to write about what I'm doing on Tabulas; what's the point of this journal if I can't reflect about what I did in vivid detail some far-off time in the future? Heck, maybe one day in the future someone will read this and go, "Wow, they actually had to do that?"


I've been working on and off with some intermittency on the new control panel. I've slowly been chugging through, rewriting most of the pages in the control panel from scratch. I also rewrote most of the custom libraries I use for sql handling and such; it's still mySQL specific (which I've come to realize is going to be hamper growth in the long run... ideally I could eventually move to some Oracle product which would be uberfast), but that can be a problem I fix later (does this line sound familiar?)

In any case, here are the things I have done:

- In general, I've rewritten the HTML for the control panel. For the most part, it avoids using tables and sticks with CSS for output. I reorganized the structuring of the tabs so things make more sense in terms of the context of the site (e.g. categories and such are located under the 'journal' tab, while 'entry options' was moved to the 'preferences' tab.

- Most of the work I've done so far is in the 'Website' management. I ported the old code for hit log management (that had recently been optimized and I saw no reason to mess with it), but I rewrote link and content page handling, as well as link categories. Again, there have been almost no aesthetic changes yet (besides the redesign).

- Although I did take advantage of bookmarklets to create a link bookmarklet. What you basically do is drag a link to your IE toolbar; then whenever you visit a page you want to add to your links page, you click the link. The page automatically extracts all relevant information and will redirect you back to the page; think of it as "bookmarking" on your Tabulas. It's very easy and fast, and I've been taking advantage of it lately (you can see my links page has gotten a few more links).

- Of all the coding on Tabulas, two things have not ever been rescripted since day one: the gallery and the color style management. Whoops. Both of those are such a mess that I *literally* have no idea what's happening in either script; that's why I've never really been able to address bugs to either one; the scripting is just SO horrendous that I don't know where to start.

- So I've been slowly rewriting the gallery management; it's going to be a lot simpler than it currently is (but a lot easier to use). There will be "mass delete" options for albums and such so you don't have to delete images individually; that works fine... I decided to use almost the same UI as the existing gallery, so the gallery control panel will mostly be table-driven (but who really cares?!)

- The big hurdle for me is tackling the color management system. There's a combination of bad hacks that's making things very difficult. The problem is that the color schemes was always meant to be for CSS-driven templates ... but the "default" styles used are horrendously not-standards-compliant (ever try to create a custom Tabulas template using the existing CSS files? I even shudder at the thought of it).

The original problem is there are TOO many options; people should not be allowed to choose the padding and margins and obscure styling references (is font-weight _really_ necessary?) So in the next rollout of the control panel, the color scheme is going to parse only a few class attributes in each CSS file: font-family, font-size, background-color, color, border-color, border-style, line-height. Everything else will be set by default.

I've also tried to make the default templating engine much more open-ended that it needs to be. I've given people _too_ many options; I've learned that if people really want to get a fully customized journal, they _will_ learn HTML/CSS or ask their friends to help them. Tabulas does not necessarily need to accomodate them at the risk of alienating less-savvy users.

But this leads me to my next point: default templates suckage. I'm going to have to roll out changes to the templating engine as well as the color scheme engine, but this means I probaby want to revamp the templates to be standard-compliant (semantically). So it's basically I have to do everything at once, which is why it's taking some time... planning everything is going to be tricky.

As far as I can see, all people using custom color schemes will have to restart (I'm sure it's not too big of a deal) ... as I will have to delete all the old color schemes. But I'm sure it'll be fine.

- The messaging center has been simplified; only two boxes now (inbox/outbox), but there is now the ability to "attach" templates and css files for use on your own site... so people can start "trading" templates and whatnot.

- I'm aiming to make the user directory more of a social-networking type of place; you will be able to view templatized views of each user with more specific information ... and be able to search by age, sex, location, name... I must say that thefacebook inspired me in a way to generate a "Tabulas" version.

But the question is how much hitting can the database take? Granted, the profile table isn't too highly in use so collisions are very low, but ideally I would like the user directory to hit the database as little as possible.

So what I've decided to do is when I do finally open up the user directory, I'll make it beta/paid only... this will help limit the stress on the database so I can see how well it scales. But I do think I need to be looking at purchasing a sole database server ... Tabulas is getting quite hefty, and I think I will be reaching some sort of limitation quite soon.

Man I'm tired. More later.