Mobile Maps for the Masses:

The first Location Based Service (LBS)

Greg Bryant

The first location-aware app 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 servers.

The app was called TrafficTouch, and was the first mobile traffic app, joining the initial batch of digital map applications.

This is the story of how I came to build it, and how it came to be a Location Based Service.

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 partner MetroTraffic, by this time 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 a more 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. Consumers wouldn't accept it.

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 the 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 a 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 hardware-indifferent licensing policy. SONY successfully introduced the Compact Disc as part of an industry collaboration -- this strategy was clearly the future of media.

Consequently, 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 create ONE CD.

It was the most ambitious guide 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.

The logistical problem they faced: how to author HUNDREDS of different Naviken CD's of at least this complexity. Oh, and we may need to make another one really soon.

The victims of the first CD production effort poured out details and suggestions. I began by making sure that I could reconstruct the one-off product, and then I started to substitute chunks of code that were more abstract and parameterized.

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

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, programming language.

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 precede any kind of visual representation of non-visual structure. You need to find notations, a mathematically and logically-consistent technical 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 extracted ideas.

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

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

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, Gatemaker, 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, handmade alternatives. 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 quite straightforward.

"Michael, do you see how, when you look at the Palm screen, every single application is wrapped in a round dot?"

"Sure ..."

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

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.

Foundation work

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

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

Mobile Web

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

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 routes. Of course, JavaScript was not capable of anything like this in 1998. 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 away.

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

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.

March, 2014