Today's typical mobile phone or wireless handheld is far more powerful than early personal computers. Could a mobile phone or wireless handheld be an effective primary computing platform for average folks? Philip Greenspun lays out a detailed proposal for how this might be done. He proposes an appliance that would act as docking station for the wireless handheld. The appliance would provide a large keyboard, large screen, broadband connectivity, large amounts of storage, and basic applications: web browsing, email, digital photo and music organization, and so on.
Greenspun's appliance project is terrific. I'd love to see that it not
only has the right hardware and connectivity, but begins to address
some of the big picture usability problems that have plagued personal
computing. He points to usability problems with PC file systems (I elaborate on that issue below). But there is much more to get right if the appliance is to be more than just a PC plus a cell phone dock.
Here are my thoughts on what is needed to make the proposed wireless handheld docking appliance really work for non-sophisticated users.
User Objects Move Between Wildly Different Platforms
How do the user's objects of interest -- documents, people, projects, music, photos, call history entries, email messages, tasks, reminders -- seamlessly migrate to/from the handheld as needed. Updates entered when the handheld device is in the field should automatically move to the appliance while updates that arrive to the appliance by broadband need to selectively move to the handheld device.
Two Kinds of Applications For the Same Objects
The applications that operate on user objects -- like browsers, editors, search tools, organization tools -- will need to have two completely different user interfaces -- one for the handheld device and one for the appliance. Appliance applications are designed around a full sized screen and a full keyboard. This is the user interface where the bulk of the typing and organization will happen. The handheld device user interface needs to deal with the small screen, unloved tiny keyboards (or only a numeric keypad) and other limitations of handheld devices. Handheld applications demand on-the-go usage without "browsing" and single hand operation. Arguably, there will need to be two completely different applications
sharing the same data objects synchronized between the handheld and the appliance data stores.
Synchronization of Objects Between Platforms
The handheld device docking appliance that replaces a PC needs to have brilliant synchronization, operating more seamlessly then current schemes like Intellsync and Sync-ML. The synchronization should be push, rather than pull. This means that the synchronizations happens automatically whenever the handheld is docked (or connected via a wireless connection). The user should not need to initiate the synch manually. Furthermore, the synch should be fine grained, working on an object-by-object basis, not just as a batch. Generally, the synchronization should happen quietly under the covers and bother the user rarely if ever. There should be priority rules -- one kind of object gets synchronized agressively using any connection even if it is a slow or expensive wireless connection. Other kinds of objects only get synchronized when there is a cheap high-bandwidth connection. Perhaps RSS can provide a good basis for the synchronization (some good background on RSS here) as it allows for a finer grained approach than Sync-ML. Whatever the technology, we need to figure out how to make synchronization much less complicated and much more closely tied to human usage patterns.
Applications Move With Their Objects - Plug and Play Applications
A handheld docking appliance needs a standard for applications that allow them to move seamlessly to the device along with their critical content. An unfortunate approach, that even has a standard defined, requires handheld users to download, maintain, and install handheld applications in the same broken and unmanageable way that PC applications are downloaded, maintained and installed. Besides the inherent manageability problems, this misses the critical usage issue for handhelds: applications are very fine-grained and they have to operate while disconnected.
For example, when I book an airline reservation, the application to
book seats for that airline reservation should move from the network to the handheld with the
reservation object. This is a fine grained application by itself, but
it gets worse: each airline company will have their own seat selection
application. When you consider the range of fine-grained hand-held and
mobile applications, all of which have to work while sometimes
disconnected, it is obvious that the traditional install model is
broken. Here are the kinds of applications you want to run on your
handheld: airline reservation applications from each carrier, a
movie-ticket application (from each theater chain), prescription drug
application for ordering refills, an application to notify my friends
that I am going to a certain concert or movie this weekend, a way to
manage the weekly tasks lists for each of my employees.
Just like the web, handhelds want to get their applications on an "as needed" basis. There are relatively few "generic" applications (like a word processor) in the handheld world. Applications are small, tailored, and focused on particular tasks at hand. Consider how unworkable the web would be if you needed to "install" a page any time you wanted to do something that requires an operation. That is crucially flawed, but that is what is widely proposed as a standard for wireless applications. Instead, applications want to be plug and play. As you use a handheld you want relevant applications to be available as needed without an install step.
Why not just use the kind of thin client browsing that works fine on the desktop web? That is fine for when you are at the appliance. But on a handheld you ARE NOT always connected. Despite "can you hear me now" TV commercials, our typical commercial user goes in and out of coverage 5-10 times per day. Your screen is small and browsing does not work. Some way to manage "store and forward" or "plug and play" applications is required. On the web applications live on the server (via PHP, JSP, ASP, etc.) or travel to the desktop as light-weight bits of program that enhance a pure browser experience (e.g Javascript or Flash). On a handheld you are not always connected. Plug and play applications need to keep operating even when disconnected.
My company, JumpStart Wireless, provides the kinds of plug and play applications described in this section, but in a commercial setting for mobile workers doing repair, delivery, inspection, etc. Our technology would work in the broad context described here (anyone interested in funding a move of this technology into a broad consumer world?). Other approaches would work as well. The key here, however, is the need for plug and play, disconnectable applications.
Working Out Smooth Object Movement -- What Do You Want to Carry With You?
Working out how to have object movement from the handheld to/from the application is another key issue. How do I set things up to keep the right objects in the right place without a lot of manual manipulation. For example, how do I choose the limited number of songs I can carry with my phone today? How do I ensure that an email from james[email protected] is properly connected to the address book entry for Jim Smith? If I have an appointment today with Mary Jones, could I arrange to have the phone automatically get copies of all recent emails to and from Mary?
Getting the "File" (really Object) System Right
Greenspun talks about how PC file systems are far too complex and counterintunitive. Why, for example, when I update a document do I need to "save" those updates before I "exit" the word processing program. Updates to your phone address book are automatically saved without any explicit save. Why should your other computer objects be different? Furthermore, using that address book entry happens in context, for example, addressing an email or dialing a phone number, without needing to search through the hierarchical folders holding the raw address book data. Again, I would like my computing objects to place themselves in useful places that can easily be found by automatically maintained indices?
It is a huge failure of the PC industry that, after all these years, we are still living with file systems that force users to understand lots of low level details about how hard disks and operating systems work.
Beyond the confusion of the file system, crucial information is stored in isolated silos that are hard to coordinate and manage. Your address book is arguably your most important data. Why isn't it trivial to keep your address book for your mobile phone coordinated with copy on your desktop computing device? Why can't EVERY program treat that as your only address book, instead of every program keeping its own copy. Microsoft Outlook, to cite a particularly nasty example, keeps three different address books.
File System: Concrete Proposal
Here is my concrete proposal for what should be done to a file system. Every object - every photo, address book entry, email, phone call record, etc, should be filed in at least 3 places:
- Everything should be filed based on when it was created/received. A calendar-like viewer should allow you to retrieve things by when they were created/received.
- Everything should be filed based on the people involved. For example, filing based on To,From, and CC for emails and filing based on the Artist for music. An address book viewer should allow you to retrieve not only address and phone, but also recent documents and emails.
- Everything should be filed based on interest/project tags (gardening, family reunion, promotion, etc.). Objects can be stored based on many different tags so you can find it multiple ways.
Summary
I love Greenspun's proposal. It is exactly the right project for an obvious direction that convergence of telecom and computing is taking. Usability, however, is far more important than just getting the hardware right.
Recent Comments