Inside Technique : Legacy Data and the Web: WAPping it to the Web!
By P.C. McGrew, EDPP and W.D. McDaniel, EDPP

Has anyone asked you to get your data to a WAP phone yet? Or a PDA? How about a billboard in Times Square? No? Hold on, it could happen to you!

When we first started talking about moving legacy data to the web we all thought we understood the big issues.  We're trying to move some fairly big data chunks that use proprietary formatting to an output device that has lower resolution and some interesting variations in real estate, but which also has color. In this column we've walked through the graphics and font issues enough so that you should have a fairly good idea of what's involved. You need to think about those non-standard fonts, come up with a plan for handling graphics, and develop a strategy for version control across web and paper. that's not everything, but that's a good chunk. And right about now, if you've been following us, you should be fairly comfortable with the to-do list. So, now there is one more consideration. 

Alternative output devices. That used to mean the web, but not anymore. Today when we talk about output to alternative devices we're talking about delivering information to cell phones, PDAs and netpliances. Don't be surprised if someone starts mumbling about delivering utility bills to refrigerators. You can do it today with the right environment. Don't be too frightened; you already have the skills to deal with it. You just need a bit more information about the real world of alternative devices and you can help your company make better decisions.  

Starting with the basics, everything is tagged with markup to accomplish this delivery to phones and fridges. In Europe there are already extensive implementations of something called WAP: Wireless Application Protocol. WAP is the communications protocol that makes it possible to send data to a wireless device and it works through the use of WML, or Wireless Markup Language. Yes, it's another ML, an XML-compliant language that can be understood and transformed by WAP gateways into the stuff your phone and PDA can display. So far so good: we all understand markup languages and what they can do. All of the groundwork you laid for getting your legacy information to the web in HTML or some form of XML applies here. The trick is that WML is a slim language. It doesn't have a lot of bandwidth to play with or storage on the output device, so we don't do graphics today and we don't use identified fonts. This will all come later, but for today we need to get the markup into bit sized chunks to display.  

Let's step back for a moment. Why would I want to get corporate data to someone's phone or PDA? Good question. Think about a couple of  applications:

• Customer service people in the printing area currently see jobs data on their host-attached or network-attached workstation at their desk.  When they are walking through the print shop or away from their desk resolving problems there is no way for them to know what other job statuses are. If that information could appear on a PDA that they carry with them everywhere it would make them more knowledgeable, able to answer questions faster, and a lot more work could be processed with higher quality.
• Sales representatives live and die by their ability to track work in progress, whether its a tractor, a drilling rig, a software package or an eCRM implementation. They are often on the go with limited ability to check email in real time. Pagers work to get their attention, but even two-way text messaging pagers have real limitations. If they could have all work in progress for their customers available real-time on their PDAs they could save hours of email downloads and phone tag adventures. Knowledge is power!
• End users who were early adopters of web-based bill paying are sure targets of PDA and phone based bill paying. WAP phone bill paying is already common in several places in Europe, so we'll want it too!

We've been using the term WAP and we want to be sure you understand that it is not actually available in the US at this point.  While you may encounter something called a WAP phone, in the US there are few WAP gateways that use the true WAP standard. Sprint PCS phones use an earlier version that relies on their gateway and a proprietary transform to their own language for displaying text on their phones. AT&T Pocket Cell phones rely on their own gateway to use a form of display that complied with older, less elegant standards. But slowly we will get everyone reading from the same game book and we'll be able to drive our data to our portable information devices reliably. 

So what do you need to know about your data to drive it to a WAP gateway when they become available here? You need to know how you want it to be displayed on a small screen. What's important and what's not. For the moment, forget corporate logos and color marketing messages. Concentrate on the meat of the information:  purchase order numbers and purchase amounts, invoice numbers and amounts, approval codes, job numbers, and anything else that you'd consider critical information. Then start to look around for WML templates that might work for your industry. Check out resources like the WAP Forum at www.wapforum.org, and the WAP developer's repository at www.wapulous.com. There is even an Open WAP Project at www.openwap.org and WAP toolkits from Nokia and Ericsson. Ask your vendors if they support WAP output from their existing applications. You might be surprised, many already do! 

In the best of all possible worlds when someone comes up to you and says, "Smile! I need WAP output!" You'll be able to smile because you know what you need to do! 

What's next? It's been awhile since we looked at the data issues. We'll return to our roots!  As always, send your questions to siteexpert@mcgrewmcdaniel.com.

Copyright 2000 McGrew + McDaniel Group, Inc. 

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.