|
March 12, 2001 Newsletter.
Subscribe now.
 So youíre building a wireless application? Who isnít these days. Scores of entrepreneurs and companies are dipping their toes into the wireless application pool looking for productivity gains, new service revenues or IPO riches.
Some are looking to extend wired Internet sites to yet another market segment or user set. Others are just attracted by the supposed "next big thing." But whatever the motivation they are sure to find wireless is more than just another form of access.
And itís much more than browsers or thin-client solutions too. Thereís a mistaken notion that wireless means "WAP." But with all the intelligent and programmable devices in the marketplace currently -- and more coming soon -- wireless applications have the potential to be so much more.
Whatever the variety, developing wireless applications involves a structured process with healthy doses of technology, science and a little bit of art. And despite what you hear to the contrary, building an efficient wireless application can border on rocket science.
There are plenty of hurdles to climb, decisions to make and situations to avoid. Itís why weíve compiled the following list of Top Ten Pitfalls of Wireless Application Development. Now these arenít the only development pitfalls youíll likely face but theyíre definitely issues and areas to be aware of, to plan for and be competent in.
At Outr.Net weíve just about seen it all, made our own share of mistakes and cleaned up a number of wireless application disasters along the way. If you can conquer these ten pitfalls, youíre on track for a smoother development process.
This newsletter is our first installment in a series of discussions centered on the wireless application development process. So take the opportunity to share in our expertise and insight. In subsequent issues we'll delve deeper into each of these topics with hopes of easing your wireless development burden and increasing your chance for success.
Decisions made at the front end of your application development process are often the most crucial. And if the foundation is shaky the project is bound to tumble somewhere down the road. Selecting your application's target wireless devices is a good example. It's an early pitfall that's not often given enough consideration.
Everyone is enamored with wireless devices and you've probably got preferences of your own. Can't live without that Palm Pilot - right? Or maybe you agree cell phones are the ultimate mobile companions. Well, before you lock your application to a personal preference - or the device du jour - consider device selection from the application's perspective.
For example, if text input is involved - even in small doses - a cell phone may not be an ideal choice. And while some alternative devices offer keyboards, are your users thumb-typing dynamos or dolts? Then there are display and battery-life considerations, or how well the device holds up in the field, surviving the elements or a clumsy user.
Selecting the right combination of devices - or even a single device - for your application should be a logical process. But many companies make device decisions without fully understanding potential limitations or future impacts. And making an inappropriate choice is somewhat akin to racing the Indy 500 in a Ford Escort. Sure it gets you around the track, but you're not going to grab the checkered flag.
Update: April 25, 2001. Click here to read a separate newsletter about the physical characteristics of wireless devices.
Update: May 29, 2001. Click here to read a separate newsletter about the software and cost issues of wireless devices.
Networks go hand-in-hand with devices and selection of one often limits or determines the other. The problem is, not all networks are created equal. Some offer wider coverage while others have better in-building penetration. Then thereís circuit-switched versus packet data issues plus a variety of current and future transmission rates.
Speaking of which, how well do you understand higher-bandwidth future network hype versus current network reality? Everyoneís heard about third generation wireless systems and Dick Tracy-style video or downloadable MP3 music on a cell phone. But did you realize these capabilities are still a number of years away from commercial availability?
The pitfall in choosing a network(s) for your application is understanding the capabilities of whatís out there, when its available and whether its right for what youíre trying to accomplish. Many entrepreneurs and companies donít fully consider the implications of their network choice - until itís too late.
Knowing a little about network congestion, packet size, transmission characteristics or network upgrade potential goes a long way towards creating an efficient wireless application. None of these networks may actually give you everything youíd like or need. But separating the hype from reality and making an informed choice - even with a few peculiarities and limitations - is a great place to start.
Networks and devices are crucial development considerations but everybody knows itís the application, stupid! So how well have you thought yours through? Of course you know what itís supposed to do but the real question is how do you make those things happen?
One common mistake is settling for a thin-client solution when a custom application is warranted. For example, browser-based applications using WAP or Palmís Web Clippings are great thin client solutions for targeting a wide variety of devices. But developing with a text-based "least common denominator" solution can limit your application options.
Do you require off-line as well as online data access? Integration with other application software? Tight interface control or detailed graphics? How about infrared or Bluetooth networking? If you answered yes to even one of these queries a custom-developed solution is your only option.
Yes, you can probably shoehorn any application into a thin-client solution. And just like the wired Internet, wireless browser features and capabilities will continue to expand. But until then it may not be a good idea to ignore the custom development option.
The "www" in wireless Internet doesnít stand for Wild Wild West but it isnít far off. The territory is wide open, there are few hard-and-fast rules and no oneís security is widely assured.
Odds are you arenít ignoring wireless security issues but you may not be paying enough attention to them either. Wireless applications are so new that many potential trouble spots have yet to be identified. And device-side security concerns deserve particular attention.
PDAs and other intelligent wireless devices are quickly becoming extensions of the desktop computer and business office. And thanks to wireless connections, access to corporate data is a mere key click or touch screen away. But these devices - and the data inside them - are vulnerable. Do you understand the consequences of a user losing one? Or a rogue application accessing data on yours?
If not, take a hard look at your applicationís security needs in light of what the device does or doesnít provide. If youíre going the thin-client route, remember that built-in security is limited but getting better with each new version. Better yet, with a custom approach you control the protection and encryption options.
But regardless of the development route, itís your job to play wireless "sheriff." Security must be an integral part of your project to prevent accidental or malicious deeds from compromising an otherwise promising application.
Wireless applications are like complex jigsaw puzzles. You never know how itís going to look until you try to bring it all together. But the pitfall in integrating the carrier, host and device components isnít the process itself; itís the puzzle pieces they left out of the box.
For example, the carrier component can be one big puzzle piece - a huge black box. You put data in one end and it comes out the other. Problem is it doesnít always come out the way you expect it to.
Carriers optimize their networks for different types of data and what your application is sending could be different from what the network is optimized for. In some, itís human readable text and for others -- binary data transfer. How these network gateways "massage" your data could have unforeseen and unpleasant impacts on your application, if youíre not adequately prepared.
To be on the safe side, be ready for the unexpected, the undocumented, the unknown. And most importantly, allow plenty of time for puzzle assembly. Wireless networks are unpredictable but they can be conquered.
Integrating all the wireless application components and getting them to work as expected is a major accomplishment. But it doesnít mean youíre ready to start distributing the shrink-wrap boxes. If you havenít scheduled adequate time for pilot and beta testing youíll soon experience a common pitfall of many wireless application developers.
The pressure to get an application out the door is tremendous. And many a project manager sees the testing phase as a perfect opportunity to make up for lost time and schedule overruns. Eliminating or compressing the pilot or beta cycles may seem like a good idea but resist the temptation. Both phases have differing objectives and the prospect of entirely different outcomes
Your "friendly" pilot testers are there to determine if the development world bears any resemblance to the production wireless environment. Odds are there will be differences. These could include latency and coverage issues as well as time-of-day performance. Donít forget, even the weather affects wireless signals and ultimately your application.
Beta testing goes one step further and involves actual target users. Itís where you hope Murphyís Law comes into play because if there was ever a time for something to go wrong, better now than later.
The real benefit of pilot and beta testing comes from the opportunity to correct the problems and deficiencies you find -- before they become expensive "shrink wrap" mistakes. It allows your potential users to be as excited and pleased with the final product as you were with the original concept.
Planning for deployment and support of your application is one of the last steps before getting it out the door. Itís often the final opportunity to anticipate, identify and lay the groundwork for future application changes.
Logistics play a key role in the deployment process and if itís your first time through youíre bound to underestimate the complexity, time and effort involved. Considerations include where users get their devices, how software gets loaded on them as well as who they call when thereís a problem. And what about that usersí guide? Can you anticipate everything to keep them from making that tech-support call?
Then there are the future application changes. These are an absolute "given" in any development process but the secret lies in the anticipation and planning. A good developer knows where the technology, market and application are headed. But a great one anticipates and plans for those changes in the first iteration, making the transition easier down the road.
Depending on the platform, device or network youíre developing for, you are probably aware of its certification requirements. In many instances there arenít any. But as wireless applications proliferate, devices get more open and complex and carriers more astute, certification requirements and demands are sure to increase.
Platform certification implies your application is "ready to roll" on a particular operating system. For example, Palm offers a certification procedure but like the Windows OS, it isnít mandatory. On the other hand, some device manufacturers do require certification to guarantee a poor application wonít jeopardize or tarnish their reputation.
Network certification is fairly uncommon, as carriers have been less concerned with applications up to now. But wireless spectrum is a precious and limited commodity so if thereís any chance your application might abuse it; donít assume theyíll look the other way.
Certification is a right of passage (and often times an opportunity for someone to collect a fee). Itís all about ensuring your application wonít interfere with another application, the device, network or OS. But in a wireless world of downloadable applications and transaction-based revenues, certification is certain to play a much larger role. Make sure youíre ready to deal with it at any and all levels.
Getting an application out the door is an accomplishment but real success often depends on what comes next-- porting that same application to another platform. The catch is if you didnít begin planning for this step early on in the process, youíll likely fall victim to one of the most costly development pitfalls there is.
For example, you may have launched your application on the RIM platform because it was the best match for the majority of your users. But your executive cadre really prefers their shiny Platinum Visors. Obviously, the next logical step is to incorporate this second device.
The trick to successfully expanding your applicationís scope is in leveraging as much of the existing work, code and effort as possible. With the right design and sufficient forethought you can often reuse the business logic and rules, host application, server, interface design and even the wireless protocol. Because of the obvious platform differences the device side will require some new effort.
Experienced developers start their application process knowing this day will come. They avoid the pitfall by recognizing the porting eventuality and planning for it adequately. A skillfully architected solution simplifies the porting process, eliminates duplicated effort and avoids a considerable amount of unnecessary time and development expense.
Wireless is far from a stagnant environment. Networks are getting faster, devices smarter and development effort more complex. How well equipped are you to keep up?
Itís important for developers to have a good understanding and handle on where the wireless marketplace stands as well where itís headed. In the U.S. that includes eight or more different wireless network technologies with the prospects of more on the way.
Devices continue to shift and morph as well, with PDAs incorporating voice and cell phones looking more like PDAs. Even the development process is in a constant state of flux with new tools and new middleware products appearing on the scene.
The pitfall for any developer lies in keeping up with all these options and determining which direction(s) to head. Do you lead the market building a bleeding-edge GPRS application knowing sufficient devices arenít available to take advantage of your genius? Do you rely on supposed "magic bullet" middleware products that abstract the wireless component but add complexity of their own?
These are decisions developers face every day. And making the right choice is often a crapshoot - you arenít going to be right every time. What looks hot today could be tomorrowís dog. But keeping up with and understanding the implications of wireless evolution means you wonít bet the farm on market hype alone.
So thatís our choice for the Top Ten Pitfalls of Wireless Application Development. As weíve said, they certainly arenít the only obstacles youíll face. But being aware of these can simplify the process, leading to better applications in the end.
Wireless applications will remain a tough nut to crack at least in the short term. And despite the fact that wireless data applications have been around for more than ten years, weíre still in the "pioneering" stages - maybe circa 1995 in "wired" Internet time.
The technology is immature and the wireless learning curve fairly steep. Development tools are available but thereís always room for improvement. And there are plenty of subtle issues and nuances you canít learn until you get your hands dirty.
Wireless will never be as straightforward and simple as TCP/IP, HTML and the wired Internet. The RF environment will always present challenges that a wired connection need not be concerned with. And as wireless evolves to high-speed third-generation capabilities, the complexity of developing applications will only increase.
For these reasons be mindful of the wireless expertise available and make use of it as necessary. Sure you can turn a great programmer into a wireless expert but be aware of the true development costs. Not all wireless projects can absorb the time, trial-and-error and tribulations involved.
Knowing when to raise the white flag and ask for expert help could save your application some day. And itís one last development pitfall youíll probably want to avoid.
Written by:
Joe Mather, Jane Somerville and Kim Spitznagel
Outr.Net, Inc.
Comments on this newsletter? Please let us know.
I'd like to subscribe to the Outr.Net newsletter.
|
