4. The Leibniz TLSI: A secondary macro programming interface and universal ASCII User Interface Shell for Hypermedia

The Leibniz TLSI is a simple and flexible programming interface that can be added as macro programmable user shell to existing C compatible applications to provide ASCII readable definition files for user interfaces, menu layouts, key bindings, and help information, as well as site-local and individual configurations. It thus serves as secondary programming facility or End User Programming Language (EUPL). In courseware applications, it provides programming access for local adaptation by teachers and students. The Inter-Actor technology of the system provides a powerful user-interface metaphor similar to a mechanical power tool for the end-user to experiment with available functions and build his own applications. The TLSI technology used is similar to the Java Virtual Machine (VM) principle and can be integrated in the Java environment.

There are several challenges posed in Multimedia (MM) software development projects: 1) The production environment: The need to integrate an inhomogenous range of skills: programmers, designers, documenters, artists, media technicians, etc. Each of these groups have their specific work and communication procedures. 2) The wide range and demands of application media. 3) The inhomogenous user community that is to be served with the multimedia applications created. The market is in full flux and the main driving force is the prospect of opening up ever new customer bases that have not been accessible with the existing technology so far. Systems that can from the beginning be designed to accomodate very different user groups will have a strong margin of profitability. In the education field, a special customer group are intermediary courseware developers who need very flexible construction sets for their work. Pre-fabricated, frozen-structure systems as they dominate the market today, don't serve the needs of this group. Another potential user group that is presently hard put to use the interfaces of current systems are people with disabilities who don't have the hand-eye motor control needed to operate the mouse-icon interface. This paper describes an approach to systems construction that provides a simple, robust, flexible, and adaptible base, which can be library-linked to existing C compatible system, and provides a standard common ASCII programmable interface.

The technical principle of the Leibniz TLSI is based on the VM (Virtual Machine) principle, similar to the one used in Java® (and compatible with it). Similar to SUN's system philosophy, it is the ultimately open system: The TLSI system was designed on the base of a minimal kernel system of about 50 K bytes, to be completely open and extendable in all ways. Its power rests on the ability to create special-purpose interpreters for special applications on the fly, in the field, and even by the end-user. A similar, but not as general and flexible, approach is the popular EMACS editor which implements its functionality in a special interpreter. The minimal run time kernel can be linked on top of any C compatible system. This allows to use the TLSI as a re-vectorable and re-programmable interactive user interface on top of any existing software (the host system). The minimal kernel alone provides the equivalent of an interactive low-level debug monitor system that allows to test and execute any of the functionality of the host system that one desires interactive access to. Any routine can at any time be called separately from the interactive user shell. By way of its macro programmability, any higher assembly of a set of basic host functions can be constructed on the fly.

The TLSI approach offers a very easy way to achieve a secondary programming facility or End User Programming Language (EUPL). The developer of the basic MM functionality (the MM provider) can use a standard compiler technology or an authoring system to provide the tool set which the user (or secondary programmer) can then extend into any direction he deems necessary. All secondary programming can be done with the macro language of the TLSI. The TLSI can provide a large functionality to the user without having to include the original authoring system or the compiler package, who is also relieved from the need to learn the conventions of the authoring system, he needs only to concentrate on the functionality that is offered by the specific TLSI interface which the MM provider supplies. This approach allows a comfortable division of expertise and responsibilities between the different groups involved in the authoring process of a MM system. The software engineers need only to deal with their compiler tools and SW methodology to provide a rich tool set of TLSI tools for secondary, or applications developers to build their systems upon.

The TLSI principle allows the construction of a very simple and effective common interface shell on top of different software systems, thus providing a generalized User Interface Language (UIL) that is adaptdable to specific user profiles. It allows to create flexible keyboard and menu layouts. All the functionality of the system is configured in ASCII readable files, that can be changed and re-configured with any text editor, at any time, even while the system is running, without any re-compile or otherwise low-level system interaction. Ideally the whole menu structure of the system resides in a single file, giving also a transparent access path to the logical structure of the whole system. In the Leibniz Hypertext Software Development System, an integrated hypertext function connects every menu with an associated help text residing in an ASCII readable text file that can be accessed in hypertext manner.

In the Leibniz TLSI environment, special focus was laid on maximum production speed in the rapid prototyping environment. These factors are essential: 1) Archive: Access to existing large libraries of functions. This requires optimization and structuring of a hypertext data base. Different access hierarchies must be possible for the different user groups who have different views of the system. Quick overview functions are available through a combination of hypertext with special folding method implemented in the system editor. The principle is: overview combined with detail view results in perspective. 2) Constructor: Must allow overloading and modification of functions without recompile of the system. 3) Testing: Flexible and powerful testing environment. Allow to generate standard input scripts that can be used on whole classes of functions. The testing scripts can also be derived from the interface declarations in the source code. All testing inputs can be logged, for reproducible error histories and to generate automated test suites for further testing sessions. All inputs that the user would perform interactively can be redirected to script files so that auto demo functions are readily available.

The development of the Leibniz system resulted in the Inter-Actor principle, a powerful unified representation and access metaphor for program functionality that is accessible in all its aspects from the user interface level. The structure of the Inter-Actor is similar to an object class, but it provides many extra user interface handles, like a self-display function, and a standardized experimentation field with test data for a new user who wants to try out the functionality of the system. For training purposes, all functionality of the system can be provided with sample data, sample inputs, the display of the internal state of the Inter-Actor before and after each function, and a way to change all the state variables individually. The metaphor of the Power Tool provides a tangible and direct user interface for non-software engineer users. The TLSI resembles a multi-function power tool, which can be converted in a minute into a drill, a buzz-saw, a jigsaw, a water pump, a sander, a grinder, and a screw-driver. Its add-on functionality rests on a practical functional classification that is hard to describe in a generic structural class inheritance structure of OO Software. It is achieved through function frames with re-vectorable executor modules. They can be re-vectored interactively, on the fly, just like in the machine shop. The functionality can be implemented on top of available OO technology, if it is possible to interface with the message structure of the OO processor. How this can be practically added to an existing authoring system, is not a technical question but mostly a problem with the closed shop proprietary policy of authoring system vendors. SUN's Java approach seems to provide the most painless access path.

1) The production environment: Here it is the inhomogenous range of skills that needs to be coordinated in the development of a multimedia system: programmers, designers, documenters, artists, media technicians, etc. Not all of these can be assumed to have a working knowledge of the rules of the trade of software development. Each of these groups have their respective procedures and communication interfaces. A software system that implements a workable CSCW approach for the cooperation of these heterogenous groups would is a useful, if not essential precondition for a successful project. At least it should be avoided that an authoring system is tailored only to the tastes and preferences of just one of the participating groups, as is the case with current authoring systems.

2) The wide range and demands of application media. The technology is in full flux, and new media and new formats are appearing every few months, and it is not possible to establish a fixed set of standards and procedures in an authoring system and expect it to last for more than half a year. The built-in obsolescence of MM technology is a boon for the authoring system manufactures who are assured of a constant revenue flow because the systems developers are forced to buy the latest version of the authoring system every year, but it is a catastrophe from the viewpoint of backwards compatibility and re-usability of investments already made in existing technologies.

3) Third, and most difficult, is the particularly inhomogenous user community that is to be served with the multimedia applications created. As much as the technology, the market is also in full flux and the main driving force is the prospect of opening up ever new markets and user groups that have not been accessible with the existing technology so far. This means that systems that can from the beginning be designed to accomodate very different user groups will have a strong margin of profitability. This also means that the existing user interface metaphors, like the mouse-/touchscreen and icon interface prove to be limited, and limiting. There is a need to have field exchangeable interface routines, for user groups that either have no table top to position a mouse on, others who only have a keyboard, and still others who can't or won't use their hands at all and can do only voice input. Then there is the large, and potentially decisive group of educational multimedia customers, who want to act as MM-OEMs. These are school teachers or students who want to make their own selection of materials to present to their special clientele. They want to buy a CD with a loosely ordered and assembled set of materials, and they need a programmable access to the interface to make their customized adaptations of course materials. The business potential of such half-product applications is substantially larger than that of huge, frozen-structure systems that need to be targeted at a very large customer base to be profitable. This requirement is currently being totally neglected by state-of-the art authoring systems which encapsulate the presentation structure and user access procedures without modification possibility. The last potential user group that is presently hard put to use current interfaces are people with disabilities who don't have the hand-eye motor control needed to operate the mouse-icon interface. (Fig. TLSI-1)

Current MM authoring systems are struggling to meet the various, and sometimes conflicting demands from these diverse areas, and technology will need considerably more time to mature and deliver a platform that can accomodate to such demands more easily and flexibly than the available systems. This paper describes an approach to systems construction that provides a simple, robust, flexible and adaptible base, which can be library-linked to existing C compatible systems, and provides a standard common ASCII programmable interface.

When Alan Kay made this statement in 1984, no one exept maybe he himself could have foreseen the rise of MM capable computers ten years later. In effect, the criterium he stated will be the hallmark of successful MM authoring systems of the future. It was also the criterium for the development of the Leibniz TLSI or Token List Subroutine Interpreter project. Its use for MM applications is but one of a range of (unforseeable) domains that it can be adopted to.

The technical principle of the Leibniz TLSI is based on the VM (Virtual Machine) principle, similar to the one used in Java® (and compatible with it). Similar to SUN's system philosophy, it is the ultimately open system: The TLSI system was designed on the base of a minimal kernel system of about 50 K bytes, to be completely open and extendable in all ways. Its power rests on the ability to create special-purpose interpreters for special applications on the fly, in the field, and even by the end-user. Similar, but not as general and flexible, approaches exist in the popular EMACS editor which implements all its functionality in a special LISP interpreter, or the AutoCad system, which also uses a LISP interface, or Microsoft's Word Basic, that allows the user to field rig the editor to his tastes, if and only if he ever finds out how to operate the macro programming facility. (Fig. TLSI-2, 3)

Optimization for speed: The optimization principle of the Leibniz TLSI is speed, speed, and again speed. The system answering reaction is totally transparent to the user. For this purpose, a fully transparent programmable keyboard access to all functions is essential, because mouse- /icon interfaces, though convenient for beginners and casual users, are about one order of magnitude slower. For any repeated acess to any set of consecutive actions, the extensive macro programming facility (see below) allows the user to field rig his own preferred access method.

Implementation of the minimal kernel system: The TLSI is implemented in C. The minimal run time kernel requires about 30 to 50 K Bytes. It can be linked on top of any C compatible system, this makes it feasible to use the TLSI as a re-vectorable and re-programmable interactive user interface on top of any existing software (the host system). As minimal kernel, it provides the equivalent of an interactive low-level debug monitor system that allows to test and execute any of the functionality of the host system that one desires interactive access to. Any routine can at any time be called separately from the interactive user shell. By way of its macro programmability, any higher assembly of a set of basic host functions can be constructed on the fly. A program for the TLSI consists of a list of code tokens to be executed. Each code token corresponds to an entry in the code data structure. The token is accessible via a unique name in the system dictionary. This corresponds to the conventional linker symbol table but is interactively accessible to the user. The name table can be exchanged by the user for any name pattern the user requires. With the necessary pointers, each token code table entry needs on the average 50 Bytes, depending on the name length. The token can point either to a directly executable binary code of the host system, or it points to another list of token codes that are executed recursively as subroutines.

Macro programming facility: New subroutine lists can be constructed as macros at run time and entered into the system as user programs. These programs can be saved across sessions in a user dictionary image and re-loaded again. Since each token code entry in the subroutine table requires 4 bytes, large programs that consist mostly of recursive token calls are much shorter than C programs whose function calls are usually in-line expanded for performance reasons. Each new program is identifiable by its unique name and is entered into the system dictionary together with all the existing programs. These macro routines can be removed at any time as well. Thus an application can grow and shrink during a user session or as an applications developer experiments with the available possibilities.

Conversion to compilable C code and local optimizations: Since all TLSI subroutines resolve eventually into C function calls, a simple filter can convert a high level symbolic TLSI code into a compilable sequence of C function calls that can be optimized with standard compiler technology. Therefore, optimizations can be fine-tuned either to the run-time performance end, or to address space conservation end. A complete conversion into C code will have the fastest run-time performance and will require the most address space. Since a large code image that has been compiled for maximum speed will slow down to snail pace when the machine needs to swap a lot, it is very useful to provide different kinds of optimization images for different sizes of available target system memory. There still are 4 MB RAM computers out there.

A pressing need for MM systems development is the facility of secondary programming (or the end user programming language EUPL). This is required for any but the most simple-minded consumer applications (which are at best a very temporary market to disappear when the customers get more sophisticated). In the case of the MM-OEMs mentioned above, the practicability and comfort of this facility will prove crucial for wide market penetration of systems. The TLSI approach offers a very easy way to achieve this secondary programming facility. The developer of the basic MM functionality (the MM provider) can use a standard compiler technology or an authoring system to provide the tool set which the user (or secondary programmer) can then extend into any direction he deems necessary. All secondary programming would be done with the TLSI. Because of its simplicity and extendability, the TLSI can provide a large functionality to the user without having to include the original authoring system or the compiler package, this also relieves the user from the need to learn the conventions of the authoring system, he needs only to concentrate on the functionality that is offered by the specific TLSI interface which the MM provider supplies. This approach can also be chosen for in-house MM development of the MM provider. It allows a very comfortable division of expertise and responsibilities between the different groups involved in the authoring process of a MM system. The software engineers need only to deal with their compiler tools and SW methodology to provide a rich tool set of TLSI tools for secondary, or applications developers to build their prototypes upon. These can then be converted with the filter tools into "hard" software structures, or delivered to end users as TLSI structures to be modified by them or not, just as the MM provider decides is within the scope of his marketing policies. It is as easily possible to implement tertiary programming structures which can then be even more simplified and standardized to provide a very specific programmability to end users. Because of the unlimited extendability of the TLSI, this can have any shape and form wished for.

One of the main user interface problems of contemporary software packages in a windowing system like MS-Windows is the chaotic menu and hotkey layout of the diverse systems that are offered for this platform. The situation is worse for Windows, than for the Apple System, where a certain level of standardization has been provided, and it is worse for national language adaptations than for the original US layout. Each package developer seems to express his original creativity by inventing his own special hotkey binding layout from scratch. Some manufacturers insist on using the special symbols from the national character set for their hotkeys, so that anyone not using this keyboard will be out of luck and not able to use that nationalized product. The solution taken by many recent MM systems to provide no hotkeys at all, is also no solution at all. Because any repeated use of such a system, for example when the user wants to traverse just a few specific access paths that are often repeated, leads invariably to the "Pinball Wizard Syndrome", the unhappy user having to wade through an orgy of points and clicks before he finally gets to the place where he wants to do some real work. Instead of trying to create a uniform hotkey and menu pattern for all packages, which is hard do design, and impossible to enforce, the much easier solution is to allow the end user (or, in larger organizations, the in-house systems configuration manager) to create exactly the kind of keyboard and menu layout that is considered most appropriate at the location.

This can be easily accomplished with the common interface level of the TLSI, where all the functionality of the system that is accessible to the user is configured in ASCII readable files, that can be changed with any text editor, and re-configured at any time, even while the system is running, without any re-compile or otherwise low-level system interaction. Ideally the whole menu structure of the system would reside in a single file, giving also a transparent access path to the logical structure of the whole system, something that the handbook writers seem to consider a totally unnecessary luxury. The TLSI enables one to build very simple specialized interpreters that can build keyboard binding schemes or menu layouts. Below is an example how a menu configuration file may look like. The exact syntax is open to any design principle one may want to implement. The sample given is from a menu configuration file of the string handling processor of the Leibniz Hypertext Software Development System. (Fig. TLSI-4)

Using the TLSI principle, a complete production system has been created: the Leibniz Hypertext Software Development System. Through the integrated hypertext function, every menu entry has an associated help text that resides in an ASCII readable text file, which can also be edited and modified at any time (if the systems provider opens access to this option). Below an extract of the help file associated with the above string processor menu. For specific national languages, the file contains keyed entries with the prefixes !ENG !GER !FRA !ITA etc. Switching to different languages is simply done at run-time through the system configuration menu. The menu configuration file and the help information file can be filtered and merged easily to produce a printed manual. Thus, documentation production is centralized on a single data base for all national language editions, and for all stages of the production process: the in-house source code documentation provides the base for the help file, which then enters the printed documentation.

In the Leibniz TLSI environment, special focus was laid on maximum production speed in the rapid prototyping environment. For this aim, all the system components were carefully tuned and integrated with each other to achieve maximum efficiency. Originally intended for standalone hardware, embedded systems, and real-time industrial machinery control (the most general interpretation of multi-media), it contains its own operating system functions, a software prototyping and testing shell, a fully self-contained windowing system, a hypertext-integrated full-screen ASCII editor, and a hypertext database system. In the present implementation, the Leibniz system contains 10.000 functions in 100.000 lines code with 6 megabytes source, and 500 source and configuration files. A system of this size puts the built in information management functions to a severe test, because such a huge function library is impossible to memorize, and printed paper documentation is much too cumbersome besides being hopelessly behind the current version status. 100.000 lines would occupy a hefty 2000 pages of A4 paper. Listing only the function names fills a book of 200 pages. Even an experienced OO SW developer cannot be expected to master such a library in an afternoon. Therefore the optimal structuring and maximal speed of the retrieval environment is crucial. The available tools of the system allow access any of the 10.000 functions even in multi-level hypertext access in a matter of maximally 5 to 10 seconds. A special interface shell allows to call the very efficient GREP tool from within the editor with one keystroke, searching the 6 MB source in about 10 to 30 seconds, and delivering its output in a table that is routed to the editor. The output can then be fed into the hypertext system.

The code examples supplied are not just there to show another kind of yacc (yet another cryptic code) but to exemplify how a very condensed and powerful knowledge organization scheme can be embedded in the function names, serving as their own database ordering principle. While these names may seem cryptic and not very intuitive in the beginning, they have a few important information management factors speaking for them. First, the average length of a Leibniz function name is about half of that of usual comparable systems which have the well known expressive full-length meaningful english names like:

These names may be more expressive but if they were used throughout the Leibniz system, the size would not be 6 Mbytes, but 12 Mbytes, each file would be twice as big, it would need twice as long to load, the user dictionary would have to be twice as big, and the listing would need 4000 pages, not just 2000 pages. And what is even more problematic, testing would be more than twice as long, and less efficient, because of the tedium of typing in those long expressive names. Typing errors tend to accumulate more than proportionally after about eight characters. It is clear to see that there are information handling limits more on the human than on the machine side that are imposed by the sheer size of application systems.

This declares the window W-MSG as default window to which all the subsequent v.xxx messages apply. This saves a lot of unnecessary individual name-dropping, also saving code space. Moreover, the usual case in an application is that we return to the window we came from before we entered the special function. So we need not even name the old window any more. v.pop_parm does this all for us, returning us to that window without any additional code. All string processor commands are keyed with $.xxx, and for each special processor, there is such a very short keying sequence. m.xxx for the memory operators, mov.xxx for moves and fills, and so on. This allows to implement a very cheap run-time search of all methods a class has to offer by making a string compare through the database for the first 2 or 3 matching letters. More elaborate codification schemes for names are implemented with matrix words, which are a kind of logical place value system wherein a certain character at a specific position encodes a specific function subclass. The move processor has the following message modifications:

Without going into unnecessary details, it suffices to say that the universal prefix mov. specifies the operator class for memory moves. The < > [ ] ? a x codes specify what kinds of parameters are needed, if it is a move-and-fill (with a fill pattern of byte, word, longword, or string), and so on. There are very many combination possibilities for just this one operator alone. Naming them all with long names would be quite cumbersome.

1) Archive: Access to existing libraries of functions. This requires the optimization and structuring of the hypertext data base. The categorization of functions must be possible under any suitable ordering scheme, and must not be restricted to (for example) object hierarchies that are exclusively implementation dependent. Many different access hierarchies must be possible for the different user groups who have different views of the system. Quick overview functions are available through a combination of hypertext with special folding method implemented in the system editor. The principle is: overview combined with detail view results in perspective (Überblick und Einblick ergibt den Durchblick). It is necessary to present the system designer with as much useful information as he can keep in short term memory, and carry on to the task he has to solve.

3) Testing: Flexible and powerful testing environment. The TLSI allows to generate standard input scripts that can be used on whole classes of functions. The testing scripts can also be derived from the interface declarations in the source code. All testing inputs can be logged, for reproducible error histories and to generate automated test suites for further testing sessions. All inputs that the user would perform interactively can be redirected to script files so that auto demo functions are readily available.

4) Interface access: Transparent, most direct method. The mouse- /icon interface provides the easiest to use, and most fool-proof access method. Unfortunately it is also one of the slowest. For expert users, this proves to be a serious productivity obstacle. These users need a completely transparent access to all functions through key-strings, and must be able to create their own shortcuts. This is possible only when a uniform keyboard interface exists for all functions. This is ensured by the TLSI principle. Only through the keyboard interface can the complete control of the system through script files be achieved, as well as the log function.

The development of the Leibniz system resulted in the Inter-Actor principle, a powerful unified representation and access metaphor for program functionality that is accessible in all its aspects from the user interface level. The structure of the Inter-Actor is similar to an object class, but it provides many extra user interface handles, like a self-display function, and an experimentation field with test data for a new user who wants to try out the functionality of the system. For training purposes, all functionality of the system should be provided with sample data, sample inputs, the display of the internal state of the Inter-Actor before and after each function, and a way to change all the state variables individually. The functionality also resembles the Unix filter tool approach, with the difference, that in the filter approach, the CR-file is the one-and-only class of data it can work upon. Also, the Unix filters are "lean and mean" tools that are very powerful but don't offer much in terms of user friendliness. In the Inter-Actor approach, there exists a CR-file processor which has the functionality of GREP, AWK, and SED combined. Besides this, there exists a powerful string processor. With all the available string methods taken together, about 200, the Leibniz String Inter-Actor provides a functionality much exceeding that of commercially available string libraries and comes close to special string handling systems, like SNOBOL. There is also a processor for memory patterns (byte patterns) and shifts, for Windows (here called VDEVs, see the code example) and for numbers and arrays of numbers (like in APL), and extensions for pictures and drawings, like an on-board Postscript, for movies, sound files, can be added as well.

While the present implementation of the TLSI presents a solution to software structure that is in many ways equivalent to the OO-paradigm currently en vogue in the software industry, it takes different and parallel approaches in some aspects. The OO-paradigm is a solution to structuring problems that is geared to a certain way of thinking in the software industry and needs a lot of training. For unexperienced users, the ins-and-outs of the OO-classification rules are sometimes hard to understand. This may pose too much of a time investment for practically oriented user groups who should better use their time creatively designing and implementing artistic and aesthetic parts of the system, instead of dealing with deeply nested class hierarchy trees whose structure is not obvious. The metaphor of the Power Tool provides a tangible and direct user interface for non-software engineer users. The TLSI resembles a multi-function power tool, which can be converted in a minute into a drill, a buzz-saw, a jigsaw, a water pump, a sander, a grinder, and a screw-driver. Its add-on functionality rests on a practical functional classification that is hard to describe in a generic structural class inheritance structure of OO Software. It is achieved through function frames with re-vectorable executor modules. They can be re-vectored interactively, on the fly, just like in the machine shop. The functionality can be implemented on top of available OO technology, if it is possible to interface with the message structure of the OO processor. How this can be practically added to an existing authoring system, is not a technical question but mostly a problem with the closed shop proprietary policy of authoring system vendors. SUN's Java approach seems to provide the most painless access path.

4. The Leibniz TLSI: A secondary macro programming interface and universal ASCII User Interface Shell for Hypermedia

4.1. List of abbreviations

4.2. Abstract

4.3. Short Version of the Paper

4.3.1. Challenges of Multimedia Software Development

4.3.2. The Leibniz TLSI Virtual Machine

4.3.3. EUPL: User Programming of the Macro System

4.3.4. UIL: User Interface Language, Field Configuration, Integrated Help

4.3.5. Factors of the Optimal Rapid Prototyping Process

4.3.6. The Inter-Actor Principle and Power Tool Metaphor

4.4. Long Version

4.4.1. Introduction

4.4.2. The Leibniz TLSI "Token List Subroutine Interpreter"

4.4.3. EUPL: End user programming facility through the macro system

4.4.4. UIL: User Interface Language, field configuration, specialized interpreters

4.4.5. A sample TLSI menu configuration file

4.4.6. Hypertext integrated help information system

4.4.7. Sample Leibniz TLSI Source Code

4.4.8. Higher functionality and

4.4.9. Mnemotechnic and embedded database access keys in function names

4.4.10. Factors of the optimal rapid prototyping process

4.4.11. The Inter-Actor principle

4.4.12. Interfacing with OO-Systems and the power tool metaphor

.