Adaptive Path Blog

Lately there’s been a little bit of noise about the fact that we chose Wordpress as the platform for this here weblog, even though historically we’ve been a Movable Type kind of company. Just to clear some stuff up: Our main site’s still powered by, and will continue to be powered by, Movable Type. Thing is, when you’ve got friends all over the Internet (and all over the companies that power it), you’ve got to spread the love around. Wordpress, Movable Type, and my own personal site runs on Blogger. Who knows? Maybe we’ll rearchitect with Drupal next. Gotta keep it interesting.

Still, equal opportunity was only one consideration we used when picking Wordpress. At AP, we’re deeply technology-agnostic, because we firmly believe that technology should enable the choices you make, not constrain them. Too many firms buy into expensive applications expecting quick fixes and miracle solutions, an approach that never works; instead, take the time to understand what your current situation is and what your real needs are, then choose a platform that aligns with those needs. People and process first, then technology.

And in that spirit, an explanation of why in this instance Wordpress was the deliberate choice for the AP weblog:

Pricing. They’re gonna smack me for saying this, but despite some strides made since they first introduced it, MT’s pricing system is still more confusing than it needs to be. This page, in particular, leaves me scratching my head (it’s not that I can’t figure it out, it’s that I shouldn’t have to work so hard!) Given that everybody in the company can post, I think we would have had to spent $600 to run MT in this case (assuming we upgraded from version 2, which we’re still running on our site, though hopefully not much longer.) Wordpress, open-source, is free. Advantage: Wordpress.

Multi-blog support. One install of MT can power many weblogs, whereas Wordpress, as far as I can tell, supports only one per install. Wacky. MT’s had this support forever, and this is one of the big reasons we use MT as the CMS for the AP site. Advantage: Movable Type, though since we’re only doing a single group blog, Wordpress is fine in this instance.

Backend integration. Sure, we don’t have much of a backend, but we do have one (and, actually, a lot of it was written by Ben Trott pre-SixApart!) David Verba, our tech director and manager of all things AP-Internet-related, is a perl guy at heart — points in favor of MT — but he’s smart and flexible and knows his LAMP, so PHP-based Wordpress isn’t a problem. Advantage: MT, but really it’s a wash.

Healthy competition. We love a good technology ecosystem. Competition keeps companies on their toes, especially young and hungry ones. We appreciate our competitors, just like I’m sure MT and Wordpress appreciate each other. In the end, the customers win! For us, given this, advantage: Wordpress, but points to both companies for contributing to such a rich cultural and technical environment.

All other things being equal — including two incredibly robust third-party plug-in developer communities, and a similar level of awkward interface heaviness (oh, how I miss the day when the entire Blogger app was one framed page!) — we leaned on our propensity for sharing the love and went with Wordpress. Bearing in mind that MT continues to amaze me with its flexibility as a small-scale CMS for the AP site, which I’m sure will only improve once we finally install MT3.

Conclusion: So far, so good! We still love Movable Type! Blogger is super-easy to use! Drupal rocks! Be my MySpace friend! I love your Flickr stream! BFF, everybody, ok?

Share This

When we first started AP, a lot of clients came to us asking for assistance re-architecting their public-facing websites. And every time we sat down to learn about how their existing architecture came about, they told us the same two things: first, that it hadn’t been developed intentionally but instead “grew organically;” and second, that the structure of the information on their site was tightly tied to the way their company was organized.

Knowing this, our goal was to transform each site from something that reflected corporate hierarchy to something designed to support users’ needs. Then — the harder part — we helped them figure out how to support this new structure, in terms of process, content, and technology, since the new design no longer neatly mapped to the way the company operated. A lot of the more strategic work we do at AP around how to best integrate design teams into larger organizations developed out of a need to figure out how to best support this kind of information transformation. Peter was talking a lot about this way back in 2002.

It’s not surprising that companies exposed their org charts as their sites back then. After all, it’s a structure they were familiar with, and this was before we understood the opportunities afforded by the hyperlink and the real power of bottom-up data organization (not to mention what you can do with user-generated content.) Five years later, the corporate landscape looks very different. Though you can still find the occasional org chart online, it’s more the exception than the rule for successful businesses.

Still, when we decided it was time to revisit the Adaptive Path website, we realized we’d fallen into the same trap. Our site’s set up around our various lines of business — services, events, publications, and products — and the current setup doesn’t scale at all. My new line of business could just as easily sit under “Services” as “Products,” where we put it, and take a look at how we tacked this “Blog” onto the top nav, too.

So we’re retrenching, thinking about what we want our site to be, and how we can move it beyond a traditional consulting website into something bigger, better, something more in line with the kind of company we want to be. At the same time, we’re also rethinking our internal organization, trying to come up with ways to allow for more creativity, more flexibility, more opportunity for people who work at AP to figure out what they want to do and then just go do it.

In exploring both of these things, my coworker Kate and I realized something: the model she’s been developing to describe the concept behind AP.com v4, very bottom-up and matrixed, very much about the intersection of people and ideas and the larger community AP exists within, looks a whole lot like what we’ve been talking about when we discuss the way we want our company to work, too.

Which got us thinking: if websites were first hierarchically organized like the companies that created them, forcing a customer to interact with a company’s view of itself, and then those sites were updated to operate the way customers perceived and wanted to interact with those companies, what comes next? Isn’t it possible that it’s time to take what we’ve learned about what our customers want from our sites, and then apply that learning back to the structure of our own organizations? Is the next stage in this evolution not on the site per se, but instead on the company that supports it, finding ways to make our companies work more like our websites do?

What would that look like?

Share This