Are you tired of all the geek bullies kicking virtual sand in your face, flexing their apps, and getting all the URLs? Have you ever looked at your site on the monitor and wished that you too could bulk up like the big geeks? Well, now you can.

Presenting Outgoing RSS Feeds:

• They're quick.
• They're easy.
• They keep working even while you sleep.
• No special diet.
• No exercise.

Whatever your coding preference, we've got the plan for you. Whether you'd rather pop it right out of the bottle or create beautifully hand-crafted feeds we've got you covered. Order now, supplies are limited (only by your imagination.)

Sorry, folks, I just couldn't resist that.

Basically, the fastest way to begin putting an RSS feed out from a standard website is to convert already existing HTML pages to RSS XML. This works especially well if you're already separating content like event announcements and program highlights into separate files and using SSIs to plug them into your page templates. However, some of the available tools will parse sections out of larger pages.

A good, free tool for this is the RSSxl Generator from WotZWot. This is a (seemingly permanent) beta application, so you might have to double-check the resulting XML. However, it does let you specify strings in your document that identify where the feed content starts and where individual RSS items and item descriptions are located.

XML:Wrench is another free tool. It's a fairly decent (if simple) XML editor that will convert HTML to XML. Even if you limit the source HTML document to nothing but the basic feed content, you'll still have to go through the code itself in the editor and do some cleanup.

The RSS Wizard is a fairly cheap solution from Extralabs Software that generates "the RSS feed out of virtually any web page without having to edit it first." That's the claim anyway. I say you're better off checking code out for yourself, but, then, I'm known to be somewhat anal about these things.

Fill-In-the-Blanks RSS Creation

A fill-in-the-blanks form solution for the quick creation of RSS feeds is a distinct possibility to get you started. This is a good interim option until you have something better in place. This type of tool is available as a stand-alone desktop application or through web applications on other sites.

FeedForAll has one of the best known tools for the dynamic creation of RSS feeds, and the software, although powerful, is very cheap. Another paid option is PRESSfeed which actively promotes the use of RSS feeds for press releases and other forms of marketing and includes social bookmarking aspects and a number of other services.
Go there for Sally Falkow’s blog on How to use RSS feeds in enterprise marketing and promotions if for no other reason.

The main fill-in-the-blanks solution I want to draw your attention to is a special resource created by the web team at ONIX specifically for the creation of station feeds. It seems that the folks at Newshour would like to see more stations syndicating their news content so that more local news can be picked up by the national Newshour site–especially local election coverage. Pretty smart of them, huh? The thing to remember about this web application from Newshour is that it will work for the creation of any RSS feed irregardless of its "newsworthiness." You simply enter the content directly into form fields, and it does the rest.

There are a couple quick caveats worth noting with this service. First of all, there's a separate form to use if your feed will include podcasts. Podcasts require their own special code enclosures to be part of the feed, and, even though nearly any type of content can be syndicated by RSS, they've limited the content type to MP3s for this tool. Also, there's currently a bug that leaves empty image enclosures if you don't happen to include an image in your feed. This will probably be fixed at some point very soon.

Database-Driven Dynamic Feeds

The problem with all these non-database-driven methods is that the content is not truly dynamic. You'll have to add to, delete, or replace content in the feed file yourself item by item in order to keep it up to date. If it's also being used as site-based content like program highlights or events, then you'll end up having to create the content twice, once in HTML for your site and once in XML for your feed. You lose the power of a database to parse the same content into multiple formats and put it where it belongs on its own.

The best method for feed generation is the adaptation of an open-source CMS tool like Drupal or Joomla to do the job for you. RSS feed syndication is built in. This will allow for the running of the site along with simultaneous feed management. Some have even had success with adapting blogging tools like Movable Type and WordPress for use as a CMS.

Ang Zhuu Ming over at blogHelper has written a pretty comprehensive guide to the ins and outs of using WordPress as a CMS if you're thinking along those lines. Also, Ross Johnson over at 3.7 Designs has recommended five plugins that will help to turn WordPress into a CMS. [Just a sidenote while you're there, check out Ross's feed promotion at the top of his blog. Now that's a clear call to action.]

A good station example of using Movable Type as a station CMS can be seen at WTIU's website, though I'm surprised to see that they still aren't making use of the inherent RSS capabilities. You might want to check out my previous article, Movable Type: An Interview with Angela Jordan of WTIU, for more information about how to get that set up.

Leveraging Your Feed

It's all well and good that we're offering our station website content for syndication, but don't miss the opportunity to push your membership/support reminders. As far as I'm concerned, the station membership page should never be more than one click away from anything related to a station's website–including the RSS feed. By subscribing to your feed, users are showing that they appreciate your efforts to keep them informed of site updates and station news. There's absolutely nothing wrong with politely reminding them that this too takes time and money and is publicly supported.

Another thing to keep in mind is good titling and content. Make sure that you pick some kind of title (preferably a catchy one) for each item in your feed. That can get tricky sometimes, but it's worth it to the end user who's feed reader is limited to just titles. Catchy content description is worth some effort here too since the idea is to engage the user quickly and make them want to see more.

Playing Nice With RSS

Before I go any further in this, let me clarify something right quick. Although RSS tends to be pretty "stretchable" and certain de facto standards and practices have successfully crept into common usage, the actual specification doesn't allow for much of what is being done with it. That is changing though.

The usage of HTML within an RSS feed must be limited to what is absolutely necessary. That does not include any kind of formatting. Even the kind of CDATA embedded hyperlink that I'll be getting to in Part 5 as we "hand-code" an actual feed is only necessary until some kind of source-type sub-element of the description element is added to the specification. [NOTE: I am aware that entity-encoded HTML is allowable in the description, but I'm trying to keep this as simple as possible here.]

Nothing but plain-text is allowable in the title. It cannot include a hyperlink because it is, in and of itself, a hyperlink back to the source page. Also, keep in mind that RSS feeds are designed to be read outside of your site, so relative URLs may not work; every link should be a complete, direct URL address.

One other thing here is the question of how to handle multiple feeds such as station news, program highlights, and community events. The very simple answer is to create multiple feed files. Each can have a separate name with either an RSS or XML extension (though I recommend the latter.) You can place them all in your root directory, in a "feed" subdirectory (and this is my recommendation,) or in a subdirectory related to the content. Choose names with some semantic meaning to make them somewhat human-readable.

Putting the Feed Out

Strangely enough, this is the point in the discussion where I will probably begin breaking some new ground for even seasoned RSS users. I say that because there are quite a few stations (and even PBS itself) that are clearly getting the necessity of creating RSS feeds and have, in some form or another, done all the steps I've listed up to this point and then just stopped there as if they were done. There's more to it then just putting an RSS link icon or text in the body of your pages to notify users that you have RSS feeds. They're failing to make use of RSS auto-discovery, and they don't actively promote their feeds.

RSS Auto-Discovery

RSS auto-discovery is not a new feature of RSS. (In fact, it's not even limited to RSS.) Yet it's a very widely ignored resource. This is one of the more powerful aspects of RSS that's helping to bring it into the mainstream. Not only are many feed aggregators, news readers, and search engines actively hunting this for content, but it's what makes the feed icon in Firefox and IE7 and other browsers that support it pop into life and draw users into subscribing right through their browser.

Trust me when I say, "You definitely want this on your site."

Once you have your RSS file created, you then place an auto-discovery LINK tag for each of your feeds in the head section of your site pages. It looks like the code below, only edited for the correct path and title of your content:

RSS Promotion

Placing a visible link to your RSS feeds on your pages will get you subscribers–and it is vitally important that you have this displayed prominently–but feed syndication doesn't end there any more than television syndication ends in the producer's office. You gotta get the word out. You have to notify the various feed directories like syndic8 that you have a feed. You need to promote the use of your feed not only as a convenience but as content for other sites.

One of the more interesting aspects of RSS syndication is that your content can be included in other sites complete with your links back to your site. This is good to encourage among school and community event sites in your viewing area (and almost any other site that you can talk into doing this) as it spreads not only your station's brand, identity, content, and events to a wider audience, it also spreads your membership/support reminders.

Another good free tool to help in the management, promotion, and monetization of your feed is FeedBurner. This will give you numerous tools to monitor and accessorize your feed.

Some Final Words

If it seems to you that I've been harping on the station membership/support aspects of this, then maybe you're actually getting the point I'm trying to make here. Web content syndication should be an important part of not only your station's web presence, but its online membership recruitment and marketing. Nonprofit does not mean that you should ignore potential revenue sources. If anything, it means that you should jump at all of them–especially the ones that have been made so incredibly easy for you.

Let me run through it again here because it's so vitally important:

• Syndicate your content with RSS web feeds.
• Leverage your feeds with station membership/support reminders.
• Promote your feeds.

Say that over and over again, make it your mantra, and get to work.

Thank you all, code well, and good night.

Before I begin this discussion explaining RSS to you as if I were this fount of knowledge that clearly recognized its value from the very first moment I saw it, the fact is that my initial impression after a cursory look-over several years ago was that it was only useful to blogs and news-oriented sites. Outside of syndicating teasers of news headlines and blog posts, not a single aspect of its current usage occurred to me, and I never expected it to become an indispensable part of standard web development or to redefine the web as I knew it. So, if you can forgive me that incredible oversight, then we can get on with this…

To explain what RSS is and why it has everyone so excited, let me just start out on common ground with something we already know, a traditional website. Traditionally, a website contained whatever content may have been put on it and that content may be static or may change constantly. The problem here has always been that a user had no way of knowing when or if that content had changed other than checking back periodically or being notified by someone.

RSS solved that problem by "announcing" content updates. A site owner creates a special file called an RSS file along with a link to it, and this creates a "web feed." A web feed is a data format used for sending users content updates. Users have the option of "subscribing" to this feed either through a stand-alone desktop application called a "feed reader," through an online content aggregator like Newsburst, or, increasingly, directly through their standard web browser. Once subscribed, users are notified whenever there's new content posted to the feed. That's all well and good, but it doesn't end there.

RSS Web Feeds

An RSS web feed is actually just an XML-based file that sits on a site like any other file and contains whatever content the site owner wants to put into it for distribution. It can be created and maintained manually or dynamically (preferably the latter.) Part 3 of this series will cover the creation of such feeds. There's not really a lot to it.

I don't want to lose you in the terminology or the acronyms here. An XML document–especially of the type we're talking about here–is an extremely simple text document. The markup has certain similarities to HTML, but where HTML defines how to display the content, XML categorizes the content (for instance, identifying title, description, author, etc.) and does it in a machine-readable format which means that different software on different operating systems on different platforms can easily access and display that content. This is the part that allows for syndication. Numerous applications exist that look for such files, read the content, and parse it back out for use elsewhere.

RSS for Content Syndication

Content syndication is (by definition) the primary use of RSS. Originally, RSS files listed just the title of a piece, the author, the date of publication, a link back to the original content, and a quick summary to act as a kind of teaser to get you to go back to the original site to read the article–hence the mistaken view that it was only good for blog posts and news headlines. Now it includes syndication of full content–including HTML–along with "enclosures" to contain multimedia content like images, audio files, and video files and that content is being used in ever more imaginative ways. This needn't scare you away from using it.

RSS Content Usage

Primarily, RSS syndicated web content simply turns up in some form of RSS reader for the usage of an individual who wants to remain informed of content updates on your site. However, this syndication of content along with the inherent extensibility of XML allows for a kind of web presence and sharing of content that was never available before. It's the underlying workhorse or building block of the entire "Web 2.0" movement.

Web content stored and distributed in this manner can be accessed and processed in ways similar to database applications allowing your content to simply be replicated elsewhere or become the basis for an application built on the underlying data. It can turn up as content on another website. It's absolutely adored by search engines (practically search bot candy) which will often index it far faster and with better results than equivalent content on a standard HTML page.

Think syndication, not coordination. Simple web services, like RSS…are about syndicating data outwards, not controlling what happens when it gets to the other end of the connection. This idea is fundamental to the internet itself, a reflection of what is known as the end-to-end principle.
–Tim O'Reilly, What Is Web 2.0?

As much as I agree with the ideal expressed here by Tim O'Reilly, I tend to take a more pragmatic approach. I encourage you, if you're considering RSS syndication of your content, to set up a Creative Commons License allowing for the distribution of your content while requiring the retention of source attribution and backlinking. It's not that you don't want anyone else to use your content, but you should get something out of it as well. The idea here is not only to increase your web presence but also your underlying user base.

What Is RSS

With all this background in mind, we can get more directly into what RSS actually is. Wikipedia puts it this way:

RSS is a family of web feed formats. The initials "RSS" are variously used to refer to the following standards:

• Really Simple Syndication (RSS 2.0)
• Rich Site Summary (RSS 0.91, RSS 1.0)
• RDF Site Summary (RSS 0.9 and 1.0)

–Wikipedia, RSS (file format)

and Tim O'Reilly refines that further (as is his disposition):

RSS is now being used to push not just notices of new blog entries, but also all kinds of data updates, including stock quotes, weather data, and photo availability. This use is actually a return to one of its roots: RSS was born in 1997 out of the confluence of Dave Winer's "Really Simple Syndication" technology, used to push out blog updates, and Netscape's "Rich Site Summary", which allowed users to create custom Netscape home pages with regularly updated data flows. Netscape lost interest, and the technology was carried forward by blogging pioneer Userland, Winer's company. In the current crop of applications, we see, though, the heritage of both parents.
–Tim O'Reilly, What Is Web 2.0?

The hardcore purists out there aren't going to be too happy with this series of articles, because my focus, as I start describing how to create an RSS feed in the next article, will be on RSS 2.0, Dave Winer's "Really Simple Syndication." I've chosen that particular "flavor" of RSS because it allows me to really bring home the incredible simplicity of syndicating web content. My point here is to encourage more RSS usage, not scare anyone away.

What Are The Benefits of RSS?

I've only touched on some of the benefits of having an RSS feed. Things like the inherent search engine optimization are secondary to the incredible expansion of your audience that comes about through content syndication. You reach people that you would never have reached before. You're able to communicate with them and show them the value of your station as a resource.

It's perfectly acceptable to sell advertising on your feed and include membership/support reminders. Keep this in mind always, unlike other methods of boosting membership, every single person reading your feed has willingly opted-in to receive your message. They won't consider it spam.

RSS was designed to empower the user to view the content he or she wants, when it's wanted, not at the behest of the information provider.
–Tim O'Reilly, What Is Web 2.0?

Where Do I Get The Content?

The question of where to get the content to feed out always amazes me–especially in relation to a public television station website. Unless your site is absolutely static, unless there's nothing there that changes, unless it's the online equivalent of a pre-printed brochure, you have content to syndicate. Even the tiniest station websites are not excluded from this, because it's not about having money for great content productions.

If your station updates any of the following items on their website–even if it's only once or twice a month–you have content to syndicate:

• Program Highlights
• Station Events
• Station News Announcements
• Community Events
• Newsletters (including RTL and non-member-based eguides)
• Upcoming Pledge Drives
• Auction Announcements
• Etc., etc., etc.

Each of these can be fed into separate RSS files and syndicated separately. Each of them can be used to expand the station branding, presence, user base, message, and support reminders. Each of them will take their own roads through the Internet and reach people you would never have reached otherwise.

Some Final Words

RSS is an incredibly powerful tool easily implemented with enormous benefits going far beyond the station itself. I implore you, if you haven't done it already, then, for the good of your station, for the good of your users, and for the good of public broadcasting as a whole, please, please, feed your site.

Thank you all, code well, and good night.

It's been pointed out to me recently, and rightly so, that although I've been telling everyone how important it is to have and promote and use RSS feeds for their sites, I haven't stopped to explain anything about how one would actually go about doing that. Personally, I recommend the use of RSS Pixy Dust, but, if you don't happen to have that available, it gets a little more complicated.

I've decided that the best way to provide a useful explanation that will satisfy the most people is to break the whole thing up into a series of articles that I'm calling “Please DO Feed the Sites.” In this way, people can look for the parts they need, and, if I should miss something, I can just tag it on later as an extra part. Currently, I have it planned as follows:

• Part 1: Introduction (You're reading it now.)
• Part 2: What Is RSS?
• Part 3: Creating Outgoing Feeds
• Part 4: Using Incoming Feeds

If I can get the time (and there's enough interest,) I will continue the series by showing you the creation of a hand-coded and maintained RSS feed which may be a possible working solution for some sites. I will also try to move on to a walkthrough demonstration showing the creation of database-driven, dynamically maintained and updated RSS feeds. I may also add other parts later.

I'm aiming high with this, but, again, it depends on the kind of response I get. If this is the kind of useful content that you want to see here, then you gotta let me know.

Thank you all, code well, and good night.

Let's face it, we live in a world where any high school kid with a semester course in "web design" (if even that much training) and a copy of Frontpage can hang out a virtual shingle calling himself (or herself) a "webmaster." Factor WordPress into that with its five-minute install and innumerable themes and you have a job title glutted with people who don't know the first thing about what they're doing. An amazingly large number of otherwise intelligent business people are entrusting their entire web presence to such as these. The general public's lack of knowledge in this area only serves to exacerbate the problem.

Without any foreseeable way to prevent this practice from continuing and growing exponentially, those of us who care are left with the onus of attempting to educate these fledgling webmasters about the need for good coding practices, accessibility, and web standards. I know, many of you have been doing that for years already, but this is an ongoing problem requiring constant reminders.

Now, before anyone gets in an uproar and thinks that I am perhaps mocking the document upon which this is based–The Declaration of Independence–I'm not. I don't know of a clearer way to outline an ongoing problem and then express the need for action and the conviction to carry it out. As a pure study in writing, it's one of the greatest essays ever written. I humbly borrow from the masters.

The need for web standards and accessibility cannot be understated. If you're putting content out there for the world to see, use, and interact with, then there is a certain underlying responsibility to do it correctly. That requires some extra work and study. Fortunately, the web is full of people willing to share that knowledge. I've put together a list of such resources on my Anal Coding page to serve as a beginning point. The very abundance of this information made freely available to everyone everywhere is what makes the practice of bad coding so pointedly shameful.

One important thing to remember, however, is that the web is not a static technology. It is constantly growing, expanding, and evolving. New people, ideas, and technologies will come along and suddenly change everything we've taken for granted. (That may even include the aforementioned high school student.) The standards, therefore, that guide us in the creation of accessible and well-coded pages are themselves evolving and subject to change.

I encourage you to read the document itself, comment on it, and, if you agree with it, go to the declaration page and find out how to become a signatory of this important declaration and thereby further get the word out on the need for web standards and accessibility.

Thank you all, code well, and good night.

The recent spate of new web content modules coming out of PBS (and beyond) has me thinking about the need for beta testers. For those of you that may never have given it a try, beta-testing is the process of testing something out before it's ready for release to the general public. It can be quite interesting whether it's software or a new web module. It gives you a chance to not only critique someone else's work, but to sharpen your coding skills and offer suggestions for refinement. It makes you a part of the work. The biggest kick for me, however, is getting to play around with all the newest toys before anyone else even gets to see them.

There are a few important things to remember when beta-testing PBS modules for your station site. The first and most important of these is to test it on a working version of your actual station website as it would run under normal conditions (although in a nonpublic area protected from search bots and perhaps requiring a password to enter.) The idea here is to see how it functions on a real station website. The PBS Interactive in-house alpha testing should have already covered how it works under other conditions.

It must be allowed to interact with your usual station CSS in place on the page. No matter how narrow and focused the CSS for a new module may be, there may still be unforeseen interactions with already existing styles. That's exactly the kind of stuff that PBS Interactive is looking for and needs to learn from your feedback, and that's exactly why they have to have beta testers. I, for instance, have noticed the recurring use of common words (like "description") for CLASS or ID element names which virtually guarantees problematic interactions with already existing styles and script triggers.

The module should also be tested under the normal coding restrictions (or lack thereof) imposed by your site's primary document type declaration. To make the modules as cross-platform, cross-server, and cross-browser compatible as they can possibly be, they need to be tested under differing document types. Ideally, the people at PBS Interactive should have picked their beta testers from a wide selection of stations representing as many different document types and servers as they possibly could to get the widest possible testing results and thereby eliminate the most possible errors. Therefore, the minimum testing that should be performed from our end is simply to set it up on a regular page of our site. We're, of course, always welcome to test more beyond that.

The Process of Beta Testing

I don't know how others do this–and I'd love to hear–but I generally start out by implementing a new web module in its raw state (no code or style modifications) in the widest possible section of a page. I usually pick a single-column page layout for this (no sidebars) in order to get a good 700 to 740 pixels of width to play in. A site with a non-fixed-width (or "liquid") layout will, of course, have variable outcomes for this. I do this even if the module is actually meant to be narrow sidebar content.

The idea here is twofold; first, to see if the module even works, and second, to see just how wide the module will go. After looking at the results of that–and assuming it works–I check the code and CSS to see if there's anything in place that restricts the module from going even wider. Playing around with the Pre-K Block Module, for instance, shows that it can be used not only as sidebar content as it was originally intended, but also as a variable-width page filler wherever needed. That gives me a nice new tool for balancing out low-content pages.

The next test I do is to implement the module into a narrow, restricted space. The easiest way to do this is by putting it into a table and deliberately setting the width too low (like 10 pixels) and the border to zero. If your CSS has predefined table element padding and margins, then this experiment may require the creation of a specially named CLASS for a non-padded table that will have to be defined in your style sheet.

The point of this test, of course, is to get a minimum width for the module—usually the width of the widest single element like a graphic. I personally think that every web module should have the minimum and maximum widths spelled out in the documentation. It makes it easier to plan layout and placement. Everything after this is just about playing around with the CSS and coding to either fit it in better with your site's style or run further experiments.

My general last step is just to put it into a page with other content, style it to fit, and get an idea of the full visual and content impact of the module and, of course, what it does when a user intereacts with it. Some of the modules take users offsite, some open new content windows, and some (like the TeacherSource Monthly Theme Module and the Schedules Module) open out on the same page from a small space initially into larger pieces of content. These followup module states must also be taken into account and planned for (as many stations discovered after implementing the Schedules Module.)

Some Final Words

Although most of the PBS member station websites routinely rely on the content they receive through PBS web modules to fill out their own sites, there is quite often a shortage of station web developers willing to help out in the beta-testing phase of their development. That's too bad since shortages of staff and time at PBS Interactive are already impacting development of new content. It's in our own best interest, if we're to remain relevant in the 21st-century, for us to be a willing part of this important aspect of content development.

Meaghan Zimmerman of PBS Interactive sums it up best:

BETA testing is a vital part of the process of building and launching modules for stations. Our thanks and appreciation go out to those stations who continue to volunteer when asked for their time. The more BETA testers who volunteer, the better the results.
–Meaghan Zimmerman, Senior Associate, Station Services, PBS Interactive

Thank you all, code well, and good night.

BEWARE: Web developer letting off steam. Read at your own risk.

Okay, I've had it. I'm tired of telling people that what they're seeing on their screen isn't really what my site looks like. I'm tired of explaining to site users that I did not populate my site with sucky graphics. In point of fact, I'm sick and tired of the entire concept of "Accelerated Dialup" that ISPs have been selling for years. It's a myth, an illusion people; it doesn't exist. Now, I realize, of course, that my audience here is primarily web developers and that this isn't anything they don't already know, but I just can't stand it anymore. I'm sure you understand my need for a rant here.

I'm over at a friend's house or a get-together or something. Someone walks up to me and says something like, "I just heard that you handle such-and-such website." I straighten up and get prepared to receive the unsolicited commendations I'm sure are forthcoming. The next thing I hear is something like, "You'd think they could afford some decent graphics." or, "Why does it look all crappy like that?" Then I have to spend the rest of my time there trying to save what's left of my deflated ego and explain how they've been duped by their ISP.

ISPs routinely sell the concept of "Accelerated Dialup" with ridiculous phrases promising "DSL-like speed from your dialup connection." They'll even explain how it works right on their homepages while knowing full well that the majority of their users don't read anything past the lurid sales bullets and the stated price.

The way it works is to remove some of the quality from all of the graphics they display so that the page loads faster. Is it just me or does this strike you as the web equivalent of the potato-chip bag disclaimers that say, "Some settling may occur," as if that explains why the bag is more than half empty when you open it?

The problem here is that within a week or two of signing on, most users have forgotten (if they ever noticed in the first place) this aspect of their ISP's behavior, and they begin to think that what they're seeing is just the way the web looks. If you're like me and you've taken the time to optimize your graphics as far as possible to achieve the fastest possible downloads for your users, then the extra filtering of "Accelerated Dialup" will result in graphics that look like they were created by a third-grader with a water-color set. The alternative is using higher-quality, slower-loading graphics to compensate.

Here's how the ISP's should explain it:

We know that your 56k-modem won't go any faster than 56k, but, in order to get you to give us your money, we will gladly give you the illusion of faster web surfing by stripping 20% to 50% of the quality from even the most carefully crafted and optimized graphics before you view them.

To be slightly fair in my rant, "Accelerated Dialup" does have it's place. There are times when a dialup user will want to surf the web faster without being that particular about graphics. However, this should be done knowingly.

Why can't the ISPs, since they're already processing the graphic anyway, brand it somehow to remind users that they've tampered with it and it's not the original? I would offer some constructive ideas along these lines, but, in the mood I'm in right now, all I can picture is a toilet-seat cover and the words, "Optimized for your deception."

I really can't believe that I'm the only person bothered by this. Anyway, I appreciate the chance to get that off my chest.

Thank you all, code well, and good night.

Potentially more exciting than the arrival of a new phonebook is the planned automatic update of Microsoft's web browser, Internet Explorer. If you haven't already heard about it–and I'm sure that most of you have–Microsoft is planning to release the first major upgrade to Internet Explorer since IE6 in 2001. With many new features, security upgrades, and changes to the core software itself, it's a totally new browser that will suddenly be the primary browser of a good 70% or more of your audience. Is your site ready for that? If you don't know for sure, now's the time to find out.

Those of us that routinely use other browsers or check our sites out in multiple browsers will find a lot of very familiar things integrated into IE7. I have mixed feelings about this. On the one hand, I'm happy for the changes and improvements they've made, but on the other, I find it annoying that a majority of non-technically-oriented web users will think of these as Microsoft innovations rather than Microsoft trying to catch up with everyone else's innovations. Still, there is a lot to be happy about in this upgrade. Some of it–like improved web standards and CSS support–might require changes for some sites (That's a good thing, really.) and some of it–like RSS integration–are an open opportunity to provide new services and gain a larger audience.

Tabbed Browsing

That's right, tabbed browsing has finally made its way to Internet Explorer (boldly going where everyone else has been for quite some time.) If you're like me and you regularly have to have a number of applications running simultaneously and then additionally have to open several different browsers to compare page layouts, then you'll truly appreciate this addition. I can finally have ONE window of Internet Explorer open with a number of web pages displayed in different tabs (as I always could in other browsers.)

My only regret here is that there's not yet a good, all-purpose, cross-browser compatible script to automatically open external links in new tabs rather than new windows. This would make a nice addition to Paul Boag's External Links script that I (like many others) use so extensively. However, I'm sure that one will come along eventually.

RSS Integration

This is truly an awesome feature. I know that it's already been a standard part of other browsers, but, because 70% to 90% of your users are surfing the web with nothing but Internet Explorer, the sudden ability to read and subscribe to RSS feeds right in their browser will be a totally new experience. If your site already has an RSS feed, then now's the time to start planning how you might promote it to a more main-stream audience as well as how you might make it a more prominent part of your pages. If your site doesn't, then now's the time to start working on one.

The feed button for IE7 remains grayed out and inactive while viewing pages without a recognizable feed (RSS1, RSS2, Atom, etc.) and then springs to vivid, orange life when viewing a page that has one. I don't know about you, but I'd like it to be one of MY sites that a user first notices this strange new button on. You know it has to be tried at least once just to see what it does, and what it does is tell your users that there's even more content available from your site then they may have ever been aware of otherwise.

The drop-down list of available feeds and feed types next to the button is a potential source of confusion for non-technical users, but most will simply click the main button and get the topmost, default feed. Upon clicking it, however, they get not only a new feed page, but some helpful information about feeds and how to use them. My favorite part, though, is the bolded statement in the yellow box that says, "You are viewing a feed that contains frequently updated content." That's practically an unsolicited advertisement for viewing your feed. I really have to thank Microsoft for including that.

Between all the browsers that I've tried (Firefox, Opera, and IE7) and all the feed readers I've tried out (including Outlook 2007 RSS) nothing beats the simplicity and ease of reading feeds of IE7.
- Greg Kniffin RSS Feed Readin' - IE7 is king

They've even gone a step further and added a sidebar allowing users to sort or filter your feed by date, title, author, and even category. These categories, by the way, are the ones you've assigned to each piece of feed content. A little careful forethought in this department could net you some permanent, new site users viewing your content and, more especially, your membership reminders–especially if you pad every RSS "post" with a membership link.

Extensibility

One of the problems that Internet Explorer has always had was its inherent lack of extensibility. It was a proprietary, Microsoft application meant to do only what Microsoft had in mind when they shipped it–nothing more. This misguided approach froze it into being a passive browser. Firefox, with its numerous extensions, changed all that along with everyone's concept of what a browser could be and what it can do.

With IE7, Microsoft has seen the light of following this approach, and they're not stepping in with nothing either. They're starting right out with some heavy-hitters, two of which immediately caught my eye, the Developer Toolbar–the Internet Explorer answer to Chris Pederick's indispensable Web Developer add-in for Firefox–and Fiddler which is an HTTP Debugger that lets you fiddle around in that particular pot of code.

Of course, it remains to be seen if they can harness the kind of voluntary developer community that Firefox has, but they are off to a good start. At least this kind of "raising the bar" back and forth between the various browsers will continue to benefit all of us out here in the trenches.

Security Features

After taking it on the chin for ages, Microsoft has gotten downright serious with security–perhaps a little overboard in some ways–but serious nonetheless. One of the better aspects of this new security consciousness is their phishing filter. IE7 will block access to (or at least warn you about) fake sites that pretend to be trusted sites in order to get you to reveal private information, download malignant software, or just look around while it loads crap onto your computer in the background.

None of the phishing features in IE7 appears to cause problems with legitimate Web sites. I tested all the features in both application suites in all environments, without once running afoul of this particular feature. In fact, developers should be happy about this feature, because it means that nefarious individuals are less likely to hijack users that are coming to your Web site.
- John Mueller Making Your Apps work with Internet Explorer 7

IE7 defaults to blocking most pop-ups now. As an underhanded advertising method, this is better dropped anyway, but, as a legitimate method of delivering small pieces of extra content like program information or auction item windows, this might require a little rethinking. It's also more aggressive about cookies. A good P3P Privacy Policy should prevent most problems of this nature.

It also has safeguards in place to protect against old or inappropriate SSL certificates. If yours is out of date or contains invalid information, it's time to get that fixed now.

Better CSS Support

After working with the Web Standards Project (WaSP) since July of 2005, believe it or not, IE7 now sports CSS 2.1 compliance. That means that Internet Explorer, still the most popular browser on the planet, has made a major move–at least for Microsoft–toward the world of web standards. It's a start.

With all these major bug fixes in place, there are those of us–myself included–who may have to revisit some of our CSS files to double-check their compatibility with IE7.

If your layout relied on us "growing" the box (if your content did not fit the dimensions you gave it) then this can lead to breaks. You can easily discover breaks related to overflow by observing content suddenly overlapping other content.
- Cascading Style Sheet Compatibility in Internet Explorer 7

Some of the CSS hacks we've been using for awhile are no longer valid. I'm sure new ones will come into play. Currently, the Star-HTML hack is still okay, but others may not fair so well. It's worth running through their posted list and checking for any hacks you may have used. Frankly, it's just time to move away from that whole way of coding. (I'm saying that for my benefit since I'm sure that you already knew that.)

After all this, they still treat ALT text as a tooltip. Will someone please tell them that that's a bug and not a feature. I'm so tired of it.

PNG Support

Real PNG support and everything that goes with it has finally made it to Internet Explorer.

You can now display Portable Network Graphics (PNG) images without relying on odd workarounds to implement transparency. However, some older features are also gone. If you rely on the Dynsrc attribute of the <IMG> tag, you'll need to change your Web page, because it no longer works in IE7.
- John Mueller Making Your Apps work with Internet Explorer 7

I'm looking forward to seeing a lot more sites taking advantage of the real power inherent in PNG images. The combined use of lossless graphics images with layered transparencies and semi-transparencies can not only create stunningly vivid pages but, with a little imagination, whole new ways of presenting content.

Things to Worry About

Although most sites tend to look the same in IE7 as they did in IE6, there are some potential problems. Most of these have to do with site applications (like shopping carts and such) and the use of ActiveX controls. John Mueller outlined these in detail on the DevSource website, and I really encourage you to take the time to read through all five parts of his article on Making Your Apps work with Internet Explorer 7, because I'm only scratching the surface here.

Don't wait until Microsoft releases IE7 to begin testing your applications. Based on what I've seen so far, unless you're using pretty much pure HTML on static pages, your application is going to break in some way.
- John Mueller Making Your Apps work with Internet Explorer 7

ActiveX Problems

I don't know if anyone else remembers it this way, but I seem to recall that ActiveX was developed by Microsoft as an extension of OLE back in the mid to late 90's and pushed as an incredible new way to make the web work directly with your already existing desktop applications–especially the Microsoft ones. Now, in a bizarre turn of events, they're trying to protect users from their own creation.

After having seen many examples of just how bad malignant ActiveX controls can get, Microsoft finally decided to add some protection for users in IE7. Unfortunately, this halfway measure doesn't really help anyone. Users will be annoyed by having to OK every ActiveX control, every time one appears on a Web page.
- John Mueller Making Your Apps work with Internet Explorer 7

If you haven't done it already, lose the ActiveX reliance. It's just going to be more and more of a problem over time.

Since most other browsers (including Firefox) ignore ActiveX controls, you might want to phase out use of ActiveX in your applications. They were always a bad idea. Unfortunately, this one change is going to break many applications; everything from shopping carts to data collaboration.
- John Mueller Making Your Apps work with Internet Explorer 7

Header Information & Range Checking

If you've gone out of your way to provide appropriate content to your users based on the browser he or she is using or whether or not a specific plugin is available, then you're to be commended. You went above and beyond the call of duty for the sake of your users. Unfortunately, you may now have more work to do.

A check of the request header information that IE7 provides shows that some applications will break when they employ poor range-checking methods. My test system shows that IE7 supports nine file types by default… The user agent information is also different… If your application checks for specific version numbers, rather than a range of numbers, it may stop working with IE7.
- John Mueller Making Your Apps work with Internet Explorer 7

Multiple Home Pages

This is kind of a weird thing to get used to and you may not think of it as something to worry about. The idea here is that you can have more than one home page, and they'll all open up in separate tabs of which you can set the order.

While that's all well and good, I can easily picture a lot of web developers running out and dusting off their old "Make this your homepage" JavaScript link. I tested this in IE7 Beta 3, and yes it does still work. If you click on one of these links, it will bring up an "Add or Change Home Page" dialog box. This will allow you make that page your only home page or add it to your home page tabs. So what's the matter with that, you may ask. Well, frankly, familiarity breeds contempt.

I, personally, don't want my pages associated with anything that can clog up a user's experience online. Setting three or four homepages won't really impact broadband users, but dialup users will see significant delays in just being able to get started when they open IE7. The usual reaction to that is to blame the last page that was added, and I don't want that to be my page. There's also the problem of incomplete page rendering if an impatient dialup user (Name one that isn't.) starts browsing in another tab while your page is still loading.

All in all, I'm planning to avoid encouraging the use of my pages as home pages. It's not really the opportunity that it might seem to be. Instead of that, I plan to create content that users will want to come back to again and again and even add to their favorites or bookmarks. I still think that the real opportunity is in the RSS integration.

Some Final Words

With all of that said about this changeover, you might be wondering about how you can check your site out. Well, to be honest, the two main methods are only available to customers running genuine Microsoft Windows. Apparently, Microsoft doesn't want to help non-Windows-based web developers to get their sites ready for IE7. That makes no sense to me since they should want the majority of websites that their customers have been using to continue to work in their new-and-improved browser. If users make this change as planned and begin immediately seeing broken pages, then they'll blame the browser, not the web developer.

Anyway, the two main tools are the Internet Explorer 7 Readiness Toolkit and simply downloading the latest release candidate of IE7. If you can stand the wait time and their servers aren't too overwhelmed, then you might want to check out BrowserShots.org to get screen shots of your pages in multiple browsers including IE7.

I'm going to let John Mueller sum up what he calls "The Bottom Line" of all of this.

You might think that all of these changes are a pain. In many respects, you're right. However, the changes really are necessary. Creating a secure internet (or at least one where you don't have to walk on eggshells) is everyone's responsibility. The changes you make to update your Web site to IE7 will benefit everyone. The user benefits from added security, enhanced privacy protection, and improved features. Your company benefits from fewer attacks and reduced support requirements. You'll benefit from those extra weekends you get to spend at home, rather than at the office. Unfortunately, to get all of these benefits, you'll need to spend time now fixing the things that caused the problems in the first place.
- John Mueller Making Your Apps work with Internet Explorer 7

Thank you all, code well, and good night.

It was a turning point in Internet history, and it happened in October of 1995. Frontline had been investigating the 1993 Waco siege for an upcoming report when David Fanning, the Executive Producer of Frontline, made the decision to put a good deal of the material derived from their research and reporting (photos, FBI surveillance audiotapes, reporting notes, interviews) on the web for everyone to see. It was their very first website and done with a staff of just two people. That single act not only created the concept of open (or transparent) journalism but forever changed the way we look at and what we expect out of the World Wide Web.

You may be wondering what this has to do with your local station website. After all, it's been a while since we've had Frontline content available to us as local web content–not counting RSS feeds. The original Frontline Video module that some of us once utilized on our local sites was a rather short-lived experiment, and even the more long-term Headlines module (much lamented in its passing) eventually faded into history. So what is there now that could inspire a public television station web developer like myself to bring up such a sore subject? Well, you're not going to believe this, but Frontline Video is back, and it's all grown up now.

Sam Bailey, Frontline's Director of New Media and Technology, has spent the last two years developing a new, enhanced web video player designed specifically to play high-quality, large-frame video of full Frontline programs directly off of local station web sites. The new player will be able to play at a bitrate of 350k–a considerable increase over the current 220k–in a fairly large and customizable playing window, and PBS is providing the bandwidth for it. The only downside is that it's available for broadband only.

We're going for incremental improvements here. I think eventually the bitrates will go higher, but, right now, 350k is a good number for us (and for PBS who has to pay the bill.) Frankly the quality of many broadband connections and general latency is such that higher bitrates can sometimes not work so smoothly.
– Sam Bailey, Director of New Media and Technology, Frontline

One exciting aspect of this delivery system is the distinct possibility that West Coast station sites could actually receive the latest program through their website prior to the on-air broadcast. Frontline's current plan is to make the shows available online on the same day they're broadcast which means that West Coast station sites will have direct access to the shows three hours earlier in the day (in terms of local time) than East Coast stations. This aspect of the player's behavior is still under consideration but probably won't change.

But Wait, There's More…

I know it sounds like a bad commercial, but this player has a lot of other innovations that will make it indispensable to your station website. It appears initially as a small piece of page content (probably sidebar,) but what it does next is controllable by you. There are two different options that you can set up to control what happens when a user clicks the link; it can open a player window or a menu page.

The Player Window

The Player Window is the heart and soul of this new module. It's designed to open as a small, popup window over your page and begin playing a Frontline program of your choice. The real innovation, however, is that there's a space around the window that can be customized for station logo and messaging that you can control. If only CSS control could be built into the final version (which is not currently planned,) then this player could be reskinned locally as each station sees fit. Still, it's definitely going to be an important part of the local station site and yet one more really awesome service to offer to the community.

The Menu Page

The Menu Page option opens as a new page. It currently contains a selection of 16 available videos, but there are at least 10 shows in the coming season that are due to be added. For the entire archive, we'll still have to send visitors to the Frontline site, but I plan to do that with a simple, localized “More Videos >>” link at the bottom of the page pointing to the Frontline Video view page.

You get to customize this menu page as well with your information such as upcoming broadcasts of Frontline and your other public affairs programs as well as other messages you might want to convey, pledge drives, local events, appeals for membership…
– David Fanning, Executive Producer, Frontline

Other Issues

Implementation

The implementation of the player is quite simple and will come as a standard toolkit complete with multiple templates, full instructions, and even promotional materials. Frontline's web team (in conjunction with PBS Interactive) will be available to advise and assist participating stations. My personal plans are to set up a homepage version pointing at the most current episode available for viewing and a news page version set up to open the Menu Page for the site visitor to choose from. You, of course, might choose differently.

Marketing

Frontline's marketing department will create materials customized to your station to help get the word out to your viewers. They have a vested interest in making this work, and they're willing to go out of their way to get your local station viewers to go to your site and try this out. They're offering a number of promotional materials:

• On-air promotion spot
• Member Magazine article
• Press release for local publications
• On-air tag reminder to go to your website and watch the program again any time
• Ecards or postcards for online and mass mailing promotion

It might even be worth asking for if you can think of something else to add to the list.

Objectionable Content

Although on-air broadcasts of Frontline occasionally require editing for "objectionable content" and fall within applicable FCC decency regulations, online broadcasts (webcasts) have no such limitations. So Frontline is looking at the Internet as having "another level of gatekeeping," because you have to actively chose to click (or take some other action) to get to the content. Their plan is to carry an "appropriate warning" in the program description and go ahead with streaming the unedited version. There's still some discussion as to whether to create a special edited version for schools to access, but it seems to me that the easier answer to that would be to simply point schools to a more limited collection of videos, ones without such content.

Player Rollout

There will be a multi-phase rollout with changes and updates to the player over time. The plan is for the first round of stations to launch at the start of next season, October 3. The first version will make use of Flash and Quicktime, and the content will be delivered via HTTP–"at least this version; the Windows Media version is another matter entirely."

I should say up front that some of this may not be set in stone yet. We're busy rebuilding part of this right now.
– Sam Bailey, Director of New Media and Technology, Frontline

Accessibility

To their further credit, Frontline (or, more specifically, Sam Bailey) actually considered accessibility issues in the creation of this player. Some of it is in place now, and some will require more work later. They're linking from the video to the existing transcript on the Frontline site and captioning is possible in the player.

This initial version will only have limited captioning, because the archived shows are not captioned at this point. We're exploring going back and having them captioned now, but there's no timeline for it. As for keyboard navigation, we're pondering that at the moment, but, other than rudimentary stuff like play and stop arrows and the return key to select a program, we don't have much in there right now. We need to talk about accessibility options with NCAM if the test goes well.
– Sam Bailey, Director of New Media and Technology, Frontline

Some Final Words

On Revolution and Renaissance

There's a lot happening in public broadcasting right now, and the Internet is a major part of that. Many of the current models and methods are failing to work in this 21^st-century view of instant media. Strangely, many of the earliest models and methods of public broadcasting are being resurrected, dusted off, and seeing new light. They were envisioned for what was then a new media with infinite possibilities, television.

We're all witnessing an accelerating shift in the television landscape. We're in the midst of a great technological revolution in delivering programming.
– David Fanning, Executive Producer, Frontline

We may well be in a "technological revolution" as far as program (or content) delivery is concerned, but I'm seeing the effect on the programming itself as more of a renaissance for public broadcasting. Not since its very beginnings has there been such a wide open landscape of possibilities for what public broadcasting can do and be. It's being reborn and redefined almost daily–as is the station website.

We know that there are all sorts of discussions about how we're going to enter this new age of congruence between the Internet and television, but we don't want to wait around. We want to get our service out to you as soon as possible so that public television, Frontline, and your station are on the forefront of the revolution.
– David Fanning, Executive Producer, Frontline

Personally, I'm going to stick to the forefront of the renaissance. The revolution can take care of itself.

The Changing Role of the Station Website

The advent of this player marks the beginnings of a new role for the station website as well. If more national programming follows Frontline into this model of online delivery to the local station site, then that site begins to be more of a separate channel of station programming rather than just a convenient online station brochure. That's an entirely new direction for the local station website, and it will attract a whole new audience. That, in turn, will translate into station membership.

What's interesting is that a new, younger audience is finding us on the Internet, and so too is our old audience. By harnessing the Internet's simple technology to send your viewers what they want, when they want it, freely available and accessible, we are trying to build that audience and deliver for the future on the great promise of public broadcasting.
– David Fanning, Executive Producer, Frontline

I don't know about you, but I think that that future is looking pretty bright, and I can't wait to make this new tool an integral part of my station websites. I think that it brings a whole new resource to the local communities I serve and adds to the overall value of the stations themselves. Watch for it to be available. Check it out immediately. I know that you'll agree.

Thank you all, code well, and good night.

I apologize to everyone for having been too busy to post anything here for the last month, but many of my projects will be coming your way as new station web content very soon. However, to get back into the swing of things, I bring you the KIXE redesign. I have maintained the KIXE website (such as it is) for several years now with a complete redesign always pending but never approved. It's horrible design and coding has always been a thorn in my side and, with the launch of their new logo and look, I've finally gotten the go-ahead.

There are a number of challenges to be met in getting KIXE's site up to standards. There's the usual content rescue wherein I have to find all of the actually useful content and extract it from the coding nightmare that it's currently buried in. There's the fact that it's hosted on a Windows 2003 server with a number of other sites, and I don't have the usual server control that I've been getting so spoiled on. There's the addition of an online auction and an eGuide that will require initial setup and long-term maintenance–probably with Microsoft Access interaction. However, the greatest challenge here–and I'm gritting my teeth and going forward anyway–is the absolute reliance on Microsoft Frontpage.

I'm not a Microsoft basher, so if you were hoping for a tirade on that subject, you'll have to look elsewhere. The web is full of them; they're not hard to find.

That kind of stuff always reminds me of those guys that see you putting a tiny nail in the wall with a little utility hammer and start in making derisive comments about what they call "housewife hammers." You have to cut off people like that before they start telling you how many ounces their "real hammer" is and let them know that the point is the job and not the tool. Best answer for that kind of stuff: "I could do it with a rock; I'm sorry that it requires so much more for you to accomplish the same thing."

So, how does one go about creating an accessible, standards-based, cross-browser compatible, dynamic website with a tool like Frontpage? Frankly, you cheat. You do as much as possible directly in the code, and you start with a standards-based design and rework it to fit your job. KIXE wants a site based on the PBS Be More Station Website Prototype which varies between differing static pages having one- to three-column rigid layouts and a header and footer. Therefore, I've decided to adapt the Piefecta layout to the prototype to achieve a standards-based, rigid-column design. [Thank you John and Holly.]

Piefecta is a beautiful piece of coding and highly adaptable. I've reworked it to cover one-, two-, and three-column layout from a single CSS file and even added in support for the three faux columns found in the center column of the homepage. If you'd like to see where this is at right now, then visit the KIXE test page. There are still a lot of internal styles to work in, but the primary layout is there and waiting to be filled.

If you look closely, then you'll see that I've actually used a few proprietary Frontpage extensions for server side includes. This makes up for the fact that I don't have the .htaccess control of an Apache server here to hide my server processing in a plain HTML file. I don't want to create a site laid out with all the files having SHTML or ASP extensions as those tend to confuse people, so I will be making use of what the server offers me. I will be using both standard and timed Frontpage includes to run basic server preprocessing from a plain HTML file.

Keep checking back here as I update you not only on the progress of this redesign, but also on some great new tools that you'll be wanting to add to your station website soon.

Thank you all, code well, and good night.

Introduction

In one of its most brilliant decisions ever, PBS decided to downplay itself as a national entity in favor of extending the perceived reach of every one of its local member stations. (Web: best medium for local/national convergence?) In other words, PBS in Medford, Oregon IS SOPTV, PBS in Redding, California IS KIXE, and PBS in your local town or city IS your local station. This doesn't just happen on-air, it extends online as well.

When a local station website links to a PBS program site like Frontline or Nova, it uses station-linking code to pass its station identification to that site which in turn dynamically generates a localized version of that page complete with a backlinked station logo and localized broadcast information. The end result for the user is that their local station website and the PBS.org national site (the most popular dot org site on the planet) work together as a single, cohesive unit creating the perception that they are one whole site. In fact, some studies have shown that many users are totally unaware of ever having left the local station site.

PBS localization has added to the perceived value of the local station site as a community resource. It extends the perceived reach of the local station into vast resources and archives of information that no one station could ever achieve. Basically, PBS was a Web 2.0 resource long before anyone conceived of such a term to describe that kind of online interaction and interconnectedness. Now, while the rest of the web tries to catch up to even that level, the time has come for us to extend this even further.

Individual stations across the country have for years been creating small (and some very large) pieces of original web content. Some of these are tied to local productions or events and hold little interest outside the local community, but many are very interesting slices of local history, art, and culture and have value to the system as a whole. This kind of web content along with content tied to nationally distributed programs would be ideal for localization.

The Proposal

I propose the creation of localized versions of such pages set up to take advantage of and function similarly to the already existing localization system in place on PBS.org. The beauty of this system is that it's so easy to tap into from outside sources. Actually, if you think about it, that's exactly what it was designed for.

In point of fact, creating such a localized page requires only a few things:

• the addition of the standard localized PBS navbar to the top of the page to carry users back to their local station or pass them on to PBS,
• a reworking of the page header to showcase the specific logo or content of the page rather than the organization behind it,
• the elimination of any internal site navigation, search boxes, or links meant to get site users around that specific site rather than just the specifically localized content,
• the elimination of any internal support link coupled with the addition of a PBS localized station support link (and this is very important to make it valuable to other stations,)
• a reworking of the page footer to again eliminate any standard internal site links and the addition of a sublimated organization logo, credit, link, and copyright/trademark statement,
• and, finally, a way to receive the station identification parameter through the URL and pass it into all of the PBS links.

It's really a lot less complicated than it sounds.

Reasons For Doing This

If you're wondering why a station would want to do this with their own content, there are a number of reasons:

• Showcasing your local art, history, culture, entertainment, and educational resources to stations and web users across the rest of the country is yet one more way of adding value to YOUR station as a modern and relevant connection to the rest of the world.
• It makes YOUR local station a more attractive and valuable outlet for the people who create this kind of content to bring it to.
• It supports and adds value to the system as a whole.
• It adds some small bit of value to your nationally distributed programs when stations considering running them know that there's localized content that they can link into.

Station Example

If you're tired of just hearing about this and you'd rather see it in action, then check out Sierra Center Stage, a new program being distributed by Southern Oregon Public Television. To reach that page normally as a part of the SOPTV website, you would go to www.soptv.org/scs. That takes you to the non-localized version of that page meant for users of the SOPTV site. However, with the simple addition of a question mark and your station's call letters (try www.soptv.org/scs?wnet) you get a localized version of the page complete with station logo and a support link tied to your local station's membership page (provided your membership link is current with PBS Station Remote Control.)

Potential Worries

If you're worried that this could somehow affect currently localized users and perhaps "relocalize" them to a different station, it can't. The already existing PBS localization cookie system is not affected in any way by this kind of "homemade localization." Since it doesn't store anything on the client computer, it's temporary and page-specific. When an already localized user clicks through to the PBS main site-even on the support link-the already existing PBS localization cookie will override any parameters passed in the URL and localize them accordingly. Therefore, you can't lose already localized viewers though you might potentially gain a few.

If you're worried about what will happen to users who bookmark a page like this, they'll bookmark your localization code along with the site URL. That means that unless they alter the properties of their bookmark, it will always open localized to you.

If you're worried that localizing your content for other stations could cut into potential revenues by turning the support links away from you, then this one you'll actually have to weigh against your own records. For the most part, stations do not make support money from web content linked into by other stations. However, if your station actually does, then that content would not be a good candidate for localization. No one should lose money or users by doing this.

Beyond Even The Stations Themselves

This kind of extension of station localization and what it can do goes even beyond public television station websites. Any piece of web content on any site can be localized to make it useful and valuable to PBS member stations that want to link into it. That means that any organization or individual out there with a website can make localized content available to stations to use or not use as they see fit. I don't think that it takes a major stretch of the imagination to envision a time when web producers and web content distributors will approach public broadcasting stations in much the same way as program producers and distributors with the hope of having their content featured by those stations.

Non-Station Example

If you're wondering how even a non-station website could manage this, then check out Online Xtras, a page I created on my ptvguy.com website as a collection of links to PBS online-only content (and, yes, I still hate the name, but I can't think of anything better.) If you go to the page directly at www.ptvguy.com/xtras/ (spelled without the "e" as x-t-r-a-s,) then you'll see that it wasn't designed to be used as anything other than a localized page. All the localized station linking ends up missing the station identification and the navbar at the top is taller than it should be, because there's no image where the station logo goes. However, if you go to the page with station linking by adding a question mark, the word "station," an equal sign, and your station's call letters (as in www.ptvguy.com/xtras?station=wyes) then you'll see a version of the page localized to your station. If you'd rather see how an actual station website might link into this, then have a look at the left sidebar on the homepage of SOPTV and click through to Online Xtras. It not only can be done, it IS being done.

How To Do It

If you're wondering why my two examples use different station-linking code, it's because I set them up using two different server technologies. One utilizes simple SSI directives that you'd normally see on an SHTML page and the other utilizes PHP. The point I wanted to make with this is that it doesn't really matter how you set it up as long as it localizes correctly and you make the method clear. I kept it as simple as possible. The only reason that I didn't create an ASP example is that I don't have anything available on a Microsoft Windows server worth localizing.

I've put together a downloadable file with all the pertinent underlying code and included content from both of these examples, so that you can look it over and see how simple it is. If you have content that could be used in this way, why not give it a try. If you know of content that could be used in this way, why not suggest it. You don't lose anything by doing this. You do, however, have a potential to increase your audience while simultaneously supporting PBS member stations everywhere.

How Will We Use It

If we can get enough localized content together to justify the effort, then we could create portal pages (like my Online Xtras example) to organize or categorize the content and create a single link-in point for stations to connect to. Who knows, maybe we can get enough high-quality content together to get PBS itself interested in creating more portal collections like Global Connections or African American World. I already know of some more local content that could be added into this, and I bet you do to.

"PBS.org's top priority is presenting content that supports the broadcast schedule," said Cindy Johanson, Senior Vice President, PBS Interactive and Education during an interview back in 2002. Although many aspects of the web itself and how PBS uses it have changed and evolved since then, budget and staffing cuts have forced PBS to be extremely selective in what they put out and support on their website. Witness the move of PBS LiteracyLink™ from PBS to KET (speaking of which, there's a broadly used resource that I'd love to see localized,) and the cutting of PBS Campus, PBS YOU, and a number of other PBS resources. Frankly, good content is not always supportable content.

I don't believe that local stations can or should be solely dependent on PBS to provide original web content any longer-which is not to say that we don't still need them. However, we are more than capable of (and in fact already are) producing such content. It amazes me that we are not tapping into ourselves as the incredible resource that we are. We are an already existing network of interconnected content providers and developers. If we open up our own resources to each other and tap into other organizations and individuals willing share their content with us, then, in combination with PBS itself, we will become something greater than the sum total of our parts and, in fact, something greater than anything else on the web.

"Can we build it? Yes, we can."

Thank you all, code well, and good night.