May 25, 1999

A New Approach

Even though the purpose of these columns is to allow me to write short thoughts without having the burden of fully exploring the idea (or the reader having the burden of wading through long writing). But I've found myself accumulating ideas rather than writing them down. My goal is to keep a current column on my computer's desktop so I can easily add new topics. The result is likely to violate the fundamental rule of good writing by focusing on my interests rather than creating a coherent story for the reader.

I would rather think of it as piquing the reader's interest with the intent of following up more coherently later. If there is interest (including comments via email), I can elaborate on topics either privately or in another essay or column. The columns are meant to start a topic, not end it.

TIF vs File Name Suffixes

Or, the longer name, TIFF for Tagged Image File Format (.tif in the MSDOS file system). Seemed like a great idea, file that contains graphic images tagged with their format. One needn't worry a confusing set of suffixes such JPG, PCX, PIC, GIF etc. Instead there would be a single graphics self-describing graphics file format.

The problem became apparent when I attempted to view a fax and found that Adobe PhotoDeluxe had], once again, hijacked (declared itself as the handler for) the .TIF suffix and then discovered it couldn't read the fax graphics format. In Windows only a single program is associated with a file type (suffix). In effect, the TIF file is itself a file system with its own content. But since it seems to be a single file to Windows, it follows that a single program must be able to handle all the graphics format it may contain.

The new container is more sophisticated than the standard file system and allows for rich descriptions of the contents and better organization. But the price is that all graphics tools must play by TIF rules and support its model of sharing the handling of the contents.

While this should be an advantage of the uncoordinated use of file names with its attendant confusion it requires all graphics programs cooperate with the new mechanism and requires the user have a new set of tools to understand the files.

By using the standard file system as a container one gains access to all the support tools for files including the ability to determine the type of a file just by looking at its name. There are many problems such as users giving files names with incorrect suffixes or just confusion about what a given file type is. But this simply reflects the normal ambiguity and confusing in the rest of the world.

It forces a defensive programming style in which a program cannot assume a file is what it says it is nor that the content is valid. But that's good practice in any case.

The advantages of vigilance go beyond catching user mistakes. It also detects malicious behavior and improves compatibility by detect rather than tripping over what is often called bit rot - the tendency of information to go bad due to changes in its environments. A word processing file from an old version may be officially supported but contain corrupt data due to a long-forgotten bug or minor design decision.

Once again, a sophisticated solution turns out to be inferior with a simple, though flawed, approach. The simple approach has the advantage of reflecting the errors we are used to encountering every day. Thus we are in a better position to find solutions. A system that hides too much information might prevent some obvious problems but leaves us unable to cope with those that do arise.

WinCE Revisited

Windows CE is Microsoft's operating system for Consumer Electronics devices. Follow the links on the title in this section for more information about the platform and the devices.

I'm using two WinCE systems now. One is the AutoPC in my car and the other is the HP Jornada 420. I bought both more due to curiosity than the belief that they are the right designs. Though they both use the same operating system they are very different:

The AutoPC

The AutoPC seems like a reasonable idea: Place a Windows-like system in a car as an entertainment and navigation system. While the full Windows (nonCE) is an effective (even if problematic) platform, the AutoPC shares little of this. It has the general problems of WinCE, including a lack of tools and resources and too little memory and storage to support more than a very limited number of tightly-coded applications.

The AutoPC has the additional problem of being isolated. It is difficult to write software for it without a development environment. The device is isolated in the car, thus far from the PC. Even though it is annoyingly windows-ish, for example, the main push button is the "Enter" key and the "back" is translated into ESC to the OS, it lacks the necessary screen and keyboard for local development.

This wouldn't be so bad if it were a connected device but it isn't.

The most frustrating aspect, which harks back to arguments I had when I was at Microsoft, is that it was compromised for a nonexistent design point - the customer who will pay over $1000 for a hard to use radio because it is also a computer and a navigation device.

Thanks to Infogation there is a reasonable navigation program. Reasonable, that is, considering the limitations of a small screen, clunky model UI, a GPS that lacks backup (such as accelerometers) to compensate for an unreliable signal, and a limited database from Navitech. It is also NPR-hostile. For those listening to talk on the radio, having a discussion interrupted by a long explanation of how I should drive is very annoying. Humans are capable of paying attention to multiple audio streams. I can get navigational hints without being forced to lose radio for long periods of time. It is also annoying to have to go out of map mode into radio mode to make a station change while driving. The lack of a hard disk so that one can't listen to music and navigate at the same time is just silly. It's just one consequence of trying too hard to avoid thinking about the device as a computing platform and thus failing to give the user much advantage of having a computer in the car.

This reflects the basic devolvement of Microsoft from a company supporting a marketplace for its developers to a company doing final ossified products that reflect design decisions frozen early in the design cycle.

I look forward to Empeg's product. It is a Linux system in the dash that can play MP3 music. The early version will be closed single-purpose system. But it represents an opportunity to build upon a generic platform. Linux does have its advantages, but I find that Windows is still the basis for a very rich set of tools.

The Jornada 420

I've grown to like it. I had an Everex WinCE machine, but it was too slow and the monochrome screen was hard to read. It also had some mechanical problems.

The Jornada comes with its own problems. It is big and clunky and has a short battery life. But I now wear shirts with large-enough pockets and dock the machine frequently.

I've been a Pilot user for a long time and was reluctant to switch away from its leaner and quicker user interface. But the Jornada's color was too much of an appeal form me to ignore it. I've since found that the speech recorder is a great feature that is simply lacking on the Pilot. The Jornada is also sufficiently fast to make up for some of the UI complexities in WinCE.

I've added some software including Utopia Soft's MP3 player and NS/Basic for development.

Of course, there are still some problems. I have tried to synchronize using Socket's compact flash Ethernet adaptor, but it refused. And even if I do succeed, it seems to only want to replicate with the machine that it first got to know on a serial line. I can't even tell it that the machine has a different name on the Internet than it does locally. This is an area that needs lots of work and reflects very limited thinking in the design.

A quick Jini Observation

I've written about Sun's Jini - their protocol for cooperating devices. I finally figured out the simple explanation. At least, simple for those who know about General Magic and their Telescript language. One claim was that one needed to send procedures over the network to lookup phone numbers. It was obvious, at least to me, that this was silly. In fact, one simply sends query parameters. The most common standard is LDAP, but any bilateral agreement can work.

Jini is Telescript reborn. It sends procedures when simply queries would suffice. And, harking back to the TIF/Suffix discussion, simply descriptive requests are much more supportable. No need to make a strong case against Jini since it is doomed. One reason is that it builds in assumptions about the problems it is trying to solve and how to solve it. Closely related to this is the propensity to use Java objects where simple messages would suffice and would make it easier to have others create alternative solutions. Jini seems focused on competing with the PC rather than creating a new kinds of relationships between devices. It seems to be more a programming tool than a way to empower users to create their own solutions. Oops, I'm starting to make a strong case...