Whether it's "B&T" or the BBC, all publishers like to define their audience, its needs and how to cater for them. But while it's complicated enough for newspapers and broadcasters to keep up with their audience it even trickier for new-media publishers, where no two customers might want the same content from their service and the broadcast has to be compatible with an increasingly diverse set of devices.
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
It may have taken years for businesses to wake up to the possibilities of the Internet, but now that they have, new Internet services are emerging every week. Once consumers realised their PC could become a shopfront, no great leap of the imagination was required to envisage other intelligent devices doing the same thing. Everything from PDAs to PalmPilots to mobile phones is now seen as a potential window on the Internet. When tabloid newspapers start giving away WAP phones as competition prizes, it's as good an indicator as any that a mainstream audience wants the technology.
Unfortunately, in many cases the technology simply isn't ready. Customers may be buying WAP phones, but if they try to use them to find out where the nearest branch of, say, Carphone Warehouse is, they'll be disappointed.
In June testing facility Anywhereyougo.com tested a sample of supposedly WAP-enabled e-commerce sites. A quarter of the 50 leading sites tested either couldn't complete WAP transactions or would not even allow Web pages to be downloaded. And with one of the sites that failed to load properly onto WAP phones being run by Carphone Warehouse, you have to wonder if a mobile phone expert can't get it right, who can?
The problem, according to Anywhereyougo report author James Pearce, lies with the poor translation of HTML Web pages into the WML (Wireless Markup Language) format used for WAP devices. "It's a very complex process for developers to get pages designed for PCs to load onto WAP phones," says Pearce. "There are 27 different types of WAP phone on the market already and more than half a dozen gateways in use. Since each product has unique characteristics, every combination of device and gateway can cause unpredictable results."
Some handset manufacturers like Nokia have brought out tools supposed to make application development easier. They're obviously not working, says Kern Judge, MD of wireless solutions provider West One Technology, who believes handheld devices may *never* be good platforms for the delivery of useful Web content. "Where are the portals? The only application that seems to work on handheld is e-mail and that's just a glorified version of the messaging facility," he says. As a reseller, Judge's advice to Web developers is not to worry too much about mobile commerce - it's all hype. "It's a non-starter and we're totally disillusioned with it," he says.
Even so, considerable weight is being brought to bear to get the Internet onto other devices. More WAP handsets come on the market every day along with an increasing number of tools to overcome the teething problems. By 2003, says research company IDC, more people will be accessing the Internet through mobile devices than via PCs. Ovum Research estimates there will be 1.5 billion mobile phone users by 2006, 684 million of whom will access the Net via WAP.
Although WAP looks like being an interim technology, Web content publishers must learn to overcome its failings. "WAP was never meant to be the be-all and end-all of mobile Internet," says Ovum analyst Michele Mackenzie. "As and when improvements are made, more sophisticated technologies will take centre-stage. Meanwhile, you can't afford to ignore it."
Piecemeal solutions have emerged. Some argue that the problems of adopting HTML content for different platforms are wildly exaggerated. "I can't see why WAP and WML have stirred up such a fuss in the technical community," says Mike Banahan, lead developer at Somewhere Near, which has developed a geographical search engine. "There's nothing difficult or challenging about it at all."
The trick is to be disciplined in how you adapt your site for mobile users, advises Mike Lynch, chief executive of Autonomy, a text analysis firm which recently added WAP access capabilities. "People won't stand on a street corner and use a WAP phone in the same way they use a PC on their desktop. But you have to try and imagine which bits of information will be useful on a Wap phone and in what form." This means delivering short bursts of news, stock quotes and consumer services already on a site. Developers will also need to make allowances for limited wireless bandwidth and tiny screen sizes.
But according to the chief technology office of InterX, Phil Sant, all this completely misses the point. It's no good trying to retrofit PC technology onto a TV or mobile phone, he argues - content designers need to be working to a different model altogether. "You can't support WAP by making an addendum to some completely different architecture," says Sant. "You need to design the whole thing from scratch so it can easily be tailored for different platforms. You only achieve that by separating the presentation layer from the business logic. The problem today is that most Web application servers build the application within the presentation layer, so you can't separate the two."
In its development work for online magazine ITNetwork.com, InterX kept the two separate, allowing the technology to be ported to any new device coming on the market within two days. "The business engine is stable, while the market throws up a new device a month, so it pays to keep the content and the presentation layer separate," says Sant.
By creating a separate presentation layer, Web developers can update their application quicker and get the full benefits from each device. InterX, for example, has developed softwware that tells it the complete configuration of the device accessing its clients' Web sites, which enables those sites automatically to adjust the content they are pushing out. If the technology detects a device with full-motion video technology, then this capability can be switched on for the service delivered to that device. "You can only make a success of content delivery if your sites are dynamically compatible," says Sant.
But isn't separating content from layout and ensuring machine-to-machine transmission of structured content precisely what XML was supposed to achieve?
Paul Newstead, sales director at Eprise, agrees that personalising content is an increasing headache, but takes issue with the use of heavy-duty technology to do so. The whole process needs to be simplified, he argues, and companies can't afford to hire armies of XML programmers to keep updating interfaces - assuming they can actually find any. "XML programmers are like gold dust, and HTML inputters are the new typing pool," he says. "We need to do for Web publishing what word processors did for document writers: make it available for anyone to do. Business managers should be able to input their own text. Otherwise the cost of maintenance will continue to spiral."
Eprise's solution is to integrate the whole suite of tools needed for both updating and publishing into one application. Once the business rules (the logic that determines how content should be presented to different devices) have been set, the content can be controlled by people with a reasonable degree of IT literacy. "We need to stop creating situations where skilled workers are required to run systems," says Newstead.
One increasingly important format is interactive digital television, or iDTV, which presents many new content publishing challenges. The medium itself calls for different treatment of content from PC interfaces: the user is typically 10 feet from the screen, reclining rather than sitting forward, and typically one of a group looking at the same screen. The use of text therefore needs to be limited and transaction exchanges truncated, while the input device may limit interaction. With satellite or digital terrestrial TV, the return channel from the consumer will not normally be connected, so the content publisher will have to decide for the consumer when connection is needed, and to close it down when it is no longer in use.
With the spread of television-based access, Web demographics are likely to become more diverse, warns Clive Keyte, interactive digital director at ICL. "Personalisation will become even more significant in ensuring that consumers see content, advertising and promotional material relevant to their interests, so the content publisher maximises revenues from commercial activity," he says.
The flipside of the many new opportunities the television channel presents is lots more work for the content manager, demanding the synchronisation of online content with events appearing on television, either planned (through a scheduled programme supported by relevant content online) or opportunistic (reacting to an event with related advertising or promotional material). This places new demands for scheduling and immediacy on the publishing process.
Above all, the content publisher needs to prepare for constant change and increasing diversity. "I can only think of one or two sites where personalisation has added significant value to my session. It mostly promises much but delivers little and gets turned off rapidly," complains Mike Gove, chief operations officer of Just-sites.com, an industry-specific news portal.
As bandwidth becomes cheaper and more options open up, it becomes easier to lose your focus. Many sites have sprinted down the personalisation route without thinking of their customers' needs and desires.
The Keys to Content Management
1. Allow content authors to publish with little or no technical knowledge and training
2. Utilise existing skills and tools for content creation
3. Separate content creation from presentation
4. Provide for dynamic creation of personalised content - database extracts, for example
5. Ensure there is straightforward integration with existing systems, partners' systems and databases, and content feeds from a variety of sources
6. Use knowledge of consumer preferences to influence content displayed, as well as advertising and promotions
7. Improve productivity through tailored workflow, content re-use and automated content links
8. Make it scalable by allowing for growth across a very wide range in steps easy for the business to accommodate
9. Implement a lightweight interface, accessible from anywhere
10. Provide security of access, with content that can be created and changed only by those authorised to do so
11. Set up a central content repository, including both content and metadata, from which material can be assembled and published in different forms for different audiences
12. Build resilience into the architecture - e-commerce systems should operate continuously, not lose data or transactions, and be accessible to consumers anywhere in the world
13. Track and audit all deployed content in order to maintain and improve the effectiveness of the operation, and to provide a basis for legal redress in the relationship with the consumer
14. Support multiple delivery formats: HTML, IDTV, WML, e-mail