Creating Platform-Independent, Context-Sensitive User Assistance (On-Line Help) With an Enterprise-Wide SGML Publishing Platform		Table of contents		Indexes		Content reuse with XML: new efficiencies in complex content publishing

Brodsky, Jay  Chicago  Tribune Media Services  USA

Jay R. Brodsky

Director of Technology

Tribune Media Services

435 N Michigan Avenue Suite 1400 Chicago (Illinois)  USA (60611) Email: jaybrodsky@tribune.com Web site:http://www.tms.tribune.com

Biography

Jay Brodsky has spent his entire career in the electronic information services industry in a variety of operational, technical and product-management positions. He currently holds the position of Director of Technology at Tribune Media Services (TMS), where he leads strategic technology analysis and decision-making. TMS is a leading provider of information and entertainment products to newspapers and electronic media; Brodsky provides guidance on all aspects of technology-related business opportunities in syndication, database management and advertising. He previously served as product manager for Web syndication at TMS, responsible for developing and marketing original content for the Web sites of newspapers, broadcasters and online publishers; as technology development manager for TMS and Tribune Interactive; and as technology and operations coordinator for Voice News Network. Prior to joining Tribune in 1994, he made significant contributions to the technical and marketing efforts of the Cedar Rapids Gazette's audiotex business. Brodsky is a founding member of the ICE Authoring Group and leads its implementation subcommittee. He received his bachelor's degree from the engineering school of the University of Pennsylvania and is currently pursuing a master's degree in management at the Northwestern University's Kellogg Graduate School of Management.

Good afternoon. Thanks to Dianne and Brad for having me here today, and thanks to all of you for showing up.

My name is Jay Brodsky, and I'm the Director of Technology for Tribune Media Services, based in Chicago. TMS is a business unit of the Tribune Company - a (as the press releases say) leading media company with operations in television and radio broadcasting, publishing, education and interactive ventures. My company's role inside the corporation is to provide information and entertainment products to a whole range of print and electronic media. We collect and distribute television listings and movie showtimes, syndicate comic strips, editorial cartoons, a news and photo wire, feature columns and puzzles, and operate advertising networks.

As such, there's a whole bunch of content that's flowing through our doors every day. Most of that is destined for newspapers, monthly cable magazines, and consumer electronic devices. On the Web, though, we've been working the past four years on models in which we gain wide distribution of prepared packages of our content and, in some cases, sell the advertising that appears with it.

TMS' History in Web Syndication

Our bias toward building full-fledged Web sites out of our content instead of sending an ASCII datastream along to our clients has been driven by the limits in technology that we faced. From the first days preparing prototypes of our Web offerings, I realized that hosting the content ourselves would be infinitely easier for all parties involved than trying to scrape together some sort of distribution mechanism.

Take a look at horoscopes, one of our most popular features. We have an update every day for our clients, and it's got to be there or readers get a little feisty. (Some of them won't leave their beds without reading their forecast.) Because there really wasn't such a thing as content management in those days, this pretty much ruled out the ever-popular combination of FTP and cron. I couldn't possibly imagine explaining to a job candidate that her position would be to trouble-shoot horoscope transmissions at 3 a.m. each morning.

Floppy disks - and don't laugh: we really considered this - were out because of the time factor. Building each horoscope as an image, sticking it on our server, and having our clients embed them as image-source links wasn't too good of an idea either.

It was 1995, so we did the next best thing: FrontPage. We decided that the remote authoring capabilities in Vermeer's new product would allow us to host a mini-Web site for each one of our clients, let them fiddle with the design from their shops, and still allow us to automatically update the content every night. Let me tell you - I spent that entire first night waiting for FrontPage to copy the files to the server. And that was with ten clients. We learned how to outwit the tool after that, but things started to get bad again once we had grown to thirty clients.

And so we moved a whole bunch of our content to Vignette StoryServer. We were still hosting our clients' content centrally, but page views had climbed to six million per month, we were handling the load OK, and there still wasn't any good way to distribute all of those horoscopes automatically.

The Affiliate Model

I should probably point out that we handle a number of things beside horoscopes. We syndicate a dozen other Web "modules" - as we call them - ranging from information on how to find a job, to real estate tips, to recipes, to weather forecasts. We also build websites with television listings, personalized down to the specific cable headend your house is connected to, and a movie showtimes site with schedules for 30,000 of the nation's 32,000 screens.

For each of these products, we've adopted an affiliate model where we host the content and build custom designs for each of our clients who links to the site. This is a fine way to maintain control over our assets, to be assured that the freshest information is presented to users (and to rack up great numbers in Media Metrix surveys), but it puts an awful lot of pressure on our hosting infrastructure. Not only that, we don't have a good way to integrate our content with that of our clients.

No printed newspaper works the way syndicated content works on the web. When you read the Philadelphia Inquirer this morning, stories from the Associated Press were mixed in with locally written pieces. Comics strips from four different syndicates appeared on the same page together. The Op-Ed page had opinions from a bunch of different syndicates.

How ICE Plays a Role

Until ICE, there just wasn't a good way to accomplish the same thing on the Web. Of course, it's possible: Snap went to an awful lot of effort to integrate the content of 44 different providers onto a single page. But the effort of keeping that many ad hoc FTP scripts running occupied too many programmers' time.

With ICE, there's a way to automate this exchange of content, a way that our weather radar images can appear on the front page of Philly.com, or that a horoscope could be placed onto a personalized page. This is something that I refer to as "integrated syndication" - something that I think will be a really important way for publishers to build their websites in cost-effective ways. That's why we've gone out and licensed one of the early ICE-compatible tools and why we're restructuring some of our products for delivery instead of hosting.

You see, when you're building a website, you're always going to focus on the information your users expect you to provide there. But in the process of developing the content areas of your site, you're likely to come up with other topics that would make sense if they were integrated with what you're intending to publish, but are just too far off the mark for you to justify the expense of building. That's why syndication exists in newspapers, on TV, and yes, on the Internet.

Great, you're probably thinking: He's justified his own existence and his own purchase of an ICE tool. What's in it for me?

What's in it for me?

Well, one of the most interesting things about the web is that there are suddenly a whole bunch of new publishers. And some of the content that you create for your website might be interesting to someone else building their own website. And with ICE, the development of content-exchange networks is possible where it never was before. The benefits to a publisher may be increased revenues, brand building, or simply continued existence.

Perhaps you saw one of the articles earlier this year about how small Web publishers were doomed because of the exponential growth of the big websites like Yahoo. Two researchers out at Xerox Parc had conducted a extensive study of a month's worth of AOL traffic, trying to figure out how usage was divided amongst the 120,000 sites on the web at the time.

What they found was frightening, to be sure. The top 0.1% of all sites attracted 32% of all traffic. The top 1% received more than 55%. The top 5% attracted nearly 75% of the traffic. You've heard of the 80/20 rule - this is quite a bit more lopsided.

Their analysis compared this outcome to something economists call a "winner-take-all" market, from an influential book written earlier this decade about the increasing wealth of the wealthy. In the book, Robert Frank and Philip Cook questioned why the top one-percent of all wage earners had captured 40% of economic growth between 1973 and 1996. What they concluded was that there were a whole bunch more people in jobs where small differences in performance yield large differences in economic reward.

You can think of it like this: If you're booking a nightclub, and you have the option of hiring Frank Sinatra or another top-notch crooner who's not quite as good, who do you pick? Or if you're going into heart surgery and you can choose the best surgeon or the second-best, which one wields the knife?

The Parc researchers looked at their numbers, compared them to this salary research, and said "A-ha! It's the same thing!"

But is it? I'm not going to deny that Yahoo attracts a ton of traffic. But the reason why I don't think that the Web is a "winner-take-all" market is that through content-exchange networks, you can pool together traffic in a way not available in labor markets.

Two half-rate singers belting out duets aren't going to draw as well as Sinatra. And two surgeons aren't likely to perform as well as one. But on the Web, where you can share your content - and your advertising - with other sites, there's a clear way to keep Yahoo from winning it all.

Yahoo - or any other portal - wants to be like your local mall. They're big, they attract a bunch of traffic, they have high rents. But what's happening at the mall? The parking lots are emptier than ever and the name of the game is entertainment. Seems like the local mall owners will do just about anything to get you to come by.

So instead of being stuck with just a single, high-priced location, wouldn't a retailer love to have his products in a bunch of different places - to be in the right place at the right time? The same should be true of you and your content, whether that's stock tips, comic strips, or even a book purchase. If you've created something interesting, why spend all the money to remind people it's on your site? Why not get that content to where the people already are?

With ICE, you can actually achieve this. Build relationships with other sites. Establish content-exchange partnerships. Then fire up your ICE-compliant tool and get the information flowing. Just because everything on the Web is "one click away" doesn't mean that we want to make our users leave our sites.

How ICE Works

So maybe I should take a few minutes to talk a little more about how ICE actually accomplishes all of this. I've been a member of the ICE Authoring Group since we started building the protocol back in the beginning of 1998, representing the content creator's perspective. An important aspect of the group is that we've always tried to maintain a balance between the technology folks and the users. I think that this has helped to keep things moving, and meant that we've been able to publish an initial protocol as well as an editorial revision to that protocol, and that a number of vendors have already come out with products supporting the standard.

This Authoring Group, made up of representatives from Microsoft, Adobe, Vignette, Sun, ShiftKey, National Semiconductor, Sotheby's, WavePhore, CNET and Tribune, meets every month or so to wrestle with the improvements we want to make to the protocol, based on the suggestions we get from some of the companies that have implemented it. We're really thrilled to see products on the market from Vignette, ShiftKey, Arcadia Technologies, Andromedia and InterShop using ICE, and we're working with several others to meet our goals for interoperability.

Here's what those products do: ICE describes a relatively straightforward publish-and-subscribe mechanism for the automated exchange of information. A quote-unquote syndicator first builds a catalog of items, described with XML, that they're willing to distribute. A subscriber then points his ICE-compliant tool at the syndicator's ICE server, selects the items he wants to receive and comes to an agreement over the attributes of those items such as delivery time, frequency and rights. Once the subscription is established, the two servers take over the automation, pushing or pulling the content on schedule, and providing warnings where there are exceptions to the agreed-upon terms.

What's really important about ICE is that it's content neutral. The "payload" of an ICE package can take any form - an XML document that complies with a different DTD, a binary-encoding JPEG, or even a reference to material sitting elsewhere on the Web. As such, ICE works for my horoscopes applications, and also serves National Semiconductor, who has to update parts catalogs on dozens of VAR websites every night.

As such, ICE has a role in a traditional syndicator's shop - as I've described for you here - and also in growing e-commerce, business-to-business, and inter-application communication areas.

To make ICE even more flexible, we've mapped out how to make ICE messages extensible, and plan to add that improvement and several others to our next protocol update. You can find the protocol on the W3C website, where it lives as a note. And if you'd like to learn even more about ICE, how to implement it, and its future, please come to the ICE Special Interest Day on Thursday.

Conclusion

So, when you're thinking about the power of content-exchange networks, think about this: Imagine that you turn on the TV news one night and the anchor said "Tonight on TV9 News, a raging house fire, two car accidents and some cute babies. But first, you should switch over to channel seven, where they do some bang-up sports reporting!" Don't do the equivalent with your website. Install an ICE-compliant tool, establish a relationship with another publisher, and make sure that Yahoo doesn't take all.

Creating Platform-Independent, Context-Sensitive User Assistance (On-Line Help) With an Enterprise-Wide SGML Publishing Platform		Table of contents		Indexes		Content reuse with XML: new efficiencies in complex content publishing