Good interactive television productions perfectly marry the spontaneity of programme making with the precision of software development. There’s the chance to practise innovative ways of working, learn new skills and create something that has never been done before. If you get the opportunity to be involved with producing interactive television, do so with gusto. It’s fantastic fun.

This chapter outlines, step by step, how to take the twinkle in someone’s eye and turn it into a working interactive television application. The first step: get the right attitude.

Overview of Television, Software and Web Site Production

People involved with interactive television usually bring attitudes and ways of working from their previous jobs, which – more often than not – are in television, software or web site production. But these industries all have very different practices – and some are more relevant to interactive television than others.

Television Production

There are typically fives stages to a television production:

• In development, ideas are developed, defined, researched and pitched to commissioning executives.

• In pre-production, the programme structure is defined, the production team recruited, budgets finalised, plans written up, participants located, and the script and storyboard completed.

• In production, all the material required for the programme is shot onto videotape.

• In post-production, the finished programme is put together in an edit suite, and graphics or special effects are added.

There’s also a broadcast stage, but most people involved in the production of television programmes don’t worry about this. From the production team’s point of view, they hand over a tape and there are almost always people and technologies in place that automate the whole process from then on.

The television production process has been refined over the last 50 years. Refined to make production technologies easier to use and refined to make it possible to show programmes around the world. But, most of all, refined to facilitate creative changes at any point.

In television production, major changes can be made during development, pre-production, production and post-production. Programmes are often restructured and re-invented in the edit suite – sections can be moved, live action can be replaced with graphics, voices re-dubbed and video effects used to correct mistakes or change meanings.

That’s not to say that television producers always throw out their plans once they get into post-production, it’s just that they have a considerable arsenal at their disposal should they want to make improvements.

Software Development

Everyone uses different terminology for the stages involved in software development, but broadly they are: research and development; specification and design; production and testing; and launch.

Where software development differs from television production is that, once the specification is determined, any changes that take place in the production and testing phase risk having a detrimental impact on the schedule, costs or scope of the project. Therefore, software project managers tend to focus a lot of their time on clarifying and communicating the impact of change.

All this is necessary with software work because unexpected changes can mean that large parts of the computer code will need to be rewritten – a waste of expensive programming time. Programmers (developers) usually work by looking at the specification then assembling the code, step by step. It’s a bit like building a house. The foundations are laid first, then the walls, roof and windows added. There’s no problem if someone wants to change the programming equivalent of the colour of a window frame. Unfortunately, the changes that people want to make are often more fundamental – like the functionality available to the user or the structure of a database. These kinds of thing are often much more part of the programming foundation than the decoration – and can mean rebuilding large parts of the computer code.

Web Site Production

A looser version of software development practice is used on web site projects. Web sites are usually produced in HTML and JavaScript, which deal primarily with the layout of information on screen. This makes it much easier to make changes. Nevertheless, the more complex the web site, the more interlocking systems there are likely to be. The inclusion of back-end systems for e-commerce and other functions can also increase the complexity dramatically. With most of the bigger web sites, last minute changes can have all sorts of unexpected impacts. Therefore, bigger web projects are usually run using rigorous practices much more akin to software development.

What’s the right attitude to producing interactive television: the creative impulsiveness of television or the rigorous change control of software development?

Interactive Television Production

Interactive television applications are built using software programming code – and are often large-scale and complex. They can require months of work from multiple programmers.

Anyone charged with producing an interactive television application will have problems if they expect to be able to make changes right up to the last minute – television production style. Television production attitudes will quickly result in arguments with the software programming team – and deadlines will be missed. ‘Digital television, and the interactive part of it, is complicated,’ says Mark Rock, founder of interactive television games company Static. ‘The traditional broadcast model of ‘‘shoot it and sort it out in the edit suite’’ doesn’t work. Unfortunately, the process is more akin to software production, with all the checks, compromises and order that it brings with it.’

The majority of interactive television projects will benefit from the application of techniques used to manage software projects. This chapter outlines some of those techniques. Television and web production methods are by no means irrelevant to iTV, however, and this chapter contains pointers for the use of these when appropriate.

The Real World

The software production methodology espoused in this chapter is not the way that everyone produces interactive television. In the real world, things are often done differently, for all sorts of reasons. These include:

• The drive to save money by reusing elements of existing interactive television applications. Almost all the companies regularly involved in the production of interactive television applications will reuse code, reuse graphic design templates and make sure that all new interactive television services fit into an existing infrastructure. These factory-style production operations can cut the length and the cost of all their productions after the first by 75 per cent or more. Several of the stages outlined in this chapter can be omitted, since lots of the work will have been done already.

• The drive to save money by using interactive television production tools that make it possible for non-programmers to create applications. These tools aim to provide easy-to-use graphical interfaces for producing interactive television applications. Although much less flexible than programming from the ground up, non-technical users can, in theory at least, build applications by dragging and dropping elements on-screen. Some of the production stages outlined in this chapter can be bypassed completely. There’s more on tools (both for nontechnical operators and programmers) later.

• The drive to save money by cutting corners. In the real world of interactive television production – as teams buckle under time or budget pressures or lack of experience – stages are dropped and best practice goes out of the window. User testing, in particular, is often given much less time and money than it deserves, and many applications are built without any reference to users at all. Clear documentation and communication is often sacrificed as well, in an attempt to save time. The danger of cutting corners is that the final application will actually take more time and cost more money as a result.

• People have different views about what works best and therefore do things differently. This chapter contains just one view, to help you get started.

The Production Process Step by Step

This is one possible step-by-step process for producing interactive television applications from the ground up. Like television production and software development, interactive television production can be divided into distinct stages, although everyone involved in interactive television has different names for these stages and may break them up in different ways or change the order around as they see fit. The stages are: development; specification; production and testing; and launch and operation.

Each of the stages can be subdivided again into a number of specific tasks. Depending on the size of team, the whole process typically takes anywhere between two and nine months, unless the application is very simple or the production team is able to draw on pre-existing code or interactive television production tools that remove the need for computer programming.

Stage 1: Development

The job of development is to identify opportunities, cultivate ideas and predict whether an end-product will work in the real world. This all needs to be done as quickly and cost-effectively as possible, since a number of different opportunities and ideas may need to be examined before the right one is found. The development stage can be divided into the following specific tasks:

• Spotting the opportunities.

• Developing the idea.

• Testing the concept.

• Writing the brief.

Spotting the Opportunities

There are a number of methods for making sure that opportunities are captured – such as empowering everyone involved to come up with ideas, monitoring market trends, running creative workshops aimed at spotting opportunities and so on. In particular, it’s worth:

• Closely monitoring changes to technology. Interactive television is constantly pushing technology boundaries – and each advance creates new opportunities. For example, improvements to compression technology have started to make video-on-demand a viable business proposition, after many years of failed attempts.

• Thinking mixed media. People involved in interactive television can draw inspiration from almost any medium – television and the web in particular, but also CD-ROMs, DVDs, arcade machines, radio, bank auto-teller machines, telephones and so on. It’s possible to replicate and mix aspects of these in one interactive television production. There’s the opportunity, for example, for customised video news, personalised advertising, radio-on-demand and so on. In the early 1990s, a group of television executives saw the opportunity for mixing console games with television programmes, and enhanced television games operator Two Way TV was born.

• Thinking about different types of interactivity. Interactive television applications can work in a sequence-based, narrative form (like a television programme), using one-to-one interactivity (like a web site), by drawing on community participation (like a multiplayer game) and so on.

• Looking very closely at people’s needs and wants. This is best done through user research and observation.

Developing the Concept

Once someone has spotted an opportunity, the first step is to do some thinking about ways of making the most of it. Again, brainstorming and the many other techniques that facilitate creative thinking can be useful here. The aim of concept development is to generate different ideas around the opportunity and generate some firm concepts or approaches that can be tested objectively before going into production. For example, let’s imagine you’ve identified an opportunity to sell alcohol via the television, specific approaches to this could involve building a walled garden version of an off-licence, running an auction channel for cases of wine or using late-night enhanced television quiz shows to attract drunken buyers.

Testing the Concept

Once there’s a firm concept, it’s time to get serious. Will people use it? Is there a need? Is there a market? Is it possible technically?

Concept Prototyping

One of the best ways to get to grips with the issues associated with an application in development is to build prototypes. Prototypes help everyone understand what the application is trying to achieve and can also be exploited in market and user research.

Animated prototypes can be created using web tools like Dreamweaver and FrontPage, using video editing software like Avid and Final Cut Pro, or using animation tools like Macromedia Director and Flash. Alternatively, still versions can be created using graphics programs like Photoshop or – even faster and cheaper – sketched on paper. Prototypes don’t need to be super high-quality work. The aim of prototyping is to help get a clearer idea of the options available and to facilitate discussion – preferably as quickly and cheaply as possible. Prototypes that are too well designed risk distracting people with their glitzy graphics and prototypes that take too long to build risk delaying the launch of the actual application.

Concept Market and User Research

Market and user research is about attempting to predict how successful the interactive television service will be in the real world and how it will fit into people’s lives. There are several different approaches, including formal surveys, in-depth interviews, focus groups and usability testing. It’s surprising how much hearing people say how and whether they would use an interactive television application can help coalesce thinking and generate more ideas around a concept. Even just observing and talking to colleagues or very small numbers of customers can be illuminating. If the skills to do market and user research aren’t available in-house, there are a number of specialist agencies that can perform the work to order. There’s more on usability testing in Chapter 5.

Preliminary Financial Forecasting and Analysis

At this stage, some preliminary work on the financial side can help kill off no-hope concepts and highlight important issues. Financial forecasting work relevant to interactive television includes:

• Reading research papers that predict the value of the target markets.

• Performing competitor analysis.

• Completing outline cost and benefit investigations.

It may also be necessary to do a preliminary budget, outlining the likely costs for moving the interactive television project through the specification stage.

Technical Assessment

The aim of technical assessment is to work out whether the planned application can be built and, more importantly, whether it can be built with a reasonable amount of money. The technical assessment flags up areas of particular risk, so the production can be structured to circumvent them. If, for example, the concept is based on using a brand new search engine technology, some extra work may need to be done during the specification phase on fall-back options, should the technology not work as hoped.

Writing the Brief or Pitch

Once the concept has been tested, it should be possible to write down a definition of the application. Known as the brief or outline, this is a statement of the central aims and aspirations – preferably on less than one side of A4 paper (much longer and people aren’t likely to read it). These also sometimes draw on a key insight about the potential viewers or on a clearly identified need that the viewers have.

Interactive television briefs are sometimes worked into pitches. Pitches explain the application and define, in an easy to understand way, what the investor or commissioner is likely to get out of the proposed interactive television service – and roughly what it will cost. Interactive television pitches often go hand in hand with regular television programme pitches.

The person or team in control of the money decides at this point whether the interactive television application can go onto the next stage – specification.

Stage 2: Specification

The pitch or brief has been accepted and permission has been given for the application to be specified in detail. Now a company or individual involved in interactive television production will have a range of options for going forward. The brief can be sent to an interactive television production agency to work on. Or some work can be done in-house and the rest completed by outsiders. Or everything can be done in-house. The various routes all have their advantages and disadvantages.

Production agencies, like Wheel and AKQA, can pass on the benefits of economies of scale by reusing work done for other clients. They also take responsibility for managing risks, like the use of cutting-edge technology. But using agencies keeps all the experience of building interactive television outside the company that initiated the project and could end up being more expensive if more applications need to be produced later.

With a hybrid approach, companies with particular areas of expertise can be bought in for particular elements of the production. For example: the project could be managed in-house; a specialist agency like Di3 could be used for the technology implementation; a branding agency, like Lambie-Nairn, used for the artwork; and a usability agency, like Serco Usability Services, used for the navigation design. One problem with this approach is that involving multiple companies can easily make production more complicated and, if deadlines start being missed, it can be difficult to establish which company is responsible. (This problem should never be underestimated on complex interactive television projects – it occurs frequently.)

Going it alone, on the other hand, keeps expertise within the company that initiated the project and provides a foundation for future interactive television development. In particular, code can be used on other services later. It does, however, mean that recruitment may be necessary and people may have to venture outside their normal experience and skills (although, because most interactive television technologies are quite new, everyone has had to do this to some degree).

Whatever decision is taken about whom will be involved, it needs to be clear at this point who is in charge. Whether it’s a producer, a project manager or someone else is not important, as long as there is someone who is driving the project forward.

Step one for this person: start the specification process. The more time and effort spent on specification, the more likely the production stage will deliver the right application on time. Some interactive television productions allocate much more time to specification than to production and testing. Although this can be difficult to justify to the bosses or clients, who are waiting to see something on-screen, it can pay off if problems are identified and dealt with before they arise. Also, the time spent on specification should reduce the amount of time spent on production – thereby saving money. The tasks involved in specification include:

• Deciding the project approach.

• Getting hold of project management tools.

• Identifying stakeholders.

• Collating requirements.

• Specifying the service.

• Producing the project plan.

• Producing the budget.

• Recruiting the staff.

The following pages cover each of these in detail.

Deciding the Project Approach

There are a number of different ways of managing projects. Two popular options, often used for interactive television applications, are the waterfall (also known as the staircase) approach and rapid application development.

Waterfall (Staircase) Projects

The waterfall approach splits the task into several key stages. The idea then is that each stage is pretty much complete before the next one is started. Presented graphically, as time against the stage of development, it looks like a waterfall or staircase.

The waterfall approach works well if the definition of the final product is unlikely to change during the course of the project and if the technology is likely to work as expected. The approach provides a great deal of clarity regarding expectations and deadlines, which can easily be communicated and understood across an organisation.

The system breaks down a little if the production team isn’t quite sure what viewers are going to want and how they are going to use the interactive television service. Or if it’s not entirely certain whether a given piece of technology will be able to deliver all the desired functionality.

One variation of the waterfall model adds a prototyping stage to the beginning of the process, to help lock down the correct specification before production work kicks off. Another, called rapid application development, takes this even further by making prototyping and continuous iteration a core part of the project process.

Rapid Application Development

Rapid application development is ideal for interactive television applications where it’s not entirely clear how and whether people will use the service or if there are uncertainties with any aspects of production. It follows exactly the same path as the waterfall model. But, rather than attempting to define the specification at the beginning and then have the whole product working before launch, it aims to deliver the core functionality in the first iteration and then continuously evolves it from there. It works by repeating all the stages of the staircase model many times, each time adding new functionality.

As each version is completed, features are added or removed depending on what is learnt about the usage and the technology involved.

Rapid application development requires a high level of feedback between viewers and the specification-setting process for each version. As each version is completed, viewer’s reactions are checked – and used to help define the next iteration’s functionality. It’s not always necessary to launch the end-product of a stage into a live environment, as user testing can be done on prototypes.

The disadvantage of rapid application development is that the coding can be more complicated. Programmers are expected to add and remove functionality with each version, rather than just creating one final version.

The first cable company in the United Kingdom to launch digital cable television services used a form of rapid application development. In 1999, Cable & Wireless Communications started with a version of its digital television platform that only had a simple electronic programme guide. The next version extended the EPG functions and added a walled garden. In contrast, rival United Kingdom cable operator NTL attempted to launch a fully functional enhanced service all in one go. It never managed to get it to market with its initial specification – wasting millions of pounds in the process.

Closely linked to the rapid application development methodology is user-centred design. This is based on the idea that users need to be consulted all the way through the production process, and that the more prototypes and designs that are tested with users, the better. There’s more on this in Chapter 5.

Getting Hold of Project Management Tools

Bigger interactive television projects can benefit from software tools designed to help manage deadlines and responsibilities. The ubiquitous Microsoft Project is a popular choice and it can be used for lots of different styles of project. Alternatively, there are specific project methodologies, like Prince and Rational Unified Process. These come with software tools, training and support. For small interactive television projects, or for project managers who want to avoid spending all their time updating the software tools, it’s not unheard of for people to rely on whiteboards and Post-it notes as project management tools. It’s best to use whatever you feel most comfortable with.

Identifying the Stakeholders

It’s big companies or agencies working for big companies that often produce interactive television. Producers in big companies in particular need to spend time identifying the parties from within and outside the company that could have an interest in the application.

‘I always make sure that I involve all the key people early on in a project,’ says Innes Ballantyne, senior producer in the BBC’s interactive television production team. ‘It prevents trouble happening further down the line, when things are expensive to change.’

Not consulting early on can result in someone, who later proves to be crucial, either not co-operating or, even worse, actively trying to sabotage the launch. Actual sabotage may sound a little difficult to believe. However, just think about how you would react if you were a brand manager who had just spent millions building the company brand and you saw a completely off-brand interactive television application about to be launched. Or if you were a technology team manager receiving a last minute request to use one of your busy specialists on an interactive television application you’ve never heard of. This kind of thing can and frequently does trip up interactive television projects.

Likely stakeholders in interactive television applications include:

• The business development team.

• The marketing department.

• The television production team (if the interactive television application supports a television programme).

• Brand guardians.

• Customer service and call-centres.

• IT support.

• Technology.

• Operations.

• The team that deals with regulators (particularly if betting or overlays to television are involved).

• The legal team (if, for example, certain EPG or other technologies are involved that may be covered by patents).

• The various parties involved in the chain from the originator of the project to the viewer – including TV channel owners and platform operators.

Collating Requirements

It’s easier and faster to work with fewer stakeholders – but there are ways of avoiding committee thinking even with lots of stakeholders. The first step is to get everyone involved in the collation of requirements.

A requirements list is a collection of everyone’s view of what they think the service should, in an ideal world, deliver. It will, among other things, cover which interactive television platforms the service needs to work on and how many viewers it will need to support.

Requirements lists are generally broken down into several sections, such as commercial requirements, technical requirements, usability requirements and so on. It’s also worth specifying the requirements for how the success (or otherwise) of the application will be judged – that is, deciding what needs to be measured to prove the application was worthwhile. This could be revenue, page views, numbers of users and so on.

The requirements should not specify any aspect of the solution, just what the application should be able to do. It can be helpful to do some more directed creative work, such as brainstorming, on the requirements and to try to think ahead about what the product will need to do when it is launched (which could be several months away), not what it needs to do at the time the requirements are being set. The requirements, of course, should always be created with reference to the end-users.

Collating a requirements list gives everyone involved the chance to make a contribution – and will, hopefully, highlight any mismatched expectations.

Specifying the Service

Once the requirements are understood, the next step is to define the functionality that will be delivered and how this will be done – the specification. Unless there is an infinite budget and infinite time available, it’s quite likely that it won’t be possible to deliver all the requirements straightaway. Therefore, ruthless decisions need to be made about which of the requirements will be incorporated in the first version of the product and which won’t.

In most companies, this can be a reasonably fraught process, as everyone has a slightly different view of what the service should be about. Also, if it’s been used, user research can sometimes be interpreted in different ways. Heated argument can ensue.

With this in mind, it’s useful if there’s one person who has the final say on what will be in the specification and what won’t – ideally the interactive television producer or project manager in charge of delivering the finished product. Research on team structures for complex projects has shown that those with strong leaders, who take the ultimate decision-making responsibility, perform better. Having a strong leader also avoids endless meetings arguing about specification – the leader can make decisions there and then, after consulting his or her team.

There are other ways to ease the process:

• It helps if everyone has a reasonable understanding of the technical potential of the different platforms for which the service is intended. Requirements that are clearly not possible or outrageously difficult (like putting true video-on-demand on the United Kingdom’s terrestrial television transmission network) need to be removed straightaway, or creative work needs to be done on alternative ways of framing the request. For example, is it really video-on-demand that is required or is it just that information needs to be accessible by viewers quickly and easily? Training sessions can be held explaining what’s technically straightforward and what isn’t.

• It helps if everyone feels involved in the decision making. One classic way of doing this is to have stakeholders rate each of their requirements as either ‘must have’ or ‘like to have’. This immediately gives the people responsible for implementing the service an idea of the relative importance of each request, as well as transferring some of the responsibility for decision making to the people setting the requirements.

• Use, as much as possible, user research data to help make decisions about requirements.

The output of all this work honing the requirements is a functional specification.

Functional Specification

The functional specification is an expression of, in the clearest and simplest language possible, what the application will be able to do. It’s a bit like what you would produce if you had to explain the application to an alien.

The functional specification is used as the primary reference point for building the application. If it’s not in the functional specification, it won’t be done. As with the requirements, functional specifications do not define any aspect of the technical solution, only what the end result is. For example, a functional specification item for a car is not that it has four wheels; it is that it should be stable and move along near the ground. If the people building the service come up with a better way of doing it – anti-gravity jet boosters in a car, for example – they should have the flexibility to build it that way. The person writing the functional specification also doesn’t need to have an in-depth technical understanding and can concentrate on what the service is meant to do.

Television Production and Project Management Cultures Don’t Always Mix

Ideally, each element of the functional specification should be discrete, to make it easy to add and remove specifications as necessary. Having said this, some people write functional specifications using prose paragraphs, rather than in a list format.

Functional specifications can run to hundreds of pages and thousands of items – especially if the service is very complex or if the person writing the specification doesn’t trust the person building it (which is often the case if one is paying the other). However, it’s possible to keep functional specification lists short by repeatedly rewriting and reducing to the bare bones. It should be possible to describe most interactive television services in less than 100 functional specification items, even less if a rapid application development approach is being used.

Functional specifications cover every aspect of the application, everything from the type and frequency of advertising it will need to support, to the number of content updates required, to the granularity of viewer usage measurement that is needed.

Storyboard and Graphic Design Brief

A functional specification is often accompanied by a storyboard. This is a pictorial representation of the navigation and functionality of each screen. It does not include any graphic design work and does not define the exact positioning of elements on the page. Storyboards can be sketched on paper or created using the graphics options in programs like Word, PowerPoint, PhotoShop or Illustrator. A specialist program, called Visio, is also excellent for creating storyboards, although it can take a little while to learn. Usability research work and prototyping can be used to help define the best storyboard (see Chapter 5).

Along with the storyboard come the design brief and a navigation map. The design team use the design brief as a guide for creating the graphics for the application. It specifies the objectives that the designers will need to address and has details about the target viewers. The navigation map is a high level representation of all the screens within the application and how each is connected.

A producer or specialist in user-interface design usually creates the storyboards, navigation map and design brief with as close reference as possible to the end-users.

Technical Specification

Once most of the functional specification and storyboard has been completed, it’s time for a technical expert to define the technical specification. This describes exactly how the application will be built.

The main part of the technical specification is the technical architecture. This outlines, usually pictorially with supporting text, how the various bits of technology, including all the major pieces of hardware and software, will work together.

The complexity of the technical architecture depends on a number of factors, such as:

• The middleware system being used.

• The type of interactive television (enhanced television and channel switching, because they involve video channels, are often much more complicated than walled garden services).

• The back-end functionality required (transactional capability and multi-player gaming both add to the complexity).

• The infrastructure already in place (some walled garden services will fit into an existing infrastructure, so may need a relatively small amount of work on technical architecture).

In addition to the technical architecture, the technical specification will include documents that detail the types of computers, mutliplexers and other electronics, the technical details of the set-top boxes and middleware systems, and details of the security systems. There may also be guidelines for the structure of the computer code and the way it should be marked up by the programmers, with rules for version control. Version control helps programmers share files without mixing up their work (there are off-the-shelf products that manage version control by forcing programmers to formally check code in and out of a central storage area, just like a library).

Finally, the technical specification will define the content management system (the software that shifts content around platforms and manages advertising) and any customer relationship management system (used to keep track of customer information).

Producing the Project Plan

The project manager can now work out exactly how long each stage of production should take. It’s usually better to have people define their own work schedules. This makes it much more likely that they will buy into the deadlines. For certain interactive television applications, parallel development may be possible. For example, it might be possible for work on the back-end functionality (such as customer databases) to take place at the same time as the coding of the application, rather than waiting for the coding to be finished. Parallel working is common when coding in HTML and JavaScript.

Watch out for underestimating particular stages of production in the project plan. In particular:

• Graphic design invariably takes longer than expected, particularly if the designers are new to interactive television.

• Plenty of time needs to be allocated to integrating finished chunks of code with each other and integrating the finished application with the back-end system and platform.

• Getting the application to work on different types of set-top box can be enormously time-consuming, even if the middleware is the same. Middleware is not always perfect at making differences between set-top boxes invisible to applications – and some tweaking may be required.

• The implementation of systems to manage multiple video streams can take much more time and effort than the coding of the application itself.

The project plan should also be used to plan for slippage. Contingency options can be placed around the parts of the schedule that look uncertain. These include putting buffers in the schedule, allocating time to set up alternative staffing options, and allocating time to locate and brief alternative suppliers. Do not fall into the trap of secretly planning for slippage by mentally preparing to squeeze the time available for the last stage of production – testing. Testing is crucial for interactive television (see the testing section later in this chapter).

Producing the Budget

Once the functional and technical specifications have been completed, it’s money time – the budget. There are lots of questions to be resolved during the budget process, all of which can make a dramatic difference to the final figure:

• Should computers and other equipment be leased or purchased outright? It’s easy to lease computers but using them for a few months can cost more than buying them.

• Is the production eligible for tax breaks or grants? Television and film productions sometimes get tax breaks that may also apply to interactive television, while various European governments and universities have helped pay for some pioneering interactive television work.

• What contingencies should be added to the budget? It sometimes makes it easier to manage the finances if the budget has contingencies rather than overestimated costs.

• Are there any economies associated with using the same technology for multiple applications or reusing programming code – or even going into partnership with another interactive television producer? Almost every company involved in interactive television reuses code between applications and most new interactive television applications are designed to be reusable and extendable (the costs of subsequent services based on the same code will then be much lower).

• Are all the costs covered? Often forgotten are the costs of a content management system (used to update and develop the service after launch), administration costs (like phones and office stationery) and post-launch costs (like a project review and tweaks to the code).

Ideally, each part of the team that will be spending money should come up with budget figures for their area and be held to account for under- and overspends.

After the project plan and budget are complete, it’s worth reviewing the work so far. Is the project still viable? Are the costs appropriate? Will the benefits be delivered quickly enough? If not, it might be that the functional specification will need to be simplified or the technical specification reworked. If everything still looks good, then there’s one last job to be done before production begins – assembling the team.

Recruiting Staff

A large part of the cost of interactive television productions goes on human beings. It is theoretically possible for one person working from home to produce a credible interactive television service. However, applications that need to be high quality, compelling and launched to a strict deadline often require a range of people with different skills. Platform operators usually have the largest production teams – 200 people or more is not unusual – especially during the early phases of development. Companies involved in developing a single application for the first time will typically need anywhere between three and 30 people, depending on the complexity of the application and target platforms.

Staff with interactive television experience can be recruited using intermediaries, like Tara West Recruiting and Recruit Media, or directly using advertising in trade publications such as, in the United Kingdom, Broadcast, New Media Age and the Guardian Media Supplement. Another option is to place advertisements on interactive television discussion groups (like www.broadbandbananas.com).

Although roles will be broadly the same across companies, interactive television job titles can vary dramatically. It’s also not unusual for people to cover web, mobile phone and television production duties, along with their interactive television work.

In-depth: An Example Interactive Television Budget

In-depth: The Interactive Television Production Team

Stage 3: Production and Testing

Now the serious work begins:

• Designing the graphics.

• Building the technical architecture.

• Coding the application.

• Managing change.

• Managing deadlines.

• Performing rigorous tests.

Designing the Graphics

Using the storyboard and design brief, the design team creates the graphics. For initial graphics work, most interactive television designers use a personal computer equipped with Adobe Photoshop, although some prefer the sketching freedoms of Illustrator. There’s also the considerably cheaper PaintShop. Designers from a television background sometimes use television graphic design equipment, such as the systems from Quantel and Discreet. However, these are expensive to buy or hire and don’t always output graphics in the right format for use in interactive television.

Whatever software is used, it should be connected up to a television as well as a personal computer monitor. A personal computer monitor provides a very poor reference point for television design and should not be used in isolation. PC-to-TV signal converters cost between £100 ($160) and £10 000 ($16 000) or more, depending on the quality and flexibility required.

It’s worth bearing in mind that even viewing interactive television graphics on a television set connected to a personal computer is still only an approximation. The final design will be rendered by a set-top box for display on television, not via a personal computer – and set-top boxes sometimes work in different ways with graphics. To get round this problem, it’s worth the design team or the developers periodically putting the graphics in a format that can be sent to a set-top box connected to a television for viewing. Most middleware suppliers provide set-top box kits that can be connected to personal computers for this purpose.

The designer can be left alone to produce the final design. However, a more collaborative approach improves the chances of the final design being spot on. One way of doing this is for the producer, in the first instance, to ask the design team to produce a number of different designs (known as mood boards). They can produce three to ten completely different designs, all of which fulfil the brief.

These mood designs or prototypes give the designer and producer a framework to discuss which approach works best – and can also be shown to other interested parties (potential users, for example). (Note for designers: make sure you like all the designs you come up with, because people will invariably want to use your least favourite.)

Once a decision has been reached, the design team can do the detailed work required to finalise the graphic design. Usability research will be useful to get the designs just right (see Chapter 5). Once the final design has been agreed, the graphics for each page can be cut up into constituent elements (such as the background, the titles and the different navigation icons), converted into a format that the middleware will support (for example, jpeg or gif) and then sent to the developers for incorporation into the application. The designer or developers should also optimise the graphics, using special compression software (provided with packages like PhotoShop and as part of the tool set provided by middleware suppliers). This software cuts out extraneous information in order to keep the file size down to an absolute minimum.

Building the Technical Architecture

One problem interactive television productions often have is that pieces of equipment take some time to be delivered or set up – or both. For example, leasing fibre-optic links for fast connectivity between an office and an interactive television platform operator can require two or three months lead-time. Similarly, the content management system is likely to need to be running as soon as possible, as the operations staff will need to be trained. And video feeds can also take several weeks to build and test. The only way round this is to complete purchase orders and crucial technical work as early as possible in the project.

Content management systems that deal with synchronised enhanced television can be particularly complicated: both to build and use. With these, it’s worth considering buying either off-the-shelf products, such as Two Way TV’s synchronisation solution, called Ark, or multi-platform authoring tools, such as IDP from RegieLine, which includes components for dealing with enhanced television synchronisation on various platforms.

There’s also the issue of installation and support. With interactive television lots of complex systems are involved and these may not have been used with each other before. For this reason, it can be worth considering outsourcing the installation and support of back-end systems. Just ask your friendly middleware supplier or platform operator.

Coding the Application

This is usually one of the most time-consuming parts of the production. There are a wide variety of tools that can be used to help with the coding. See the production tools section later in this chapter.

It’s important that the developers understand what is expected from them and that they can get on with their work without interference. However, the project manager will need to closely manage change and deadlines during the coding process.

Managing Change

The biggest problem for most technical projects – from producing interactive television to building ships – is change. It’s almost always the case that, after the specification is set, changes will be required. This could be because of: external factors, such as a competitor launching a similar service; technical problems; or because someone comes up with an unmissable idea for improving the application. Whatever the reason, changes need to be controlled by:

• Accepting and rejecting change requests with reference to all the people who will be affected. An efficient way of doing this is to set up a project change group. This will meet on a regular basis and should have representatives from each team involved in the project.

• Communicating changes to everyone involved. This can be done by making sure that everyone shares one functional specification document – perhaps by keeping it on a shared server. When it is changed, everyone can be informed by email.

• Recognising that some changes will have an impact on schedule, cost, scope or quality of the project (and it will not always be easy to predict the level of impact).

Managing Deadlines

One of the key tasks of the project manager is to warn everyone if deadlines are going to be missed and identify the people who are likely to miss them. This requires good communication. The project manager should be in at least weekly contact with people working in the different project areas. Some people find it difficult to estimate how long their work will take, either because they are keen to please or through lack of experience of interactive television work. Progress can also be particularly difficult to fathom out if the project manager isn’t familiar with the technologies. In both these cases, asking searching questions is good. For example, rather than asking ‘will you meet your deadline?’, it can be better to ask, ‘what are the steps you have to go through to reach this deadline?’ and ‘what are the possible problems?’, and so on.

Performing Rigorous Tests

Television programmes are usually viewed once to check for problems caused by damaged videotape, mismatched light levels or errors introduced in the edit suite (such as single frames missing from the programme, known as flash frames). That’s more or less the extent of the testing process.

There’s not much testing required for television programmes because the programme itself is very unlikely to cause any problems with the viewer’s television set or with the television channel. And television production is so reliable that faults tend to arise only within the programmes themselves – sets falling down, presenters being attacked by animals or other amusing hitches – not with the delivery technologies.

In contrast, most personal computer software consists of a set of complex components that need to work in a range of circumstances, so software applications for personal computers are usually put through a barrage of tests. Despite these tests, personal computers still crash, software sometimes fails to work as expected and, even when working properly, some software is still very difficult to use. Personal computer users seem almost reconciled to these problems – at least for the moment.

The problem with interactive television applications is that they have all the complexity of personal computer applications but are working on a delivery platform that does not normally have technical or usability problems. Viewers’ televisions don’t crash, the remote control always works (unless the battery has run out) and, unlike the internet, the picture is unlikely to start running slowly at peak viewing times. Any interactive television service that causes problems with the television set or makes it do unexpected things is unlikely to be tolerated by viewers – especially if they are trying interactive television for the first time and are still learning about what it has to offer. They will not want to come back for more punishment.

What’s more, as well as putting potential customers off, technical problems can result in hefty charges from platform operators. It’s the platform operators that usually have to field complaint calls – even for interactive applications for which they are not directly responsible. It can cost a call centre £3–5 just to deal with a call. If an application causes a technical problem, the platform operators’ call-centre may need to explain over the phone to thousands of viewers how to reboot the set-top box. They may even need to send maintenance engineers out. The costs of this may be passed on to the owner of the offending application. Sky Digital in the United Kingdom, for example, gets interactive application providers to agree to millions of pounds worth of cost liabilities, before they are allowed onto the platform. For these reasons, interactive television testing has to be comprehensive and formal.

For enhanced television services, it may be necessary to build a system to mimic the broadcast play-out architecture, so that synchronised triggers can be tested. Alternatively, testing can be completed live on the television channel that the enhanced television application is supporting. In this case, the graphics that prompt users to take part aren’t displayed. Only the testing staff will know when to press the button on the remote control to start up the application.

Stage 4: Launch and Operation

Moving to the final stage:

• Launch.

• Operation and development.

Launch

Many interactive television services use soft launches. With these, the application is launched but not publicised. This allows a few days or weeks to iron out minor problems, with less people using the service than would be expected with a full (hard) launch.

With both soft and hard launches, it’s best to avoid launching on Monday or Friday, as it can be difficult to sort out any last minute or post-launch problems over the weekend. It’s also worth considering whether it’s possible to launch during non-peak television viewing times, so that if something does go wrong, it’s seen by less viewers (television is generally watched more in the evening and weekends than during office hours or late at night).

As part of the full launch, there will certainly need to be some kind of promotional work carried out. Direct promotion on-air by television presenters is one of the most effective techniques (see the marketing and promotion section in Chapter 3 for more on this).

Operation and Development

After the launch party, it’s easy to make the mistake of thinking that the job is done. Interactive television isn’t like that. First, it’s very rare that it’s not possible to improve an application. Interactive television production is reasonably new territory for most people and producers rarely get it right first time. Second, there are always problems after launch. In terms of problems that crop up, the content and operations teams should feed customer complaints and other issues into a master list. It’s usually worth arranging some more user testing of the live service, preferably in people’s homes and with reference to competitors. Tweaks may be necessary – nasty surprises are possible. These could include:

• Viewers having difficulty finding the application. Electronic programme guides and interactive service menus have lots of entries and some are badly organised. The right kind of promotion is crucial. It may even be necessary to educate viewers about exactly which buttons to press by using television advertisements, direct mail or some other form of marketing communication.

• The application may fail to excite viewers in a real-world context. However good the market and user research, the competition from great movies, great television programmes and other exciting interactive television applications could prove too strong. In this case, some more work needs to be done on the proposition and how it ties in with people’s daily lives and needs.

There should also be careful scrutiny after launch of the results of the measurement systems that have been put in place – be it to monitor revenue, viewer numbers, usage figures, or other criteria. Is the application fulfilling the original brief? How is it progressing over time (some interactive television applications get used once or twice, then never again)?

Whether tweaking or major revisions are required, the next phase of development should be approached with the same systematic process that applied to the launch. There needs to be an understanding of costs and benefits plus, if possible, market and user testing. In the fast-moving interactive television world, competitors will quickly usurp applications that aren’t constantly looking to the next step forward.

Production Tools

There are a variety of tools that can help with coding of interactive television applications. Some are effectively complex development environments, which are useful only for computer programmers. Others are designed to help non-technical people produce applications without the need to learn computer code.

As a rule, production tools for non-technical operators employ some kind of PC-based graphical interface to make production easier – for example, by allowing elements of the application to be dragged and dropped together on-screen. However, these tools usually have very limited functionality and the finished application is likely to run slower than if created by programmers from the ground up. Consequently, production tools for non-technical users are generally used to create very simple applications or to make minor adjustments to existing applications. Many companies don’t use them at all.

It’s also worth bearing in mind that even the production tools designed for nontechnical people are not always very easy to use – and certainly not as easy to use as the internet production tools available in the high street. The usability of interactive television tools is likely to improve as more time and effort is spent on their development.

This section outlines the main tools that interactive television producers are likely to encounter. These can be pigeon-holed into three broad and overlapping categories:

• Middleware-specific tools.

• Virtual machine- and presentation engine-specific tools.

• Author once, publish-to-many tools – designed to produce services that will work on two or more interactive television platforms and, sometimes, across multiple media.

Middleware-Specific Tools

There are many different middleware systems. They come and go with changes to technology and as companies start up or go out of business. Outlined in detail here are the middleware-specific tools used for the three most important middleware systems in the United Kingdom, those used by the three main platforms: Sky Digital satellite, NTL and Telewest digital cable, and digital terrestrial. The middle-ware systems respectively are: OpenTV, TV Navigator and MediaHighway.

The official standard of digital terrestrial interactivity in the UK is actually an MHEG-5 engine, not MediaHighway. However, MediaHighway hosts the MHEG-5 engine in many digital terrestrial television (DTT) set-top boxes. Other DTT set-tops and televisions run the engine using other middleware systems or using specially written code.

OpenTV Tools

Overview

American manufacturer OpenTV produces a middleware system that is popular with platform operators around the world. It is installed in millions of set-top boxes – including those owned by Sky Digital in the United Kingdom. Most OpenTV applications are created using a version of the computer language C, although the OpenTV middleware can also support various virtual machines and presentation engines.

There are three key methods for creating applications specifically for OpenTV:

• The Software Development Kit.

• OpenTV Publisher.

• OpenTV Author.

Using the Software Development Kit

For complex applications, like EPGs, games and enhanced television, it’s necessary to have a high level of control of the C code. These applications need to draw on all the power of the set-top box, and programmers usually need to find clever ways of making them run as fast as possible in the smallest amount of memory possible. To expedite this, OpenTV provides a programming environment called the Software Development Kit (SDK).

The SDK helps programmers create the exact version of C that the middleware will understand. It has a user-interface to aid programming tasks (by colour coding commands, for example), a debugging tool (for identifying problems) and provides commands to access set-top box functions – such as manipulating video streams, managing encryption and communicating with other programs in the set-top box.

OpenTV’s Target Decoder product is used to view applications in progress on a television screen attached to a set-top box and personal computer.

Using OpenTV Publisher

Some interactive television applications are straightforward. They don’t need to run very fast, because they are performing simple operations, and they don’t need to squeeze into a very small amount of memory, because more than enough is available anyway. Most walled garden applications and some digital text services fit into this category. To help create these applications, OpenTV has produced OpenTV Publisher.

Using OpenTV Publisher, non-technical staff can build services using tools normally used in web production. The application pages are built using OpenTV markup language (OML). This is based on extensible markup language (XML), a system for sharing different types of information between computers – anything from musical notation to the contents of an interactive television screen. OpenTV Publisher deals with the problem of converting this information into the C code that the middleware will understand.

Using OpenTV Author

OpenTV Author is modelled on television and multimedia authoring tools like Avid, Media 100 and Director. It provides a graphical user-interface for non-technical production staff to create interactive television services with a minimal fuss by dragging and dropping page elements on the screen.

Applications are defined in terms of scenes. Scenes are the equivalent of pages on a web site. They structure how viewers move around and experience different parts of the service. Each scene can contain a number of OpenTV Author gadgets. These perform functions like drawing a shape on-screen, animating a graphic, playing an audio file or putting up a timed icon on-screen.

Like OpenTV Publisher, applications written with OpenTV Author are less flexible and likely to run a bit slower than would be expected had they been written using the SDK.

TV Navigator Tools

Overview

United States-based company Liberate (originally an offshoot of web browser company Netscape and database company Oracle) produces TV Navigator. Both the big digital cable operators in the United Kingdom (NTL and Telewest) use it.

TV Navigator was created with internet technologies very much in mind. By supporting internet standards, like HTML and JavaScript, Liberate hopes to make application development cheap and easy. This is because there is a large pool of people with knowledge of internet production and a whole range of production tools and resources. Some versions of TV Navigator, generally running on more powerful settop boxes, also have the capability to support a version of the animation engine Flash. TV Navigator can also run a variety of virtual machines and presentation engines.

TV Navigator consists of two key parts: the TV Navigator client and the TV Navigator Connect Suite. The client sits on the set-top box and controls the hardware in the same way other middleware systems do. The TV Navigator Connect Suite sits on a server at the platform provider’s office. The most important part of the TV Navigator Connect Suite is the transcoding server. This converts content into formats that the software on the set-top box can understand. It also caches data, improving the retrieval speeds and processes encrypted information. When it encounters web pages it converts them into formats better suited to television by, for example, lowering the level of colour saturation on graphics.

There are two key methods for producing Liberate applications:

• Using an off-the-shelf programmers’ text-editing tool (like BBEdit or UltraEdit).

• Using an off-the-shelf graphical production tool designed for web sites, like Dreamweaver.

Using Programmers’ Text-Editing Tools

Most complex TV Navigator applications are hand-coded, which means they are written into off-the-shelf text editors like BBEdit, UltraEdit or, even Notepad. These have functions to help programmers quickly identify, search and replace code.

Most TV Navigator applications in the United Kingdom are written in HTML and JavaScript. JavaScript is designed to help make web pages more interactive – anything from animating page elements to performing calculations. To complement the standard JavaScript functions, Liberate has developed special JavaScript extensions that can be used to control set-top-box-specific tasks like changing channels and displaying television-style graphics. For example, there’s the TvChannel object, which can be manipulated to change channels. There’s also a particularly useful JavaScript extension for manipulating on-screen content, called dynamic tables. This allows user-driven actions on one part of the screen to result in changes to other parts of the screen, using straightforward JavaScript commands – great for television-style animations, tickers and games. (Note: platform operators, to avoid applications breaking their customers’ set-top boxes, sometimes restrict iTV producers’ access to some of the TV Navigator functions, such as channel changing.)

To help producers and programmers check how an application in progress looks on-screen, Liberate has created the TV Navigator Emulator, known as Emmy. This reproduces all the elements of a typical TV Navigator interactive television system but on a personal computer. It does this by mimicking the TV Navigator client (which normally runs on a set-top box) on the personal computer. The computer is then connected, via the internet, to a mock TV Navigator Connect Suite and transcoding server held at Liberate’s office or with a platform operator. Producers can then view applications in action on a personal computer, without the need for a set-top box. Emmy is available as part of TV Producer Studio from Liberate and from some platform operators (like NTL and UPC).

Liberate and platform operators also provide set-top boxes, which can be connected to the internet, to test applications.

Using off-the-Shelf Graphical-Interface Web Production Tools

Internet production tools like Dreamweaver and FrontPage are rarely used to create complicated TV Navigator applications. They risk adding superfluous code, which could slow down the speed of the application. They also do not offer the flexibility and control that most programmers require. However, they can be useful for simpler applications and prototypes. In fact, Liberate has worked with Macromedia to develop special additions to the Dreamweaver software so it can produce TV Navigator-compliant pages. These additions can be used to manipulate some of the JavaScript extensions that Liberate has written for TV Navigator. Liberate provides Dreamweaver as part of its TV Producer Studio package of authoring tools for TV Navigator.

Be warned: regular versions of Dreamweaver, without special extensions, are of limited use for creating TV Navigator applications. Also, platform operators often make changes to the parameters of the version of TV Navigator running on their systems – changing the size of the screen area or limiting the available functionality. If this is the case, even a TV Navigator-customised version of Dreamweaver may be of limited use – and it may be easier to hand-code the application.

MediaHighway Tools

Overview

MediaHighway is used as the middleware in some of the digital terrestrial television set-top boxes and televisions in the United Kingdom (including the set-top boxes of the defunct ITV Digital) and on Canal Satellite, the French digital platform. French company Canal+ Technologies (part of Thomson) owns it. The middleware can support a number of different virtual machines and presentation engines.

Using the Application Workshop

The Application Workshop is a development environment for creating MediaHighway applications using the programming language Pantalk. The environment consists of tools for creating user-interfaces, editing graphics and debugging the programming code.

Tools for Other Middleware Systems

As well as OpenTV, TV Navigator and MediaHighway, there are a variety of other middleware systems, each with its own tools.

Virtual Machine- and Presentation Engine-Specific Tools

The advantage of virtual machines and presentation engines is that applications written for them should be interoperable across platforms. The theory doesn’t always live up to the reality, unfortunately, and applications often need to be tweaked to work on different platforms and set-top boxes.

Java for Multimedia Home Platform (MHP) tools

Overview

Depending on the version, MHP includes both HTML and JavaScript presentation engines as part of the standard. However, the core of MHP, known as DVB-J, specifies a virtual machine that supports a version of the Java programming language. Java is a powerful language designed to run on virtual machines and is ideal for creating interactive television applications.

Using the Java Development Kit

Java is typically created using programming environments, like the Java Development Kit or Visual Cafe. These help programmers write and debug code.

Using Graphical-Interface Tools

There are a number of production tools designed to help non-technical people produce Java code for MHP-compliant middleware. One example is AltiComposer from Alticast. This has a graphical user-interface where applications are created by dragging and dropping constituent elements together.

The basic unit in AltiComposer is called a scene. This contains all the pages and interactivity involved in the application. After the scene is created the shots and actors are added. A shot is comparable to a page on a web site, and is the basic unit for navigation. Within shots are objects and functions known as actors. Actors can be set to behave differently depending on what the viewer is doing. Examples of actors include animating a graphic or putting text on-screen after a set viewer action.

Expert programmers can also use Alticast to save time on Java coding tasks.

WML tools

Overview

A number of companies have written presentation engines that work with the mobile phone markup language WML. WML is based on XML (extensible markup language). It is particularly useful in the interactive television environment because it takes up very little bandwidth, which makes it relatively cheap to transmit alongside an existing television channel. Sky Digital in the United Kingdom has a WML browser running in OpenTV called WapTV (WAP is a phone data-transfer standard that utilises WML). Rather than having to broadcast code that the OpenTV middleware can understand, all the application producer has to do is send WML in the right format for the WapTV browser to understand.

Developers can use off-the-shelf WML management and editing tools or can work with specialised software, like that provided by 24X Rock Technology. This offers an easy to use graphical user-interface for creating WapTV services. Testing is done on specially adapted set-top boxes. Using WML makes it particularly easy to draw in content from existing web databases, particularly if the content is already in XML format.

MHEG-5

Overview

MHEG-5 is a standardised way for storing, exchanging and displaying multimedia content, sanctioned and developed by the Multimedia Hypermedia Experts Group – an organisation set up by the International Standards Association (ISO). The language focuses on the presentation and manipulation of on-screen elements (in this sense, it is similar to JavaScript, although the language itself is quite different). As previously mentioned, it is the standard for digital terrestrial television interactivity in the UK.

Using Text-Editing Tools

Most development for MHEG-5 virtual machines is done using off-the-shelf computer code-editing tools, like UltraEdit. Developers can add their own customised debugging and coding functions to these. The code is sent to a set-top box running an MHEG-5 engine or engine emulator running on a personal computer for testing.

MHEG-5 applications are built by defining scenes. Scenes are similar to web pages, although they can also be set to exist for a period of time. Each scene contains elements known in MHEG-5 as ingredients. These define how the interactivity, text and graphics work on-screen.

Using Graphical-Interface Tools

There are a number of products on the market that offer graphical-interfaces for building MHEG-5 applications. The market for these is quite small, however, and they are often used in conjunction with expert programming tools. Examples include SmartStudio from Samsung and SceneBuilder from Strategy and Technology.

Production Tools for Authoring Once, Publishing to Many

Because there are lots of different types of middleware and lots of different tools, recruiting and deploying production staff that have expertise in enough tools to create an interactive television application for more than one platform can be very expensive. Consequently, there are a number of products on the market that attempt to take the pain out of interactive television production by offering a single tool or solution for authoring applications across platforms.

The main disadvantage of all these multi-platform tools and solutions is that they support a limited set of platforms and the applications can usually only perform a limited set of functions. Anyone wanting to produce an application that does something beyond the basic function set might as well commission or write his or her own application from the ground up. There’s also the danger of having to drop to the lowest common denominator of functionality in an attempt to publish to multiple platforms – risky, since it may mean having to forego functionality that competitors will be only too happy to use.

These multi-platform tools can be split into three categories:

• Off-the-shelf systems designed specifically for interactive television.

• Extensions to existing television and internet production tools.

• Production companies’ customised solutions.

Off-the-Shelf Systems Designed Specifically for Interactive Television

There are off-the-shelf multi-platform interactive television production tools available, including Regieline from IDP, Storyteller from Watchpoint, ITV Factory from NPTV, SCIP and Ensequence. (There are also advertising-specific solutions from companies like Wink, RespondTV and PressRed). These companies work with platform operators and middleware suppliers – usually to incorporate a special engine in the target platforms’ set-top boxes. They then provide one central easy-to-use tool for creating applications for every platform.

Extensions to Existing Television and Internet Production Tools

Some existing television and web production tools have been extended to deal with simple interactive television authoring for multiple platforms, including the Lyric range from television graphics company Chyron, extensions to Avid editing software and the SpinTV Studio Suite for Dreamweaver. As with the systems designed specifically for interactive television, they work only with a pre-defined set of platform operators.

Production Companies’ Customised Solutions

Production companies such as Go-Interact, Di3, NDS and Two Way TV have their own infrastructure and solutions for creating and running interactive television applications across a number of platforms. They can utilise and customise their existing solutions for a particular customer’s needs. Some of these companies will also offer production technolgies that encompass publishing to the web, mobile phones and other media too. They tend to work with pre-defined platforms and it will cost much more to produce for a platform that isn’t already covered by their infrastructure.

Case study: The Production Process for Big Brother

Case Study: Enhanced Television Production Workflows – now and in the Future

Case Study: The Development of BBCi, the BBC’s Digital Text Service – Services, Structure and Processes

Case Study: The Development and Production of Sky NZ’s Weather Channel