Elemental Database

Marketplace Challenges

The North American Presentation Level Protocol Syntax (NAPLPS) was initially introduced in 1982 as a graphically enhanced vehicle for the online electronic publishing and transaction services industry know generically as "videotex". NAPLPS was to provide videotex with sophisticated graphic presentation capabilities, thereby attracting service providers who might otherwise not be interested in the medium (especially advertisers).

Unfortunately, the videotex industry has not successfully implemented NAPLPS in America. There have been problems at several levels:

• A failure to standardize effectively among decoder manufacturers led to confusion on the technical side. A major issue has been - curiously - the definition of text. Perhaps this meeting will help resolve the technical inconsistencies.
• Lack of cooperation among system operators on issues regarding the exchange of common information meant much needless repetition of effort for information service providers. Hopefully, as system operators develop a more mature approach to the information industry, they will be better able to see the value of cooperation and coordination.
• Exclusionary tactics by system operators limited the production and services market unnecessarily. A disproportionate percentage of viable, creative new ideas come from small and independent service houses, and the videotex industry is in critical need of such resources, especially now.
• Many information providers lacked adequate and appropriate software to effectively handle NAPLPS screen production and file management. This is perhaps the most critical bottleneck in the whole NAPLPS videotex production scenario.
• Hardware manufacturers were unable to deliver decoders in an affordable price range for consumers. The recent emergence of "dedicated" NAPLPS boards and software decoders may change that situation soon.
• Both information providers and system operators have failed to integrate their services effectively with existing and successful parallel industries. This is a major issue for the technical side of the business; only recently has the industry offered anything even approaching NTSC-recordable decoder output.

* The explosive growth of the microcomputer no doubt encroached upon much of the anticipated videotex market, and the videotex industry as a whole was slow to perceive the microcomputer market as anything other than competition. The slowdown in microcomputer sales and less defensiveness in the videotex industry may yet bring these two together for their mutual benefit.

Obviously, many of the mistakes which the industry has made thus far can be considered as part of "the learning curve". Should the industry wish to pursue the enhanced presentation path (and that is not altogether unlikely), they can probably do better than they have up until now.

In many ways, the situation demands that we look at NAPLPS "beyond videotex". We may find ourselves looking at some new applications, as well as a better way to implement some already-existing applications. We shall attempt to address three issues which are critical to the success of NAPLPS videotex:

• Integration of NAPLPS information services with existing and successful parallel text, graphics and communications industries
• The development of a common Application Level protocol for document exchange among NAPLPS and NAPLPS-subset services
• The development of appropriate tools for the production of a NAPLPS service: frame creation, application software design, text entry/update, image librarying and database management

Integrating with Applications Beyond Videotex

One way for the industry to transcend its present malaise is to explore applications for NAPLPS display technology in areas which might not be considered "conventional" videotex. We can see potential uses of NAPLPS in three major areas of technical configuration:

• those applications which use a modem for communication with an external device or over a transmission line
• as a graphics support production utility for conventional video-based applications
• as the graphics display control for a microcomupter

Modem-based (Online) Applications

The NAPLPS protocol can he used in applications which require a modem (for integration with an external or peripheral device), but would not be considered "conventional videotex".

STANDALONE TERMINALS OR KIOSKS Retail Marketing, Point-of-Sale Advertising, Tourist/Travel Information, Product Catalogs

"SMART" BUILDINGS Building Directory, Company Logos, Electronic Mail, Systems Panel

CLOSED-CIRCUIT CABLE SYSTEMS Hotel Services, Updatable News Scroll, Security Monitoring

VIDEOTAPE/VIDEODISC OVERLAY Map Notation, Titling, Image Icons, Dynamic Text & Graphics Authoring Utility

OPTICAL DISC & CD-ROM INTEGRATION Database Storage, Parallel Digital Audio, Software Library & Image Library Storage

Video / Television Support

The NAPLPS protocol provides reasonable graphics and text quality to be available as a recordable and editable video signal.

INEXPENSIVE ANIMATION, SPECIAL EFFECTS AND TITLING (Cartoons, Advertising, Industrial Training, Business-to-Business Programs)

REMOTE PRODUCTION SUPPORT (Easy to Store, Transmit and Update, Local Graphics Generation)

UPDATEABLE GRAPHICS (Business Charts, Weather Icons, Team Logos and Sports Scores)

CABLE TV INFORMATION CHANNELS (Scrolling Text, Animation, Advertising)

MUSIC VIDEOS (Animation, Dynamic Graphics, Sync-to-Sound Images)

Microcomputer Support

The emergence of NAPLPS software decoders on the market indicates substantial applications simply as the design, storage and display medium for microcomputer graphics.

COMPUTER AIDED DESIGN (Shared Graphic Workspace, High-Resolution Graphics Production, 3-D Modelling)

COMPUTER ASSISTED MANUFACTURING (Robotic Controls, Work Flow Diagrams, System Monitoring Panel)

EDUCATION/TRAINING (Graphics Reinforcement, Easy Graphic/Text Updating and Customization, Maps and Charts)

GAMES & SIMULATIONS ("Face of the Interface" for Microcomputers, Dynamic Modelling, Animation, Music and Audio Support)

BUSINESS APPLICATIONS (Graphs & Charts, Business Presentations, Graphic Continuity among Applications)

TELECONFERENCING (Electronic Mail, Image & Document Exchange, Shared Working Environment)

The videotex industry may find a new synthesis for graphically enhanced NAPLPS services by exploring the potential for integration with these successful applications.

The Applications Level Protocol

This session is based upon some ASSUMPTIONS about Videotex User Terminals:

• Videotex will operate upon the Intelligent Local Terminal (probably a software NAPLPS decoder integrated with a personal computer). The "dumb" terminal will exist primarily as a microcomputer peripheral.
• Unifunctional hardware decoders have a limited lifespan as transitional units in the industry.
• Dedicated hardware decoders operates as peripherals in an intelligent module configuration (PC/Touch-Sensitive-Screen/ Videodisc/External Disk Storage/etc.) will probably serve as the developmental bed for converging technologies and enhancements in areas such as: "public" videotex, educational/training stations, and kiosk applications.

 

THEREFORE:

• Videotex screens (occasionally referred to as "pages") will continue to be displayed on unifunctional "dumb" decoders over the near term.
• In the near future, and over the long term, videotex screens will likely be processed through an Intelligent Local Terminal.
• Much of the Application Level software will be stored in this Intelligent Local Terminal rather than at the host. In fact, the ILT will sometimes operate as a Host in its own right.
• The Intelligent Local Terminal provides the user with far more intelligence and processing power than the NAPLPS SRM of 3000 Bytes of local memory would seem to indicate (though it is also likely to fall below SRM in terms of graphic sophistication).

Recommendation

The industry should develop a set of applications guidelines which will be able to creatively address the "next wave" of videotex developments, which will be based on intelligent local terminals, downloaded software, and more sophisticated database design.

In proposing its recommendations and guidelines, the industry should differentiate between issues of FUNCTION and issues of STYLE.

The common ground for most videotex systems is in what we call the "Generic Functions". As mentioned before, a given Function may have many names. For instance, the "Next Page" Function is variously implemented as "MORE", "#", "NEXT", "> ", "RETURN", etc. in different systems. (This terminology is taken directly from the "Report of the Applications Level User Interface Committee of the VIA".) These differing interpretations of the generic Functions are a reflection of differing presentational STYLES among SO's and IP's

Headering

One way for the videotex industry to accommodate the need for both stylistic flexibility and functional consistency is through Elemental Headering. This technique assumes that we have identified a range of mandatory applications functions. Let us assume that we have identified the following navigation functions as MANDATORY:

FUNCTION		IN-USE NAMING CONVENTIONS
Next Screen Previous Screen Help Option		NEXT, MORE, >, RETURN, #, F+1 BACK,< , R, B, PREV PG, PREVIOUS HELP, ?, H, K, GUIDE

 

The Elemental Headering technique proposes to assign a unique "name" to each of these generic functions. This "name" would be coded into the data in the videotex file, but would not itself be displayed on the screen. Let us assume that we have assigned the following code name to our list of mandatory functions:

CODE	FUNCTION	IN-USE NAMING CONVENTIONS
011	Next Screen	NEXT, MORE, > , RETURN, #, F+1
023	Previous Screen	BACK,< , R, B, PREV PG, PREVIOUS
911	Help Option	HELP, ?, H, K, GUIDE

 

In this situation, every time that the generic "Next Screen" prompt appears in a videotex display, it will be preceded by the code name "011" (regardless of whose database it is). Now it becomes possible to transport that videotex file from one system to another easily. Each System Operator may choose to create software that will identify that header (code name "011"), and insert his own proprietary terminology for the "Next Screen" function (whether is be "Next", "MORE", ";>", "F" + "1", or whatever). It even becomes possible for software in an Intelligent Local Terminal to perform the same interpretive task and thereby "personalize" the "Next Page" function: "CONTINUE", "PAGINA PROXIMA" (Spanish), an Iconic Symbol, or "ZIBBLE").

the loop between data sent from the Host to the User (Screen Display) and data sent from the User to the Host (User Response). By establishing common coding conventions for generic user functions, it becomes possible for a videotex screen to be displayed in a number of different stylistic environments. In our example, the "Next Page" option (code name "011") can be displayed through several different systems as (variously): "MORE", "NEXT", ">", "RETURN", "F" + 1", depending upon the system operator's preference. The same "Next Page" function can also be customized by an Intelligent Local Terminal as "ZIBBLE".

So what happens when a user transmits a request for the Host to "Send Next Page"? If it is a one-dimensional system where all of the User terminals are hardwired unifunctional decoders, then ALL such requests will transmit to the Host the unique coding sequence for "MORE" or the unique coding sequence for "NEXT", or the unique coding sequence for ") ", depending on the dedicated decoder which is being used throughout the system.

But if the Host is attempting to service multiple system styles, OR if the Host is attempting to service a network of intelligent local terminals which have been customized for their users' individual needs, then the poor host computer will be deluged by a babble of different unique codes - each requesting (in its own way) that the Host "Send Next Page".

Wouldn't it be easier if there were a unique code name (like "012") that was assigned to the generic function "Send Next Page"? Now that poor overworked host computer can service a request from ANY videotex system or individual user.

* Note It is important that we differentiate between the key (or keys) that the User presses when sending his request to the Host (This may be - variously - "MORE", "NEXT", " >", etc.) and the actual data stream which is transmitted. We propose that in all cases this should be a common designated standard code (in our example, the unique code "012").

How do we ensure that all videotex decoders will transmit "012" when the User requests the "Send Next Page" function? In a unifunctional decoder, that code name will be hardwired into the appropriate dedicated key: "MORE" (Sceptre) or ">" (Norpak), for example. In a flexible Intelligent Local Terminal however, it is possible to dynamically assign the unique code "012" to any input device as appropriate (This may include QWERTY keys, function keys (1-10), dedicated function keys, joystick, or voice activation).

Implementing the Interface Standard

What we have described here is a system which would allow System Operators, Information Providers, Software Packagers, and even Individual Users to customize their user interface, while at the same time allowing them to communicate with each other using a common language. The basis for this common language (or interface standard) is a set of unique, designated code names (Elemental Headers) which have been assigned to a range of generic interactive Functions. This set of code names would itself be transparent to the User. It is essentially a "Look-up Table", and might be described as a Rosetta Stone of sorts, providing a cross-reference between different presentational styles. (See Illustration)

We propose that the industry delineate a common Interface Standard which will designate a unique code name (Elemental Header) to each of a range of generic Functions (Applications). We see the generic Functions as falling in two major areas:

• The data transmitted from the Host to the user identifies which generic Functions are active at that point (i. e. "Next Screen", "Purchase", "Menu Choice", etc.).
• The data transmitted from the User to the Host identifies which Function he wishes to use.

By designating a unique code name for each of a range of applications (whether transmitted from the Host to the User, transmitted to the Host from the User, or processed in an Intelligent Local Terminal), we can assure ourselves of:

• Functional compatibility among diverse systems
• Easy transportability of videotex files

While still maintaining:

• Flexibility in presentational design

The technique of Elemental Headering can be extended to allow for a variety of screen layout formats as well. In NAPLPS it is not necessary to standardize the Location of information on a screen. If the generic functions within a file have been properly headered, then a given screenful of information:

• May be displayed in a variety of stylistic formats and screen layouts
• May be combined (in whole or in part) with other screen displays
• May be further processed by software in the Intelligent Local Terminal

The Elemental Database notion is discussed further in the article "Interactive Architecture and the Role of the Designer" (The Communication Studio) published in the Proceedings from Videotex '84 A by Online Conferences.

We believe that, by following this plan of action, the industry can provide a basis for consistency and standardization of Function across the industry while still allowing for a variety of different implementation Styles. Perhaps most importantly, the Elemental Headering technique is well suited to the likely future development of the intelligent videotex interface.

The Context Management Technique

One approach to the issue is to conscienciously separate the Information CONTENT (text, titles, logos, illustrations, graph data, etc.) from the Display CONTENT (layout, colors, decoder parameters, system prompts, graph and chart styles, etc.). This system of "Context Management" provides a framework for the creation and maintenance of a dynamic, modular, highly integrated information service.

The Context Management technique provides the Editorial Director with a flexible system for Inventory Management on a single integrated workstation. It allows the various members of the Production Team (Artists, Text Editors, Advertisers, Quality Control, Logical Routing, Software Development, etc.) to each work independently while still maintaining product continuity and integration. It also enables the Design Manager to make global changes in screen design by Template swapping. And the Information Provider can adapt his

database to the design constraints of different - often incompatable System Operators and decoder devices - with ease.

Content Integration Through Context Management

By using Elemental Database design techniques in a Context Management environment, it becomes possible to allow a non-specialist to enter and update the informational "content" of a screen without knowing anything about NAPLPS. For example, one can easily create NAPLPS display templates which will automatically merge existing ASCII services. Graphics files can be merged into the screen design and graphical attributes such as color, texture and blinking can be manipulated with ease. Modest software applications allow the display of statistical data through dynamic NAPLPS graphics.

Aside from the obvious advantages for the production process, the Elemental Database allows system operators to easily exchange and integrate information from various information providers without laborious screen redesign. Service providers can transport data from one display format to another. Individual users and value-added repackagers can customize the presentation and display of information drawn from a NAPLPS service (See Illustration)

The technique of Elemental Headering can be extended to allow for a variety of screen layout formats as well. In NAPLPS it is not necessary to standardize the Location of information on a screen. If the generic functions within a file have been properly headered, then a given screenful of information:

• May be displayed in a variety of stylistic formats and screen layouts
• May be combined (in whole or in part) with other screen displays
• May be further processed by software in the Intelligent Local Terminal

The Elemental Database notion is discussed further in the article "Interactive Architecture and the Role of the Designer" (The Communication Studio) published in the Proceedings from Videotex '84 A by Online Conferences.

We believe that, by following this plan of action, the industry can provide a basis for consistency and standardization of Function across the industry while still allowing for a variety of different implementation Styles. Perhaps most importantly, the Elemental Headering technique is well suited to the likely future development of the intelligent videotex interface.

The Need for Service Production Software

NAPLPS is an elegant way to create and store pictures. It is made even more powerful by the fact that it is essentially based upon the ASCII text protocol.

Unfortunately, the companies which are interested in using NAPLPS for electronic publishing and information exchange have developed neither the techniques nor the software for handling the NAPLPS code without requiring the operator to be a NAPLPS graphics specialist. Up until recently almost all production and maintenance utilities have been based on mini or mainframe level hardware which is centralized and generally inaccessible.

Product Suite

The software which is necessary for such a production environment includes utilities such as:

TEMPLATE GENERATOR Allows non-specialist to create annotated NAPLPS templates

LAYOUT COMPOSER Allows designer to alter the spatial characteristics of the screen layout

ATTRIBUTE CONTROLLER Allows designer to alter PDI attributes in the screen without corrupting the content of the screen

HEADERING UTILITY Allow easy annotation and identification of "coherent blocks" of information

IMAGE LIBRARY INVENTORY Lists and cross references the available graphics "clip art"

CONTEXT MANAGEMENT UTILITY Allows the designer to organize contextual parameters among various services on the database

ASCII FILE MERGER Automatically merges pre-existing ASCII files into NAPLPS templates

IMAGE AND TEXT UPDATE UTILITY Allows non-specialist to update text and merge graphic files in NAPLPS template without fear of corrupting NAPLPS screen data

GRAPH AND CHART GENERATOR Transposes data into a variety of graphic chart and graph formats

DATABASE ROUTING MANAGEMENT Allows designer to create logical links among screens and audit logical paths

HARDWARE INTEGRATOR Allows integration of NAPLPS service with external and peripheral devices, such as optical disc, videotape deck, or audio control

LOCAL MEMORY MANAGEMENT Allows local decoder to be polled for status of various attributes (including macros, DRCS, domain, etc.); useful for both host interactions and local software applications

APPLICATIONS INTEGRATOR Allows Content of NAPLPS service to be integrated with (manipulated by) local user or third party software applications

Summary

NAPLPS is unparalleled as a byte-efficient technique for both storing and transmitting text/graphic files. It is graphically sophisticated, dynamic, upgradable, highly flexible and expandable across a broad range of applications. Furthermore, it is supported by a number of existing products in the field. Ultimately, whatever happens (or doesn't happen) to videotex, the future for NAPLPS looks very bright, in any case.