This article appeared in the Multimedia and Videodisc Monitor, in June 1992. Appears here by permission.
Return to Multimedia and Digital Commentary Online
Over the past several months I have been heavily involved in the development of new capabilities for our interactive videodisc language learning technology center at the United States Air Force Academy. Some time before beginning this phase of our development, I also submitted proposals to speak at a couple of conferences. During these recent efforts, preparation for the presentations, and attendance at the conferences (in particular at The Seventh International Conference and Exposition on Multimedia and CD-ROM) I have come to several conclusions that are perhaps of interest to others. Some of my comments to support the various points are negative (we often call work in our lab "Life on the Bleeding Edge") but the final conclusion is quite upbeat:
Computer hardware companies often seem to think their main challenge in seeking market share lies in obtaining product differentiation. They see competitive advantage as resulting from adding some particular performance increase, or worse, they just are different for the sake of being different. The latter case is frequently made manifest in situations where manufacturers want software to run on their unique hardware implementations. It is impossible for developers to put their often limited resources into developing for all platforms that are available, thus the platforms that are skipped languish for lack of applications.
I term this problem a political one rather than one having economic causes. Principles of market economics dictate that platforms with the most software applications will be the ones that will sell. The political nature of what is going on is founded in the perception that companies often might create or stick by incompatible platforms for reasons of pride and nothing else. The classic example is that of Sony's Beta format going up against VHS in the consumer electronics marketplace. No one I know disputes the fact that Beta is a technically superior technology, but VHS won out because players were cheaper and perhaps more importantly, the tapes were cheaper. Video stores didn't exist in the beginning and the only affordable source material came from illegal copies of movies or from recordings off the air. VHS owners could place more material on a single cassette, making theirs the cheaper format overall and the winner in the battle for market share. Nevertheless, Sony took several years to finally produce and market their own VHS VCR.
A similar situation existed in the early days of MS-DOS, when it wasn't clear whether CP/M or MS-DOS would come out as the predominant operating system for desktop machines. Shortly after IBM had announced its first microcomputer, the numerous CP/M versions in the market at the time (resulting, I think, mostly because of incompatible disk formats) made life very difficult for developers and distributors alike.
In the quest for shelf space and buyer awareness, IBM won out, not only by the sheer weight and influence of being IBM, but also by their architectural openness that enabled clone makers to create and sell machines. (I am not sure that MS-DOS Version 1.0 was a whole lot better than CP/M!) In the first coverage I read on IBM's new system, I still remember the reviewer's amazement at the first press conference on the system. The comments were something like, "And on the table behind the speakers there were two and a half feet of system documentation!"
Created to facilitate the efforts of software developers, the documentation served as excellent source material for the clone manufacturers as well. Able to capitalize on IBM's openness, new companies came to life to make machines that were software- and hardware-compatible with IBM's offerings.
From that time forward, CP/M didn't have a chance. Developers flocked to the MS-DOS/Intel architecture in droves, making it the dominant force in the marketplace it is even today.
Yet commentators never cease stating just how un-inventive that first IBM PC was in reality. As a matter of fact I feel I suffer on a daily basis from the limitations of this system that was based on an architecture that was designed around the 640K of memory that was thought of at the time as being "more than we'll ever need." The combined limitations and flexibility of the resulting architecture make life difficult for anyone today who wants to do anything out of the ordinary, a situation that often arises during the integration of hardware and software from various vendors.
Nevertheless, 90 to 100 million machines have been sold,. and the show isn't over yet. Price reductions and new improvements in performance show no sign of letting up.
This situation was fostered by IBM's early willingness to seemingly give away competitive advantage that permitted the development of the huge installed base that exists today. IBM had a very high percentage of the PC market from the outset and continued in this vein for several years until their failures to innovate (ahead of competition) in both price and performance cost them market share.
In an attempt to re-capture lost ground they developed the Micro-Channel Architecture (MCA). Its technical merits are hotly contested by people on both sides of the argument, but IBM's desires to increase market share were certainly frustrated in the beginning and for some time after the release of MCA. Why? The license fees were deemed by many companies to be too high for them to make it worth their while. Also, although IBM claimed openness, I heard stories about companies having difficulties getting necessary data from IBM to make add-in cards. IBM has since made it easier for other companies to work in this area, but not before its market share continued its precipitous drop, raising serious concerns about the market's continuing reliance on IBM's leadership. These concerns have significantly reduced the giant company's already flagging influence on directions in technological innovation in the microcomputer marketplace.
History in the short experience of this industry should make it clear that open architectures (Apple II and the original IBM PC) have been more successful that closed ones (Atari and TI 99/4). In fact Texas Instruments really showed how not to do things. Before abandoning their efforts, they were losing money on every machine they shipped (hoping to make it up on volume?). Their plan was to imitate razor blade companies by almost giving the computer away and making their money on the software. They put a lot of money into their own software development efforts and made it very hard for third party software developers to get into the game. Seeking to obtain almost all gain for themselves, they wound up losing their shirt!
This is very pertinent to the current efforts of the Interactive Multimedia Association (IMA) to come up with a recommended format for compressed digital audio. Sony has made its ADPCM algorithms available to the CD-I effort and has put them out into the microcomputer market under CD-ROM XA. XA has been adopted by IBM for its Ultimedia platform and Sony showed an XA handheld device (Sony's internal code name: BookMan) at last month's Microsoft CD-ROM Conference. Nevertheless, there is a problem.
The IMA is insisting on making ADPCM available at all standard sampling rates and wants to add 8 kilohertz. Sony on the other hand doesn't want its algorithms used at sample rates that are too slow: their representatives apparently don't feel the resulting sound quality is sufficient. As a result the IMA is looking very closely at other algorithms, some of which were published in a twenty year old text book.
Additional confusion arises from announcements in industry trade publications. For example, we read recently that IBM and Apple will be proposing new multimedia standards through their joint Kaleida effort. Very close to the appearance of that information was news that developments at Microsoft would soon be bringing requests for new multimedia standards.
At a minimum this situation brings much confusion to anyone close enough to observe what is going on. In the worst case a lack of standards brings serious difficulties to those who wish to be involved in the developing multimedia industry, either as producers or consumers of multimedia products.
Consider this concrete but certainly related example of the kind of problems we face. I wanted to integrate a particular hardware board into one of our Air Force Desktop III machines, but the full length card (with its protruding, female RCA plugs on the back) would not fit into the machine. What was the solution? We had to take a hacksaw to the frame of the microcomputer, turning the unit onto its side to keep filings off of the mother board and out of the inside of the unit. There is something wrong with this picture! Furthermore, just as these two pieces of hardware would not fit together, there are many other pieces of hardware and software that are not easily integrated, despite the best efforts of the most serious and adept users.
Witnessed here is the confusion that often exists in the multimedia industry today. Moreover, often the confusion arises from more esoteric issues than whether or not two pieces of hardware enjoy a proper physical fit. Esoteric they might be, but these issues are no less of a problem. This industry needs stability, tools, and delivery platforms and instead we get uncertainty that hurts us all on all counts.
In my mind the issues are once again political rather than economic: I don't see how anyone will benefit economically from a lack of clear standards and openness in architectures. There are two critical issues at hand. First is the apparent rule that those who wish to keep virtually all benefit for themselves wind up losing everything in the long run, hurting many others in the process. Second, confusion in the marketplace will only cause buyers to postpone purchases.
My hope is that we will do CD-ROM XA right. Its birth in the CD-I industry gives us the closest thing to an international standard that exists. In any case, the multimedia industry needs as soon as possible an affordable, coherent standard for the development and delivery of compressed audio.
I previously wrote here (Monitor, November, 1989) about the importance of Windows for interactive videodisc (IVD) development. Although I feel we as an industry are now finally getting a handle on IVD development, I also feel that the movement to all-digital applications is raising development complexity to new highs. Instead of dealing with 54,000 frames on a videodisc for an application, we must now deal with thousands of digital files, the encoding and decoding processes, and a software tool base that has once again followed convention and has not kept pace with hardware developments.
For example, researchers conducted a survey of ten developers for Digital Video Interactive (DVI). Most of the developers had previous IVD experience and reported the DVI applications development process to be quite difficult (Lidard and Hix, 1990). Developers working on applications for Compact Disc Interactive (CD-I) (Fritz, 1990) report a similar situation.
Although the IVD industry has been working for several years to create useful tools, tools for manipulating digital information are only now becoming available. In addition, developers are having their problems using the tools that are available.
For example, a multimedia product for the MPC "standard" I recently examined was delivered on two CD's. One CD contained the software and waveform audio files and the other was filled with Red Book audio. Operation requires lesson files and associated audio files be copied onto the system hard disk, with the stiff storage requirements taking a serious toll on available space. Following the loading of the lessons that fit onto the hard disk, the user then substitutes the audio CD for the program CD. Menu requests for lessons not on the hard disk prompt the user to delete some lesson files and substitute the CD's (twice: once for the file copying and once to return the audio CD to the drive).
Other problems are more economic than technical. Because multimedia materials are delivered on microcomputers, developers have long determined that materials should be "programmed". This assumption dates from the early days of development of lessons for computer-assisted instruction. This results in applications that are very expensive and thus few in number.
In our lab at the Air Force Academy, we have determined that the materials development problem is one that is more related to database management issues than it is to issues associated with programming. By "separating content and interaction structure" we divide the problem into the two components of interaction layer and database layer, methodology that constitutes essentially a new paradigm. Through this approach, a given set of user interactions can be used with incredible amounts of content that is maintained in a database layer. We use powerful tools running under graphical user interfaces (AimTech's IconAuthor and Borland's Turbo Pascal for Windows running under Microsoft Windows) to create the interactions as well as tools to format the data for inclusion into the database for particular sets of lessons.
Our efforts have yielded incredible economies of scale in materials development and we have been pleased to see some of the concepts we have developed be used in projects out in industry. We have enjoyed success, nevertheless, we feel strongly that we are just getting started in our development of cost-effective interactions and development approaches.
New development paradigms require powerful development platforms running with operating systems that are suited to the development task. The evolution of the microcomputer industry has given us what I call the Dual Double-edged Sword Phenomenon: Macintosh and MS-DOS. On the Macintosh side, Apple's absolute control results in greater ease for users who must integrate additional functionality into this environment. On the downside, a smaller installed base has given rise to fewer hardware and software options that often bring higher prices than are usually seen on PC-compatible products.
On the other hand, MS-DOS flexibility has created a huge installed base that in turn has generated a large number of machine and peripheral manufacturers. This of course has driven prices down, but the lack of the monolithic control of the overall system enjoyed by Apple has created integration problems that at times defy the imagination.
To better understand this situation, let's examine the past. Rumor has it that during the design of MS-DOS and the de facto IBM PC standard, system developers tried to imagine how much memory would be the most required in the unit they were creating. Contemplating the "big" microcomputers of the day (64K!) they said, "Let's make ours ten times as big."
Whatever its origins, the MS-DOS/Intel architecture has its problems in the form of the 640K memory model and the 64K segment memory management approach. Graphics memory, device ports, and device buffers have been placed in the area between 640K and 1meg (high memory), with the lack of standards creating many serious integration problems. The innumerable devices that make willy-nilly use of this high memory address space makes our lives difficult on a daily basis. The 64K segment problem is perhaps even more serious and has made things difficult for programmers for years. As we have implemented devices that are a little bit out of the ordinary, the restriction of cramming powerful (read large!) digital development tools into the same 640K made available on early IBM PC's has become an almost impossible hurdle.
Here is an illustration of the kinds of problems we face, this one resulting from the lack of memory address standards. As I recently installed some multimedia development software, I discovered that the software needed every byte it could get of the machine's main 640K of memory. The only solution was to purchase and install the recommended memory manager and tweak software access to the memory between 640K and 1meg for the particular machine's graphics card, hard disk controller, and other peripherals. Hours and hours and hours later we discovered that the particular SCSI harddisk controller in that machine would not allow things to work properly. Swapping for a slower controller card enabled us to proceed with our work.
Running this same software offered its own special challenges. Its purpose is to digitally encode audio and video for placement (interleaving) into a single CD-ROM XA data stream. The software works but it is necessary to encode the video into a single file and then encode the audio into another separate file. With a nice interface, the application allows the two files to be synchronized, removing the skew between the audio and video, i.e. so lips move with the appropriate sounds. This is a non-trivial process and although this software is functional under MS-DOS, the developer's job would be greatly simplified with a multi-tasking system. It should be possible to accomplish the three tasks (audio encoding, video digitization, and interleaving) simultaneously, greatly speeding up XA application development.
Whether we consider the requirements of digital applications development tools, the difficulties of the older Intel architecture with 64K memory segments, or the problems that arise from the lack of specification of how high memory is to be used, it seems obvious that something has to change. In order to address these issues and yet to continue to benefit from the economies of scale that exist in the MS-DOS world, we absolutely must implement 32-bit operating systems as soon as possible on development stations.
Implementation of this type of system is possible on 80386 and more recent microprocessors and will provide software developers access to large memory segments and true multi-tasking. I am not too concerned by whether the operating system will be OS/2, UNIX, or Windows NT just as long as the capabilities not present in MS-DOS are provided.
Such a move will give programmers the large memory segment size they need to help insure that software progress will have a chance at keeping pace with advances in hardware. Multitasking will facilitate the development of the capability to do such things as simultaneous encoding the of the audio and video portions of an XA data stream as I mentioned earlier. In addition, manufacturers need to devise and adhere to a memory specification that will address system integration problems.
Despite the challenges we face as we move into multimedia development, I am convinced that multimedia will be a hit in several ways. This is somewhat contrary to the thoughts of John McCormick, who in a column in Government Computer News, states that "Multimedia, or Lotus meets the Simpsons, is a no."
In my mind there are three reasons why McCormick is wrong and why multimedia will prove to be a useful technology. First, the information explosion is flooding us with more data than we can handle. We need better ways to generate, store, and transmit the knowledge that is obtained through the processing of this data. It appears to me that multimedia is a natural step in the evolution of communication, a further development that allows the means of transmitting information (words, images and sounds) to more closely reflect the actual information or knowledge being transmitted. This move toward increasing fidelity is seen in previous developments in the ways that words, images, and sounds are handled (printing, photography, radio, hi-fi, television, etc.). Thus multimedia is a dynamic but yet straightforward extension to what we have done before, an extension that allows the dynamic world in which we live to be more adequately represented for purposes of communication.
Second, for most all of the 90-100 million PC's in use, it is often estimated that the typical user obtains no more than 20-40% of the total potential benefit of his or her hardware and software combination. It seems clear to me that applications such as Lotus' multimedia SmartHelp functionality will help us users move beyond the comfort zones in software functionality we all seem to find and settle into. In fact I am dreaming about the day when a task (on my multi-tasking machine!) will monitor my key strokes and will recognize patterns captured and identified during research. A talking head representation of that task will pop-up and say, "Mike, I have been watching what you have been doing and can show you a better way. May I?" This "agent" would then proceed to take me through a multimedia demonstration that would help me move to a new level of productivity.
Finally, the complex world in which we live has rendered complex many processes that used to be simple. For example scientific advances of the past century were often made by single individuals working alone in their laboratories, perhaps with the aid of an assistant or two. Making progress in scientific research today often requires the inter-working of a team of individuals that must create, communicate, and react to the work of the other team members. Multimedia has the potential to significantly facilitate this very complex process.
Yes, multimedia is more than a marketing ploy or a flash in the technological pan. For it to be useful, however, cost-effective applications development is an essential pre-requisite. With the creation of standards, powerful applications development methodologies, and multi-tasking development systems on affordable platforms, multimedia developers will be able to cost-effectively produce the materials these applications will require. Progress toward cost-effectiveness will be facilitated if manufacturers can make important decisions based on technological advances rather than on politics.
The ways we apply cost-effective development is also important. For example, it is difficult to beat the cost-effectiveness of the creativity of one individual working alone. Just as great books, paintings and symphonies are most often the works of single individuals, many of the early hits on the Apple II were produced by single programmers. To produce their applications, these early pioneers were willing to put in the necessary blood, sweat, and tears often impossible to obtain from large teams working in development houses on software for today's complex systems. Maybe most multimedia applications are too complex for this individual effort to still be feasible, but I would like to think the implementation of the capabilities I discussed here will help keep title development as simple as possible. If we can't rely on single individuals, then maybe the capabilities I have discussed will at least reduce the size of development teams, thereby increasing quality at decreasing costs.
Fritz, M. (1990) Inside CD-I. Data Training, IX(4), 29-30, March 1990.
Lidard, S and Hix, D. (1990) Digital Video Interactive: What Multimedia Developers Think About It. Virginia Tech DVI Project Research Project Report. Funded by the NCR Corporation and the Virginia Center for Innovative Technology.
McCormick, J. (1991) My Predictions for 1992: OS/2 and ACE Go Nowhere (Whew!). Government Computer News, December 9, 1991, p 19.