Importance of ``push''
The first step in achieving The Keitai is to realize that most of the
traffic on Japan's successful wireless webs (EZweb, i-mode, J-Sky) is
not wireless web traffic at all---it's ``push''-based email.
Therefore, the so-called ``browser'' needs to come second on keitai.
With US handsets, the browser is the first and the only application
available.
I keep saying this, but ``pull'' email is no good. WAPmail and POP3 have to go. However I think ``push'' applications have broader relevance than just email. Particularly on small screens and high-latency networks, pull-based web browsers are annoying.
Let's be clear about this. ``push'' does not mean broadcasting advertisements into a keitai for later delivery over some shared channel like ``AOL art.'' It's not a way to blast ringing coupons at helpless pedestrians as they pass storefronts: charge the store to send ads, charge the user for access to the ad stream, everybody wins! Nor is it about delivering stock-news-weather-sports cheaply to lots of users at once. Why does everyone think I want stock quotes, news, weather, and sports scores while I'm out walking around? Sure, it is easy to provide, but is email so hard?
As I loosely use the term, ``push'' means anything that's not ``pull'': anything that defies the tired and presumptuous client-question, server-answer model. Properly-implemented email and ``instant messaging'' qualify. Multiplayer soldier games, Unix shell logins, and Nextel Direct Connect also loosely qualify. Supporting push services has network requirements that ``pull'' doesn't: the keitai and the packet connection both need to be ``always-on,'' and the keitai needs to have a unique network address that's valid to the push application servers, not just to some simplified WAP gateway.
``Read-ahead'' is another concept that might prove useful, even though it's not the same as ``push.'' For example, a really long news article or a full-length book might get sent to the keitai lazily and predictively: at any moment, the keitai wants to contain all the text on the screen plus a few pages of text above and below the screen. If the user reads or skims the text rather than jumping to a random chapter, the keitai will seem to contain the entire book without the waste of transmitting huge chunks of text that the user never bothers to read.
Similarly, a web server might send URLs that the browser hasn't requested, but that the server thinks it will soon request based on its experience with the links that past users tend to follow. However this type of read-ahead is tricky for users who pay per-packet because the corporate coders' idea of what's interesting enough to pre-send is likely to differ from the paying user's idea. Since the cel network megacorporation will probably control all the servers, gateways, and applications, I bet they will decide to preload all the advertisements on their partner web pages so that anyone who clicks on an ad gets delivered to the advertising partner superfast. And the subscriber gets to pay for the extra packets to send these ads. ``DRIVE hits to your web site!'' maybe not such a fantastic precedent to encourage.
``Can you hear me, Rod?''
``Todd, you're breaking up. Why don't you call me later?''
``Can you hear me, Rod?''
``Can you hear me?''
``Rod, can you hear me?''
``Rod?''
``Rod, are you there?''
``I THINK THE PROBLEM MUST BE BETWEEN MY MOUTH, AND THE PHONE. ROD! ROD! ROD! CAN YOU HEAR ME? I'M IN SOME TRENDY COFFEE SPOT. CAN YOU HEAR ME, ROD? I HAVE A MOTOROLA STAR TAC, AND THE MICROPHONE DOESN'T QUITE REACH TO MY MOUTH, SO I HAVE TO SHOUT SOMETIMES! HELLO? I CAN'T, ROD, ARE YOU THERE? HELLO?''
``Okay, Todd. I'm right here <coughFucker>. It's called radio, dipshit.''
Anyway, like I was saying the only two reasons to turn off a keitai are exceptional. Therefore, the battery must last as long as you're away from your home: long enough to sleep over at someone else's place and go out to breakfast the next day. I think this is about 33 hours, 6:00 - 15:00.
Most Japanese keitai for the PDC networks last over 100 hours, but CDPD terminals, Ricochet terminals, and Ericsson's R380 phone-PDA combo last only 6 - 16 hours. While standalone PDAs usually need battery charging or replacement weekly or less often, that's a disingenuous boast because they're turned off most of the time. With ``push''-based ringing email, PDA battery life plummets. My MobilePro 800 dives from achieving the industry-standard 1-week-under-typical-use with lid-close suspending down to 4 - 16 hours depending on backlight intensity when it's always on. Battery life remains a challenge, and it's fairly important to conquer it.
The screen must have high contrast in both total darkness and direct sunlight. My MobilePro 800 fails miserably in this regard---older PDAs have either reflective screens with junky backlights or regular laptop screens that are too dim in the sun. I don't know what's going on out there now because my phone is too old, but I think there are good backlit transflective screens now, right? I noticed one trick the iPaq and MobilePro both use to varying extents is, while a normal laptop or desktop LCD panel tries to boast a wide viewing angle, they put a Fresnel lens on the backlight and deliberately make most of the light come straight out, blasting a squareish tunnel toward the eyes of a centered viewer perpendicular to the screen.
Smooth-scrolling with an analog wheel or stress-stick would be nice. The screen needs to be fast to do smooth scrolling without blurring, but this isn't a big challenge.
802.11b and PHS devices seem to often have two antennas these days. Maybe some day devices will have insect-eye antennas, creating a reception sphere or reception doughnut of 10 - 20 antennas. This would be great for saving battery life and conquering multipath, and it might eliminate the solid-state compass in LBS keitai. Maybe MIMO is sort of like that, but not exactly. Anyway, I think whip antennas are lame.
On the train today, I had an epiphany watching some guy gab on his flip-phone. The line between one's mouth and ear is nearly horizontal, and cel systems are vertically-polarized. An antenna parallel to the phone's long axis isn't properly-oriented while the phone is in use. An actual vertical antenna would almost stick out parallel to the hinge rotation on a flip phone. so let's quit with the lame whip antennas.
I dislike four-way joy-blobs or movement-rings, because (1) four-way isn't a convenient one-handed pressing gesture, and (2) there is nothing in a keitai's user interface that should map to four cardinal directions.
I dislike softkeys with labels on the screen. For example, Nokia has lots of one-button handsets where the wildbutton is labeled in the lower-center of the screen. If there is only one button, why does it need a label? There is no chance of pressing the wrong button, because there is only one button. The button's appropriate label is therefore ``the button.'' I know, I know, the label is a sort of context-sensitive help, and it more or less works well.
Likewise, the i85s has two soft-buttons in addition to its Send and End keys. However the keys are backwards with respect to each other, so the screen will say:
+---------------+ | | | Call from | | +13035452390 | | Answer? | | | | Yes No | +---------------+ [ o ] [ o ] X [End] [Send]
umm... DUH. Motorola is fired once for excessive buttonage. They're fired a second time for making multiple buttons do the same thing. And they are fired a third time for getting the redundant buttons backwards. Hopefully this is boring for you because you already realize Motorola interfaces are below par.
I don't know if the keys need to light up so long as they have a good layout, but lit-up keypads look cool, so as a practical matter I think that keyboard backlights are mandatory. This is another feature that keyboarded PDAs like the Nokia 9210 and the Ericsson MC218 lack. It would be even cooler if the user interface could control the color and analog intensity of a few keys seperately. The machine should give the impression that it wants to be touched and handled, so the keys should beg for pressing.
First, the batteries on Ericsson's 3V handsets (T28, R320) gave the industry a real schooling. Internal compartments create dead airspace and redundant clasps and springs, while their batteries simply snap onto rather than going underneath some cover. I haven't seen the latest ``Sony-Ericsson'' stuff, so maybe they've recanted.
Second, instead of selling accessory blocks that snap onto the handset, why not sell blocks that snap onto the other device? For example, for older laptops that are missing Bluetooth hardware or software, don't make an IrDA fob, or a twelve-foot voltage-quadrupling serial cable that looks like an engorged snake and coils up bigger than the keitai itself. Instead, make a Bluetooth modem-emulator fob that gloms onto laptop USB or serial ports. Maybe the fob doesn't always need to give your laptop Bluetooth access---maybe it just emulates a plain serial port, for simplicity and compatibility. This is a superior sort of remedial device because it parasites onto the big laptop, not onto the small keitai. Likewise, I've got little interest in a heavy ear-twisting Bluetooth headset loaded down with a battery, but a strap-on Bluetooth vibrator with a jack for a light analog headset makes more sense.
I like the copper-pads-inside-the-battery-compartment connector, the one where a C-clamp mates directly with the mainboard. If you need to debug, upgrade firmware, or calibrate the microphone, that's the way to do it. It's stylin'. Forget all exterior jacks besides charging pads.
OTOH I still think antenna jacks are a good idea. Sorry! Tethering a one-handed keitai isn't the greatest result, but I'd be pretty keen on buying an NEC t-shirt with an 8dB antenna woven into the fabric.
I think the tablet is altogether a non-starter. While handwriting recognition is kind of cool when it's done well, (1) it hasn't been done well since the Apple Newton 2000, and (2) even when done well, it is merely cool, not useful, because fast 12-button keitai typing is equally easy to learn as fast, error-free handwriting style. Future keitai may have ergonomic keyboards rather than the current trivial solution of touchtone pads, which should allow even faster typing.
Forget the tablet. Forget the Palm and the iPaq and any other 320x240 keyboardless device. However, both the keitai and the pad make more sense to me and seem kinda useful.
``But,'' you are begged to object, ``surely you must choose one or the other. Otherwise, you have to pay for two expensive delicate devices. You have the synchronization mess of smearing the same data across too many silly toys, the differing applications available on each platform, and the wireless carriers will want to double your bill for two devices.
I think we need some new shapes than these three. Here's a fourth shape:
I like that shape. It's sort of like the danger.com hiptop, which I also like. I'd like to try one for a while before praising it too much. And I'd like to propose s fifth shape.
I propose a new addition to the three categories of PDA: the slate. Although physically similar to the pad (remember, the widescreen 640x240 clamshell PDAs with the full keyboard) the proposed slate, being made as it is of stone, lacks the subtleties of paper-milling and all that they imply.
The slate is a dumb screen and keyboard that connects to a matching keitai over Bluetooth using a lightweight network-console protocol analagous to vnc---something like the ``translucent panes'' models made fashionable by Plan 9, QNX's Photon, and XRENDER. Unlike a regular X server, these protocols are very simple on the console's end. While not in use, the slate switches off and becomes stateless. It doesn't need any ``suspend'' mode or user-writeable FLASH memory because the keitai can retain state for disconnected slate sessions, remembering what was on your screen and repainting it when you turn the slate back on.
Because the slate is so dumb, I think it can be much cheaper than the pad. Hopefully it will cost about the same amount as the keitai. I think it will be cheaper to manufacture than the keitai, but network carriers will subsidize the keitai, bringing the prices close together.
The pads that I've used have passive backlit color LCD screens. These are no good for keitai because they would need a very heavy battery to run at reasonable brightness, and even that brightness is only readable in the shade, not in direct sunlight. The slate can continue using these dim, non-reflective screens because it's got plenty of battery room, and it's still useful even if it has to be an indoor- or nighttime-only device.
There's a temptation to add slots for storage media or a LAN interface or a modem to the slate because chips used for other purposes often include these interfaces for free, but I think the temptation should be resisted. Keep the slate stripped down to screen and keyboard, only. The slate depends on the keitai. The keitai does not depend on the slate. If the dependency goes both ways, the keitai might end up, for example, without some of your old emails that are stored on a CF card shoved into the slate. This gets complicated and awkward, and it defeats the slate's main purpose which is to be a bulky thing that one can either carry or leave behind without a second thought, without feeling handicapped, that can be switched to zero power when not in use, that won't handicap you too much if the battery dies. Now you have to plan what you carry. Now we have to leave it running with the screen closed and argue about how long the battery must last to get you through a day. The slate's radio, albeit small, has to stay on always, too. That's not what the slate is supposed to be: it's merely the convenience of a faster keyboard and a bigger screen. One should grow accustomed to having keitai capability always, and any capability you can't count on always having shouldn't become part of the keitai-slate system. If the keitai doesn't have enough slow storage for saved email, maybe it should have an internal Microdrive, or maybe it should migrate older mail back over the network for slower ``pull'' fetching. If you want LAN access to save money on packet usage while at home, don't put it into the slate but rather buy a separate Bluetooth AP to which the keitai can connect---putting Ethernet into the slate would be equivalent to constructing a Bluetooth AP, so just build a Bluetooth AP and leave it at home all the time plugged into the LAN. Maybe it makes sense to put a modem in the slate for traveling to strange continents like Africa or North America that don't have normal cellular service, but I think adding any other traditional pad features like CF, SD, and PC Card slots is a bad idea. I have fun collecting powerup CF and PC Cards like Pokemon cards, because they turn into a Kit of Power, and they impress your friends. but in the end I think I won't miss this: a properly-integrated system is better.
Although the slate is not an original idea, I hope that my description is more specific and slightly different from that below. Terry Lloyd pointed me toward it in J@pan Inc's newsletter Terry's Take #179:
--> Detachable cellphone LCD NTT DoCoMo has announced that it will introduce in summer a Bluetooth-enabled detachable large-size LCD display for use with its 3G FOMA phones. The company's web site doesn't feature the unit yet, but we wonder if it's going to be the train pass sized unit we heard about from a major local manufacturer last year. According to DoCoMo, the new screen will be around 3.5" square, the size of a PDA screen, and will include a touch sensitive built-in keyboard. (Source: TT commentary from IHT/Asahi, Apr 30, 2002) http://www.asahi.com/english/business/K2002043000279.html
My slate would be MobilePro 780 or SigMarion size: the minimum size of a touch-typeable keyboard, not 3.5" diagonal, the stupid shape of the pad. But it sounds suspiciously like DoCoMo's slate will be similar to mine software-wise---I hope so.
Keitai software
Of course the greatest triumph of keitai is their software. Their
physical form is interesting largely because it forces the software to
grow in directions that mainstream desktop software, under Microsoft's
hedgemony, balks.
The emacs frame analogy is the best, because one frame has one keyboard and one mouse interacting with it, one frame can display multiple buffers, and two frames pick buffers to display out of the same pool so that two frames can actually display the same buffer. But, when two frames display the same buffer, this doesn't make them into mirror images of each other like pcAnywhere taking over some Windows screen. A ``buffer'' is sort of like a text file that you're editing, so the two frames could be viewing different parts of the same file. It is really neat: you get two independently moveable cursors, but if the two frames do happen to be looking at the same part of the file, your changes appear instantly in both frames. This is important for the keitai/slate system because it means the two frames could view the same buffer, but be different sizes, without having useless borders. For example (although emacs does not do this) the same text could be auto-wrapped differently on the slate than on the keitai, even though both were composing the same email message. You could type on the slate and watch your changes on the keitai. Or, hand the keitai to someone else and work on two different paragraphs of the same email at the same time! Just like Interleaf Publisher.
Most operating systems, or window managers, or whatever you call them, have ``bars'' or ``pull-downs'' or ``docks'' for switching among a list of ``running applications.'' I think these metaphors are wrong for the keitai. Context is so important, and the thing is never shut off, so I think there should be no such concept as starting an application. It should all be about saving the spot where you left off, or creating a new Instance of something. It is maybe sort of the OpenDoc idea that you open documents, not programs, except hopefully not so slow.
Really, though, I think emacs buffers are a better analogy than applications or documents, because emacs has a few refinements that translate nicely into the keitai system. First is the notion of implicit buffer-switching. Unlike an ``application window,'' the purpose of a ``buffer'' doesn't change substantially during its existence. If a buffer started as a help menu or a list of mail groups, that's how it stays. If you choose some menu item or action in one of these buffers---a specific type of help, a mail group you want to read---this creates a new buffer and implicitly switches to it. This metaphor works better for keitai with small screens and dependency on keyboard shortcuts, compared to the alternative: Photoshop for example. Photoshop has windows within windows. The user is expected to show, hide, raise, lower, resize, and move these windows with a 2D mouse that doesn't and shouldn't exist on a keitai. Photoshop power-users want huge screens to avoid this window-management baggage as much as possible, yet most of the huge screen is occupied by ``the workspace''---in other words, nothing. All those ideas are too wasteful.
The second relevant emacs refinement is eliminating the metaphor of
starting and quitting applications. Instead, emacs commands are
active verbs: 'w3-browse-url'. One uses the same command
to browse URLs, irrespective of whether the W3 Browser is loaded or
not. There is no such thing as starting, only loading. There's no
generic way to quit applications other than closing all their buffers,
and emacs makes no special effort to mark buffers as to what
application they belong. There is 'loading', sort of (usually it is
auto-loading), but there is no such thing as unloading. One
interesting caveat is that emacs is a gigantic single-threaded beast,
and aside from a few conspicuously ugly kludges emacs doesn't do
anything without user interaction. If keitai applications need to do
things that don't involve the user interface (as they probably will
need to do), then under an applicationless metaphor they must always
start doing these things as soon as the keitai is switched on.
There are probably several advantages to eliminating the start and quit metaphors, but the one I see immediately is that you don't have to put away your toys when you're done playing with them---rather, the toys remain organized on the shelf even during play! The keitai thus absorbs the feel of the Dr. Evil Motorized Command Chair, the Airplane Cockpit, the Giant Fighting Robot's Pilot Chair as found in anime, rather than the legacy metaphor of the cluttered ``workspace'' or ``desktop'' of Jesus's slow, patient carpentry shack.
Unfortunately, there are also several ways that eliminating the starting-and-quitting metaphor can fail. Apple tried the same thing with OpenDoc and CyberDog, but the effort was a failure because the applications still existed underneath the wallpaper, and they took so loooong to start. Experienced users learned to always keep one CyberDog window open to keep the CyberDog and OpenDoc gunk pegged in memory, and inexperienced users were irritated by the seemingly arbitrary resposne delays. Symbian's EPOC32 half-heartedly follows this metaphor by hiding the ``quit'' and ``switch application'' in places where only veteran users tend to find them. Fresh users make the same gestures to ``start'' an application as to ``switch to'' it, so they don't notice whether the application is already started or not, and they never bother to quit anything. This works poorly on the Diamond Mako---some applications perform conspicuous initialization rituals, and also it's easy to run out of memory by starting every application. The plan I describe makes sense for a diskless device that does execute-in-place, because, depending on the runtime environment, the application's large read-only text segment stays on FLASH and doesn't take any extra space while it's running compared to while it's not.
Cisco routers sort of follow this metaphor, not with respect to the ``exec'' login shell but with respect to all the processes that wait for people to login on modem lines or keep routing adjacencies up or synchronize the clock with NTP. There is a config file in which you declare what things you want running, but there is no way to start and stop something. You just declare what you want to be running, and pow, it's running, as if it were always running. There is 'show' so processes can tell you about themselves. There is 'clear' so you can kick a process wedged waiting for certain things, sometimes. But there is no way to restart a process (because they're expected to be bug-free and not need restarting), and there is no clear definition of where one process ends and another begins.
Anyway, the simpler non-PDAish existing handsets also use this start- and quit-less metaphor, and I think keitai should, too. It's important to observe that buffer-switching doesn't imply starting and quitting applications. Those who have only seen task bars and pull-downs might get the wrong impression.
Sliding panes, like smooth scrolling, makes fast TFT screens preferable, but screens seem to be getting faster on their own.
Pens are a terrible idea. No pens, please. Remember: one-handed! This requirement drives the whole user interface, because the usual metaphor of arranging bloated Fischer-Price virtual buttons on the screen is now dead. The buttons are once again physical buttons, limited in number, and can't be rearranged. Because of this, I think porting PDA operating systems into keitai is a doomed idea. Penless one-handed keitai can't run PDA applications, even though the new keitai have color screens with the same shape and size as PDAs. The Ericsson R380 tried to use this metaphor: with the ``flip closed'' it's a one-handed phone, and with the ``flip open'' it's a two-handed PDA. With the flip closed it was boring and ugly, worse even than an inexpensive handset. With the flip open, it was awkward---hard to use while walking around, hard to set on a table, easy to lose the tiny pen. I said before that I don't like pen-based PDAs---I only like keyboarded PDAs and keitai---but a PDAphone is even worse than any of the three variants alone. Note please that this means the slate also will not have a pen or touchscreen!
I really like danger.com's proxy architecture. Once you have made the keitai/proxy into a team, you can do some really neat things, like for example a JRE could be split between the keitai and the proxy. The JIT could run on the proxy and download machine code into the phone as it runs. Maybe that's too optimistic, and of course there are big problems with the way T-Mobile is using it in practice that suggest maybe, unfortunately, the keitai/slate system is only going to develop nicely if it's entirely under the user's control.
The difficult thing about the extension language is that keitai will have differing physical button layouts. I think this cannot be ``abstracted away.'' Instead, keitai applications must be slightly customized for every physical keitai, just as video games are customized to work with each game console's different controller. The keitai-specific work will be minimal, but I don't think keitai applications can run on arbitrary keitai without a little user-interface-porting.
Manufacturers will find it difficult to resist the temptation of adding other portability obstacles, figuring, ``well they have to port the interface anyway, so adding this little we-know-best-ism won't make much difference.'' To stop this, I think the extension language should support applications in a clumsy ``remedial mode:''
Note that, in this plan, there are no ``soft buttons'' positioned around the screen's edges with constant on-screen labels. Such buttons are often awkward and always a waste of screen-space, and no keitai that uses them ever has enough of them.
Applications will be extremely ugly in remedial mode, but the requirement that any application run on any keitai at least in remedial mode will stop manufacturers from adding other gratuitous portability obstacles.
future work: conclusion
The keitai is a unique type of device. It's not the same as a
cellular handset. It's not the same as a PDA. It's not a hybrid of
any kind. It's a unique device unto itself, and its shape and
behavior must reflect this uniqueness.
Keitai must stay close to their owners, switched on, and connected to the radio network all day long. These requirements determine how the keitai evolves. Cellular handsets have the same requirements, except that they haven't evolved---they still look and act like cordless phones for landlines, and cordless phones are not motivated by the same aforementioned three requirements that motivate keitai.
If we forget for a moment the unfortunate business behavior of US wireless carriers---ridiculous and frustrating billing regimes, terrible customer service, bad attitude---then the success or failure of future wireless data systems depends on the keitai.
Unfortunately for Americans, this is a hollow victory. All US data services are poorly-integrated, so that throughout their history the only customers who have made productive use of the data services are large corporate fleets that can do their own integration and have narrow applications that can tolerate clumsyness. The Blackberry represents unusually good integration for the US market, but it's still pretty bad: it's very expensive, confusingly-marketed, and limited in capability.
Recently, the networks themselves are starting to lag behind the international norm. Cingular/AT&T's UMTS rollout seemingly stalled, and all the other US carriers are using the CDMA 1x standard that elsewhere in the world has not led to as many neat applications and handset fancyness as UMTS2100. We still don't have the god damned videophones the 3G people promised us. We still get shipped remedial custom US versions of all the GSM handsets. But I think it's important not to focus too much on the network, because even a slow packet network is adequate for a rich selection of amazing revolutionary applications that don't really exist here yet.
There are some open networks that, for example, work with laptops, thus dispensing with the integration issue by mimicking wired Internet access. However I think this is also a dead-end because the desires of wireless data users are different from those of wired users.
More specifically, the uniquely successful wireless data networks in Japan show that wireless users want always-on ``push''-based ringing email. Providing this means offering integrated services around new wireless terminals called keitai.
The design of keitai should aggressively maximize coolness and try to prepare for the next big thing, but just providing polished ``push''-based email like the Blackberry begins to do would be a very good start---a much better start than providing WAP or SMS, for example.