This position paper reflects some views based on discussions in the ATSC’s T3/S17 Specialist Group for DTV Application Software Environment, which I chair. The discussions have revolved around the suitability of HTML and some other associated technologies for interactive television. In this paper I have shown some differences between HTML broadcast and interactive television. I have also tried to point out what features lack in HTML such that it is unsuitable for interactive television.

Difference between Web and TV

Web surfers are mainly looking for information, and TV-watchers mainly get entertained. Granted, that with improving technology, people may turn to the Web for entertainment too, but such technologies are in the future, and many pieces along the IP chain have to improve before high-quality audio/video entertainment can be delivered to homes via the Internet. Discounting the limited use of the Web for multicast and broadcast content, the Web mainly supports an information-pull paradigm, whereas while watching TV, information is mostly pushed at a viewer. Finally, much of the Web’s usage is suitable for an individual (results of search queries, financial and retail transactions, private X-rated shows, etc.) and therefore inherently not suitable to be broadcast or multicast to many users. Finally, surfing the Web requires substantial user interaction, often with a keyboard, while watching TV has so far been a passive function.

Convergent Television and Web

Many services have tried to merge television and Web content. In fact, many people believe that a convergence of broadcast TV content and Web content is inevitable. In some trials, program-related Web content is broadcast along with the audio/video (A/V) content. These trials are mainly restricted to WebTV-like devices and PCs that contain a receiver plug-in card. In some other trials, Web content unrelated to the A/V program is also sent out, but this type of service need not concern us. In yet another set of trials, some non-Web data content is broadcast along with A/V, to enhance or supplement the A/V program that is still given its due prominence in the content.

What is Interactive Television?

By definition, any broadcast content that allows the user to interact with it, and changes on-screen elements as per the user’s interaction, can be considered suitable for interactive television.

By this definition, content that shrinks the video to a portion of the TV screen and fills the rest of the real estate with program-related Web content is interactive television. I refer to this as HTML broadcast. I believe that such services are of interest to Web fans, who like surfing the Web while watching TV. Although there is no saying if this mode of TV-watching will be acceptable to mainstream viewers, many broadcasters have shown interest in such trials. I wonder, however, if the novelty of the Web has anything to do with viewers wanting to watch TV and surf the Web simultaneously. PC-buffs, or long-time Web fans, understandably would like such services. Advertisers are likely to be very vary of these services, because there is the potential for viewers to surf away from the program-related Web site and on to sites where the advertiser does not get any value or revenue. In my personal opinion, Web-surfing takes too much user interaction (often using a keyboard), and a viewer reclining on a sofa and wanting to be entertained will not put up with so much interaction.

I believe that viewers would like A/V content enhanced with data that requires minimal interaction with the TV. I believe that most of us watch television in the couch-potato mode, where we are mainly looking to be entertained. A few clicks on the remote is all a normal viewer will accept. Interactive television to me is content that enhances the main A/V program with some related data and information (e.g., statistics of a player on screen pointed to by the user, or targeted advertisement), or provides some additional convenience along with the main program (e.g., saving discount coupons, or delivering the phone number of a local dealer, etc.). Interactive TV should keep the user focussed on the main A/V program, and not encourage the viewer from wandering away. Interactive TV must also tightly synchronize the A/V content with the data/information content. Temporal (upto frame level, or millisecond level) synchronization, and accurate positioning of various screen elements is required. Interactive TV must maintain the "Hollywood experience" that viewers are used to on broadcast TV.

Where HTML Lacks

HTML does not allow any temporal synchronization or accurate positioning between A/V content and data/information. It does not allow any convenient interactions with procedural code that might be necessary for computations. It’s support for applets and scripts is not a natural way to pass data and messages back and forth between the HTML interpreter and other execution engine of procedural content. Some tags of HTML are really not required for a broadcast TV environment, and should be taken out to reduce the footprint of the interpreter. CE manufacturers are very conscious of TV receiver costs, and one should strive for even minor savings in memory required for code or data. HTML is often used with other technologies like CSS, DOM/XML, JavaScript, VRML, SMIL, etc., to overcome some of its limitations. Integrating so many different interpreters/decoders is difficult and inelegant. Authoring content in so many formats is also difficult. The W3C should work towards evolving HTML towards one standard that merges much of the required functionality of the above technologies to enable interactive TV at low cost.