Usability Standards

Observations about the Videotex Industry:

Several of the videotex systems and trials operating in the industry today (both ASCII and NAPLPS) appear to have many common generic Functions - or Applications (amply doCumented in the ALUIC Report).

There also appear to be - among these several disparate services - a number of markedly different versions of Videotex at the Applications Level. These different styles vary as to Terminology, Screen Design, and Database Routing Conventions,

No single one of these interpretations has yet shown itself to be either substantially superior or substantially inferior to any of the other competing interpretations.

Based on recent experience; it is not yet possible to say that Videotex - in its present form, at least - is an unqualified success.

Therefore:

Since we seem to lack any real and justifiable basis for recommending the "The Right Way" to design Videotex, it seems premature to,limit further development and exploration in Presentational Screen Design technique at this time. There are already several companies which are substantially invested in THEIR OWN interpretations of videotex. It seems unlikely that we could convince them to change their screen layout and terminology simply on the basis of our unverified assumptions.

Some ASSUMPTIONS about User Terminals:

(a) Videotex will operate upon the Intelligent Local Terminal (probably a software decoder integrated with a personal computer).

(b) Unifunctional hardware decoders have a limited lifespan as transitional units in the industry.

(c) Dedicated hardware decoders operating as periipherals 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:

Any suggestions or guidelines offered by the Useability Committee should assume that

• Videotex screens (occasionally referred to as "pages") will continue to 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).

Recommendations

The Useability Committee should be careful to frame its guidelines in such a way that they are relevant to the less-than-overwhelmingly-successful page-oriented and tree structure-based design techniques presently being used in the videotex industry.

These same guidelines should also be flexible enough to meet the developmental challenge offered by newer - perhaps more appropriate - technology and techniques which are emerging in the industry as well.

We believe that it would be a serious mistake for the Committee to confine its guidelines to a set of assumptions which are based on transitional technology (the unifunctional or "dumb" decoder) and the limitationsof a tree-structure oriented database, neither of which have demonstrated a terrific degree of success. Of course, we still need some guidelines and meaningful recommendations. And we believe that we can do that, without compromising our ability to creatively address the "next wave" of videotex development, which will be based on intelligent local. terminals, downloaded software, and more sophisticated database , design.

Proposals

in proposing its recommendations and guidelines, the Useability Committee should differentiate between issues of FUNCTION and issues of STYLE.

(A Relevant Digression:)

At TCS we often like to invoke the "Highway Metaphor" when describing videotex database design. It is a dynamic, spatial metaphor which assumes that you are using a reasonably accessible, user-friendly piece of high technology for getting around. The System Operators have defined a certain number of pathways (the Database Structure) which you can use to get to a variety of services. Both System Operators and Service Providers offer directions and signs (Routing, Indexes, and System Messages) to help you navigate. In the Highway Metaphor your local User Terminal is your vehicle.

In the automotive world, all cars share a range of generic functions (s.a. brakes, gear shifts, windshield wipers, hi-lo • beams, hazard lights), which exist as Controls available to the driver as he navigates.

Only a FEW of these functions are located consistently in the. same place in all cars (s.a. brakes, accelerator, steerin*wheel, turn signal). The vast majority of the other functional fbatures appear in a variety of locations around the dashboard. . The horn, hi/lo beam control, windshield wiper controls, and gear shift layout vary substantially in their location from year to year and from model to model. They are what we might call "implementation dependent".

And yet, even with all of this inconsistency in physical layout within the auto industry, we still manage to support a wide variety of "user interfaces" ,-- including .a "British. format" which totally reverses our conventional control panel layout. Most of us manage to cope with the variety pretty handily - in fact, we seem to welcome innovative differences in design. (Would it seem • too cynical if we suggested that many competing car models differ PRIMARILY on the level of the user interface features and other purely stylistic enhancements?)

We would heartily recommend that the Useability Committee rigorously AVOID proposing specific screen layout conventions for the industry. That is an issue of STYLE, and should be left as flexible as possible.

We believe that we are on firmer turf when we address-the issue', of FUNCTION. There is a "bottom-line" of function/controls which' should be mandatory in any videotex system. The Committee should define which applications or functions are absolutely necessary.

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 (terminology taken from the ALUIC Report):

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").

Graphic: How it Works

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)

The Role of the VIAUC

We propose. that the VIAUC 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:

1) 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.).

2) The data transmitted from the User to the Host identifies ' which Function he wishes to use.

NOTE: We anticipate that the Intelligent Local Terminal will be able to perform substantial processing on videotex data. The , ILT will - in a very real sense - act as a "Host" in its own right.

• The VIAUC may wish to identify a certain range of generic Functions as MANDATORY. These will define the functional "bottom:: line" of any videotex service.
• The VIAUC may also wish to identify a range of functions which would be OPTIONAL to any videotex service, but which could be recognized by a "full SRM" decoder.
• The VIAUC should also allow some room in the coding structure for future additions.

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

John Altson's document outlining ATEK's thoughts on a "standard interface" puts this arguement in clearer and broader perspective. Contact;

John Altson ATEX, INC.

32 Wiggins Avenue

Bedford, MA 01730

(617) 275-8300

Headering Technique

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 by Online Conferences. .

Summary

* The Committee should identify a range of generic applications Functions which would be MANDATORY for any videotex system (The Committee may at the same time wish to also identify a range of OPTIONAL generic Functions)

* The Committee should propose a set of Elemental Headering Conventions (unique code names) as a way of identifying each of. these Functions (to be accepted as a VIA Standard Interface)

* The Committee may also wish to address the full range of • Headering issues as outlined in the document from John Altson of ATEX

* The Committee should NOT involve itself in issues of Layout or Style

We desperately need a set of interface standards that wiAl allow IPs to transport their screens among multiple SOs. This involves ensuring accessibility at both the Presentation and Application Levels - and appears to be primarily a political issue for the SOs. Viewtron's recent layoffs would seem to confirm that a strategy of inaccessibility is suicidal. We can only pray that the other SOs in consumer videotex will get hip before they, too, run out of money.

Inasmuch as there is - as far as we can tell - no single "Right Way" to design videotex {Just yet, at least), we must allow ourselves the flexibility to explore and develop further. The use of generic Elemental Headers accommodates the broad range of different implementation styles existing in the industry today.. .,

We believe that, by following this plan of action, the Committee 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.