The future that everyone forgot
Some of the work we did at Danger
I came across a website whose purpose was to provide a super detailed list of every handheld computing environment going back to the early 1970's. It did a great job except for one glaring omission: the first mobile platform that I helped develop. The company was called Danger, the platform was called hiptop, and what follows is an account of our early days, and a list of some of the “modern” technologies we shipped years before you could buy an iOS or Android device.
Who we were and where we came from
Way back in early 2000 a new consumer electronics startup was founded and took up residence in Palo Alto, California. The company’s name was Danger Research, Inc. The three founders (Andy Rubin, Matt Hershenson, Joe Britt) were all Apple alumni. They were involved with several companies between Apple and Danger (General Magic, Catapult Entertainment, WebTV) but I still always think of them as being Apple guys.
Anyway, the early cast at Danger was largely from Apple, WebTV, General Magic, and Be. I was one of those Apple people. Joe had invited me to lunch one day—sushi, as I recall—and when we were finished eating he casually mentioned that he and Andy had started a new company and asked if I wanted a job. I said, “yes,” without even asking what the company was going to do. I figured that it would probably be cool. Danger ended up being the most fun place I’ve ever worked (and not just because of how cool it was to be known to the world as chris@danger.com).
But first, Peanut
You see, it was all about portals
Think back to 2000. Web browsers are just a few years old, your parents probably didn’t have email, you possibly didn’t own a cell phone yet, almost no one had broadband. The commercial web was all about portals—big monolithic sites that you’d visit to read your mail, view your calendar, check headline news, etc. all in one place. The internet was all abuzz with the idea of merging big media with the web. This stuff was costly so they needed to keep your eyeballs on the site as much as possible. Any new thing they could tack onto a site to keep you there a little longer was fair game.
I started at Danger in April of 2000. If you’d like a shock take a look at what the yahoo.com front page looked like back then. (Actually, the shock is how little it’s changed.)
The huge problem facing portal developers then was that they only had access to users while they were at their desktop computer, often only at work. There were no general purpose connected mobile computers. Well, there were a few but they were super costly, and aimed at enterprise users. They didn’t exist to help Mom check her online to-do list while in line at the grocery. Danger’s original product idea aimed to solve that problem.
We code-named it Peanut (possibly because it was shaped like a Nutter Butter cookie). It was a keychain fob with a small LCD display and some buttons. The idea was that it would be a one-way data device that would hold the most important bits of info from your portal account so you had it with you at all times (to-do list, calendar, most recent emails, etc). The plan was to sell the end-user a Peanut for $1, and then charge the portal a monthly fee to run a service that would tie the portal data to the user’s device. This cool new value-add seemed like something the portals would want since it would bind the user to the portal even more tightly.
We had two methods of getting data onto Peanut. The first involved placing your Peanut in a dock that connected to a serial port, and then going to a special web page that would talk to a custom browser plugin (that’s what I originally worked on) to pull the data down and store it on your Peanut. We did some crazy demos with that, and my favorite involved ads. While your data was being downloaded we would show an ad in the plug-in’s frame in the browser window, and also show a complementary animated ad on the Peanut’s LCD screen. This data sync was something we expected you to do once per day to get the big data movement done.
The second method was to send the data over FM radio subcarrier. We had this plan to lease bandwidth from radio stations in every major metropolitan market. If you could receive FM radio, you could get your data. That technology was obviously one-way, and couldn’t send very much data at one time, so it was intended for small incremental updates throughout the day.
We actually got all of this stuff working, and the fact that it used FM radio to transmit the data opened up some interesting possibilities. One of our ideas was that retailers could buy a small, super low-power FM transmitter connected to our network and serve targeted rewards and specials. We liked to talk about folks walking past a Starbucks, having their Peanut go <ding>, looking down at it, and seeing that they’d just received a 10% off coupon that was good for the next 5 minutes. Although we never developed that part of the product, the concept lives on and is now known as iBeacon.
Great for music, horrible for data
There were a lot of problems with using FM radio for delivery. The biggest was trying to convince radio stations to let us attach and manage our gear on their systems. It was going to take a really long time before we would have any kind of serious coverage. The other big hurdle was just figuring out where to broadcast your data. When you signed up for our service we’d get your zip code and broadcast your data primarily from the nearest transmitter. But what if you traveled? We worked out this insane system of slowly propagating your changes out to other market areas once in a while in the hopes of catching you as you moved around. Anyway, it turned out to be a really bad idea. (Microsoft, Fossil, and several other watchmakers would launch a nearly identical product in 2004 called SPOT. It was a dismal failure and they shut it down a few years later.)
Right about that time our VC partner ran some numbers and came up with a great idea. His back-of-the-napkin math showed that for about the same cost as building out and maintaining this doomed nationwide FM data network we could instead do the R&D on a two-way data device hosted on GSM cellular networks. The data service on those networks was called GPRS, bleeding edge stuff at the time. This was awesome! Prior to GPRS you were mostly restricted to using pager networks. Our VC partner even found us a data provider that was looking for devices to showcase on its network—VoiceStream—a small regional carrier in the Pacific Northwest that had spun off from Western Wireless. VoiceStream would later get acquired by Deutsche Telekom to act as the management for its data products division and would eventually be renamed T-Mobile.
Pivoting before pivoting was a thing
So we dropped Peanut and started development of this new thing. We weren’t exactly sure what it was going to be, but we all knew that we wanted one. Since there wasn’t really anything in the marketplace to model ourselves after we just built the thing we all wanted to have in the hopes that other people would share our enthusiasm and want one too.
hiptop
We called the device hiptop (though T-Mobile sold it in the US as the Sidekick). It was the first always-on, internet-connected smartphone. The name hiptop came from the idea that you’d wear it in a belt holster, and thus computing had gone from the desktop, to the laptop, to the palmtop, and ultimately to the hiptop. That justification may have been invented after the fact, but, whatever, it was a great name.
The features
The only product out there at the time doing anything even remotely like what we were thinking of was the early Blackberry. It worked over pager networks, required attaching special hardware from RIM to your IT setup, and was sold solely to enterprise. It was not anything we wanted so we spent some time thinking about what we did want. Being entirely staffed with early-adopter types who had been wired for as long as we’d had that meaning of the adjective, clearly it was going to be focused around electronic communication and personal data management. Since most of us were in our 20's it was also going to be very non-enterprise.
Always-on two-way data—In the days when other wireless PDAs made you have to go into a transmission mode, then do a sync, the hiptop was always connected. Data could be pushed down to the device from our service at any time, and the device could respond immediately. This was a huge leap forward. If you lost connectivity then all of your apps would queue up their activity (outbound emails, calendar changes, etc.) and process all of them the instant you got a network connection again. There were none of the pull-to-refresh or tap-to-retry crutches that are all in vogue these days. If you had a network connection your data was fresh, and you, the user, didn’t have to do the work to make that happen—period.
A brief aside: the world owes a debt of thanks to Jeff Bush who was the first person we know of to get a full TCP/IP stack working on a cellular data connection. The hiptop magic couldn’t have happened without him. Jeff would later move on to work at Apple, and then Palm.
Tons of inputs—being power users of our desktop computers we wanted lots of inputs and lots of ways to tie them together to do extra stuff. We had a 1D roller controller that was also the main action button (later replaced with a 2D trackball), a 4-way d-pad (for games and such), three buttons on the corners of the face of the device (menu, jump, cancel). There was also a full QWERTY keyboard with a dedicated number row. You could chord the menu button with keyboard keys to perform menu actions (cut/copy/paste, etc), or with the jump button to quickly switch between apps. We’d later add two top-edge shoulder buttons, an “ok” button, and dedicated buttons for answering and hanging up phone calls. Written out like that it sounds like a lot but you quickly got used to them and they allowed you to do a lot of complicated actions without ever having to look at the screen.
Multi-Protocol Instant Messaging—we included an IM client(AOL Instant Messenger, Yahoo Messenger, MSN Messenger). We had Jabber support early on (the technology that Google Talk is based on) but we never shipped that. I don’t recall why. You could have up to 10 chats going at once and use the shoulder buttons to rotate between them, or chord the menu button and the number row on the keyboard to jump directly to a specific chat. It supported graphical emoticons and everything. We couldn’t use the full set of Emoji images back then because they were still under copyright from SoftBank in Japan, but we had pretty good coverage of the smileys that most people used.
Multi-Account Email—We supported POP and IMAP. You got a built-in email account when you signed up for service, and you could link in up to three more external accounts. Our email supported rich text (we’d convert incoming HTML mail to a simplified form for display but we handled bold, italic, etc. quite well), images, other attachments (including the ability to send email attachments off to other apps on your device). Our first model only had 16 MB of storage so we couldn’t keep all of your mail on the hiptop at once. As you got low on space we’d start dumping bits and pieces of messages. If you went to read it later we’d bring all those pieces back on-demand over the network.
PIM Apps—Is PIM still a term people use? Personal Information Manager? Well, anyway, we had PIM apps: note pad, to-do list, address book, and calendar. They all did exactly what you’d expect. I’ll say this though, our calendar app handled multi-timezone and repeating events way better than anything else out there.
Web Browser—I saved this app for last because it was such a huge undertaking. At a time when other devices’ idea of how to let users access the internet was to provide a WAP browser (a super crappy, text-only walled garden based on text messages) we allowed you to view the entire World Wide Web.
The magic behind that was in some technology we licensed from AvantGo. We had a big bank of web proxy servers sitting between the hiptop browser and the Internet. When you requested a page it would be fetched by one of our special proxies (which ran a heavily modified version of the Mozilla browser), then fully rendered and measured, and then converted to a highly-compressed list of display elements for the hiptop browser to put on screen. It would fetch, resize, and recompress images. It would convert text character encodings so that the only thing we had to natively support was UTF-8. It did a lot of other magic so that you could still use web forms and other stuff. It was super complicated and difficult to modify, but amazingly well-suited for serving the types of web pages common in 2001.
One of our other browser innovations was to let you leave off the www and .com on URLs you entered into the browser. Type ‘apple’ and it would go to www.apple.com which is exactly what you want nearly every time when you enter a single word. That was one of many cases where we just said, “what really bugs me about x?” and then we would make our own version that didn’t bug us.
Great Text—I am a text geek. I don’t know how it happened, but that’s how I turned out. hiptop had amazing text. We did insane amounts of work on the shape of the keys on the keyboard so that you could easily type without looking. Experienced users easily touch-typed 40 words-per-minute with zero errors. With its silicone keycaps and unique key shape it was amazing for typing. Our users didn’t hesitate to use IM for hours straight, or compose an email that was thousands of words long. I wrote the first version of the text editor and I baked in all the text features I loved so much from my beloved Macintosh software. Selection, cursor movement, deletion (back and forward), page up/down, home/end, they were all there and worked exactly as you expected. We initially had hand-crafted bitmap fonts designed by Susan Kare (she had previously done all the original Macintosh fonts and icons). When other devices were showing you horrible dot-matrix block letters we had this lovely proportional font system. It just looked great.
Since our platform was Unicode-based we could handle tons of non-English languages. You know that thing where you hold down a letter on an iPhone or Android keyboard and it pops up a list of extended options? We did that years earlier.
Ok, so maybe we took it a little too far by showing you the Unicode code point for the characters in hexadecimal. That was only because we had an alternate input method that would allow you to type the characters in in hex—admittedly a little far out on the nerd spectrum.
Cloud Storage—Having your iPhone data all backed up in iCloud, or your Android data in Google services, is super cool and great for today’s users. Years of research has shown that if you have to plug a phone in and manually sync then fewer than 50% of users will ever do it. So having it all be automagic is great. Our early folks that had come from WebTV had been doing this for years already so it was natural for us to do it as well. Everything you did on the hiptop was immediately communicated to our servers and backed up. If you had multiple devices attached to the same account then changes were instantly distributed to all of your devices.
We did a demo once at a trade show where we had someone in the audience give us a quote. Our presenter typed the quote into a hiptop and then put it on the ground and dropped a bowling ball on it. The hiptop was destroyed. He then removed the SIM card, plugged it into another hiptop, signed into the same account and seconds later there was the Notes app with the quote fully restored. Much applause.
Web Apps—Because we had a backup of all of your data we could do some neat stuff for you. One of those was that we provided a web interface to your email, PIM apps, and photo gallery.
This turned out to be a surprisingly big deal. Remember that this was the early 2000's and data over commercial cellular was brand new. Very few places outside of the US had it. If you traveled overseas it was likely that you’d have no data coverage so being able to access all your data via a desktop browser was invaluable.
Along with enabling web apps, cloud storage also meant we could provide a way to sync your data across other services. Sync products were a big market category back then and we added ways for those products to talk to our service on your behalf and sync all of your data to related apps on your desktop computer (Outlook, Lotus Notes, etc).
Multitasking and Interapp Communication—Once you launched an app it just stayed running all the time. In fact, our application framework didn’t even provide a way for an app to quit. Everything just always stayed running. This meant you could do stuff like have the web browser start loading a really big page, switch over and read some email, reply to a few IMs, note a lunch date on your calendar, and then pop back to the web browser once the page was loaded (it would alert you when it finished).
All of the apps talked to each other too. For example, you could select anything in the notes/to-do/calendar/etc. apps, hit menu+m and it would start a new email with that item’s data. Menu+m in the web browser would start a new email with the URL of the page you were looking at.
Any place that drew text would highlight email and web URLs and make them selectable. You could download files from your web browser, store them on an SD card, and then forward them to other apps for viewing or editing. There were many other ways that the apps cooperated with each other as well.
App Store—Although T-Mobile (inexplicably) called it “Download Fun”, the hiptop offered an online app store. There were categories for apps, games, utilities, seasonal stuff, trending products, ringtones, and wallpapers. You could browse the whole catalog online, see screenshots and detailed descriptions, etc. If it was a ringtone you could play a sample. If you clicked the “buy” button it downloaded and installed instantly and the charge was added to your phone bill. No credit cards, no extra accounts, no nothing. One-click purchasing and the simplest billing ever. We also offered a 24 hour return policy. If you deleted an app within 24 hours you weren’t billed for it. It was great. Apple wouldn’t launch its app store until iOS 2.0.1 in 2008.
Speaking of Billing—the cost of the hiptop service was just $19.95 per month on top of whatever voice plan you had with your carrier. It was cheap and easy to understand. No haggling, no deciding which data cap to choose. Granted, by virtue of the networks back then we only used a tiny fraction of the data that today’s phone use, but still, at the time flat-rate data billing was novel and very pro-user.
Over the Air Updates—Knowing that we would need to be able to fix bugs and add new features to existing devices we added the ability for all of the hiptop’s software to be wirelessly upgraded over the cell network. It would all happen in the background and then you’d get a notification telling you the update was there and asking you to reboot. You could defer it if you wanted. iOS didn’t add this capability until late in 2011—a full 10 years after we did it.
Notifications and Music—one area where the hiptop really shone was multimedia playback. We had a RGB LED on the device that we could light up any color. We also had a vibrator with fine-grained controls. This enabled us to do some things that still no one has matched. One of our ringtone format options was an enhanced version of General MIDI. The multi-color LED and the vibrator were both MIDI “instruments” in our system and so you could do really amazing music with synchronized colored lights and vibration. Folks published amazing professionally engineered ringtones for the platform.
When the screen was turned off the LED would periodically blink to let you know you had notifications waiting. You could choose what color and flashing pattern you wanted for each app. For instance, on my hiptop I knew that yellow meant I had unread IMs, blue meant email, purple was for calendar, red was for web page loading, etc. I could glance at my hiptop from across the room and know what was going on.
We also had a mode in our music playback system where we’d analyze the music waveform and pulse the vibrator to match the bass line of the music for an added bit of low-end oomph. It was surprisingly effective. Games made great use of the vibrator too.
The amazing audio engine we had in hiptop is in tons of other things that you’ve used as well. That engine has been open sourced.
The Deaf community
One thing that really surprised us with the hiptop was how popular it was with the Deaf community. There were two reasons behind this.
The first was that the cellular radio chipset we used for the phone portion of our device just happened to be compatible with t-coils. Telecoils are special circuits that allow phones to be used with hearing aids and cochlear implants without causing electromagnetic interference. As of today there are still cell phones on the market that are not hearing aid compatible. In 2001 virtually none were.
The second reason the deaf and hard of hearing users loved us was because we included TTY/TDD applications free starting with the hiptop II(2004). Prior to that, if you were a deaf person who wanted to communicate with a hearing person over the phone you would have to connect a phone handset to a special modem. The hearing person would speak, the operator would type, and the deaf person would read the typing and type back. All of this assumed that you had the device with you. It wasn’t small, and it wasn’t sexy. I imagine most deaf folks just left them at home most of the time.
You also had to make sure you had access to a handset that was the right shape for the acoustic coupler. Ugh. With the hiptop you could get the same functionality without the extra hardware. Our TDD was software based and built in. Suddenly deaf and hard of hearing users could communicate with hearing users anywhere, anytime. A cell phone for deaf users. The letters of thanks we received at the office because of this would break your heart if you read them. T-Mobile did a great thing and offered a data-only pricing plan for deaf users since they couldn’t use the voice minutes. There is an official ASL sign for the hiptop. Can you find the TTY/TDD support in your current smartphone?
Developer program
We knew that third-party applications (especially games) would be crucial to the success of the platform so we had a way for you to write and sell your own apps and have them listed in our app store. Our platform was Java-based which meant that there was a huge host of free tools available for any platform you wanted. All of the tools we provided for packing, testing, and submitting your applications were also Java-based so you could write hiptop apps on Mac OS, Windows, Linux, whatever. As an interesting historical side note: the engineers who developed the Java runtime for hiptop would later join Google and lead the Android kernel engineering team; and develop Dalvik, the Java language runtime for Android.
We provided an outstanding device simulator that let you test everything. You could even simulate the camera and other hardware. It could simulate poor network conditions to see how your app would behave. Lots of neat stuff.
One aspect of our developer program that remains unique is the level of testing we did of third-party app submissions. We had an army of extremely skilled software QA folks who would give each submission hours of testing. If your app was rejected, it wouldn’t be a mystery as to why because we provided you with a multi-hundred item checklist of all of the tests we’d be performing. You as the developer could do your own testing of all the things we would check and have some sense of confidence in your product before you submitted it. It cost us a lot in manpower but I think it was a better developer experience than what you see on Android now (zero testing, tons of malware), or iOS (some testing, no visibility into the process).
One of the apps in our app store was an ssh client that we had developed in-house. This led to the hiptop becoming wildly popular with IT folks since they could use our IM client to chat with folks back at the office about a problem and then use the ssh client to remotely administer their machines.
Another aside: one of my favorite Danger stories was a time when one of our server engineers was stuck in an airport waiting for a delayed flight and noticed a problem with our AOL Instant Messenger proxy. So he used the ssh client to remotely connect to his computer at the office, coded up a fix, kicked off a build, and pushed it out to production.
Encryption
Security and privacy are pretty hot topics these days. I can’t remember how it came up but we had decided that all of the communications between the hiptop and our servers should be encrypted. We used either Blowfish or Twofish with a 128 bit key as the cipher (though we later switched to AES after it was ratified).
Doing crypto requires a lot of hard math operations performed on very large numbers. The original hiptop only had a 24 MHz processor and we quickly found that implementing our crypto in the Java application layer would require minutes for doing things like validating a certificate during an ssh handshake. So all of this stuff was written in hand-crafted ARM assembly. The engineer who did it all told me this great story of having to go to used bookstores to find a book on numerical methods that was originally written for slide rule calculation. When all was said and done we could validate that certificate in five seconds.
A few more things we could do before iOS and Android
2001—Years before Find My Friends, or Foursquare, we had an app called Where My Dogs At? It would show you on a map where all of your hiptop-connected friends were. Phones didn’t have GPS back then so we determined your location based on the cell tower you were connected to. It wasn’t super accurate but it was good enough. One of our engineers also made a cool app that let you leave location-based notes. If you were standing in the right place you could see the notes, otherwise they were hidden.
2002—We all started microblogging/lifestreaming. Our device had a camera, and a network connection, and an email app. We tied all that together with a procmail filter and a perl script that would generate web pages and all our employees started chronicling their lives on the go.
2003 — We later turned that into a service (replacing perl with python). All you had to do was email your text and photos to hiplogs@hiptop.com and they’d get added to your hosted blog. Zero setup. We picked up your account name from the device. It was tumblr and Instagram all rolled into one (and simpler to use). It’s neat to use the Internet Archive Wayback Machine to view old posts.
2005—Full support for Bluetooth headsets, audio systems, and car interfaces.
2009—I was always sort of surprised by some of the amazing deals our bizdev folks managed. One of them was getting dedicated native Facebook, Twitter, and MySpace clients on our platform. I recently learned that we offered a mapping/routing/live traffic app created by TeleNav. From the screenshots it looks like it was pretty cool.
And finally, the coolest thing we never shipped
In 2004 there was a skunkworks project within Danger to merge a color Gameboy with a hiptop—we called it G1. The hiptop’s color screen was manufactured by Sharp and happened to be the same one used by the Gameboy Advance. There were other common components as well. So we figured that if we had virtually the same hardware as a handheld game player, why not play those games?
We extracted a Gameboy Advance chipset and built it on to the backside of the hiptop’s main board. We then developed a custom chip that would let us mix the video signals of the Gameboy and the hiptop so that on a per-pixel basis we could decide which to show on the screen. We made hiptop software that would let us start and stop the Gameboy, or play/pause a game, etc. The Gameboy inputs came from the hiptop’s d-pad and four corner buttons.
This let us do the following demo: start a Gameboy game and be watching regular Gameboy video. Then you’d receive a phone call and the Gameboy game would magically pause, and a hiptop alert window would display over top of the Gameboy video asking if you wanted to answer the call. As soon as the call was over the game would resume.
Since we had our network, and an app store, that seemed like a great way to distribute Gameboy ROMs. We got all of that working too. You could browse Gameboy games in the app store, pick one, buy it, download it, and be playing it in seconds with no need to haul cartridges around with you.
The executives at Nintendo were blown away. They absolutely loved it. Unfortunately…Nintendo’s license for all of the games in their catalog didn’t include rights for electronic distribution. That, coupled with the need to take new screenshots, and write new catalog copy in electronic format, determine pricing, etc. meant that there was just no way we could have gotten a big enough catalog of titles built up in time for Christmas that year. The next window would have been graduation season the following year. The whole project fizzled out and died, but damn it was cool.
Updated January 5, 2014 with photo of G1 prototype, and added Encryption section.
