Telirati Newsletter #10
This newsletter contains much that is still valid on the topic of legacy baggage, plus a real howler of a bad prediction: That Windows CE (a.k.a. Pocket PC) would be successful. I should have listened more closely to my own words on how the crushing weight of PC clone numbers keeps any other computing platform from being competitive in price and performance.
Newsletter #10: Check your baggage?
On the underside of success you find the encrustation caused by years of neglecting to scrape old features off a product as it sails toward its future. These barnacles can slow a product down until it stops progressing.
It is remarkable that under the weight of an antiquated peripheral bus, a motley assortment of ports of various speeds and interface peculiarities, power and cooling from the dark ages, floppy drives with ridiculously small capacity, a tightly limited number of interrupts devices can use, and an instruction set evolved from an 8-bit processor that would scarcely be considered fit to run your toaster today, the PC marches on. Some of this remarkable buoyancy is evidence that volume conquers all. It doesn’t matter that a stamped sheet metal chassis full of screws and brackets is less efficient than a molded box with snap-in fixtures. If you make tens of millions of the inefficient metal ones they will be cheaper than the cleverest design produced “only” in the hundreds of thousands. More interestingly, it doesn’t even matter if your processor is burdened by the most inelegant instruction set and registers of any processor save, perhaps, the 6502. If you build fabs that cost more, produce more, and drive the state of the art in manufacturing technology and fab construction, you can bury any alternative, like RISC, under unconquerable numbers. Numbers also float the other hardware crud in the PC that would weigh down anything not made in such quantity.
Baggage, it’s real weight, and externalities that make it heavier or lighter control whether products and companies win or lose. It's time to check the weight of your baggage, and your competitors’ baggage.
Look at that keyboard in front of you. Function keys, arrow keys, a numeric keypad, more function keys. The thing looks like the deck of an aircraft carrier parked on your desk. Is there any harm in this excess considering how cheap keyboards have become? Well, yes. How far is your mouse from where your hands are while typing? A good 8" farther than it needs to be. Why? Because at some point in the past, spreadsheets were the reason people bought computers. If it were not easy to enter lots of numbers, computer sales would suffer. Even Apple, which banged it's head against the wall of corporate computer sales without substantial effect for however long gradually polluted the original, well-designed Macintosh keyboard with all the same crud adorning PC keyboards.
Perhaps USB keyboards will save us. With USB, you can daisy-chain devices, like keyboards for all us mouse users that don't carry excess baggage, plus, for those of you that need it, the extra numeric pad, pad-o-buttons, joystick, etc. Apple, of course, had this very solution in the form of Apple Desktop Bus for years already. Did that stop them from crudding up their keyboards? No.
How about those windows? You may recall from newsletter #7 I explained how the desktop metaphor is here to stay until someone comes up with a better metaphor, or framework, for architecting a user interface. But we could have some non-rectilinear shapes by now, for heaven's sake. Gray backgrounds to buttons and beveled edges are the state of the art in user interface. Little color, less motion. We need some ovoids, some anthropomorphic shapes, for relief from the on-screen monotony for rectangular paper shapes. And not be just for the sake of whimsy: A tab-shaped title bar to a window would hide less of what is behind it. And the tabs might move to reveal as much of the tabs on title bars behind the front window as possible -- kind of a self-organizing set of file folder tabs. They would also be easier to see: our eyes process edges. If all the edges on a screen are the same, they fade together and camouflage one another.
Controls that pop out from the edges of a document as needed would also focus the screen display on content and not user interface overhead. Smooth shapes would help distinguish controls from content. If PCs are to converge with TVs, you'll have to clear the screen of non-content material until it's needed. The pop-up task bar in Win95 is a start. Now let's have more of this good thing. And if you are starting from scratch, leave the baggage of old gray toolbars behind.
Icons: Icons are icons of user interface. Only they have silly restrictions that limit them from being pictures, and that makes them baggage. As capacity increases, the number of different data types that have their origins in efficiency or expediency should decrease. A picture is a picture. Size, shape, and such mundanes and bit-depth should cease to be issues when labeling things in the computing environment pictorially.
Despite this user interface baggage, and a good deal more that we don’t have time or space to examine here, Windows looks to make good on the boast of “Windows everywhere.” Why hasn’t baggage slowed down Windows? Unlike Intel, Microsoft cannot shut out competition by redefining industry economics. Making software doesn’t require 3 billion dollar factories. And some of Microsoft’s would-be competitors have spent as much, and sometimes much more, on OS development only to come up short.
Microsoft actively sheds baggage. One recent example is COM+, which effectively shed the ungainly baggage COM attached to C++, and which makes coding COM+ apps in C++ nearly as convenient as Java coding. Windows 95, and even more so Windows 98, go to great lengths not to be weighed down by hardware baggage the PC has accumulated. Imagine the effort it must have taken to treat almost all non-plug-and-play peripherals as if they were plug-and-play by discovering them and how they are configured, and automatically installing the correct software. This works remarkably well, and has taken what had been a nasty, error prone, and time-consuming task, and turned it into the near-equal of plugging peripherals into the elegant self-configuring bus Apple introduced in the Mac II. All this through brute effort at making the PC pig fly. The lesson here is: if you are stuck with baggage, work like the devil to make it lighter.
Other OSs, notably OS/2, did not learn this lesson. OS/2 relied on plug and play support from the BIOS vendors while Microsoft was busy obsoleting separate plug and play (and PCMCIA card and socket services, too). You can’t rely on others to implement something as strategic as making your OS installable on nearly any grungy patched-together PC. Or perhaps it was just Microsoft’s cussed resistance to allowing anyone other than Microsoft to have a franchise on a required bit of software going into a PC. In any case, the result is that you take a card, stick it in the ISA, VESA, PCI, or PCMCIA bus and it just works. N.B., makers of voice processing cards and high-density fax cards, this is the difference between selling a few and selling a lot.
Speaking of OS/2… Two desktop operating systems have recently attempted to change direction. Both Mac OS and OS/2 have branched off into variants that are supposed to operate as NC OSs. There’s a problem with this, however. Desktop operating systems are kind of like very sophisticated Tamogatchis: if you don’t feed them, water them, and play with them, they clog with crud like temp files, configuration files, settings and preferences in system databases, etc. Desktop OSs are by nature the software needed to operate a complete computer system. So, while the NC idea, that the PC has hugely overrun its natural constituency of people who actually want and need a complete computer system on their desks, is a good idea, it won’t get to Jerusalem running Mac OS or OS/2. This is an example of fatally heavy baggage.
Some people get lucky about their baggage. Sun had done a poor job of managing the baggage of Unix. For years and years, Unix stayed as antediluvian in configuration, installation, and operation as it was when I was knee high to a PDP-11. In many ways, it still is just as bad. (Which is not to say it was bad 17 years ago. Unix was cool 17 years ago.) As a result, Sun, which has shone as a beacon of relative stability in the balkanization of Unix, began to lose workstation customers to fast PCs and Windows NT (which is no configuration picnic itself, but at least gives you stultifying and arcane dialog boxes rather than stultifying and arcane text files). Then came the Internet, and some of the things intrinsic to Unix became suddenly all the rage. For a brief window, you could look at NT and Unix and say "Unix would make it easier for me to get on the Internet.” Sun is still riding the momentum of this huge bit of good fortune. Trouble is, Microsoft has long since slammed this opening closed, and is rapidly making NT simple to configure and connect to the Internet so that any small business that wants a presence on the Internet will choose NT. So here is a prediction: If Sun cannot produce a Java OS that sheds the baggage of Unix, and cannot lighten the load on Unix as well, Sun’s momentum gained from the Internet explosion will run out in two years. In five years it’ll be “Sun who?” and everyone will think Bill Gates invented the Internet.
Much of the entire attraction of Java is the lack of baggage. One person had tight control over what was in, and what was not in. Trouble is, you can’t be a fashionable tourist without accumulating souvenirs, and even a retinue. The Java Telephony API is huge. And I recently saw announcements that Sun and IBM are working together on a future user interface standard. Now if that isn’t the crack of doom. There’s probably even some Taligent office space still available.
There is one very interesting lightweight traveler on the scene: Windows CE. While Windows CE cannot be said to be a huge success yet, here is a bold prediction: CE will be very, very important, and will rival the unit volume of Windows 95 sooner than almost everyone outside Microsoft expects. This is because CE is the answer to one of the most fundamental baggage problems: Many people who use a PC don’t need one, and many people who don’t use a PC do need some of the capabilities of a PC. Why is this so? This is because a PC, no matter how well each component has overcome its historical baggage in terms of driving down the price of a PC, it is still a complete, whole, general purpose, super-flexible computer. A PC is made in the image of the minicomputer. Everything is there: you can add any software, remove any software, including the OS, and and remove hardware components -- you can, in short, royally screw up if you don’t know what you are doing. Look to your left, look to your right. Do most people know what they are doing? So to compensate between the competency mismatch between computing and computer users, all manner of kludges and patches, like DMI and Zero Administration, have cropped up to keep Dilbert’s boss from blowing away his already meager productivity and then blaming it on the computer and the people in his company charged with keeping Dilbert’s boss’s PC useful. PCs were made for revolutionaries -- hotheads who can’t wait for the MIS department to get it right. CE is more like what many people really need. If I could screw up my car (which, the manual says, has a 32 bit CPU) by turning it off at an inopportune time, I would not consider it acceptable. Windows CE is more like my car, you turn it off, it stops computing, you turn it on, and it starts again.
In telephony (see, I did work telephony into this newsletter), PBX makers are unloading their hardware baggage and moving the soul of the PBX, the control program, to PC servers. These servers will either control slimmed-down “dumb” switches, or perform PBX-like services for users of IP telephony on intranets, or both. The question is, however: do the functions of a high-end PBX constitute value, or baggage? Do customers really need to minutely control dialing privileges, or are these features just the answer to the question “What do we do now that the switch connects calls?”
How do you integrate user management when moving the software infrastructure of a PBX into a network? Or is that even the right question? Does it make sense to have restrictions on individuals on a data network, beyond restricting them from the data they can access? Do the complex relationships of covering extensions, break-in capability, etc. make sense in an environment where the number of channels open to a desk is effectively unlimited?
What kind of telephony should be ported to data networks? The whole enchilada? Or something more like a simple switch that enables calls on trunks to reach inside extensions? How much of the idea of a PBX can really be ported, and how much must be invented afresh? And what does that imply for which market segment makes the right first target for network telephony?
One approach to an answer is to trace the evolutionary path of telephone switches, and strip the functions back to an earlier stage in development. This approach implies that complex PBX functions, especially the more esoteric user management functions, are not good candidates for implementation in IP telephony servers. This is because they overlap the later, more sophisticated development of similarly intended functions in data networks, and they are farther away from the basics of why we built telephone switches in the first place: to share resources.
So far so good, but we are left with a dilemma: telephony servers are, nowadays, expensive. They won’t ship in large volumes. They are, mostly, direct analogs of high-end PBXs. Big organizations that would gain the most in cost savings by consolidating their wiring plant and using the Internet to economize on calls to odd and expensive locations are now the target market for IP telephony. But is that really the right market given where telephony servers should begin their evolution? The challenge may be less to implement a comprehensive reinterpretation of what a complex PBX does, than to find a way to sell IP telephony to smaller organizations, and then to drive up-market as the product evolves.
Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.
Newsletter #10: Check your baggage?
On the underside of success you find the encrustation caused by years of neglecting to scrape old features off a product as it sails toward its future. These barnacles can slow a product down until it stops progressing.
It is remarkable that under the weight of an antiquated peripheral bus, a motley assortment of ports of various speeds and interface peculiarities, power and cooling from the dark ages, floppy drives with ridiculously small capacity, a tightly limited number of interrupts devices can use, and an instruction set evolved from an 8-bit processor that would scarcely be considered fit to run your toaster today, the PC marches on. Some of this remarkable buoyancy is evidence that volume conquers all. It doesn’t matter that a stamped sheet metal chassis full of screws and brackets is less efficient than a molded box with snap-in fixtures. If you make tens of millions of the inefficient metal ones they will be cheaper than the cleverest design produced “only” in the hundreds of thousands. More interestingly, it doesn’t even matter if your processor is burdened by the most inelegant instruction set and registers of any processor save, perhaps, the 6502. If you build fabs that cost more, produce more, and drive the state of the art in manufacturing technology and fab construction, you can bury any alternative, like RISC, under unconquerable numbers. Numbers also float the other hardware crud in the PC that would weigh down anything not made in such quantity.
Baggage, it’s real weight, and externalities that make it heavier or lighter control whether products and companies win or lose. It's time to check the weight of your baggage, and your competitors’ baggage.
Look at that keyboard in front of you. Function keys, arrow keys, a numeric keypad, more function keys. The thing looks like the deck of an aircraft carrier parked on your desk. Is there any harm in this excess considering how cheap keyboards have become? Well, yes. How far is your mouse from where your hands are while typing? A good 8" farther than it needs to be. Why? Because at some point in the past, spreadsheets were the reason people bought computers. If it were not easy to enter lots of numbers, computer sales would suffer. Even Apple, which banged it's head against the wall of corporate computer sales without substantial effect for however long gradually polluted the original, well-designed Macintosh keyboard with all the same crud adorning PC keyboards.
Perhaps USB keyboards will save us. With USB, you can daisy-chain devices, like keyboards for all us mouse users that don't carry excess baggage, plus, for those of you that need it, the extra numeric pad, pad-o-buttons, joystick, etc. Apple, of course, had this very solution in the form of Apple Desktop Bus for years already. Did that stop them from crudding up their keyboards? No.
How about those windows? You may recall from newsletter #7 I explained how the desktop metaphor is here to stay until someone comes up with a better metaphor, or framework, for architecting a user interface. But we could have some non-rectilinear shapes by now, for heaven's sake. Gray backgrounds to buttons and beveled edges are the state of the art in user interface. Little color, less motion. We need some ovoids, some anthropomorphic shapes, for relief from the on-screen monotony for rectangular paper shapes. And not be just for the sake of whimsy: A tab-shaped title bar to a window would hide less of what is behind it. And the tabs might move to reveal as much of the tabs on title bars behind the front window as possible -- kind of a self-organizing set of file folder tabs. They would also be easier to see: our eyes process edges. If all the edges on a screen are the same, they fade together and camouflage one another.
Controls that pop out from the edges of a document as needed would also focus the screen display on content and not user interface overhead. Smooth shapes would help distinguish controls from content. If PCs are to converge with TVs, you'll have to clear the screen of non-content material until it's needed. The pop-up task bar in Win95 is a start. Now let's have more of this good thing. And if you are starting from scratch, leave the baggage of old gray toolbars behind.
Icons: Icons are icons of user interface. Only they have silly restrictions that limit them from being pictures, and that makes them baggage. As capacity increases, the number of different data types that have their origins in efficiency or expediency should decrease. A picture is a picture. Size, shape, and such mundanes and bit-depth should cease to be issues when labeling things in the computing environment pictorially.
Despite this user interface baggage, and a good deal more that we don’t have time or space to examine here, Windows looks to make good on the boast of “Windows everywhere.” Why hasn’t baggage slowed down Windows? Unlike Intel, Microsoft cannot shut out competition by redefining industry economics. Making software doesn’t require 3 billion dollar factories. And some of Microsoft’s would-be competitors have spent as much, and sometimes much more, on OS development only to come up short.
Microsoft actively sheds baggage. One recent example is COM+, which effectively shed the ungainly baggage COM attached to C++, and which makes coding COM+ apps in C++ nearly as convenient as Java coding. Windows 95, and even more so Windows 98, go to great lengths not to be weighed down by hardware baggage the PC has accumulated. Imagine the effort it must have taken to treat almost all non-plug-and-play peripherals as if they were plug-and-play by discovering them and how they are configured, and automatically installing the correct software. This works remarkably well, and has taken what had been a nasty, error prone, and time-consuming task, and turned it into the near-equal of plugging peripherals into the elegant self-configuring bus Apple introduced in the Mac II. All this through brute effort at making the PC pig fly. The lesson here is: if you are stuck with baggage, work like the devil to make it lighter.
Other OSs, notably OS/2, did not learn this lesson. OS/2 relied on plug and play support from the BIOS vendors while Microsoft was busy obsoleting separate plug and play (and PCMCIA card and socket services, too). You can’t rely on others to implement something as strategic as making your OS installable on nearly any grungy patched-together PC. Or perhaps it was just Microsoft’s cussed resistance to allowing anyone other than Microsoft to have a franchise on a required bit of software going into a PC. In any case, the result is that you take a card, stick it in the ISA, VESA, PCI, or PCMCIA bus and it just works. N.B., makers of voice processing cards and high-density fax cards, this is the difference between selling a few and selling a lot.
Speaking of OS/2… Two desktop operating systems have recently attempted to change direction. Both Mac OS and OS/2 have branched off into variants that are supposed to operate as NC OSs. There’s a problem with this, however. Desktop operating systems are kind of like very sophisticated Tamogatchis: if you don’t feed them, water them, and play with them, they clog with crud like temp files, configuration files, settings and preferences in system databases, etc. Desktop OSs are by nature the software needed to operate a complete computer system. So, while the NC idea, that the PC has hugely overrun its natural constituency of people who actually want and need a complete computer system on their desks, is a good idea, it won’t get to Jerusalem running Mac OS or OS/2. This is an example of fatally heavy baggage.
Some people get lucky about their baggage. Sun had done a poor job of managing the baggage of Unix. For years and years, Unix stayed as antediluvian in configuration, installation, and operation as it was when I was knee high to a PDP-11. In many ways, it still is just as bad. (Which is not to say it was bad 17 years ago. Unix was cool 17 years ago.) As a result, Sun, which has shone as a beacon of relative stability in the balkanization of Unix, began to lose workstation customers to fast PCs and Windows NT (which is no configuration picnic itself, but at least gives you stultifying and arcane dialog boxes rather than stultifying and arcane text files). Then came the Internet, and some of the things intrinsic to Unix became suddenly all the rage. For a brief window, you could look at NT and Unix and say "Unix would make it easier for me to get on the Internet.” Sun is still riding the momentum of this huge bit of good fortune. Trouble is, Microsoft has long since slammed this opening closed, and is rapidly making NT simple to configure and connect to the Internet so that any small business that wants a presence on the Internet will choose NT. So here is a prediction: If Sun cannot produce a Java OS that sheds the baggage of Unix, and cannot lighten the load on Unix as well, Sun’s momentum gained from the Internet explosion will run out in two years. In five years it’ll be “Sun who?” and everyone will think Bill Gates invented the Internet.
Much of the entire attraction of Java is the lack of baggage. One person had tight control over what was in, and what was not in. Trouble is, you can’t be a fashionable tourist without accumulating souvenirs, and even a retinue. The Java Telephony API is huge. And I recently saw announcements that Sun and IBM are working together on a future user interface standard. Now if that isn’t the crack of doom. There’s probably even some Taligent office space still available.
There is one very interesting lightweight traveler on the scene: Windows CE. While Windows CE cannot be said to be a huge success yet, here is a bold prediction: CE will be very, very important, and will rival the unit volume of Windows 95 sooner than almost everyone outside Microsoft expects. This is because CE is the answer to one of the most fundamental baggage problems: Many people who use a PC don’t need one, and many people who don’t use a PC do need some of the capabilities of a PC. Why is this so? This is because a PC, no matter how well each component has overcome its historical baggage in terms of driving down the price of a PC, it is still a complete, whole, general purpose, super-flexible computer. A PC is made in the image of the minicomputer. Everything is there: you can add any software, remove any software, including the OS, and and remove hardware components -- you can, in short, royally screw up if you don’t know what you are doing. Look to your left, look to your right. Do most people know what they are doing? So to compensate between the competency mismatch between computing and computer users, all manner of kludges and patches, like DMI and Zero Administration, have cropped up to keep Dilbert’s boss from blowing away his already meager productivity and then blaming it on the computer and the people in his company charged with keeping Dilbert’s boss’s PC useful. PCs were made for revolutionaries -- hotheads who can’t wait for the MIS department to get it right. CE is more like what many people really need. If I could screw up my car (which, the manual says, has a 32 bit CPU) by turning it off at an inopportune time, I would not consider it acceptable. Windows CE is more like my car, you turn it off, it stops computing, you turn it on, and it starts again.
In telephony (see, I did work telephony into this newsletter), PBX makers are unloading their hardware baggage and moving the soul of the PBX, the control program, to PC servers. These servers will either control slimmed-down “dumb” switches, or perform PBX-like services for users of IP telephony on intranets, or both. The question is, however: do the functions of a high-end PBX constitute value, or baggage? Do customers really need to minutely control dialing privileges, or are these features just the answer to the question “What do we do now that the switch connects calls?”
How do you integrate user management when moving the software infrastructure of a PBX into a network? Or is that even the right question? Does it make sense to have restrictions on individuals on a data network, beyond restricting them from the data they can access? Do the complex relationships of covering extensions, break-in capability, etc. make sense in an environment where the number of channels open to a desk is effectively unlimited?
What kind of telephony should be ported to data networks? The whole enchilada? Or something more like a simple switch that enables calls on trunks to reach inside extensions? How much of the idea of a PBX can really be ported, and how much must be invented afresh? And what does that imply for which market segment makes the right first target for network telephony?
One approach to an answer is to trace the evolutionary path of telephone switches, and strip the functions back to an earlier stage in development. This approach implies that complex PBX functions, especially the more esoteric user management functions, are not good candidates for implementation in IP telephony servers. This is because they overlap the later, more sophisticated development of similarly intended functions in data networks, and they are farther away from the basics of why we built telephone switches in the first place: to share resources.
So far so good, but we are left with a dilemma: telephony servers are, nowadays, expensive. They won’t ship in large volumes. They are, mostly, direct analogs of high-end PBXs. Big organizations that would gain the most in cost savings by consolidating their wiring plant and using the Internet to economize on calls to odd and expensive locations are now the target market for IP telephony. But is that really the right market given where telephony servers should begin their evolution? The challenge may be less to implement a comprehensive reinterpretation of what a complex PBX does, than to find a way to sell IP telephony to smaller organizations, and then to drive up-market as the product evolves.
Copyright 1997 Zigurd Mednieks. May be reproduced and redistributed with attribution and this notice intact.
Comments
Post a Comment