Magic Web Fairies

Well a bit of time passed since my first entry. Had a lovely, yet unpaid vacation in Seattle (curse you, contract work.) So this blog entry is about the length of five.

The other day someone mentioned that Web 2.0 sites are successful because they follow a “producer model” meaning that one person does everything on the site and makes all of the decisions (ie has the vision). While this is potentially true for single person blogs, it falls apart when applied in an actual business setting for complex sites.

The fact is that the Web 2.0 publishing model is not much different from the Web publishing model that most of us have been following for over ten years. This model is both precise & flexible. It’s precise in that there are specific tasks that must be done. It’s flexible in that these tasks can distribute differently depending on resource talents, resource availability and funding level.

In order to bring up our three Web 2.0 sites we needed:

Hardware

• Hardware specs
• Set up
• Management
• Infrastructure roadmap for growth
• Budget management

Back end software (there’s prob a better term for this but I’m going to continue to call it this till someone corrects me)

• Specs
• Installation and set up (ranges from OS to applications to metrics packages)
• Management
• Budget management
• Programming

Front end work (in brain dump order)

• UI design
• Information Architecture
• Accessibility
• Graphics
• HTML, CSS coding
• Scripting
• SEO
• QA
• CMS management
• Training for CMS use
• Document creation/formatting in CMS
• Process development
• Coding standards
• Publishing standards
• Site roadmap
• Ad rotation
• Budget management
• Site management
• Research
• Documentation
• User support (increased need because of interactive nature of sites)
• RSS feeds (a Web 2.0 addition)
• Moderation (a Web 2.0 addition – to deal with all the comment and trackback spam and the occasional nasty comment)
• Blogger training (yet more W2)

Metrics

• Choose a metrics program(s) (often more than one if you need click tracking or special reports for media)
• Pull reports
• Interpretation of reports (some of this will be done by other areas)
• Media stats

Content

• Acquisition
• Editing
• Writing
• Editorial standards
• Site editorial vision (ie what types of content to pursue at what time)
• Editorial calendar
• Budget management
• Podcast production, scheduling & communications (Web 2.0 addition – this is a beast)
• Research
• Interpretation of social tagging and what it means for editorial (another W2.0 addition)

Marketing

• Ad or sponsorships
• Media kits
• Google AdWords
• Process development to move money brought in to Finance area

Finance

• PO processing
• Distribution of budget to different groups

Users (a Web 2.0 addition!)

• Social tagging (site participation)

Media (podcasts are a Web 2.0 addition for our sites)

• Recording
• Host for interviews
• Audio editing
• Music
• Media hosting

(I’m definitely missing things esp. under marketing. But that’s not my field and I’m just happy when a marketing person brings in money and tells me that some ad space sold.)

An example of the flexibility can be seen in what we are doing for hardware and back end software. Traditionally, you would probably put both hardware & back end software (in our case Apache, Linux, Zope, Plone) in the hands of IT. But due to overload in our IT shop, that just wasn’t even vaguely possibly.

So we came up with a different plan. Hardware specs, budget for hardware and back end software, infrastructure roadmap & PO processing are done by our “audio” guy, Tom Parish, because he has the strongest background in it and has a side company that can deal with the paperwork chaos. The hardware itself is outsourced to a USA hosting company who also monitors the servers (hardware only). The loading and monitoring of software as well as additional python programming is done by a Ukranian group called QuintaGroup (they rock) who are experts in Plone and Zope. QG also monitors server performance and does reboots and other adjustments. Sometimes, we pull QG into front end work because they have a great CSS/graphics guy there who can help us out during front end resource crunches.

So two areas of specific tasks that you might think would be housed in one place for responsibility are actually housed in three for our group. And it works just fine. Mainly due to who we’ve chosen as our resources and their skill and reliability.

So if I were a corporate person prone to making org charts, the one I’d create for crafting a Web site would look like this:

You can throw out those hierarchical org charts when it comes to the Web. They will never reflect the necessary empowerment of the leads in each area or the connections required between the areas to make it all flow. Each lead has a vision for their area and works hard to integrate that vision with all the other leads for the good of the site, the visitors and the company.

I do see a few differences between our “old” Web publishing model and what’s required for Web 2.0 sites. Many of the main areas (front end, content etc) have expanded duties to encompass the increased demand that community Web sites require. Media might even be considered a “new” channel even though we’ve had the base capabilities for years – now we have the addition of finding the “right” media hosting service and getting our RSS feeds in order. (And one day I’ll tell ya a little story about that.) Another new one is that users can be considered an active partner in these sites now due to the participation level you hit after you’ve gained their trust.

My punk rock side says that this is an over analysis of a working model that in the best situation “just happens” (rather like magic). I constantly see confusion around who does what because of the flexibility of this model. When I showed the graphic to a content manager at my work she told me it looked like a weather system. Well, welcome to the hurricane that is the Web!