Mobile Maps for the Masses:
The first Location Based Service (LBS)
The first location-aware web application for a consumer mobile device was developed
from 1998 to 1999.
It was released to the general public in May of 1999, in-the-box for the Palm VII.
The Palm VII was a Palm Pilot, a Personal Digital Assistant (PDA), with connectivity to
the mobitex pager network, which in turn was connected to Palm's webservers.
It was called TrafficTouch, and was the first mobile traffic app, and in the
initial batch of mobile map apps.
This is the story of how I came to build
this app, and how it came to be a LBS.
It was one of two applications on release that took advantage of a value, in the client HTTP request message, which provided the zipcode of the mobitex
tower that relayed the HTTP request. My client, SONY/Etak, and their partners MetroTraffic and Palm, by this time finally had traffic
alerts organized by zipcode in a geographic database. SONY/Etak had started this digitizing/conversion process with MetroTraffic in 1997,
and this was the first significant product to make use of it.
There was one other LBS on this first LBS-capable consumer device: weather.com. Their browser-based web application already asked a user
for a zipcode, to provide personalized weather reports.
But first, a little prehistory.
The first in-car navigation systems
Etak began 10 years before I arrived, and produced the first practical in-car
navigation systems -- funded by Nolan Bushnell of Atari, and founded by an engineer
who was still there, and looked every inch like someone who spent his spare time in
yacht races. He had sold the company in 1989 to the rightly detested Rupert Murdoch,
who invested heavily in the digital maps side of the business. Murdoch had a simple
vision: own the world's maps, and you could charge McDonald's for an especially
large map icon. He turned out to be wrong about that.
Etak made deals with car companies quite often, who would install their expensive
navigation systems for people with too much money ... oops, I meant 'early
adopters'. An additional client, of course, was that backbone of Silicon Valley, and
of all computing: government procurement.
These nearly custom machines, could hardly
be considered consumer products. But in 1994 you couldn't look at one of these
systems without imagining one on your wrist or in your pocket, so there was broad
understanding that price reduction was inevitable.
Along those lines, Etak stopped producing their own systems, and focussed on partnerships
with consumer manufacturers. By 1994 it had clearly become a software and data shop,
but one that was littered with prototype consumer systems. There was a vast warehouse of
map digitizers and geographers, and a small group of programmers, and a very large
budget: I first heard of Etak around 1990 as a reliable place to get consulting work.
When I arrived, they had a huge problem in software logistics to overcome.
They had a new partnership with SONY, who planned to build in-car navigation systems,
but didn't want to create the standard for them without agreement with their
competitors. They were confident that they could build the best technology,
but that they might lose the 'standards battle' ... the executives were still
sensitive about their defeat in the 'videotape standard' wars. Betamax was a better
technology than VHS, but VHS was a coalition standard among competitors, so
everyone gravitated towards it. SONY still made professional Betacam tapes,
in the shape of the Betamax, but the market was very small. The lesson was
very much compared to Apple's failure, around the same time, to maintain market
share proportional to their product quality, against Microsoft, which had a rather
open licensing policy. SONY successfully introduced the Compact Disc as part of an
industry collaboration, and this was clearly the future of media.
So SONY initiated an in-car navigation system media and hardware standard, facilitating
a coalition of industry competitors, and called it 'Naviken'.
The Logistical Problem
A CD would be a guidebook to an area ... the guidebook was a digital map of the
area and the roads, along with other information depending on the nature of the
guide. There would be many guidebooks, many definitions of 'area', and many machines
... but they all needed to be compatible with each other. That was the mission
of the Naviken consortium.
But when I arrived, News Corp/Etak had only been able to author one CD.
It was the most ambitious that SONY and Naviken had seen, but it was essentially a
one-off piece of code and data. It had been hacked together under high-pressure to
run on a prototype piece of machinery. Which is no big deal. "Hacked together under
pressure" could be the best epithet for the entire history of computing to date.
The logistical problem: how to author hundreds of different Naviken CD's of at least
this complexity. Oh, and we may need to suddenly make one soon.
The victims of the first CD production effort poured details and suggestions over me.
I began by making sure that I could reconstruct the one-off product, and then I
started to replace chunks of code with more abstract and parameterized substitutes.
After a little clean-up, it was clear that most of the sophisticated, high-level
structure, implemented in an inflexible way, could be found nowhere in human-readable form
in the software. The structural interpretation lay in the minds of the original
programmer-designers. As their replacement, and with an ambitious new feature list from
SONY, I needed to listen carefully to the decisions they'd made, and how they
thought about the structure of this geographic, navigational, multimedia
The only thing that made sense, was to build a set of authoring tools. And I found
that the ideas expressed among the previous generation of engineers made quite
a reasonable definition for a general-purpose, yet domain-specific,
Listening to people and building a language that would allow them to more directly
achieve their ends, was something I'd done a number of times already. It typically
is a step that needs to preceed any kind of visual representation of non-visual
structure. You need to find a notation, a mathematical characterization, which is
accurate. Only after that, can you attempt to reformulate the tool in a manner
that is even harder to build: a simple visual representation of a complex reality.
This isn't true of easy ideas, but it's definitely true of complex, barely
The language, sd_rpl, was written in Lex, Yacc and C/C++. It allowed the definition
of map-to-card-deck behavior, the creation of cards and their interlinking (with a
very special kind of querying among already constructed cards), and an overall hypercard
flow for the user. This along with heavily massaged geographic data and other content such
as Michelin guides, shaped by card templates designed with the help of a WYSIWYG Naviken
editor I built (written in Tcl/Tk, a nice tool at the time, which I only looked at because I'd hung
out with Jon Ousterhout when he visited Intel HQ 10 years earlier). This system, with
lots of awk, shell scripts, Make, and M4, generated the image for the Naviken-standard
With some impossible effort, we managed to use it to generate a CD for Paris
in time for an auto show, where it was used in an elite demo (heads of state and heads
of corporations) in a helicopter with special permission to fly over the city.
My colleague Jan Piper was using my languages, with my help, to produce the Paris disc.
In the last week before the show, we didn't sleep, and we'd switch who was programming,
and who was helping, based on who could muster another burst of mental energy. This was
a kind of "extreme programming" and "pair programming" that can be very effective ...
in a life-and-death situation. But, honestly, this is no way to build technology. And
yet this overwork remains common in our impossibly trivial and wasteful industry.
It was easy to make a case for further improving the tools, after the success of the
Paris Show. I was given time to make them easy for anyone to use for new discs.
SONY was SO impressed -- by our performance, the new tools, the quality
of the work and the sensitivity of the user design -- that they bought Etak.
Our liaison became our new CEO, and he reported
directly to SONY's Board and new Chairman, Norio Ohga. The man who decided how much
music should be on a CD.
Things became a little more relaxed. I was quite happy to get rid of the previous crowd,
who seemed unconcerned with moral issues, such as the fact that people were crashing
their cars while looking at their
I continued to publish my magazine about grassroots
community projects, RAIN, and skipped over
to the UK to film a documentary about Prince Charles, his school of architecture, and
their interaction with Christopher Alexander, the most influential practicing
philosopher about a slew of subjects: design, art, cities, architecture ... in computing,
'patterns' were inspired by his work, which led to the wiki, among many other things ...
I came back, published some more discs. This time my colleague was Michael Lunsford,
who would later go work for Palm and, with IDEO, direct the building of a rather
game-changing device, the Palm V, wich arguably inspired Apple's design direction
from the iPod forward.
Around 1996 time I made a number of research suggestions to the new CEO,
which he found quite exciting, to generate 3D maps, with buildings, using
a procedural approach, and to make something like a gaming platform, except
for real-world applications, such as the effect of rising sea levels due
to global warming.
I took another break to do another Christopher Alexander project,
which involved some more influential people, and which I think represents an
important moment in human-computer interface design.
A digression on the two worlds of design
I mentioned that the Michael Lunsford Palm/IDEO collaboration, the Palm V,
was so popular that it basically set the standard for the next 15 years of
tech industrial design. Quite simple really: anodized aluminum with glass.
This was borrowed from the kitchen appliance industry. You can almost see the
subconscious answer bubbling up from the question "how do we make these
computer devices seem more permanent, sturdy and expensive?" Everything
at the time was hard plastic and painted metal. A good glass stovetop
with brushed metal was the height of kitchen cool.
But it's also definitively hard & sterile. The plastic
and painted metal was also bad, but compare either one to customized,
Imagine a phone that you build for yourself, shaped for your comfort, out
of materials that make you feel good. Gatemaker was part of that
yet-to-come technological 'revolution'. (Sorry for the quotes, but I find
that many computer people, poisoned by a
profit-driven marketing sensibility, seem to think that every little
change is a 'revolutionary paradigm shift').
But there's a smaller design story in the Palm V and the Palm VII. It
reveals the insensitivity of the current "age of user design".
While I was in the Bay Area, working with SUN and CES on Gatemaker
and its consequences, I stopped by SONY/Etak to help Michael produce
one last Guidebook.
This was his last SONY/Etak project, but he already had the Product
Management job for what was to become the Palm V, and he spent much of
his time with me talking about the existing Palm Pilot, and its issues.
He had many opinions on the subject, and one day I pointed out something
"Michael, do you see how, when you look at the Palm screen, every single
application is wrapped in a round dot?"
"Well, the first thing I see, when searching for an application,
is a bunch of dots, that are supposed to be 'buttons'. But there's
no way to engage my intution and
just go to the right one ... I have to think about which symbol means
what, and which subtitle means which application. I can usually
remember it, but esentially, the icon isn't very hepful, because its
main characteristic is a filled-in circle. That's the opposite of
what an icon is supposed to do! It's supposed to make life easier!"
He paused, thinking. I continued my rant:
"They did this because somebody wanted the pages of applications to look
consistent and organized, but instead, they've made them useless. I
essentially have to read the icons each time to find the one I want."
"And the real reason for this, is that all the space in-between the icons, the negative space, is identical,
hence it cannot help to differetiate any icon from any other. So most of the screen is
After another pause, he nodded, and said. "That's so obvious."
I'm not sure how he made this case at Palm, but over a year later,
when I received my prototypes of the Palm VII, the icon recommendations
had changed completely. Finally, the icon shapes weren't bordered
and more-or-less hidden by another arbitrary shape.
Notice how this important lesson has been forgotten.
Look at the iPhone
or iPad screen today, with icons similarly constrained by squares. When deisgners
are compelled or trained to focus on the trivial, on hollow style and flash,
there's no real progress. And the fundamentals are continually lost.
Meanwhile, by 1997, Etak was agressively collecting and correcting its digital maps, to an
unprecedented level of quality.
It was also becoming competitive in providing maps to web operations, and was working
hard on geographic database organization, for less costly and faster response times.
It was improving road-data quality, turn-by-turn navigation data and algorithms, and geocoding
services (finding a point on the globe based on a street address).
The work to keep maps pretty and legible was also important, and during the early SONY
work I did some subtle guiding of the company towards something that wouldn't sound
out of place in my Gatemaker work ... using human judgement to determine the best
automated mapping approach, and working hard to find an algorithmic characterization
of good placement and color.
After the end of the Gatemaker project, and one more Etak guidebook with new features,
I found that the suggestions I'd made earlier had been turned into a research
department. My first contract for them was to produce a new kind of navigation system
with 3D map data. This was an interesting UI problem, and I decided on a point-of-view
rendering, kind of like a flight simulator, but running along roads. I built this
3D renderer from scratch in C++, to improve the rendering speed and change the
rendering priorities. With all the subtle color projects I'd been engaged in, it looked
Norio Ohga, the Chairman of SONY, was coming for a demo. He was a pilot, and flew into
Silicon Valley one sunny day, and Etak's research department was his first stop. He sat
at my desk, and we gave him some demos. The POV navigation system struck him, and now
it's one of the standard types you'll find in car navigation systems.
SONY had released their first Naviken-standard product, the NVX-1, along with the
guides produced by my authoring software. I had one more unusual guidebook to produce,
and enlisted Bruce Robertson, and old colleague who had introduced me to Etak in
the first place. Together we polished up the tools again to meet new standards,
and passed the results to teams producing guidebooks for a raft of navigation systems.
After that, Jan Piper asked me down to Menlo Park for two reasons. Firstly, he needed me to add
something else to the first serious PC-based navigation product, SkyMap, which he'd
nutured for a number of years. This was also the first packaged computer software
released under the SONY name. It came with a GPS device, and the idea was to use
your notebook computer as a navigator. It worked quite well, and won PC magazine's
best new software product. This was the first time SONY had an award-winning piece of
software, making the board at SONY quite happy with the company they'd purchased.
So they kept the funding at high levels.
With this money, the marketing department made deals with every upcoming mobile internet
device-maker, and Jan needed me to just take charge, and build and release these products.
This was brand new territory. I worked with tiny text-menu cellphone protocols, with
Motorola's voice-response dialogue software, and an idea from Palm for a web-enabled
Even the palm-based device, which had the largest screen and was dangling the
possibility of location information, had its limits. One of the applications
was a customized traffic report. The mission was to allow the user to
optimize traffic flow through enlightened self-interest. Etak had just automated
an extremely antiquated Metro Traffic reporting system, so we had the data available
to steer people around traffic jams. But to do that, we really needed to know where
people were trying to go, and their preferred routes. The Palm screen, the tiny bit
of available memory for maps, and the wireless communication latency, just made
picking a route on a tiny map too irritating.
So we tried a supporting web-page, which the user could access at home or work.
We needed an applet. I'd just come off of a big Java project, and it seemed do-able,
so I found someone at Etak willing to try to build the complex,
map-loading applet that we would need, to allow the user to determine preferred
I managed this in parallel to client-server programming I was doing, which
included wandering around Palo Alto testing a prototype Palm VII, and the
geographic database I was directing another team to build.
Although this browser-solution worked, we included some independent geographic functionality in the
mobile app, just in case no PC was available. These devices, recall, had no browser.
And a mobile browser that could run anything even resembling a Java applet was years
Luckily, I convinced the marketing department that all these features could
be sold to customers as part of the premium service, a kind of mobile subscription
on top of the Palm subscription. This multi-tiered approach to charge for mobile
device services was not new, of course.
Which begs the question: what were the basic, non-premium features of TrafficTouch?
Essentially an "incident map" and an "incident list", based on the zipcode reported
by Palm's network. The limitations of the Palm device, and the availability of
the user's location, turned TrafficTouch into a serious LBS mobile app.
This was the first traffic app, but I must say, 15 years later, although occasionally
helpful, the actual usefulness of re-routing information is quite minimal. At the
time, this was the spearhead for an old dream, which Etak had often pitched and sold
to government transportation planners, to optimize traffic flow. While I was willing
to build the technology, I'm also an alternative transportation activist, and I
knew that the only way to significantly reduce traffic problems were to reduce trips
and reduce travel speed and throughput.
The most famous study supporting this thesis involved Hammermith bridge in London, a major choke point in
London's traffic. There was a need to shut the bridge down for repairs, but beforehand,
the City surveyed drivers who were regularly stuck in traffic on the bridge. They found
significant reduction in actual trips when the bridge was shut down ... and traffic
levels adjusted accordingly. When good public transportation is available, simple road
closures eliminate unecessary driving. Slowing down traffic has similarly been
found to be effective. Self-re-routing cars armed with traffic info? ... not so much.
It took a great deal of work to make the premium, browser-based routing applet
work properly, because even by late 1998 Java was pretty shaky for large applications.
In the same amount of time, we could have created a very robust C/C++ application
or Tcl/Tk application for a desktop. But we wanted to put it in a browser. This clash,
between the need to webify and the browser's technical limits, led me to the idea for
using a browser as a thin-client to a Unix box running desktop applications, and I
released the first such service for GNU/Linux in 1999 at my Palo Alto based company
WorkSpot. This was the first such commercial service to use VNC after it became free
software. It would have been perfect for the TrafficTouch problem, and I later
showed off a VNC-to-WorkSpot app on a Palm VII, at Palm HQ.
After TrafficTouch was wrapped, and the servers stable, the general discussion
towards the end of 1998 was about Hotmail, a simple mail service that had just sold
to Microsoft for $400 million. TrafficTouch, for example, was a much more sophisticated
application than Hotmail. Even the executives around me were asking "what are we wage-
slaves doing, building something for a corporation like SONY, when we could be building
something for ourselves, and selling it for a fortune?" Well, my motivation was to build
things that might be genuinely useful, empowering and beneficial to people, something
corporations almost never do.
I remember describing to people the way Etak could do this -- on the
street. "Let's set up at a cafe in downtown
Palo Alto, or on a street corner, and build little useful products based on GPS and GIS,
based on people's suggestions, and see what sells, or even see if people would be willing
to pay for services to be available for free to others."
Fundamentally, this is the direction that GIS and mobile ultimately took. Look at all those
I left Etak to start WorkSpot, with a first contract to build
eBay's first mobile app, and about 20 of Etak's top engineers came to my start-up.
Soon afterwards, SONY sold Etak to its longtime rival, Tele Atlas.