|
April 25, 2001 Newsletter.
Subscribe now.
 The world is going wireless crazy. If you believe some companies and analysts weíll all be running our lives and businesses through wireless devices and applications in the not too distant future. Much of it is hype. Yet itís all grounded in some degree of reality.
Differentiating between the two can be difficult. But keeping focused on your wireless goals, applying sound business principles and avoiding potential development pitfalls should keep your wireless application on the right track ñ and in the reality column.
Which brings us to the topic of selecting the appropriate wireless device, the first of our ìTop Tenî Pitfalls. Itís one of the most crucial choices youíll make, particularly because it comes at the front end of the wireless application development process.
To a large extent, the capabilities of your wireless application are determined by the features and functions of the wireless device. Is there an absolute right or wrong device for your application? Probably not, but keep in mind that some devices will be better than others. Making the best choice possible should be your goal. And in many instances, the best choice will be multiple devices.
A good place to start in device selection is a clear statement of the wireless problem youíre trying to solve. Then consider existing constraints that could limit your wireless project or device choice. Examples include network airtime ìdealsî or a user who canít live without a particular PDA. Equally important is knowing the range of devices available in the market place ñ both today and in the future.
That said, the following discussion centers on a number of device selection/evaluation criteria. They may not all apply to your wireless application and development process but consider them a convenient check and balance against what you may have discovered already.
Sometimes itís best to begin with the obvious. Form factor issues are primary considerations in any device selection and something youíre not likely to overlook. But just like a great magic trick, there is often more to wireless devices than what meets the eye.
Screens are a good example. For instance, you may have a minimum display size in mind for your application. Or maybe you know a touch screen works best for the level of navigation required. But have you considered how the application will actually look on the screen or whether backlighting is important? Would you know if weather conditions could affect the display?
Display technology varies from device to device as does screen resolution. Having more screen real estate doesnít necessarily ensure higher resolution or better-looking graphics. Sometimes higher screen resolution results in smaller fonts, which affect readability. And just because a screen is readable indoors doesnít guarantee similar results outdoors where screen glare is to be expected.
Backlighting is just as important if dimly lit environments or nighttime use factor into the application equation. Even environmental conditions, like heat from the sun or a cold winter blast can affect screen appearance so itís good to know if the device has adjustable contrast. Then again, are you willing to subject your users to the wide fluctuations some screens are prone to?
Device size and keyboards are other obvious form factor considerations that deserve extra attention. While everyone seems to want the smallest, lightest and most compact device possible, there are times when these characteristics present application impediments. Could your preferred device be too small or the keyboard too compact for the hands of your users?
Form factor issues may appear simple but theyíre not always obvious. If youíre going to make a wireless device an integral part of someoneís job be sure you look at the choices and options from their perspective. Gloss over some critical factors and ñ presto changeo ñ you may just turn a successful application into a dog.
Everyone knows wireless devices canít run without them but odds are you havenít given batteries more than a passing thought in your device selection process. Surprisingly, batteries can be make-or-break device considerations. And the pink bunny implications of battery life and issues of disposable versus rechargeable/embedded will play an important role in your applicationís success.
Devices offer a variety of application ìlivesî based on their batteries. For example, wireless PDAs may get a few weeks worth of use, cell phones a few days and two-way data devices somewhere in between. How these average battery lives complement your application is something to evaluate but what happens when batteries die is the more pertinent question.
Field service representatives canít afford to have an application quit on them during the course of their day. But itís a tolerable risk if popping two new alkalines puts them back in business. Rechargeable batteries offer similar survival benefits ñ as long as they retain their charge until required for duty.
In contrast, embedded rechargeable batteries present some unique challenges. They canít always be swapped easily and often require time on a charging cradle. Depending on the application and user circumstances, the latter scenario might not be appropriate.
Some wireless devices complicate the predictable ìlifeî issue with separate battery types for the device and its wireless modem. And under these mixed environment circumstances itís very probable for one battery to die while the other has hours of useful life.
Integrated devices pose unique challenges as well. Some incorporate separate internal batteries to build the extra ìwirelessî transmission power that standard disposable batteries canít provide. Itís a clever solution but can lead to limited wireless up-time ñ and even delays ñ as the internal battery recharges.
Batteries power the wireless devices and in turn your application. Make sure you give yours every opportunity to keep going and going.
Like batteries, device durability is another physical issue to consider when evaluating your hardware options. How will the device stand up to the rigors of everyday use?
It wouldnít matter much if you had atomic-powered devices, offering unlimited hours of application time, if the device falls apart the first time its dropped. And lest there be any doubt, it is going to get dropped: on the ground, on the asphalt, in the sink. You name it and somebodyís probably dropped it there.
In this instance your best defense against clumsy users is a good offense: purchase some devices and start dropping them. Or better yet, have someone else drop them ñ just in case the boss is watching.
Pushing a device to its breaking point can provide valuable information. You may discover that the battery door comes off a little too easily or that clamshell shapes provide an extra cushion of protection. Just how much weight can an LCD screen handle before it cracks?
Itís important to understand your users and their application environment. Devices with tiny keyboards might not be appropriate if construction site dirt and grime can get lodged between the keys. And touch screens can be rendered useless if users keep losing the stylus.
One final word of advice: you can probably skip the water test. Few electronic devices will withstand a good dunking and live on to transmit another day. They may work for a while ñ after completely drying out - but corrosion will kill them eventually.
You canít control your users or their environment but you can give them wireless devices that are up to the challenges.
Size is a form factor issue affecting the practicality and fit between device and application. But sometimes you need to look a little further. How users carry and access their wireless devices plays a bigger role in application success than you might imagine.
Devices fall into three broad ìtransportî categories: wearable, pocketable and luggable. Wearable means you can attach the device to your person. That includes built-in belt clips or attachable carrying pouches. Pocketable suggests a slightly larger form factor but one that easily slides into a shirt or pants pocket. But if the device is too big and/or bulky it falls into the luggable category ñ and a set of constraints all its own.
With the first two categories thereís a good chance the wireless device will remain with your users ñ all or at least most of the time. Thatís an important consideration if notification, immediacy or ìpushingî data plays an important part of the application. Examples include notification sent to delivery persons, canceling or confirming their next appointment or sending pertinent contact information to a salesperson on the go.
Pocketable devices are less of a notification ìsure thingî than wearable devices, because users can inadvertently leave them behind. And obviously, notification services work only if the device is capable ñ not all of them are.
If timeliness is not a major issue then luggable devices can make great wireless companions. But itís trickier to predict how users will take to them or incorporate them into a daily routine. A device thatís too bulky or inconvenient to use could find itself at the bottom of a briefcase, purse or toolbox, along with your application.
Thatís why there are special challenges involved with luggable devices. They may be the most full-featured wireless companions out there, but if those features donít improve, simplify or empower someone on the job it doesnít much matter.
Give your users a great application on a device thatís convenient to use and carry and you may never hear about it. But give them one thatís awkward and cumbersome and you may never hear the end of it.
Many wireless devices are fixed products; what you see is what you get. But others can be expanded through peripherals and add-on modules. If thereís any chance your application could be enhanced with optional hardware ñ today or in the future ñ you should consider the benefits of expansion capabilities in your device selection.
Peripherals and expansion modules allow devices to morph into other things. PDAs can become cell phones. Cell phones can become cameras or bar code readers. And a new piece of hardware opens up the application opportunities considerably.
For example, a PDA with a wireless interface makes for a great inventory tracking system but the application could be ten times as efficient and accurate with a bar code reader. Digital cameras present some unique application and service opportunities as well, and they donít all center on sending pictures to grandma.
Not all wireless devices directly incorporate peripherals or include add-on strategies. In some instances, third parties have fashioned peripheral solutions around them anyway. In fact, some devices wouldnít be ìwirelessî without a peripheral. In the long run, technologies like Bluetooth leave the door open for almost any device to become a peripheral of another ñ with the right software.
If thereís a place for peripherals in your applicationís future, research whatís available when and from whom ñ waiting for a manufacturer to deliver a peripheral could be a risky move. Be mindful of the cost implications as well, since peripherals can add significantly to the solutionís price tag.
If expansion slots and peripherals are not germane to your applicationís present or future needs then you may want to steer clear. Expansion capabilities are not ideal or required for every wireless application. And you may be giving something else up for a luxury youíd best do without.
Peer-to-peer capability seems a bit more fun than functional but itís a device feature not to overlook in your selection process. Better known as ìbeaming,î the infra red (IR) port on many wireless devices adds a layer of capability with considerable value. And peer-to-peer is a feature that all wireless devices will likely have in the not-too-distant future.
IR capability is much more than a way to beam your business ìcardî to another individual ñ although thatís still pretty cool. With peer-to-peer capability, your device can create its own personal network, communicating and exchanging information, data or even complete applications with whoever comes within a few feet.
The implications are considerable when it comes to wireless applications. Peer-to-peer could serve as a way of virally distributing your applications, patches or updates without relying on the wireless or wired network. And while it may seem counterintuitive to bypass the wireless network for a wireless application, just think about all the places wireless doesnít yet penetrate.
Of course, there are limitations. Most importantly the devices need to be compatible or even run the same OS. Palms can talk to other Palms or Handspring devices but theyíd have little to say to a Pagewriter or Pocket PC. They could exchange ìdataî if the applications supported it, but beaming applications across OS types isnít usually an option.
A bigger limitation is that many devices donít have peer-to-peer capability, so if itís a feature youíd like to incorporate your device options dwindle. PDAs are the most common devices with IR ports although there are a few cell phones with the technology.
Bluetooth should change all that. The expectations ñ and hype factor ñ are pretty high for Bluetooth and its personal area network (PAN) concept. Weíre still a couple of years away from the proliferation of this type of technology ñ at a reasonable cost ñ but itís a good bet that it is going to happen.
Peer-to-peer capability hasnít lived up to its original expectations but ìbeamingî has plenty of application potential. Could it be in the cards for yours?
All of the above are worth considering as you evaluate and select the right devices for your particular wireless application. Some may be relevant, others not. But these ìphysicalî characteristics arenít all there is to consider.
Equally as important are the device software issues such as operating systems, middleware, other applications and development tools. And as much as weíd like to think it shouldnít matter, there is the question of device start-up and lifecycle cost. Weíll tackle these next time.
Next Up: Selecting the Right Device - Part 2
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.
|
