New site design with ModX content management

I’m working on a redesign of One-Shore.com, with a blue and tan “nautical” theme.  I’ve run into the usual frustrations with Javascript, CSS, and DOM, but am working through them.

The new site is under development at http://new.one-shore.com.

I’m also using the QA Site for development (at http://one-shore.qa-site.com) , but right now that consists of just using Bugzilla and Trac (for design.)

I really liked my method of using the wiki for design, building a wireframe (that’s not the perfect term) of the links in the wiki, and then a wiki features list.  The as you flesh out the pages, you can link to features, components. I’d like a feature checklist app that can tie in to the wiki pages detailing each feature, and the ability to spin a discussion off of the actual documentation.

I’ll be using Project Pier for planning as well, but I don’t know how happy I am using lightweight PM tools.  The task lists seem too informal, more like todo lists, and I’d like to tie work to features, but keep the project->milestone->task->work and product->release->feature->requirement hierarchies separate.  (See my post on modeling projects and products.)

I’ll wait until after the site design to put anything valuable on the dashboard.  Things like recent changes and assigned bugs, tasks, tests executed, etc. kind of get unused on a one-man show, since everthing is assigned to you.  But I do need some help prioritizing.

Besides the new layout, I’m working on the site navigation and content.  I’ve got a new menu list, and am still debating whether to add drop down menus:

• about
• blog
• wiki
• demos
• products
• services
• support
• contact

I’m leaving the forum off (and may take the demos off) and added products and support.  Support can lead to the forum or contact. I’ve also thought about putting blog/wiki/forum/demo on a sidebar.  Maybe with the tools wiki links.

I’ll be making the tools menu tree into a dynamic widget (eventually) – though it seems more of a hassle than it’s worth.  I’d still have to keep it in sync with the wiki.  I’ve toyed with XML and am thinking of maybe creating a DB table for it.  Shoehorning a hierarchy into a table structure isn’t always best, but I think it might make sense in this situation.   The table could look like:

• Link
• Id
• Label
• Expandible (or hasChildren)
• Parent (or Category)

Or I could have flags (or associations) for QA, Dev, PM, Biz, etc.  as well as tool types such as bug tracker, IDE, etc.  Too much abstraction is the enemy of a useful model.

Content is the big one that needs updated, though I’ve been cutting and pasting from the existing site.  I am just not good at marketing copy.  In order to make the copy editing easier (and to impose some structure so I don’t have to make the pretty links myself, I’ve decided to use a CMS.

After a lot of evaluations, I’ve come up with a list of what’s wrong with CMSes.  Though as usual, it’s more of a ramble than a useful list.  The main issues are:

• too much of a learning curve — wasting time gaining knowledge just to use that specific tool
• letting me lay out my site the way I want — again, needing to learn a complex new templating system and arcane admin inteface
• making it easy to update content — not in a textarea in a browser and not stored in a database.

I’m using ModX for content management:  ModX has the nicest admin tool of any CMS I’ve tried.  It’s philosophy is to get out of your way.

ModX does a fairly good job of the first two.   It’s a little weak on structuring though, but that allows you to post a PHP snippet instead of learning a byzantine module format.  So there are pluses and minuses.  If you could plug in a component framework with things like authentication, etc.  then you might be cooking.  As is, you’ve got a bunch of one-off scripts that you have to cut and paste into the admin textarea.  So something like Joomla or Drupal wins in that regard, except that writing modules, plugins, etc. for either of them is too arcane, and all you get out of it is a sidebar box.

But after only a couple days, I’m really aching for a real content repository.  Something I can roll back, something I can FTP (or much better, checkin.)  Content should be under revision control.

And the develop/test/deploy cycle for textarea editing and programming is brutal.  I want to make a change in dev, run a quick script to put it in test, and then run the same script again with a different parameter to put it in staging.  Once it’s verfied in staging, I want to flip a switch (like change a VHOST and restart apache) and make it go live.

And I don’t want to do database dumps.  For one, that means losing production data every time I make a change.  And for another it makes the cycle that much longer and error prone.  I want to make a quick layout change in dev and push a button and see it show up on the production site.  For this reason, I’m thinking about giving up on CMS altogether.

What I’m really looking for is a CMS that uses a repository for content.  Including layout and formatting (themes.)   It can still use a database, especially for things like users.  But don’t put my content in there.  Or if you do, provide scripts so that I can put them in a file hierarchy and it slurps them up for search or admin or whatever.  A decent CMS outputs pages and components to a cache file anyway for display.