|
May 29, 2001 Newsletter.
Subscribe now.
Beautyís only skin deep. So itís buyer beware if youíre basing your wireless device choice on
physical characteristics alone as we discuss the
"Top Ten Pitfalls of Wireless Application Development."
Admit it, youíre attracted by that sleek metallic finish, clamshell design or sexy expansion port capability. And sure it gets great battery life, itís durable and yes, EVEN POCKETABLE! But can you be so shallow to believe physical characteristics alone can define the perfect wireless match?
You need to look deeper, beyond the physical. Wireless devices are complex things that canít be summed up simply by their great display looks, comfortable hand-held feel or peer-to-peer conversational skills. Itís time to take a look under the hood and see what makes these things tick. Are they right for the application long haul or simply a short-term infatuation?
This time weíre looking at the ìsofterî side of wireless devices because there is much more to device selection than physical characteristics. And before you establish that relationship with the wrong wireless device you deserve to know the full story.
You want a device thatís easy to get along with, open to outside input and willing to roll with the punches. One that isnít too rigid or stuck in its ways. And most of all, you want a device thatís going to reward you with the best years of its life and not bleed you dry of monetary resources.
Yes, beauty is important but it isnít the only thing on which a wireless device relationship should be based. And before you head hand-in-hand down that long development path, be mindful of the following device considerations.
Features and physical characteristics may draw you to a particular device but they canít write a wireless application for you. That takes a crack programmer and a healthy dose of wireless know-how. But if youíre lacking in either of the above be certain your device-of-choice includes a good set of tools in a productivity-enhancing development environment.
To the uninitiated, the right development environment can make the difference between application nirvana and nightmare. And even your most experienced IT developers appreciate how development tools can simplify the application process and help bring a project in on schedule.
As might be expected, development tools vary with the device platform. For example, some offer full-featured desktop simulators, which can shorten the development and debugging cycle considerably. Especially useful capabilities include server access for simultaneous testing of the device and host applications, as well as remote debugging in some development environments.
But the best advice on development tools is to know what you are getting into. Test and experiment with the tools before you assume all the necessary features and capabilities are there. And remember, the longer a particular device has been around, the more likely its tools are mature, stable and well documented.
Some developers stay away from proprietary development tools and platforms, preferring more open systems with a strong network of resource sharing. And lacking a strong peer-to-peer development community itís good to know the manufacturer supports its developers sufficiently.
Other plusses include platforms supporting multiple development languages. That way if youíre strong in C++ and light in Java, you can build to your strengths. Of course, itís always important to understand the differences and limitations between development environments and programming languages.
For instance, J2ME may be based on desktop Java but offers only a small fraction of its capability. Therefore, you canít assume the code is portable or that the tools and techniques youíre accustomed to will apply to wireless devices.
And be mindful that picking a development language can dictate additional device porting capability later on. Donít lock yourself into a particular class of device, platform or manufacturer because of the development tools and environment.
In short, all the enticing device features and whiz-bang capabilities wonít matter much if you canít make use of them easily. So ensure the device development environment is a productivity asset rather than a limitation to your application development process.
Another ìsoftî device consideration is middleware. Often misunderstood, middleware is a catchall term for some pretty sophisticated software functionality. If you donít understand it, how it fits in or its implication on device selection you had better have an intense heart-to-heart with ìChuck,î your IT department guru because it will have an impact on your wireless application.
Chuck will tell you that middleware abstracts the complexity of the wireless network. For example, if your application requires delivery to and from multiple wireless networks, middleware may be the ideal solution. It translates between all the different gateways, interfaces and protocols involved in networks such as CDPD, GPRS, or ReFLEX ñ so you donít have to.
Thatís a good thing because as carriers merge or faster networks come on line your application is one step removed from the complexity. The middleware provider incorporates the network changes and you stay focused on the application layer. But remember that middleware canít abstract everything and you need to understand its full device impact.
For starters, thereís going to be device-side middleware software. So itís important that your device has adequate RAM and/or Flash memory as well as processing power. A device and middleware combination that adds five seconds of unnecessary processing time could be an application killer. Security is another critical corporate issue, so understanding how middleware encryption interacts with the device is certainly worth pursuing.
Middleware also impacts device selection because itís usually a step behind whatís happening with device manufacturers. As new wireless devices come to market, they are supported relative to the importance and priorities of the middleware provider and not your application. That means you will experience timing lags. And in some instances, certain manufacturers and/or devices may not be supported at all.
Thereís a good chance middleware is at work somewhere in your company currently in a CRM, Help Desk or database application. And if the experience comfort level is high, that could be a good reason to stay with the current provider ñ if they support wireless.
If youíre not into middleware currently that could be a good reason to stay away. The costs and integration issues are not insignificant. And depending on the number of devices you plan to support, customized solutions can be more cost effective and are usually more efficient.
So have that heart-to-heart with ìChuckî and donít limit your device options unknowingly or unnecessarily.
Bringing a single wireless application to fruition will certainly test your mettle and challenge you beyond what you may have bargained for. But face it, just like that favorite potato chip; youíre going to be back for more.
If youíre willing to admit to the potential for a multiple application scenario then itís important to consider your choice of device in the same light. Is your preferred wireless device just as appropriate for the next most likely application(s)? And how easily can you integrate the total solution?
For instance, say youíre working on a sales support application to streamline and accelerate order placement. Wouldnít your sales force be even better equipped with some basic e-mail capability? Or for something non-wireless, how about a simple spreadsheet? Then think about the productivity gains if all these applications worked together.
The availability and integration of multiple applicationsñ wireless or otherwise ñ is a consideration that should be given sufficient thought because wireless devices are not on a level playing field when it comes to applications and integration capability.
Some come with a treasure trove of outside applications for purchase or license. They may not meet 100% of your requirements but can serve as a holdover until your own custom development is ready or economically feasible. And then again, nobody says you have to build everything from scratch.
In other instances, there may be few third-party applications available so custom development is the only option. Thatís certainly the case with cell phones, which are now only beginning to become J2ME or C++ enabled.
But the real secret to multiple applications is a seamless operating environment. Having an embedded or third-party application integrated with your own can be a valuable productivity enhancement. If itís important to you, make sure the device supports the necessary integration capability a custom application affords.
Wireless devices ñ like potato chips ñ are addictive. Once youíve built a good application youíre going to want more. Make sure youíre satisfied with the serving size your device comes with.
Wireless and device technology advances daily but you need a device thatís going to remain useful for years. And a flexible operating system that can grow or adapt to changes over time.
The problem is you canít have your cake and eat it too ñ at least not yet. Thatís why itís important to fully understand the OS features and upgrade capability of all wireless devices under consideration. You might be surprised at what you find.
For example, you probably wouldnít purchase a PC with an operating system that wasnít upgradeable. But thatís exactly the case with many portable wireless devices. They are feature frozen when shipped. If you need or want more than what itís capable of at time of purchase, you have to buy a new piece of hardware.
In most instances itís a memory issue; the OS is burned into ROM to save cost. But itís also true that manufacturers want you to purchase new devices. Cell phones, for example, turn over on average every 18 months in the U.S. and as frequent as 6 months in Japan. PDAs may have a little longer life but what individual isnít attracted by the features and looks of the latest model?
Companies ñ small or large ñ purchasing hundreds or even thousands of wireless devices to equip employees are in a vastly different situation. They canít afford wholesale device replacements because of new feature availability.
So if the OS isnít upgradeable itís important to consider the consequences. The simplest is a lack of uniformity and the potential of supporting multiple versions of an OS and even your own application. More critical is a security flaw or interface specification change that canít be accommodated easily through an application patch.
New developments and peripheral opportunities could be reduced as well. Bluetooth, for instance, will begin to appear on the scene in the next few years but existing devices wonít necessarily be capable. Your application might also miss out on future performance or network enhancements.
For some IT managers, these OS upgrade issues may be trivial ìbeen there done thatî annoyances. For others, wireless may raise concerns that havenít existed previously. But regardless of your perspective, donít overlook the implications on your device selection process.
Nobody likes to be told they can or canít have something and wireless devices arenít any different. No matter how hard you try, youíre probably going to annoy somebody with your eventual device selection.
Wireless phones and other personal devices are exactly that ñ personal. People spend more time with them than their bosses. So before you alienate an entire work force, be sure to evaluate and consider existing usage patterns of your employees and their wireless and hand held devices. Asking someone to give up his or her device or accept something new can be tricky.
Cell phones are perhaps the most difficult because they are so personal. Many individuals carry two phones: their personal home phone and the one issued at work. And for many, the bifurcated option outweighs lugging and using devices theyíd rather not have.
For the moment, cell phones pretty much imply a WAP application, which could work to your advantage. Depending on the phone vintage and its embedded browser, people could retain their existing phones. Of course that means supporting a variety of phone models and the application development and testing that goes along with deploying on multiple platforms.
The same issues apply with PDAs and other handhelds. And although the embedded base of supporters is much smaller, these users could be even more attached to their existing devices.
With cell phones itís often an issue of size and convenience but with PDAs youíve got a range of applications to contend with. People buy PDAs for the applications, such as a calendar or address book. The trick to gaining acceptance for your wireless application is in not asking someone to give up something theyíve already acquired.
The best option may involve supporting multiple devices and/or networks, if not initially then at least down the road. The ìbuy-inî from users has got to be there in any wireless application or itís doomed from the start. So if you think youíve got a device conundrum on your hands, it may be worth considering that route.
Whether itís cell phones, PDAs or some newfangled integrated device, it behooves you to know what your users prefer and the impact of going in another direction. As the saying goes, you canít and wonít please all the people all the time. But at least theyíll know you tried.
Cost is the final issue ñ and for many the most important issue ñ in the wireless device selection process. But getting a handle on the true costs for wireless devices means once again looking beyond the obvious.
For starters that means considering lifecycle costs and not just ìfirstî cost. First cost is exactly what it implies, an acquisition cost ñ the retail/wholesale cost of the device. And just because somebodyís willing to give you a bargain price on a piece of hardware doesnít mean itís the most cost effective alternative.
Many of the device selection aspects discussed previously have cost components that should be considered. These include other peripherals like docking cradles or expansion modules and accessories like carrying cases and keyboards. How about device warranties? Even the cost of replacing batteries ñ monthly or more frequently ñ can add up quickly if youíre supporting hundreds or possibly thousands of devices.
Middleware or any licensed applications are other costs to be considered as well. In most instances this additional software carries a per ìseatî price. And itís important to know if the charges are one-time or annual.
The cost of ongoing administrative support is another area not to be ignored. If youíve had experience in supporting PC networks you know users will call to ask ìhow?î instead of reading manuals. If one device and/or its OS could lead to a greater support need, then itís a legitimate cost factor to be included.
But the biggest single cost factor affecting wireless devices is airtime. Itís a monthly recurring charge and a significant ongoing expense. Itís why we suggest devices and networks go hand-in-hand in the selection process.
Within a year, airtime can easily total more than the cost of the device itself. Compound those charges over the life of the device and its first cost appears insignificant. In fact, all the costs mentioned above may not exceed the potential for total airtime used.
So itís important to understand how youíre being charged for airtime: per packet, per message, per minute, or even flat rate. And if the plans vary by carrier ñ which they likely will ñ be sure youíre equipped to do an apples-to-apples comparison.
Wireless devices have a lot of attractive features and capabilities, and if youíre comparing them to laptops youíre going to be ahead of the game from the outset. But even so, the total package needs to make sense economically, or it wonít much matter what they can do. Be certain you understand the ìtrueî and full costs of your device selection.
So weíve come to the close of our device evaluation discussion. No, it may not be exactly like establishing a personal relationship. But the wireless device you choose is going to affect people personally.
Make sure you give adequate consideration to all the physical, ìsoftî and hard cost issues involved. They may not all apply to your particular situation, application or selection process. But youíll be that much better equipped to avoid making a critical mistake in this the first of our ìTop Ten Pitfalls.î
Written by:
Joe Mather, Jane Somerville and Mark Dziakiewicz
Outr.Net, Inc.
Comments on this newsletter? Please let us know.
I'd like to subscribe to the Outr.Net newsletter.
|
