The WGBH.org Development Blog

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 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

Filed by Phil at 1:49 pm under Drupal, Drupalcon, Images

Much like after the holiday season, I’m mired in the post-Drupalcon blues. I feel tired, lethargic, gassy - no, wait, I’m sorry, that’s probably just from the Chinese food I just ate.

Last week at Drupalcon they held a case-study on the Popular Science web site which, don’t you know, was just rebuilt and relaunched using Drupal. I didn’t attend the session but one of our developers, Josh, sure as heckfire did. He was quite impressed with the job they did.

Luckily, the case-study has now been published on the Drupal web site. It’s very interesting, indeed, and details all of the fine work done by the folks at pingVision to make the site a reality.

One aspect that caught my eye was the way they made use of ImageField module for image uploads, and the Drupal Markup Engine (which I’d never heard of) to allow site editors lots of flexibility in content placement on node pages. I will have to give that a gander.

We had considered using the ImageField module for adding images to content types. However, we rejected that idea because we want our editors to have the ability to add images to content nodes (e.g. articles, TV programs, etc.) - or find existing images for reuse - in the simplest way possible. Creating nodes with image fields and relating them to other nodes via node reference doesn’t seem like the best way to do this, as it forces you to select from a drop-down list to choose an existing image. Unless, of course, I’m missing something (which is always possible).

Instead, we’re planning on making use of the Image Assist module, which offers a way to search for and choose existing images or upload new ones and add them inline in the least painful way. I have not yet seen a good case study of a Drupal site that puts much emphasis on being able to find and reuse images when there are potentially lots of images already in the system.

Needless to say, if any of you jokers out there have any insight or suggestions here, please, for the love of Pete, speak up.

Oh yeah, and it looks like we’re going to plow ahead and make the leap to Drupal 6 now, rather than build on Drupal 5 and upgrade after. More on that later…

5 Comments