I was just about to write a post reviewing my Nokia 770 as an input device for study coordinators and investigators in clinical research, when I noticed a post in Colin Jervis' Future Health IT blog entitled Healthcare Input: mission impossible?. Colin sums up nicely some of the negative things I was about to write, including one or two that hadn't occurred to me. Ultimately, to my surprise, it made me more optimistic about devices like the Nokia 770 than I had been before I read his article.
Most of what Colin says about PDAs has said is what I would have said, it applies as well to clinical researchers as it does to clinicians, and you should read his post if you haven't already. If you don't know much about the Nokia 770 itself, I recommend starting with this post on the blog Thoughtfix on the Nokia 770.
First, memory. I added a 1GB RS-MMC, nice increase over the 64MB there before; installation was a little tricky, but in the power user range of difficulty. I installed some apps, created some documents, ran out of space. It doesn't automatically use the added space for document storage. I did some investigation, found out you can extend the root filesystem onto the RS-MMC, followed the instructions, and got it to work. Not hard at all, if you have some understanding of Linux's file system and are willing to throw the little guy into R&D mode. The level of difficulty was way beyond the power user, in my opinion.
Next, the wireless doesn't seem to move seamlessly from one WAP to another. It takes about 8 annoying clicks to switch WAPs. There is a "connect without asking" checkbox, but it doesn't seem to work.
Finally, let's look at the 800-pound gorilla negative, the very limited screen real estate. It's 800 pixels wide by 240 high, if I recall the specs correctly, not a bad resolution display. However, the screen's still only about 3" wide (~8cm) - wider than your Treo or Blackberry, but still way smaller than a tablet or laptop.
This means that fonts of unbelievably (and for many of us, unreadably) small size appear sharp and clear. It's easy to magnify the screen content to a readable size, but it's a toggle to 150%, not a slider, so there's no fine-tuning. Moreover, when it's magnified it's readable, but in this mode most data entry forms require scrolling side to side as well as up and down. A fundamental axiom of Web usability is that Users Don't Scroll. In a high-intensity environment like a clinic, they not only Don't Scroll, they Can't Scroll. Data entry is difficult if the Web form in use was designed for the mainstream display size, which currently is no smaller than 1024x768 ,and assumes the presence of a usable mouse and keyboard.
I can hear your thoughts as you read this, across time and all those intervening miles of copper and glass between us: Bzzzzzzt! Thank you for playing. Bye now. But maybe the situation for the Nokia 770 and similar devices isn't as hopeless as all that.
There is an interim solution, and I'm working on an example of it, but it will take a while, what with the CTSA and my grad school class project due in a month and a daughter getting married. The interim solution is this: design screens specifically for the Nokia 770 in the default 100% magnification mode, using large enough fonts, bold enough lines, and big enough checkboxes and radio buttons. We can do this right now, mostly with CSS, though the checkboxes and radio buttons will require a bit of javascript wizardry.
There's a kind of mid-term solution, which is to drop back into client server mode and write your apps in Python. They're going to be fat client apps, albeit gorditos instead of the gordos we used to write, with all the attendant problems of version control and mysterious undiagnosable problems vaguely described but sharply complained about by the end users. But with this approach you do get a lot of control you wouldn't otherwise have (unless, of course, you are Ajax-literate).
The real solution, the ultimate solution, is one I described in a scenario planning document about the future of application architectures that I wrote back in 2001:
The advent of wireless computing has produced a profusion of devices and device types that can act as application clients. Many applications will need to support access from multiple device types. The problem raised by multiple devices is not simply a formatting issue: different kinds of devices may require entirely different content selection and user interaction scenarios, due to limitations on screen size and bandwidth.
A three-tier architecture has been popular throughout the late 1990’s and into the early 2000’s, with the three layers being presentation, business logic, and storage management. Device heterogeneity adds an additional layer, responsible for device-specific filtering and translation, which is required to adapt the application to the user’s device of choice.
Differing implementations of the adaptation layer will follow the same basic approach. The business logic layer provides information to display in XML format. XSLT stylesheets are used to transform the XML to an appropriate format for the client device (e.g., WML for a WAP phone, a subset of HTML for a Palm Web Clipping application, or XHTML for a desktop or laptop running a Web browser).
After five years the devices have proliferated and the need for such an approach has never been greater. This is one of the two most neglected aspects of Web application architectures at present (intermittent connectivity is the other, but let's save that for another discussion). Blog and news feed readers based on relatives of RDF are the best examples we have so far, but these are currently used almost exclusively for content delivery rather than electronic data capture.
Adapting to a variety of heterogeneous devices reliably means giving up on most of the control over formatting to which we Web designers have grown addicted over the past decade or so, but it hearkens back to Tim Berners-Lee's original vision of HTML as a format that could adapt easily to as-yet-unimaginable display devices and data formats.
Berners-Lee's inclusion in his vision of support for heterogeneous data formats was especially prescient. You may be viewing this page in one of many brands of Web browser on any one of a number of different types of display devices; reading it through one of many different news readers that run either as clients on your machine or tunneled through a browser-based Web application; or listening to it as a podcast on your iPod as you work out on that nice new elliptical trainer your spouse bought you for your birthday. (Shouldn't you kick up the speed, just a little bit?)
In 2005, in keeping with their new motto of "the Web on Everything", the W3C started the Mobile Web Initiative, which is intended to address this problem. I'm going to keep watching and see how they do.
Comments