Behind the scenes: Editors can lay out Web pages

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.

New homepage

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.

Tabs show if you have permissions

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.

Page in layout-dummy mode

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.

New pages can choose from a set of options

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.


Impressive flexibility. My only concern is that it seems like an attempt to make the web behave like a printed newspaper rather than a news company present content in a web-friendly manner. In print, you have one impression a day to make with your readers. On the web, your most loyal readers will likely stop back often throughout the day. So why do so many news site obsess over creating a layout that promotes stale news?

What type of impact does the flexible grid layout do you see having on the actual structure of the outputted HTML files? Every implementation of this type of concept I have seen involves lots of nested divs or tables. That is going to have a large impact on SEO and accessibility tools such as screen readers. How much consideration was given to how features like this impact compliance to WCAG or other disability guidelines? Inaccessible websites seem to be increasingly challenged in court (See National Federation of the Blind vs Target Corporation) and I would imagine a public institution like a newspaper would be a big target.

I'll have a post tomorrow that addresses the question of timeliness, which is an important one. SEO is worth a complete post as well. It's a very complicated question, and part of the answer is that complex section fronts and topics pages need to be considered separately from individual stories, blog posts, etc. We have SEO strategies for each case. As for handicap accessibility -- the truth is that it's not a priority, especially not for the homepage and section fronts. The content is available to screen readers; we're not hiding information in image files. We do use images for some labels via Drupal's contributed Signwriter module, but the corresponding language is also available in text that a screen reader could process. The underlying page isn't designed to be read by a bot, though. The content is thoroughly marked up with class names that make sense and microformats will be supported as well. But we're not worrying about writing audio stylesheets. I think a lot of standardization work needs to be done in this space. The open-source community loves standards.