Auto ID: Avoid Obvious Implementation Mistakes
Wednesday, July 21, 2010 - AIM Connections

Bert Moore

Editor

 

What everyone can learn from Apple's iPhone 4 problems

 

The widely-publicized problems with Apple's iPhone 4 show what can happen when automatic ID or mobile IT solutions are deployed without adequate testing.  I don't mean testing from an engineering and systems perspective (the "will it work up to spec?" kind of testing) but testing from a user perspective (the "what happens if I use the scanner as a hammer?" kind of testing).

 

So how does the iPhone 4 illustrate this?

 

Background

 

It's questionable whether Apple put the iPhone 4 in the hands of actual users in real world situations. If users had tested it, the antenna problem and the "face dialing" problem would have been fixed before the device was launched. For those who haven't been following the story, here's a quick summary.

 

Reportedly, blocking the lower left-hand corner of the iPhone 4 creates the most significant problem in terms of decreased antenna efficiency and dropped calls. Yet holding the phone so that the lower left-hand corner is in the palm of the hand is exactly the way a left-handed person would hold the phone. Were all the testers right-handed? Or did testers work in a relatively pristine environment where the reduced signal strength wasn't a problem? Or did they just train testers to hold it so that the antenna wasn't blocked?

 

The other significant problem is "face dialing". Apparently the touch screen is too "touchy" and interprets pressure from the face while a user is talking on the phone as a command to launch a different application or dial (apparently at random) someone from the user's phone list. If you're playing Roulette and place a chip at the intersection of four numbers, you don't care which one "hits" -- you win in any case. This is definitely not the case when launching apps on a smart phone. You do care which application -- if any -- is launched.

 

There's also the problem of random "muting" that results in the person on the other end of the call unable to hear the user. The competing wireless provider's catch phrase, "Can you hear me now?" seems oddly appropriate in this case.

 

Lessons to be learned

 

Engineering testing is essential for all equipment that is being considered for an auto ID or mobile IT application. You need to verify a device in terms of performance, durability, duty cycle and so forth because product specification sheets don't always tell the full story (or even tell the whole truth).

 

For example, if you're looking at bar code printers or RFID encoders, you need to know time-to-first-label, time-to-subsequent-labels, speed for variable data versus speed for fixed data, integration with existing system software and infrastructure. These are all very important.

 

But once viable candidate equipment has been identified, it's time to put it in the hands of those who will have to use it. The relative success or failure of a system often hinges on workers' acceptance of the devices as much as it does on how the particular device integrates with the work flow.

 

Here are some examples of the types of considerations workers will have.

 

Bar code readers

 

There are several form factors available: wearable ("ring" scanners), hand-held (of various types), integrated (in a mobile data collection device) and fixed location (from small to very large). And there are linear (laser and CCD) scanners and 2D imagers. Which type will be least intrusive to the work flow?

 

For example, an application where linear bar codes may need to be scanned in either ladder or picket fence orientation will require the worker to constantly orient a linear scanner to the symbol, resulting in strain on the worker's wrist. A 2D imager avoids that issue.

 

Or take an application where the worker is constantly handling items to be scanned such as in a hospital operating room. Here's one case where a small fixed location scanner (or a hand-held with a scanning stand) might be a better solution and not interfere with the surgical nurse's more critical job of assisting the surgeon.

 

For picking, a ring scanner or a small-fixed location scanner on the pick cart might be a better choice than a hand-held.

 

There are applications where data needs to be constantly entered into a mobile computer. For these applications, an integrated reader may be most efficient since the worker is already holding a device.

 

In all these scenarios, the workers will usually be able to quickly identify potential problems with a given device and identify the one(s) that will be easiest to use.

 

Bar code printers - RFID printer/encoders

 

Evaluating a printer or printer/encoder in a lab is one thing. Typically there's room to easily access the printer to make adjustments or change media. It may be entirely different in practice. Some printing locations are poorly lighted, cramped and less-than-lab clean.

 

The relative ease (or difficulty) of changing label or ribbon stock where the printer will actually be used can have a significant impact on efficiency and on the likelihood that routine cleaning and maintenance will actually be performed.

 

The physical environment should also be considered. When large items that are not moving past a fixed point need to be labeled, a WiFi-enabled printer mounted on a cart or a small wearable printer could bring the printing solution to the items to be labeled. This could be more efficient than having workers walk around with batches of labels to affix to the items.

 

Voice systems

 

Voice systems offer a number of benefits and are gaining popularity for a pick/put-away, inspection and similar operations. These systems, too, are available in various form factors -- from those integrated into full-function mobile computers with keyboards and large displays all the way down to small wearable devices with only a few buttons.

 

It may seem that having the full function device will be more cost-efficient in allowing the same device to be used for multiple applications but having too many features on a voice system may actually reduce efficiency if workers have to spend time setting up and configuring the device.

 

On the other hand, some may see a device with very limited functions as being more cost-effective. However, limited options may require workers to call supervisors to handle exceptions or perform the occasional additional task.

 

Of course, the activity also needs to be taken into account. If the worker's primary function is to be handling items (in pick/put-away) then having a hand-held mobile computer may be counter-productive. On the other hand, if bar codes or RFID tags need to be scanned, then the ability to interface a wearable scanner is essential.

 

Mobile computers

 

Mobile computers are available from hand-helds to those mounted on lift trucks or carts, from full keyboards and touch screens to small devices with limited (cell phone style) key boards and small displays. And in some applications, smart phones are taking the place of mobile computers.

 

Again, the work environment plays a key role in deciding which device is most appropriate. For touch screens and keyboards, workers who need to wear gloves will need larger touch areas and keys. For refrigerated or cold weather applications, heaters and cold-tolerant displays will be required.

 

For account representatives and route sales people, smaller devices -- including smart phones -- will be easier to carry and use. In many cases, a smart phone that can access the corporate database (to tell a customer inventory status, for example) provides the greatest flexibility and capabilities without encumbering the worker with an additional piece of technology to carry to the customer's site.

 

Whether a bar code, RFID or even magnetic stripe reader is integrated with the device or is separate depends entirely on the activity.

 

Conclusion

 

The examples above are certainly not inclusive of the technologies or worker considerations. Each technology, each device, each activity, each facility and each employee pool will have its own characteristics and some may have relatively unique requirements. The purpose of these examples, then, is simply to illustrate how the device, work environment and worker must be matched for optimal performance.

 

Devices that are difficult to use or cause more work for employees are more likely to "break". Or workers will figure out ways to circumvent the system to make their lives easier. And systems that aren't being used don't return any benefits.

 

Taking the time to get worker input can significantly reduce implementation problems and help ensure maximum benefits from the system.

 

Because you can't just issue a cute carrying case for a poorly-designed auto ID and mobile IT application.

 

-----

 

Comments on this column? E-mail me: Bert Moore, Editor

 

 

Share this Story
Digg   del.icio.us   Yahoo   Reddit   Facebook   Google

Related Articles :
No Related Content Found

Search Articles :