In the last article, we discussed considering platforms other than the web when deploying an application. In this article, we'll talk about choosing the right platform.
Making that determination is not always easy. It is rare that one approach stands out as more favorable than another. It is likely that your customers, whether internal or external, will want a complete copy of the entire corporate database that is easy to use. They will also want data entry capabilities on their PDA or cellular phone. In addition, they'll probably want instantaneous replication of information to and from the corporate office, taking into consideration, of course, that some of the field staff works in areas where there is no cellular coverage.
However, you can organize and prioritize their needs in ways that allow you to give them most of their desired features while keeping the architecture open for future developments. The criteria for most organizations are broken down into three basic needs: connectivity, user experience, and data storage.
When working on a solution where all of the users are in the same building, connectivity isn't much of an issue. You don't have to worry about how the users will connect with the server since nearly every organization has had a LAN since the early 1990s. However, if the users are not always in the same building, particularly if they're out in the field, connectivity can be a real issue.
Connectivity may not be an issue when working from a home office or a client where you can use a high speed connection. In today's environment of reliable, high-speed connectivity, it's certainly possible that your solution won't be constrained by connectivity issues, even when outside of a single building.
However, it is far more likely that you're deploying applications to field service and sales staff; they may barely have dial-up modem connectivity from the small towns where you sell and deliver your products. You can almost visualize the operator plugging in wires to make connections instead of the phone switches we're all used to.
In this environment, even getting email can be a painful, hour-long process. Trying to deploy a web application where the staff would need to stay connected for long periods of time would be akin to towing a monster truck with dental floss - it's not going to work very well. In this kind of an environment, a web site solution just won't work.
Even deploying smart clients in this environment is tricky since the replication of data to and from the client should work quietly in the background. It must let users know that they are synchronizing with the server, unobtrusively alerting them that replication has completed, thus allowing them to disconnect.
Typically, transmitting and receiving data takes up only a small fraction of the time spent in a connected environment. The user makes a request and waits on an answer; the majority of the connection time is spent waiting for the response. In a smart client environment, users can start a replication process in the background and continue their work while the system saturates the connection until it's complete. This fully utilizes the connectivity available and helps your staff get offline quicker.
However, even this requires some quiet time in the evening when the staff can sit quietly and do their paperwork. In some situations, this may not be practical. It may mean that neither the home office nor the field staff receives information quickly enough.
For instance, field staff for a utility company may need to check on downed power lines or a possible gas leak. They can't wait until they come back to the office or until they go home for the evening - they need near time (near real time) connectivity all day. They need to know in a relatively short period of time when something happens.
In environments like this, nearly continuous communication is a must. This typically drives towards mobile devices such as PDAs or other similar specialized devices that are small and powerful. These devices, with their integrated radios, can receive updates all day and transmit responses in near time.
Although this sounds like the ultimate answer, be prepared to pay the price. Applications on PDAs and specialized devices are still relatively expensive to develop, deploy, and maintain. In part, this is due to the relatively poor state of the wireless communications upon which they depend. Extra work must be done to "trickle sync" data from the device to the home office and back. Trickle syncing means monitoring connectivity and finding the opportune moment to synchronize so the device is kept up to date. Even in a city like Indianapolis, which is relatively flat, there are still numerous places where wireless connectivity doesn't always work.
User Experience Needs
Over the last decade or so, a lot of research has been done on how people think and the kinds of user interface devices that can be used to make software easier to use. Whether you agree with every change or not, using a GUI based computer interface has generally gotten better over the last ten years. The introduction of context menus (generally accessed by a right-click of the mouse), drop down lists, progressive searching, drag and drop placement of objects, etc., has made it easier for users to use the systems we develop.
However, maybe ninety percent of the applications that we build do not need these interface enhancements. The traditional data entry application needs the ability to locate information, enter new information on the screen, and finally, post that information back to the server for storage and processing.
When you're considering user experience, you need to consider first what controls and techniques you're going to need in order to develop a user-friendly interface. If a truly rich user environment is necessary, then you may be forced into using a smart client solution.