With ``pull'' the handset's ringing is optional, and requires a special hack on the provider's part. The two email ``solutions'' I've used---Nextel's WAP-based mail, and generic POP3 with an Ericsson R380 and GSM---do NOT ring.
Nextel has ``two-way messaging'' and ``AOL Instant Messenger'' options that do ring, but they are lame kludges. Their scheme is to send the handset ``network messages,'' which arrive as WAP browser bookmarks. When one gets a network message, the screen interrupts whatever you're doing and shows:
+----------------+ | | | 1 new network | | message. | | | | Exit Goto | +----------------+
That's it. No brief subject, no From header. When you ``Goto'' a network message, the browser loses your place and loads the page demanded by the network message. You wait while the handset loads the page, and it won't work in the subway where there is no coverage.
so, to a pedant, ``pull'' email can ring by kludging this push-based ``network message'' junk, but it is gruesome to actually use such a system. It makes those toy joke ``voicemail waiting'' lights seem reliable by comparison.
+----------------+ | Message #1 | | From: The | | Cromoglodon | | <cromoglodo... | | NEXT | +----------------+You can scroll down two or three screenfulls by pressing [Down]. Then, you have to press instead the [NEXT] button.
Meanwhile, the so-called ``network messages'' that make the rings are accumulating in the separate ``network message inbox,'' where there is no distinction between read and new messages, and where you have to delete them by hand.
With the ``pull'' metaphor, you do wait for the network. How long and how often depends on the detailed design of the system. But why should the handset ring at all before the email is sent across the network?
Push-based email is key. Good keitai software is tight, and users have no problems whipping around their keitai's menus at high speed. This skill is part of what makes the small screens tolerable. Keitai have this advantage over big computers: well-designed menus and keystroke shortcuts. Once the application moves onto a pull-based ``wireless web page,'' the menus get uglier, the keystroke shortcuts go away, and most importantly it's impossible to navigate at high speed because you frequently have to wait for the network. Sure, i-mode delays of 1 - 2 seconds are better than Nextel delays of 10 - 20 seconds, but any realistic network delay will make a small-screen user interface suck. Small screens and slow networks make pull-based wireless mail particularly intolerable compared to pull-based webmail on desktops, which is already pretty bad but much more useable.
Also, a purely-``pull'' system cannot ring at all---indeed, Nextel's simplest WAP email does not ring. It's like having a phone that never rings and has no voicemail light. You must repeatedly execute some inconvenient ritual, often finding no new messages. Although it's possible to add ringing, this is still a nasty kludge---most people have probably noticed voicemail lights on US networks aren't always correct. This problem is created by kludging ``push'' ringing on top of a ``pull'' system---by mixing delivery metaphors, the voicemail light has to be ``synchronized'' rather than merely transmitted.
The ``pull'' metaphor enumerated above is an exact description of how wireless email works on Nextel's proprietary network, which had every opportunity to do good integration: it was designed from the ground up for digital packet data, and it uses proprietary handsets. Nextel's WAPmail makes you wait for the network for tens of seconds, multiple times per email. And email does not ring.
There are other pesky details with the usability of Motorola's nasty i85s handset that turn into big problems---for example, scrolling down one screenful within the 500 character block of text requires squeezing a clumsy 4-direction rubber joy-blob, hard, for two seconds continuously before it responds. The text itself takes about three seconds to read, so even if there were zero network delay you end up spending almost half your time waiting for the user interface. This is not a screen size problem---it's a dumbass hard-to-press button and stupid-software problem.
What's more, when composing a reply you can easily erase your entire input (painfully typed with the 12-key pad) by accidentally holding down the backspace key for two seconds instead of tapping backspace to delete one letter. so much for tight software, clever menus, and keystroke shortcuts! But these problems just demonstrate that Motorola's software is not as good as that of Ericsson and Nokia. Problems with the user interface and the shapes of keys are a big deal, but they are not fundamental to ``push'' vs. ``pull.''
Really, ``push'' should extend to voicemail as well. The audio content of voicemail ought to be pushed onto one's handset over a throughput-ToS packet channel whenever coverage is available. If the radio signal is intermittent or has frequent dropouts, at least you'll still receive voicemail clearly and distinctly. And there is no more problem with the voicemail light, because the handset knows very clearly whether it contains messages or not. Finally, playing voicemail becomes part of the handset's GUI rather than a clumsy audible single-digit voicemail-hell menu. Voicemail could appear in the recent-calls list, along with time-sent and caller-id metadata. If wireless email were properly integrated, it could simply subsume current voicemail as a special case (emails with voice attachments), and end up actually being less clumsy than current systems. ``Push'' is a powerful and general, and absurdly underused, strategy.