The WGBH.org Development Blog

For those of us in the northern hemisphere, fall has arrived! In between raking up and burning piles of leaves (and useless 401K statements), we here at WGBH Online have continued to fine tune our new(ish) TV Programs and Schedules pages.

As you may recall, not long after launch in August, we began to revisit the whole notion of how we’re tagging our TV programs and episodes. The main reason was to improve the way we generate lists of related programs, so as to suggest to visitors other shows they might like. Our initial approach was simple: just tag the programs (not individual episodes) and use a Drupal view to generate a list of up to three related programs.

But this soon proved restrictive. Sure, Frontline is a News and Public Affairs program, but individual shows in the series can be about different things (technology, politics, science). So, we wanted to be able to capture this more detailed level of information and use it to generate more useful lists of related programs for our visitors.

After much thought and discussion (not to mention headaches), we came up with an expanded tagging scheme and more sophisticated program matching logic, which has now been implemented on the site. Here’s what we did:

We renamed our existing TV Program Genre vocabulary to TV Program Primary Genres.

The terms remained the same (a small set of high level classifications) and these are still only applied at the program level.

We then added a new vocabulary that can be applied to both TV programs and episodes: TV Program/Episode Secondary Genres.

This secondary list has many more terms that now allow for a more sophisticated level of classification. tags applied at the program level apply to all episodes in a series. Tags applied at the episode level are only applicable to that particular episode.

Once we had that in place we then had to think about how, using these tags and given a single program episode, we would define rules for identifying “related” programs and episodes.

This is where the aforementioned headaches started to kick in.

Once you started to think about it, all sorts of questions cropped up, like, which carries more weight, matching primary genre tags or secondary genre tags (or should they count equally)? Or, assuming two related programs have the same tags as the target episode, how to break the tie? Or, do we match an episode within one series to other episodes in that series or restrict it to episodes of other series?

Pass the aspirin, because I’m getting a headache just thinking about it again.

Luckily, we have some fine folks working here who sat down and really noodled through this to come up with some matching logic. When written out, the matching rules looked something like this:

1. Match at the episode level
2. Cull only from upcoming or recently-aired episodes
3. Look for most tag matches, with all tags equally weighted
4. Only allow one episode per program/series to appear in “You Might Also Like” box
5. In a tie, give priority to episodes with same “Program Primary” tag
6. If still a tie, give priority to episodes with exact same tag makeup (i.e. both have only one Primary tag)
7. If still a tie, give priority to the episode with soonest upcoming airing.

The idea was then to use the tags and these rules to generate up to three matches for each episode to display in the “You might also like” block in the right hand rail.

Well, up to three matches, unless there were more than three episodes with the exact same tag structure as the target episode. In that case, we will display up to five such matches.

No sweat!

In order to actually implement this, we could no longer just spit out the results from a view. Nope. Instead, we had to jump through a whole bunch of hoops. Here’s the thumbnail sketch of the implementation:

1. Given the tags for a target episode, query a view of TV programs, fetching all programs that match at least one Program Primary or Secondary tag.

2. Filter this list of programs, including only programs with an airing in our schedule data window (one week back, two weeks ahead).

3. Then count the exact number of tag matches and calculate a matching score for each program, based on the above rules. Then store the program in an array.

NOTE: I won’t go into the exact matching score formula here. Suffice it to say we came up with a formula that encapsulates the above matching and ordering rules. Please pass the aspirin again…

4. Next query a view of TV episodes, fetching all episodes that match at least one Episode Secondary genre of the episode in question.

5. Filter this list of episodes, including only those with an airing in our schedule data window. For each one count the exact number of matching genre tags for the episode and calculate the matching score. See if the episode’s parent program is already in the array of matching programs. If so, replace it with this episode if the matching score is higher.

6. Given the final array of matching episodes, reorder the array by the matching scores and display the top three (or five) entries!

The resulting PHP code to implement all of this ran to about 240 lines and looked a little something like this:

All that just to generate this on the front end:

Anybody know the limit on the number of aspirin you can take in one day?

The new WGBH TV Programs and Schedules module has been up and running on Drupal for almost a month now and - knock on wood - everything is working great! In fact, things have been going so well, operationally, at least, that all has been … quiet!

Quiet is good.

Now that this phase of the project is all done we are turning our full attention towards the real goal: porting all of WGBH.org to Drupal and completely overhauling the information architecture and user interface. We’re currently busy doing content audits, wireframes, schedules and all that sort of fun site redesign stuff. Nothing is ready yet for actual development.

In the meantime, we’re also addressing a few small desired functionality changes to TV programs and schedules that we chose not to address during the build. At the top of the list is the way that we generated the list of related (i.e. You might also like) programs on our episode pages.

Currently, this list is generated automatically using tags applied at the program (series) level. We developed a simple TV Program Genre vocabularly to potentially apply to each program.

Content producers ultimately have the ability to override the automatically generated list if they like, but, for the most part, what you see is generated on the fly based on the tags.

The upshot here is that by only applying tags at the program/series level, each episode of a given series (e.g. all NOVA episodes) will display the same set of related programs. So while NOVA may generally be a science program, a given program may be focused on, say, a physics problem, but this isn’t reflected in the related programs list. Our tagging scheme doesn’t currently allow us to relate programs on a more granular level than the simple genres we’ve defined.

Initially, we had planned to support tagging at the episode level for the initial build for use in generating the related program list. However, when we sat down to hash out how it should work it quickly became clear that using tags at both the program and episode level made things far more complex.

For example, right now, with tags only at the program level, it’s pretty simple. On a given episode page, we fetch the tags on the parent program, then using a view, generate a list of other programs with the same tag(s) and display three of those. Easy-peasy!

But once you throw episodes into the mix you now have to make decisions on issues, like, do matches on program or episode level tags count more? Should we weigh episodes with matching tags that are part of the same series more - or less - than similarly tagged episodes from other series? Etc and etc.

So, we tabled the issue for the first release and just went with program level tags. Now we want to start tagging episodes and come up with rules to generate a more granular list of related programs. That’s something we’re hoping to work out this week.

Have you run into a similar problem? Any thoughts on how best to do this? Speak now!

Visitors to WGBH.org often come to the site seeking out information about a specific TV program. Maybe they enjoy Frontline, and they want to find upcoming episodes. Or they caught the last 5 minutes of a show about hot dogs, but they can’t remember the name of the program and they want to know if will be airing again.

So one of the requirements of the TV Programs and Schedules was that we implement a scoped search – an advanced search page that would only return a list of TV episodes in the results.

In the past, I’ve used some interesting modules that modify or expand upon the core Drupal search. The Views Fast Search module offers the flexibility to define the content you perform a search on, which really enhances the searching capabilities. Unfortunately, the module is only available for Drupal 5 (although parts of Views Fast Search made it into Drupal 6). Drupal’s built-in advanced search form is also capable of limiting a search query to specific content types — there are several different approaches to achieving this. And the Restricted Search module allows administrators to exclude content types from the search index entirely.

But simply blocking other content types from the query won’t quite cut it for several reasons, and excluding content from the search index would not be a good long-term solution, because eventually we will need to make use of the full site search in addition to this scoped search. Also, just to spice things up a bit, the additional criteria for the TV search specified that:

• • The search should only return TV Episode nodes. The Airing and Program nodes do not show up in the search results, although they do play a factor in the indexing of the Episode nodes and the ordering of the results.
• • Search results should include the program and episode title, a brief description, a link to the episode page on WGBH.org, and a link to the program web site, if there is one.
• • In ordering the search results, keyword relevance is the most import factor, but upcoming airings are a close second. For example, a search for “Curious George” would yield a long list of episodes for that program, but the episode that is airing this afternoon would be at the top of the list, followed by the episode airing tomorrow morning, and so on.

The real heavy lifting of Drupal’s search mechanism can be broken down into two areas: the indexing of the nodes (hook_update_index()) and search query (hook_search()). Both of which involve some code that quickly made my head hurt. But as luck would have it, I pulled out our copy of Pro Drupal Development and discovered a whole chapter dedicated to search. That, combined with Robert Douglass’ very detailed blog post, Drupal Search: How indexing works, worked wonders like a big bottle of ibuprofen.

Indexing

When cron runs, Drupal will index any new nodes, and reindex nodes that have changed since the last run. The title and body of a node, with all HTML tags intact, are parsed — Drupal uses the HTML tags to give additional weight to words. Text in an H1 tag must be important, so those words would carry a very high score, while linked text would carry a lower score (although higher than plain text). Words that are bolded, italicized, or underlined also get a small boost.

This is why a node with “Nova” in the title scores higher than a node with “bossa-nova” in the description, when the search term is “Nova”.

Overriding the Index

For our purposes, when we index an Episode node, we also want to include the title and description of the parent Program in that index. It is entirely possible that an episode of Nova, for example, might not even mention the word “Nova” in the title or description, so we must include the Program title and description.

To achieve this we use hook_update_index() to loop through any new Episodes. We load both the Episode node and the parent Program node, and then build a string with both the Program and Episode titles in H1 tags, and append the body of each node with all HTML tags intact. That string is then passed off to search_index() where each term is counted, scored, and added to the index.

Search Query: Ordering the Results

As the requirements specified, the results of the search query should be weighted with keyword relevance and upcoming airing date being the primary factors in determining the order.

Keyword relevance, of course, is a standard part of the Drupal search ranking mechanism, but to affect the score based on upcoming airings, we construct an additional ranking query. That query, which returns the difference of the upcoming airing timestamp and the end of the data window (or 1 if there are no upcoming airings), is passed to Drupal’s do_search() function. An array of node IDs is returned and passed off to the theme level.

One very nice thing about Drupal’s search is that this custom search was developed without impacting the existing full site search capability. No core code needed to be touched, and in the future we can add scoped search to other areas (like Radio) by replicating several functions and adding a few case statements.

I don’t want to belabor the whole space travel analogy, but, what the heck - life is short! Let’s belabor-away!

Earlier this week we took one small step for TV schedules and one giant leap for WGBH.org by officially launching the new Drupal-based TV Programs and Schedules section of WGBH.org!

Aside from finding a significant bug literally 10 minutes before launch, it has all gone quite smoothly! Drupal is behaving like a champ and everything is humming along.

In fact, for a worry-wart like me, you could almost say it’s going too well.

So, now I’ve jinxed everything. Oh well. Like I said, life is short.

The list of people to thank for making this all happen so smoothly is long. At the top of the list is my friend and co-developer Pete Bull who did a great job from day one and has saved my bacon on a bunch of occasions already (including tracking down and fixing that aforementioned last minute pre-launch bug). Our good buddies in the IT department, especially, did a ton of work to get a whole new development, testing and production infrastructure in place for us, so a big thanks to Peter M., Bruce D., Sarah, Larissa and all those folks. You guys and gals rock.

Also, our project manager Louise, designer Tyler, WGBH Online Director Darleen and all of our patient content producers were great to work with under the sometimes-trying circumstances. Finally, but not leastly, our former director Bruce K. and my old buddy and our former designer Peter L. (note: WGBH apparently has a rule about employing a large number of guys named “Peter”) played big roles early on in the process.

There were also any number of outside folks who also helped out at different stages, including Drupal-gods Robert Douglass and Moshe Weitzman and the fine folks at Lullabot. Of course, there’s also all the faceless folks in the Drupal community who contribute modules, create patches and document all sort of helpful things. We love open source!

Whew! See, lots of people have contributed here.

Now, of course, the real fun begins: a full blown overhaul of all of WGBH.org, including new information architecture, look and feel and, of course, a complete port of, well, everything to Drupal.

Should be no sweat!

Sadly, though, unlike for the Apollo astronauts, there will be no ticker tape parade. Maybe next time…!

Hours before they were launched into the space, and few days before two of them became the first men to walk on the moon, the crew of Apollo 11 sat down for a hearty breakfast of eggs, toast, coffee and - of course - Tang!

Well we here at WGBH Online are getting ready for our own launch in just a few days. We’re not quite ready for the pre-launch breakfast, but we should probably go shopping for all the ingredients real soon.

A whole bunch of people are working feverishly right now to dot all the i’s and cross all the t’s on our new TV Programs and Schedules module. Everything is going smoothly - knock on wood - and I think we may pull this off as planned. Suffice it to say, lots of coffee is being consumed.

The biggest development of late is that Pete has worked wonders to get the Boost module working for us on Drupal 6. Initial benchmarking tests indicate that Boost has increased our throughput by about ten-fold over the traditional Drupal database caching.

Boy, we love that.

Anyhow, keep your eyes peeled here for the big launch announcement - and get ready to start the eggs!

Apologies to all of our loyal readers who were disappointed by the lack of a post last week (that’s you mom!). See, I was on a family vacation at an undisclosed location working on my farmers tan and spending just about every last cent we had in the bank to entertain the wife and kids.

It was a good time that unfortunately had to end, so now this week I’ve been back at it, closing in on the launch of our new TV Programs and Schedules module. Whilst I was gone Pete was busy fielding bug reports and questions from our testing team. The good news is there seem to be relatively few actual bugs. The code is pretty solid and we are plowing forward getting the production environment ship shape in preparation for launch!

However, that does not mean we are without issues.

One issue that I knew would come up eventually has already come to the surface, a bit earlier than I had figured on. It has do with modifying published content and previewing pages that contain information from multiple nodes, like our episode pages, for example.

See, our current site and CMS have lots of flaws and unsightly blemishes, but one thing it is good at is allowing content producers (CPs) to create multiple revisions of a page or content item, publish one revision and continue to tweak the content without overwriting the published version until the appropriate time. Also, our current site has very sophisticated previewing functionality, allowing CPs to preview just about any given page to see unpublished changes, including the ability to preview by date, showing what the page will look like at a future date, based on scheduled publish and expiration dates for content items.

Know what I mean?

Drupal, natively, doesn’t seem to do either of these things particularly well. Or, if it does, I still haven’t figured it out. Oh sure, you can configure content types to allow multiple revisions, but all that really does is archive earlier revisions of a node, in case you want to roll back later. That’s good, don’t get me wrong, but what we need is the ability to publish a revision, then create a new revision that isn’t published until we say so. We can sort of use the current functionality to do this. You could publish a node, update it and create a new revision (which immediately publishes the new revision), then revert back to the original revision and roll it forward when we want the new revision to be live. However (a) that’s an annoying number of steps and (b) you can only edit the currently published revision. Not so useful.

I recently played with the Revision Moderation module, which gets us closer to what we need. Basically, that module will create a new revision for you without publishing it until a user with the proper permissions chooses to. However, we’ve decided not to implement it now because the code for Drupal 6 isn’t even in alpha state yet and also because there seem to be issues with one user seeing the unpublished revision created by another user, etc. etc.

As for previewing, our new episode pages are fairly complex and draw on content from multiple nodes and content types (e.g. program descriptions, episode info, related content boxes, etc.). The problem they’re having is that they need to modify some pieces of content on a published episode page and, in doing so, need the ability to preview their work in the context of the page in order to get the layouts right. Right now there is no easy way to do that. The preview functionality provided by Drupal on the node edit pages is fine, but it doesn’t allow CPs to preview, say, right hand rail content boxes in the full context of an episode page.

What we really need is the ability to look at a published page and pass in a preview flag, which would then display the latest (potentially unpublished) revisions of the nodes on the page. Even better, this preview functionality should allow for a date parameter, which would then also take account of Scheduler publish and expiration dates.

Now tell me that that wouldn’t be sweet!

Anyhow, I knew this would be an issue sooner or later, but chose to put off dealing with it for the TV Programs and Schedules module. However, as we look to rebuild the whole rest of the WGBH.org and move everything to Drupal, we will have to come up with a better solution. In the future, our home page will be made up of view lists of content boxes, each of which could have its own publish and expiration date, multiple revisions, etc. Being able to properly preview the page will be key for us…

Any ideas? Let’s hear em.

After weeks and months of working on something you can easily forget that - at some point - it actually has to get done! Well, I’m not able to say that our new TV Programs and Schedules module is completed yet, but we have reached a big milestone: principal development is done!

What does that mean? Well, it means that Pete and I have coded up everything that we know about to the specifications provided and now it’s ready to be fully tested. You could basically call it an alpha release of the front and back end code.

Exciting? That’s one word for it.

The last piece of the puzzle was a custom search module, that Pete has coded up, based on the core Drupal search module. Basically, it’s search scoped to our TV programs and episodes (that’s all the content we have in Drupal just now anyways). Down the line, as we rebuild the whole rest of WGBH.org, we also envision a scoped search for each major subsite (e.g. one for radio, one for web only content, etc.), plus some sort of global search across everything.

We’ll write up more about how search was implemented later but for now, here’s a sneak peak:

Our goal in the next few days is to get the code base installed on our test/staging servers, document how things work and then let our content producers and functional testers have at it!

Obviously, I don’t anticipate there being any bugs, issues or blemishes of any sort. But we’ll go through the charade of testing anyways, just make everybody feel good!

Today is the first day of summer, so you know what that means: it’s officially the longest day of the year! It’s also the day to break out the “longest day of the year” jokes (i.e. “It’s the longest day of the year - other than Thanksgiving with my family,” etc.).

Thank you! You’re a great audience! I’ll be doing two shows nightly all week. Try the fish!

Back in the real world, principal development on our new TV Programs and Schedules module is almost done! Pete is busy crossing the i’s and dotting the T’s (wait, stop, reverse that) on the search module. Everything else is basically ready for full blown functional testing and tuning. Next week we’ll be getting a real staging environment set up and ready to go.

Today, class, I wanted to show you how we’re going to handle images on the new site. A site like ours will certainly make use of lots of graphics (e.g. show logos and images). We need a content producer-friendly way to upload, find and reuse images, with minimal hassle. Our current CMS makes image reuse next to impossible, not to mention the fact that all images get written to the database (shudder). That sort of thing is not what we’re looking for; we want our images in the new world to get written to the file system and we want to be able to reuse images.

First up, the requirements. Check it out, yo:

As you can see, an episode page can display up to two graphics: the series logo, and an optional image. The logo is attached to the series and will display on all of the series’ episode pages. Below that there could be an image. There may be an image related to the episode, or there could be an image attached to the series. In this case, an image differs from a logo in that the image could have (a) a caption and/or (b) a larger version that would appear in a new window if the image is clicked on. If the episode has an image, that would appear under the logo. If there is no episode image, the program image would display, if there is one. It could also be there is no logo and no images of any sort.

Now for the fun part: the implementation!

I wrote in March about our plans for handling images. Our approach hasn’t changed: we’re using the Image Assist module (which, in turn, uses the Image module) to allow content producers to easily find and reuse existing images or upload new ones. Images ultimately get stored as nodes themselves, which can be tagged, which is then used for finding images later. We did, however, make a few small tweaks.

Oh yeah, and thanks to the Image module, images get automatically resized (i.e. to create thumbnails or previews), during upload! We love that.

Here’s how it all works:

The image field of an episode is a text area. For all text areas on the node edit pages, we’ve enabled the TinyMCE WYSIWYG editor. This will allow content producers to add some simple HTML markup, like bolding and alignment and whatnot, without having to add tags! Also, image assist can be configured to work with the TinyMCE editor (which, given the unfinished state of some contributed modules for Drupal 6, took a little monkeying around). Clicking on that little camera icon in the bottom row launches…

…the Image Assist popup window! Using this window you can search for and select an existing image or you can upload a new one, all without leaving the episode edit page. By default Image Assist lets you narrow your image search to images you uploaded or using any tags you’ve applied to images, all using one drop down. We also added the ability to search against the title of the image. Sweet!

Once an image is either selected or uploaded, you see something like this:

Here you can set the title of the image (which is used at the alt attribute of the image tag), choose which size to display on the page (the original or a smaller version) and whether or not to link to the full sized version of the image (and whether to open that in a new window). Once you specfiy all of this, the HTML to display the image gets generated and written back to the image field on the node edit page, like so:

Here is where content producers can add an optional caption. They just type it under the image; they can also choose to link the caption using the link button.

One last thing: if the image is linked to a larger version, the front end page code will automatically generate an Enlarge this image link and place it under the caption.

That’s it!

Who says building web pages has to be hard?! Not me. No sir.

Like Big Brown coming down the stretch at the Belmont Stakes last week, us coders here at WGBH Online are bearing down on the finish line that is the rebuild of the TV Programs and Schedules module, well ahead of the pack… er, on second thought, maybe Big Brown at Belmont isn’t the best analogy.

In any case, deadlines are looming! We’re scheduled for a database freeze at the end of the month, by which time we need to have principal development completed and the code ready for some serious testing and tuning. At this point Pete is busy working on the search functionality and I’m tying up as many loose ends as possible.

I’d like to use today’s post to discuss one particularly funky and challenging bit of functionality that is finally working - the episode page sidebar!

Now tell me the name alone - episode page sidebar - doesn’t send a chill down your spine! It does mine, at least.

Let’s take a look-see at this little puppy to see what we’re talking about:

As you can see episode page sidebars will display information related to the series or episode (e.g. related programs or events) , as well as a search box, and some promotional content (e.g. shop, support). Nothing out of the ordinary here. We do the same thing on our current episode pages.

So how would this be implemented in Drupal? Easy, you say! Each item could be managed as a block. Voila! Hardly any technical expertise at all required here.

Not so fast, partner. There are a few additional requirements.

(1) There needs to be a default set of these items, that would display on all episode pages, unless…

(2) An editor chooses to create a series-specific version of a particular sidebar item, in which case s/he needs to be able to create it, relate it the series and have that override the default item on all episode pages for that series, unless…

(3) An editor chooses to create an episode-specific sidebar item, in which case s/he needs to be able to create it, relate it to the episode and have it override any default or series-specific version of that item.

OK, maybe it’s not so simple.

Here’s what we’ve noodled up to make this all happen.

(1) Since the search box is the one sidebar item which will always be there at the top and cannot be overridden, that is indeed managed as a stand alone Drupal block and positioned at the top of the heap.

(2) All other items in the sidebar are managed using a custom (CCK) content type called a content box. Content boxes are pretty simple and have the following attributes: title (for internal use only), a body (which contains all of the content to display, including any optional title or header), and an optional parent content item (like a TV program or episode), managed as a node reference. Also, using the Scheduler module, each content box can have specific publish and expiration dates. Content boxes will be able to have images, which will be added to the body using the Image Assist module.

(3) In order to determine where a content box displays in the sidebar we defined a fixed taxonomy vocabulary (Content Box Location), which is a hierarchical set of terms (e.g. TV -> Programs -> Sidebar -> Events). The display order of the sidebar items is determined by the order of the terms within the vocabulary. The idea here is that content boxes will eventually be used on other parts of the site once it’s all on Drupal. At that point we’ll be able to define additional terms in the vocabulary for other locations on the site (e.g. Radio Home Page -> Coming Up).

(4) Default sidebar content boxes are then defined as content boxes that are assigned a TV -> Program -> Sidebar tag, are not explicitly related to a series or episode node and which have the word default in their (internal) title.

(5) Series sidebar content boxes are defined as content boxes that are assigned a TV -> Program -> Sidebar tag and are explicitly related to a series node.

(6) Episode sidebar content boxes are defined as content boxes that are assigned a TV -> Program -> Sidebar tag and are explicitly related to an episode node.

Got all that? Good, because this will be on the final.

Given that set up, here’s how we actually construct the sidebar for a given episode.

We have a block view that selects all of the default episode sidebar content boxes. In the theme file for that view display, we then call a second block display for the sidebar view that takes a parent node id as an argument. We call this first to get any sidebar views related to the parent series and then again to get any sidebar views related to the episode. All of these content boxes that we’ve gotten back are then merged according to the rules above and the final list is displayed.

Almost forgot, the Related Programs sidebar content box adds one additional layer of complexity. The contents of that box are generated using a related programs view, which finds up to three related series using another taxonomy vocubulary (TV Program Genres). It’s pretty straightforward, unless…

See, easy peasy lemon squeezy, as my kids say!

Feels like we’re already well into summer mode, here at WGBH Online. The temperature is heating up, people are starting to take long vacations (welcome back from Hawaii, Pete!) and - the surest sign that summer is almost upon us - I’m in full blown shorts-wearing mode.

But don’t think the work on the WGBH.org rebuild has slowed at all. Oh no. My fingers are already sore from all the coding going on and we’re getting near the home stretch of the first phase of our rebuild.

Before I give the latest update, note the newest feature on the site over there to the right - a Flickr badge! Based on the recommendation of my friend - and a friend of WGBH - Steve Garfield, I’ve created a Flickr account to go along with this blog. After all, when you think web site development you think photos! Tell your friends!

Anyways, back to the rebuild of WGBH.org, I’ve been busy building our our episode page, which is fairly complex but is coming along nicely. So for those keeping track, once that’s complete we’ll have built a Programs A-Z page, Schedule Grid, Full Day by Channel schedules and now the episode page. That’ll really just leave a search page to be built and then we can prepare to test and launch!

Wait, but what about the series page, you say?

An excellent question, class. Somebody’s been paying attention!

Well, that’s no longer a concern since we recently decided to do away with building our own series pages. How about them apples?

In case it’s not clear what we’re talking about, a series page would, for example, be a page dedicated to an episodic program, such as Nova, Frontline, Masterpiece, etc. Such a page could have a description of the series, a list of upcoming episodes, other related series, etc. An episode page, on the other hand, would be dedicated to, well, a specific episode of a series.

We currently do publish series pages on WGBH.org, however most people never see them, as we generally try to direct people to the next upcoming episode of a series. But they are there and we do curate them. However, after initially planning to build them and support them in the new world, we decided to no longer produce them.

There were basically three reasons to forgo series pages:

(1) Series descriptions do not come through the PBS/TV Guide data feeds. The data contain episodic descriptions, but not descriptions for a series. So, if we want to publish series pages we’d have to enter these descriptions ourselves, which defeats one of the main purposes why we’re going to this new data feed in the first place.

(2) The episodic/non-episodic issue. Obviously, some programs are non-episodic, meaning they are not series. Since the schedule data that we’ll be getting does not explicitly distinguish between episodic and non-episodic programs, all programs coming into the system will be treated the same way and have at least one episode. In this case, non-episodic series in our system will just be a series with one episode. In this case, it wasn’t going to be trivial to deal with this issue. For example, for non-episodic programs, what page do we send users to? The series page or the episode page? Clearly we would have to either manually flag non-episodic series as they came in or work up some convoluted logic to properly display the information for such shows. Neither option sounded good.

(3) Why even bother? Each show presumably already has it’s own web site anyways, so why should we reinvent the wheel? Episode pages at least provide airing information specific to our channels, plus we can use them for promotion of DVD’s and whatnot or cross-promotion of other shows, so we do want to have those pages. But a series page really wouldn’t be adding much value to anybody.

So, there you have it: we punted the whole idea. This was fine with me, as it makes development a bit easier. No complaints here.

Time to put some sunblock on my pasty legs.