770HealthTech

Intermittent connectivity

OK, school is over and my last paper turned in, so now I can get back to serious blogging.

My device is still bricked, but I will be developing in the interim using the VMWare approach described in Teemu's blog. Before I start coding (and while I am studying up on Python) I will be writing about the requirements for a  770-based case report form application for use in the clinic exam room or hospital bedside setting.

The first requirement is for what I call intermittent connectivity. Any wireless device will eventually lose contact with the Mother Ship, and in a medical setting the device needs to press on regardless. Very few applications are currently set up to handle that turn of events, or at least not to handle it well.

Here's what I wrote back in 2002 about the requirement:

In the opinion of the writer, this architectural feature holds the most promise for groundbreaking applications in the early 21st Century. If intermittent connectivity is to be provided, the client must provide its own implementation of some subset of server functionality while disconnected, hence it requires some implementation effort. The subset typically includes data storage and retrieval and message queuing. A synchronization activity occurs whenever the intermittent connection is re-established. Complex reconciliation logic is required to support serializable database transactions in an intermittently connected architecture.

Intermittent connectivity architectures are a requirement for wireless applications, and immensely useful as a basis for telecommuting and remote workforce automation applications such as sales force and field service applications.

As used in this document, intermittent connectivity refers to the inability of the encompassing system to guarantee the possibility of connection, for example in the case of a laptop computer that must dial into an ISP to join a WAN, or a Web-enabled cell phone that may go in and out of the service area. However, intermittent connectivity architectures can be advantageous even where continuous connectivity is presumed to be available.

For example, in applications in which users are sporadically involved in heavily interactive sessions interspersed with periods of inactivity, intermittent connectivity can help maximize UI responsiveness, synchronizing during idle times. Moreover, the greater complexity of intermittent connectivity architectures can sometimes be justified simply because the cost of downtime is too great in a particular application. An ATM might be networked to its bank via a highly reliable well-shielded leased line connection, but in the relatively rare case that the WAN goes down, the ATM still must not lose any deposit transaction it has already accepted.

Furthermore, when considered in conjunction with device heterogeneity, we can see that intermittent connectivity transcends the assumption that the user will reconnect with the same client device as before—hence the state of the user’s data is maintained on the network in a form that can be served to any device of the user’s choice.

As hinted at in the last paragraph of the excerpt, there are two sides to intermittent connectivity.
The first is the client side, where data and functionality must persist with or without access to the net. The other side of the coin is exemplified by Web applications like del.icio.us and Technorati.  Necessary data access and application functionality must be available at any time from whatever device is at hand.

Intermittent connectivity is a high-level requirement that has a number of implications for design. I have to get back to my oar for the moment, but in my next post I will try to go into these implications in more detail.

In the meantime, if you're bored and looking for something fun to read, ;-) you can look deeper into the future of application architectures as I saw it in 2002, you can find the full report in AppArchFutures.pdf (416.6K).

Bricked

So, I got a nice Stowaway keyboard, installed the Maemo bluetooth software, got the keyboard paired up, and 1 minute later, the screen went dead.

From everything I can find out on the Web, this is a hardware problem. I reflashed the image and got nowhere.

If you don't hear from me for a while, this is why. People say it takes 6 weeks to get a fix/replacement from Nokia. :-(

OTOH: Perhaps this is a message from the Deity that I should be doing requirements and design before diving into coding. So maybe you will hear from me sooner... :-)

Progress

I've made considerable progress on my journey toward developer status on the Nokia 770, but none of it is ready to see the light of day yet. I can, however, recount what I've done and what's happened in the last couple weeks.

• I got OpenSSH server installed so I can get at the 770 from a desktop or laptop. This makes everything else so much easier.
• I got Python installed and running.
• I figured out what I need to do to get sqlite running on the 770. I'm playing with it on my tablet (i.e., my HP/Compaq TC1100) when I get time.
• I installed Django framework on my TC1100, and ran into a snag this early AM (most of my development time is between 0500 and 0630 hours). Need to hit the user forums and see what's what. That's what I get for trying to develop in Windows outside of the Microsoft camp. Got to get VMWare running on the TC1100, but I fear its cohones are too small for that beast.

I think I may have mentioned this, but my current goal is to develop a lean-and-mean case report form delivery tool for electronic data capture on any kind of device that runs on the Web - a survey delivery tool that takes into account the form factor of whatever display it has to work with. It will be data-driven using XML, or possibly SNX - an XML subset (ergo, not XML, which doesn't allow for subsets) whose acronym means "Snx is Not Xml" (with a deep bow in the direction of Richard Stallman of course). SNX only lives in my imagination at the moment; it's a reincarnation of the SML movement that flowered and withered in the early 2000's as a reaction to the Wurlitzer-like complexity of XML.

I'm going to spend some posting energy on gaming out the requirements for review by all and sundry (All? Sundry? I believe you're out there somewhere...) But not until I get my feet wet with some coding.

Imposter syndrome, the horror, the horror. I haven't coded anything in 3 years save for some minimal XSLT - used to be a master coder in C, C++, Visual Basic, Perl, javascript, etc. Let's see if there's life in these fingers still... :-)

Live from my 770

This is my very first post direct from my 770. what a pain using the onscreen keyboard!

My new/used bluetooth keyboard will be here any day now, so maybe I'll wait until then to get verbose.

How to make a Nokia 770-specific blog in Typepad

Typepad users: Here is the custom CSS I used to customize the template. My template is Masala using the classic 2-columns right format. I don't know if it will work with all templates. The basic idea is to make font sizes bigger by default, and use a template that adapts to screen size (i.e. no hard-coded screen width).

body {
font-size: 18px;
font-family: verdana, 'trebuchet ms', sans-serif;
margin: 0;
padding: 0;
}
.pkg:after
{
content: " ";
display: block;
visibility: hidden;
clear: both;
height: 0.1px;
font-size: 0.6em;
line-height: 0;
}
.typelist-thumbnailed .module-list-item:after
{
content: " ";
display: block;
visibility: hidden;
clear: both;
height: 0.1px;
font-size: 0.6em;
line-height: 0;
}
.module-recent-photos .module-list:after
{
content: " ";
display: block;
visibility: hidden;
clear: both;
height: 0.1px;
font-size: 0.6em;
line-height: 0;
}

Moving Day

I have copied my posts about the Nokia 770 from my FutureHIT blog to here, so I can keep a clear focus in each blog. Expect more about the 770 soon at this location!

Healthcare Input: mission impossible? Possible solutions

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.

Nokia 770 Update

It has been a while since I have posted about my work with the Nokia 770, which is because I haven't done anything much with it other than use it the past few weeks. Today I do have some progress to report on the development front.

"When The Long Tail Wags The Dog" - implications for health IT and the Nokia 770.

The entry When The Long Tail Wags The Dog on Dan Bricklin's Website takes a whole different view of "The Long Tail". Are there implications for health information technologies?

Light Blue Optics: miniature laser-driven holographic projectors

This from a comment on my Minority Report post: Light Blue Optics is demonstrating holographic laser projectors small enough to fit into bulkier PDAs and cell phones. LBO is looking for manufacturing partners to whom it can become an OEM supplier. It turns out someone "stole" my idea over a year ago at least. More power to them!