The WGBH.org Development Blog

Filed by Phil at 1:26 pm under Drupal, Television, search

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!

Leave a comment

Filed by Phil at 2:50 pm under Drupal, Television, Images, Image Assist, TinyMCE

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.

Leave a comment

Filed by Phil at 9:40 am under Drupal, Television, Views, CCK

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!

1 Comment

Filed by Phil at 11:32 am under Drupal, Television, TV Guide, Images, Flickr

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.

1 Comment