I love my MT, but have to admit the dynamic/PHP nature of WordPress’ siren song has pulled me in for a closer look. Let’s see where this all goes?

Update: so far it seems OK, but I’m still getting random 404s/errors when clicking into individual post pages, and unfortunately the tags did not transfer, as I’d feared. 9 years of tagging down the drain is a bit hard to swallow, honestly- that may end up being a deal-breaker honestly. If you stumble across this site – and post – please feel free to bang around a bit, and let me know if you see any other weirdnesses (aside from the dismal default template I’ve got applied right now)?

Update: screw that- I’m testing out WordPress right now to see if it’ll work better for me.  So far, the import in WP 2.5 is working like a champ, and aside from losing my tags seems to have migrated everything pretty well.  We may be moving to WordPress in short order.

And that response was the recent Spry 1.6 update, of course. Which is getting much better feedback than 1.0, by a long shot. Jeremy recently took another peek at Spry and was as pleased with the documentation as he was with the technical changes in 1.6, Roger also recently gave a nod to the improved accessibility and progressive enhancement support. Right on. Spry’s still young, relatively speaking- so it’s nice to know the ship is headed in the right direction in regards to best practices overall.

Would you agree? If not, why?
Inquiring minds would love to know…

One big up- I really ike the new Movable Type admin interface. It’s cleaner of design, more straightforward in function, with a lot of new features- and just seems easier to work with in general.

The Movable Type 4 Admin UI

I haven’t spent much time really tweaking the new features, but think that the scheduled posting and ‘standalone pages’ features will be new favorites. Best of all, although posting comments still isn’t overly speedy, it’s much faster now than it was last week on MT 3.x. And that, to me, is well worth the pain of upgrading.

Thanks, and my sincere apologies in advance for any strange behavior you may run across as I spruce up the ‘ol codebase.

Update – I’m now back to feature parity with my old installation, with the captcha gone from comments and the updated spam filter holding resiliency like a champ (knock wood) in it’s place. Expectations are that everything works as expected now, so please ping me if it does not, as I’m going to start updating individual features/templates one by one now. Thanks in advance.

If you’ve been trying to get to the site the last day or so and finding it not accessible, it’s because my server host (Dreamhost) decided to change the DNS entry for their Apache instances without letting their clients know. Personally, I find this pretty reprehensible, especially for a host that has been so rock-solid for so long for me.

Anyway, thebigdark.com’s back up and alive again now (as far as I can tell so far), but please bang a comment below if something’s not behaving as expected. Thanks!

Participate in ALA’s 2007 Web Design Survey here, and if you’re so inclined, discuss the survey and it’s questions here to help shape the process in the future. A great idea who’s time has certainly come.

First up when launching Coda (well, after you’ve defined a few sites to begin with), you’re greeted with a rather elegant looking list of sites to choose from. In the shot below, I’ve just two- this one and another ‘test’ site I had on hand.

Coda in Site Chooser View

After selecting one of your sites, you’re dropped into what I consider the main workspace, your file, a list of all the files in your site alongst the left of the screen (which yes- can flip between local and remote views) that allows transfer of files using a streamlined version of the lickety-split-quick Transmit engine, and nothing else. As so:

Coda in Code View

The code editor is nice- largely as it’s built on the SubEthaEdit engine, which is already a well-proven editing core on Macs. SubEtha also provides a cool collaboration feature by way of the codebase- you can share editing of the document with anyone else available using Coda (and perhaps SubEthaEdit?) accessible to you online. There’s a great grep-esque visual search and replace feature that actually lets you specify variables visually- nice touch.

You can preview your page easily via the built-in WebKit rendering engine, and with a slightly added touch- by turning on the DOM inspector you can visually select elements on your page and see their exact cascading location in the DOM. Makes it very easy to see the elements of your page in context, and understand how their ancestors may or may not be affecting them. In the screenshot below – which is admittedly teeny – the DOM elements are listed underneath the preview, with the selected element in blue at the far right.

Coda in Preview/DOM Inspection Mode

CSS styles are no second-class citizen in Coda – you can inspect the CSS files directly with a visual editing mode (think Dreamweaver’s CSS Rules editors broken out to a single-pane interface with a ‘menu’ of sorts on it’s left) as well:

Coda in CSS Edit Mode

All in all, makes for a very compelling 1.0 product. Kudos to the Panic team for doing some great work on a very focused, Mac-savvy application. I don’t see it replacing Dreamweaver CS3 for me anytime soon, but Panic’s definitely got a nice application on their hands here. It’s also just plain cool to see such elegant innovation from a Mac-specific development house, cause you know I loves me some Macintosh.

Check out Coda at the Panic website, and make sure to read Steven’s blog post about the app itself (with far more detail than I’ve hacked together here, by all means).