In a recent blog-post, I made some reflections on some issues discussed in the the Command Post newsletter inteview with Mr Kalasa, vice president of Emergency Services Group-ACS, about the trends and issues of Mobile Computing and fire and rescue work.
A question was posted to me if I could expand some of my reflections. The email sent to me is published below, with permission from the sender. I have anonymised the persons identity.
I read your blog entry regarding the interview in Fire Chief.
I do agree that an internet connection in the field will give firefighters access to more information. However currently the high speed internet connection avialble thru the phone companies are expensive and not avialable everywhere. The concept of wireless access is still new here in the US.
I am interested in discussing this statement with you:
“The greatest barrier to this type of technology is not a lack of many or to small investment budgets. From my perspective, the greatest barrier is that software vendors do not exploit the possibility to use low-cost hardware and software to make available information that really does not require much computing power. Further, software vendors does not make use of the existing information technology that is already in place and in use, but rather propose that additional hardware needs to be installed in the vehicles.”
What are these technologies?
Here is my expanded thoughts as a reply on the above question:
The type of barrier I am talking about is not about existing budgets or that they are fragmented or small. The point I am trying to make is that many vendors tend to use development platforms that basically is intended for much more performance intensive operations than is the needed for mobile applications for emergency response work.
In Sweden, we see how vendors use Microsoft dot.Net for this which leads to very hard requirements on the hardware. The functionality and information processing on the client is very limited, still the vendors use complex and heavy development infrastructures.
What I am calling for is a shift of focus where software vendors look into how everyday consumer products could be used as the artefact/device mediating some fundamental functionality. In Sweden, all response commanders use cellphones, but we see no applications or systems that exploit this opportunity. A cellphone has so powerful embedded functionality that to a very large extent would be more than what any commander would request. By designing clever solutions, the technology already in place could be used to provide applications that could support emergency responders with basic information for their operative work.
Further, there are many consumer devices, apart for traditional cellphones, that are tough enough for this user environment. Why don´t we see any applications that use portable gaming platforms/devices as the hardware. They are small, but bigg enough to provide an exiting user experience, they are availble at a relative low cost, and they are “ruggedized” enough to survive a teenagers everyday environement, many of them are now availble with either WIFI or GPRS/3G connectivity. At least, one could easily add such functionality via an external “box” connected to the devices connections.
I would also like to see more of basic web-applications that could easily run on a range of wireless devices. Such web-applications would provide the same functionality as the heavy client applications now in use. The information processing requirements in general are quite limited. By providing basic web-applications or remakes of the software vendors existing systems and applications would increase the use of, increase the availability of emergency centric information, and in the end of the day increase the value of the core system.
Having said this, developing basic web-applications means also that new problems must be addresses, such as local caching, limiting or avoiding the application to have a “talkative communication behaviour”, such as making unnecessary requests over the network. Also, there is a need to develop ways of managing situations when the internet-connectivity is lost or impossible. The good news is that these challenges are not unique for IT-use in emergency response work, but challenges that many developers face for a range of business actvities.
My point is that we should make extra effort in investigating how applications and systems for emergency responders could use the technology already in place, make use of low-cost consumer products, and develop business models that help the software vendors to avoid developing systems that provides unnecessary lock-in effects. Rather, the design should strive for network-effects.
I hope that these comments have clarified my reflections.