What I really, really want...
PDAs are great for the basic standard applications: diary, contacts and so on. They are less great for unadapted, cut down clones of desktop applications, like word processors and spreadsheets, but no doubt the developers of these apps will learn how to get it right in their own good time.
But in my quiet moments, I like to think that there are some applications for which PDAs are far better than desktop machines are, and I think that one of those applications is information retrieval. With current technology that requires a live connection to the Internet, which is certainly feasible and easy to set up. It also requires a considerably better approach to searching for information than is currently offered by the various web search engines. A local free text search engine isn't too hard to set up, if you own your own web server and have spent a lot of time and money either buying a commercial product, or installing one of the freeware ones.
A lot of corporations have recently discovered the Internet, and have been setting up their own information resources in intranets. There isn't very much being done at this stage with unstructured information resources, like that help in the web search engines, but there is some good technology on offer for accessing corporate databases via the Internet. One of the big selling points of an intranet is that rigid control of the users desktop by a central IT support organisation isn't required; done properly, the IT department can just specify required features in a browser, and leave the user departments to make their own support arrangements for desktop hardware.
I have been investigating how suitable a PDA is to access corporate intranets, and it works well enough, with one proviso, to be very interesting. That proviso is that the corporate intranet developers don't specify too many bells and whistles for their applications. Many developers understand the web well enough that they know to stick with basic HTML, including cookies, forms and tables; but some want to drop in features like Java, Javascript, Active X, and frames, which restricts the choice of browser and hence desktop platform down to a very short list. Supporting Java is a good thing, I believe, and it should be available to the mass PDA market before very long: but it isn't here yet.
To test out the idea of using a PDA for intranet access, I choose three typical intranet applications to develop: a simple one to record my CD collection, another to manage a list of product prices, and a third program that was a strict recreation of the PalmPilot Expenses program.
The tool that I chose to develop these web applications was WebObjects, from Apple. A number of significant sites have been built with this, including information sites from Capital Radio and shopping sites from Dell, Apple and Sharper Image, so it is clearly suitable for serious intranet development. The biggest criticism is the price: a developer license costs GBP 995, which is reasonable; but a deployment license for a large server connected to the Internet is about GBP 35,000, which is a lot of money unless you know that your site is going to really rake in business for you.
WebObjects links:
Apple's WebObjects: http://www.apple.com/webobjects/
Apple Store: http://store.apple.com
Sharper Image: http://www.sharperimage.com
Capital FM: http://www.capitalfm.co.uk
Internet Property Registry: http://www.propreg.com
Amusingly, Apple's WebObjects page has a small tag that says: Site Maintained with AppleScript
I have written applications using perl and cgi before now, and the experience reminded me a lot of writing programs for IBM's CICS transaction processing monitor: slow, cumbersome, and awkward. The biggest problem (with both cgi and CICS) was that your program had to do a lot of work to store the state of your query, as every page request has no inherent way of passing information about the previous history of contacts made by any particular user. WebObjects manages application state for you, and comes with a very powerful development environment, including visual page design, and a comprehensive framework of objects to build various user interface components, or access a database.
Building a page is simple: it can all be laid out visually in WOBuilder, including dynamic elements and repeated data structures within a page. You then create instance variables in your program, and visually connect them to database elements, using a definition of your database created with another tool, EOModeller. The different parts of the application, including eomodels (database structure definitions and data mappings), web components and various program files, are held together in Project Builder, which also manages compilation and debugging of your application.
Programs can be written in Java, Objective C, C++ or WebScript. Webscript is an interpreted version of Objective C that permits immediate changes of scripts to be applied to the live application (if you wish). All communication with the web and database components is by way of the WebObjects Framework, and other frameworks of objects supplied by Apple with WebObjects. So although you write programs using the Java language, it isn't true to say that you are developing in Java, because the object frameworks used are not part of the Java specification, and the program runs on the server, rather than as an applet within the client browser. If you want to include pure Java applets, or even Javascript, within the programs, you can do; but the result won't work on a PDA.
WebObjects applications include a built in statistics gathering mechanism, load balancing between multiple servers, and the database definitions are independent of the back end database used. It will also operate through NSAPI and ISAPI interfaces, as well as with cgi, making response much faster for sites running appropriate web servers. Scaling to support high transaction volumes is easy, and need not require any changes in the application. One of the example applications is a version of a shopping basket site.
A similar set of frameworks and tools are available to write programs to run directly on a desktop machine, with necessary changes to the code that builds the user interface. I am already familiar with OpenStep Enterprise, the product that does this, and will become part of Apple's Rhapsody operating system. Programs developed with OpenStep Enterprise can run without source changes on NeXTSTEP, Rhapsody, Windows NT and Windows 95. The code used to create non-user interface parts of your programs can be reused in WebObjects applications, so my first course was to write a couple of simple programs in OpenStep, that I could port to WebObjects later. It took me a weekend to write the three programs mentioned earlier.
A desktop application ready to move to the web
Replicating all three programs in WebObjects, after a quick run through the tutorial, took me about two days, which I consider good time; some of the objects I built for the desktop apps were used again in the web application. With more substantial applications, the savings from being able to do this would be enormous.
laying out the application
Expenses application on a desktop
The web pages are perfectly usable on a PDA; I used both the HP620LX with Pocket Internet, and a Psion Series 5 with the Psion Messaging Suite Web application. They both support forms, images, and tables quite well, although only Pocket Internet supports frames. The Newton web browser (NetHopper) would be equally good. On the Pilot I used TGWingman, a free web browser. It doesn't support tables, and has an unusual way of supporting forms, so I wouldn't recommend using it for intranet applications.
and on a Psion Series 5
The proof of the pudding was when I walked around Tower Records checking off wanted CDs. With the HP620LX, I only needed two boxes (the HP itself and a mobile phone), rather than the three boxes of the Psion, hipflask PC Card adaptor, plus mobile phone. You can put the phone in a jacket or shirt pocket quite happily. I'll have to write a web based shopping list next.
The Expenses application is a bit more serious, and more typical of a corporate intranet application, so I used it on the train from Marylebone. Again, it worked well enough that I'd be willing to use it for real, not just as a proof of concept.
For outbound connections initiated by the PDA user, this technology works well enough to be usable. I'd like to try the PalmPilots with some of the commercial web browsers, and the Newton MessagePad for the same purpose. The Pilot is small enough to be easily and conveniently carried around in pockets, unlike all the other machines. All it lacks is the ability to receive incoming network connections. If I had a PDA that could make transparent connections, both inbound and outbound, it would be far more useful; it seems unlikely that current Internet technology would easily work this way, although pager technology would be ideal. A Pilot with a small pager attachment that could receive incoming email and trigger alarms as items are received would be the ideal solution for this.
Words and design by:
Paul Lynch
Last updated: March 11, 1998