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