yelvington.com - Site Management System

30 content types? What?

yelvington — Thu, 04 Dec 2008 15:21:34 +0000

When I mentioned the other day that our site management system has more than 30 content types, you might have reacted in one of two ways:

1. Why on earth so many content types?
2. What's a content type?

Let's take the second question first, for clarity's sake.

In the beginning of the Web, there was only one content type, and it was the document. Typically coded by hand, it was without predictable form and structure. You can't build and maintain big websites with hand-tooled HTML, so very quickly we moved to publishing tools. These tools combined content with standard layouts (templates).

If you've posted anything on a blog, you've done something like this:

Blog posts represent a very simple content type. Other purposes require more complex structures -- additional fields -- and different templates for displaying the result.

Drupal has something called the Content Construction Kit. It's actually a family consisting of a little core functionality and quite a few contributed modules that let you create new content types and add all sorts of interesting fields such as validated date fields, embedded media objects, et cetera.

OK, so the technology supports multiple content types. Back to the first question: Why on earth so many content types?

It's easy to see good reasons for news items to be structurally more complex than a simple blog post.

But we also have some types of content you probably wouldn't think about at first.

Wire stories are an interesting case. We're not loading an AP Online feed into Drupal. We already have a system in place to support AP, and it's not so broken that it needs fixing. But we do need to manage and display AP components in the Drupal environment. So we have Drupal's FeedAPI RSS aggregator pulling in headlines and summaries. If you click on an AP headline in Drupal, you're sent directly to the AP server. This required a special content type and a bit of template work.

Promos are another. Every news site manager struggles with competing demands for promotional slots on the homepage for special projects and services, advertising sections, contests, et cetera. So we created a special content type to manage that problem. We made it simple to attach an image that is automatically resized. All the promos go into a library, so they can be temporarily removed and reused later. On Jacksonville.com the promos are displayed in a Javascript-driven carousel throughout the site.

Other content includes special types for various video players, feeds from other technology and content partners, items aggregated from websites in the community, podcasts, cartoons, Soundslides shows, and Tweets. We pull in Twitter postings from @jaxdotcom.

Drupal also creates content types for internal purposes, such as representing user groups, webforms, etc.

Now, what about that editorial content type makes it so special? I'll go into that in my next post in this series.

'Now' means 'now:' tools for timeliness

yelvington — Wed, 03 Dec 2008 12:52:15 +0000

In a comment yesterday, Ed Kohler raised some questions about timely vs. "stale news" that I thought I'd address by turning back to my theme of basic assumptions and assertions behind our site management system. Timeliness is right at the top of the list.

I've known all along that the online journalism has to be conducted in a world of "continuous now." The "continuous news desk" function was an assumption back in 1994 when we were building the first online services at the Star Tribune in Minneapolis.

Yet I still see a lot of systems built around antiquated concepts like "editions."

We're not going down that road at all. Continuous updating and instant publication have been a primary goal of this project since we started.

But there are barriers. Our newspaper newsrooms still rely on antiquated, print-centric systems for internal workflow as written copy passes through various stages of editing.

When it's ready for publication, a story can be immediately released to the Web -- but you have to be a bit patient, because it then passes through a bucket brigade of software and systems. Eventually it'll show up on the Web, but you'd better not hold your breath.

This sort of thing drives a lot of newsrooms to "fix" the problem by using blog software.

But that creates a silo of timely content that's never integrated back into the topical collections on the main site. At some newspapers, there's not even branding and ad positions on fresh news items.

In the course of this project, we've shortened and tightened and accelerated that path from the antique world to the Internet, but it's still a problem.

So here's a solution: you don't have to do it that way.

Since Drupal began its life as bloglike software, "post it right now" is a built-in feature. All you need is an account and the right permissions.

In our model, some content will still flow from the legacy system, but every reporter is expected to know how to post directly on the Web. This means stories can be filed immediately from anywhere, so long as you have a laptop (or a netbook) and an Internet connection.

Using Drupal's contributed family of Content Construction Kit modules, we've created more than 30 specialty content types for specific purposes. The basic "editorial node" is just one of those types, but it's a central and important one. (I'll talk about some of the others in a future post.)

Creating creating a story isn't much harder than simple blogging. Yet the "editorial node" type is a rich one, and when we run internal training sessions we can easily spend half an hour talking about its many possibilities.

We accommodate multiple photos, which are automatically displayed in a dynamic widget. Videos (we use Brightcove) are properly sized and embedded. If you indicate that the story is about a company with a stock symbol, the system embeds a little block linking to live ticker info. Are there related stories? Start typing the headline of one, and an Ajax-enhanced tool will dynamically look it up and create a bidirectional link. And so on.

But you don't have to do those things. Breaking news can be posted immediately in its simplest form, then updated, freshened, expanded and enhanced throughout the day. Since the system is database-driven and dynamic, updated items can be flagged (as you can see here in the top image).

Ultimately, technology isn't enough. Breaking news requires human beings to discover and tell the story. The best we can do with tools is make sure we've removed the barriers.

Behind the scenes: Editors can lay out Web pages

yelvington — Tue, 02 Dec 2008 19:54:15 +0000

I've previously mentioned some of the assumptions and assertions behind the site management toolkit we're developing at Morris. One key assumption is that editors should be able to determine page layouts -- something that's just not possible with a lot of template-driven content management systems. Here's how we're making that work.

Editors begin by seeing the site pretty much as everyone else would.

But if you look closely -- and if you have the permissions that comes with an editor's role -- you see a series of tabs across the top of the main content area on the homepage.

When you click on the content tab, you get a layout dummy. This is accomplished using the Drupal contributed Panels module, written by Earl Miles.

Elements can be added, temporarily disabled (notice the ones that are darkened), dragged and dropped from cell to cell, and so forth. This makes it possible to easily relocate or replace components.

But it's not something that you should have to do in order to update and maintain a site throughout the workday. The actual components displayed on the page are dynamic blocks. Their are determined by applying business rules to the underlying data (stories, images, blog posts, etc.)

For example, one block might list half a dozen of the most recent AP national news stories, while another might feature a picture and headline from the story currently top-ranked by editors. When fresh content is available, the site can automatically change without human intervention.

These blocks are all defined and generated using another Drupal contributed module, Views. It's also written by Earl Miles, recently honored as Drupal MVP. Web producers can learn Views, but it's not something I'd want to have to teach to the copy desk.

A lot of the work that's been going on in Jacksonville over the last month or so has been the development of a library of these Views components and corresponding HTML template work to tailor their output.

This combination of Views, Blocks and Panels is used to manage not only the home page, but also major section fronts such as Sports, News and Interact.

But editors -- not Web geeks, but journalists -- also can create such pages from scratch. It's a straightforward process. You start out by selecting a layout grid from a library.

If you don't like any of the choices, you can also create a custom layout by specifying the number of rows, then the number of columns in each row, and the widths (in pixels or percentages). It's just a matter of filling out a form and no HTML is required.

The resulting grid then can be populated with blocks from the library, or arbitrary content blocks. If you create arbitrary content blocks, you're beginning to get into a requirement that you understand some HTML, but you're still insulated from the complexity of the complete page.

The page is automatically wrapped in the site's standard design, including the required advertising positions, navigation, and branding.

This makes it possible to quickly create topics pages or special presentations for complex major news stories.

Existing pages can be copied, reworked in a "private" mode until they're finished, and then swapped into the live positions. This makes it possible to have a really special homepage when it's time to publish a really special project.

I'll have some more detail on these tools in coming days.

It's everybody's game now

yelvington — Fri, 21 Nov 2008 14:40:47 +0000

Yesterday I began listing assumptions and assertions that are part of our thinking about our evolving website management system. Here's another: It's everybody's game now.

Like it or not, the organizational model that says "you guys work for the newspaper, and you other guys work for the website" is becoming unsustainable. Newsrooms -- or, if you prefer, "news and information centers" -- must become multifunctional, multimedia, multiproduct-focused. Call it what you want: convergence, integration, the end of the world as we know it. It just has to happen.

Tools shape the user. Newspaper journalists carry a terrible burden in the shape of a toolkit focused only on print. That newsroom CMS you all love to hate is only part of that picture, but it's certainly a big part. Other parts of the toolkit may be harder to recognize. Writing styles (inverted pyramid, anecotal lede, various approaches to headlines) are tools, too. The concept of a "story" as a linear, written "article" is a tool, too -- one that is obsolescent.

We can't replace all these tools at once, or even understand how they all should be replaced, but we can go through the kit and look for barriers to performance. If the system requires a knowledge of HTML, that's a barrier. If the system requires that you be in the office to get anything done, that's a barrier. If the system doesn't support the granting of access in appropriate ways, that's a barrier. If the system requires that everything be built around a piece of text and doesn't support video, audio, Flash interactive components, and -- very importantly -- the topic-driven integrated approach that Jeff Jarvis described recently, those are unacceptable barriers.

Craft specialties persist, and not every journalist should be expected to perform every task. But the tools should allow any journalist to play an appropriate role in any medium at any time. Because it's everybody's game now.

No editions, please

yelvington — Thu, 20 Nov 2008 14:58:28 +0000

While we're treading water pending the rollout of our Drupal-based site management project, I thought it might be worth mentioning some of the principles and assumptions behind it. Here's one: No editions, please.

I've seen developers put a great deal of effort into creating Web content managment systems that are intended to reflect the edition structure -- daily, weekly, monthly, whatever -- of a legacy (print) product.

Don't do it. We live in a 24x7 world. The Internet is always on. Information should be available when it makes sense.

I'm not denying the existence of circadian rhythm, nor am I suggesting that news organizations forget all about daily cycles. Most people get up in the morning to engage with a new day, and most newspapers will still be printing daily editions for awhile yet. We still need to plan for days, and publish some information with respect to daily cycles.

But it need not, and should not, rule our lives, or dictate the organizational metaphors we use to display information online.

In the war room

yelvington — Thu, 09 Oct 2008 15:08:44 +0000

This week I'm in Jacksonville, Fla., where a team (right) is hard at work rebuilding Jacksonville.com on our new Drupal-based site management system. There are others up in Augusta and other locations, working as part of a larger virtual team, but even with instant messaging and regular conference calls there's no substitute for shoving a bunch of folks into one room with a sack full of junk food and not letting them out.

The Florida Times-Union's site will be the first on the new platform, followed by the Topeka Capital-Journal and the Conway (Ark.) Log Cabin Democrat. Launch has been pushed back a couple of weeks because of the elections -- we have high confidence in the hardware and software, but people will be stressed out enough without the added complexity of new tools on Nov. 4.

We're relying heavily on some Drupal contributed modules, especially Views (which lets you query the database and create various types of lists without writing SQL), the Content Construction Kit (arbitrarily structured special content types), FeedAPI (RSS and Atom acquisition), and Panels (arbitrary custom page layouts).

The result should be a system that lets reporters report, writers write, and editors edit without having to know anything about HTML, scripting, FTP and other online technobabble. Nevertheless, there are going to be some interesting training challenges as we move from a world in which the Web was the exclusive concern of a small team of specialists, to a world in which every member of the news organization can directly play an appropriate role in Web operations.

Training days

yelvington — Wed, 10 Sep 2008 15:49:55 +0000

Last month I described how we're working to build a next-generation news website management system, based on the Drupal platform. Much of that system has been built out and configured on a development server at work, but there's quite a bit of work remaining.

All this week I'm in daylong training sessions with 10 site developers from three Morris newspapers and Morris DigitalWorks. Many are new to Drupal, so we're covering basic site administration, configuration and operations. They're learning the power that comes with the Views, Nodequeue, Panels and Content Construction Kit modules. They're learning how the templating system gives them total control over presentational details.

When we're done, this will be an innovation platform, not just a content publishing and community platform. They'll be able to take an idea into production quickly.

For example, about a week ago a couple of us were talking about Twitter. The Florida Times-Union has a Jaxdotcom account on Twitter that's very active and rapidly gathering followers. Wouldn't it be great to include it right on the new website? We took that from an idea into a finished product in a little over an hour, using the FeedAPI RSS aggregator, a custom content type, an a custom output template for that type. To add some polish, we whipped up a custom output filter that links Twitter-style usernames like @jaxdotcom directly to their accounts.

Open tools and open platforms are great for developers, but what we really want to do is place this kind of power directly in the hands of content producers. They won't have to know a programming language, or how databases work, or even HTML to create special presentations based on database queries. Need a new XML feed? Point and click. When these folks get back to their respective newspapers, they'll become trainers and resources and spread the knowledge.