UP.phones look like a stellar step in the right direction for munchkins,
Rohit. Of course, time will tell. They have planned a browser, an
email and messaging client, and a software developer's kit for
developing handheld device applications - the send link is a primer on
the markup language for handheld devices. Very cool stuff.
> Unwired Planet enables Internet access from your cellular phone and
> pager. Now you can have the information you need when you need it most
> in a device that fits in your pocket!
Sounds like a fine idea, that "Internet in Your Pocket". UP.Phones are
currently available to corporations through the Unwired Planet
promotional UP.Kit program and through early access programs conducted
by wireless communications carriers. UP.Phones will be commercially
available in the first half of 1997. These phones will be available in
retail stores also in the first half of 1997.
Pricing will vary by phone type and manufacturer. However, we expect
phone prices under $500, with prices declining rapidly in 1997 and
1998. An important aspect to Unwired Planet's strategy is the commitment
to technology small and efficient enough to run on mass-market cellular
phones and pagers. This is evidenced by the Version 1.0 product, which
runs in 60K of ROM and 10K of RAM on the PCSI phone. This commitment to
run on mass-market devices assures high volumes, and lowest possible
prices. It is precisely this strategy that drove every major CDPD
carrier to choose Unwired Planet's technology to deliver data services
to their customers.
Carriers set data service prices. In the early market, many carriers are
"keeping it simple" by billing a flat rate for a predetermined amount of
data per month. The amount of data covered under the flat rate is
typically more than a user can consume. However, the economics of CDPD
are such that carriers can charge solely on the basis of how much data
is sent or received. CDPD data can be delivered to consumers at a rate
of $.04/kilobyte or less, making it extremely cost-effective for small
transactions, a characteristic of the Unwired Planet platform.
UP.Phones are not intended to replace laptops. Laptop computers are
ideal where volume data entry is required, and when their use is
convenient. However research shows that: Laptops are rarely connected to
corporate; typically fewer than 2 times per day. Sales people rarely
use laptops with customers except to make canned presentations. Laptops
take a long time to set up. Laptops are heavy, and cannot be used while
standing.
By contrast, the UP.Phone is always connected, is completely familiar
and comfortable, and fits in a shirt pocket. For this reason, it can be
used frequently. The functions it is likely to automate are not those
already occurring on laptops. Rather, it automates functions that
presently require human interaction, usually over the telephone.
Nobody ever argues that the sales rep's cell phone was a bad investment
- in fact, it is frequently cited as the most valuable tool the field
worker has. Think of UP.Phones simply as better cell phones, not smaller
laptops.
The stuff about HDML sounds straight out of the munchkin vault:
> The Internet revolution is about ubiquitous information: information and
> applications which are accessible anytime, anywhere, over any network
> and from any network device. The World Wide Web ushered in the first
> phase of the revolution by allowing sophisticated and graphically rich
> content and applications to be distributed to lightweight Web browsers
> running on any operating system and over any standard wireline
> connection.
>
> We are now entering the second stage of the revolution. New Internet
> devices are beginning to emerge, displacing common assumptions about
> computers and software. These devices include WebTVs, Network Computers
> and wireless handheld devices such as cellular phones and PDAs. New
> technologies are emerging which extend the core Web platform to new
> Internet devices, such as Unwired Planet's UP platform for handheld
> systems.
The first major step in this arena is our support for dynamic HDML, a
markup language which closely resembles HTML but is optimized for
handheld wireless devices running over high-latency and low-bandwidth
wireless IP connections.
Wireless Web applications using HDML work very similarly to existing
HTML browser based applications. The crucial difference between HTML and
HDML applications is the browser or device accessing the
application. Wireless Web applications are used with handheld devices
such as cellular phones which have access to wireless IP service via the
nationwide AT&T cellular network. These phones contain Unwired Planet's
UP.Browser, a micro-browser and messaging engine, which acts as an HDML
browser and HTTP front-end to Internet services.
Users of HDML capable phones can browse a simple directory of
applications or can type in a known application's unique service ID,
equivalent to an IP address. The phone then transparently connects over
the Cellular Digital Packet Data (CDPD) wireless network to a UP.Link
Internet gateway, which then resolves the service ID into a standard URL
on a Web server. The Web server then either sends back a static HDML
file, or using a tool such as Cold Fusion, a dynamically created HDML
file.
HDML applications are organized into 'Decks' which contain
'cards'. While similar to the concept of 'pages' in HTML, 'decks' are
built around the assumption that multiple tiny screens are transferred
to a client for a given transaction. For instance, an HTML page for
collecting user-input might contain an HTML form with three or four user
input areas. In HDML, this would be accomplished by sending a single
'deck' to the phone containing multiple entry 'cards'.
The following simple HDML deck includes a simple Choice card:
<HDML version=0.1 decknav="noautoload">
<ACTION TYPE="ACCEPT" LABEL="View" GOARGS="process.cfm">
<ACTION TYPE="SOFT1" LABEL="Fax" GO="sendfax.cfm">
<CHOICE>
<LINE>Cust Status
<CE VALUE="1">Orders
<CE VALUE="2">Balance
</CHOICE>
</HDML>
<ACTION> tags are used to direct the navigation of the
application. <CHOICE> tags provide a list of choices to a user, much
like a <SELECT> tag in an HTML form. Text flow-control is handled with
tags like <LINE>, <BR>, <WRAP>, and <CENTER>. The above example and
description should at least give you a flavor for how HDML looks and
feels.
Developing HDML applications DOES NOT REQUIRE owning a Web capable
cellular phone, or having digital cellular service. Unwired Planet has
created and freely distributes a Phone Simulator, which behaves exactly
as a real phone, and in fact is a pure duplicate of existing phones. The
Phone Simulator runs the very same software that the actual phones do,
and acts as an IP client against the same network as the running
phones. This means that you can begin building applications today even
if you are not ready to make an investment in the full infrastructure
needed for deployment.
Really, the HDML platform should be viewed as a natural extension to any
HTML application. Wireless applications, of course, are particularly
well suited to applications where individuals need access to
time-critical information and communications. For any organization that
relies on field personnel -- sales, support, management, or other --
wireless web applications can play a significant role in enhancing field
productivity and communication. And, as cellular phones continue to gain
mainstream consumer acceptance, online information services and
applications will thrive in the wireless domain just as they have
thrived on the public Internet. Examples of corporate style applications
include:
Electronic Mail w/ Paging
Customer status
Order status
Inventory Query
Lead tracking
Deal/Quote approval
Commission Report
Forecast management / roll up
Corporate repository access
Asset tracking
Field Service support
Service Dispatch
Workflow
Online information services
Remote faxing
Remote IS admin
Think Mochizuki would be interested?
:) Adam
----
adam@cs.caltech.edu
The only thing you can use an identifier for is to refer to an
object. When you are not dereferencing you should not look at the
contents of the URI string to gain other information.
-- Axiom: Opaqueness of URIs
From "Axioms of Web architecture" by Tim Berners-Lee, 12/19/96
http://www.w3.org/pub/WWW/DesignIssues/Axioms.html