Mobile Forms, PDA Forms and Data Collection

Choosing the right PDA

• 1 Talk to your mobile phone provider
  Talk to your mobile phone provider about PDAs. Many of the networks subsidise smartphones which are also PDAs. It may well be cheaper to acquire a number of PDAs via your phone contracts.
  


• 2 Choose the right PDA 'family'
  There are a number of factors which can influence your choice of PDA :
  
  - if users work in an environment where a PDA may have to withstand a fair amount of physical stress and strain, you may wish to consider "ruggedised" devices (eg. Symbol/Motorola, Intermec, Psion). These are particularly suitable for industrial settings. There is always a trade-off on price with these devices - they are more durable and robust than more consumer orientated devices, but they also tend to cost more. You may decide to choose an "unruggedised" device on the basis that you can afford to have X of these break and still save money. A good compromise might be to choose an "unruggedised" device but protect it with a waterproof, crushproof case from the likes of OtterBox.
  
  - if data transfer over the mobile phone network is important then it makes sense to use PDAs with integrated phones. Other solutions exist (eg. non-phone PDAs can use Bluetooth to transfer data via a standard mobile phone), but will end up being cumbersome for your users.
  
  - if a significant amount of text entry is required, you may wish to use PDAs with integrated keyboards (these can be either "clam shell" or "slide out" style.) It is important to consider whether text entry really is required, or whether you've ended up with PDA software that doesn't play to the strengths of a touch-screen PDA.
  
  These factors may well govern the family of devices that you should consider. Beyond this, issues such as screen size, the physical size and weight of the device, support for add-on peripherals etc need to be considered - these decisions should be based on the needs of your users and the requirements of their day-to-day jobs.
  

Top of Page

Design and Scope

• 3 Ensure users can work when they have no phone signal
  Ensure that your users can use their software "offline" (when there is no phone signal or connection to your systems) - mobile phone networks are getting better and better, but you don't want to have to rely on them to complete your job. The nature of many jobs makes this particularly important, for example for those working in hospitals or at the bottom of lift shafts.
  


• 4 Do the important things well
  Your primary goal should be to address the basic requirements of efficiency, turnaround time, quality, consistency or whatever else that has led you to look at PDAs. Spend the necessary effort to ensure that you are addressing these needs with excellent solutions.
  It's very easy to get caught up in "feature creep" and think of more and more "nice to have" requirements for the PDA. Don't try and put every possible function of your "back office" software onto the PDA. Aside from the smaller screen size of PDAs, limited processing and memory capabilities mean that the handheld is just not designed to do what a desktop PC can. The PDA needs to do the important things well.
  


• 5 Don't let the PDA over-complicate things
  Don't expect a PDA to automatically resolve "business process" issues. For instance, suppose you have paper forms at the moment. Once the form is returned to head office, the user has finished with it and has no way of changing the form. With a PDA there is a temptation to "submit" the electronic version of the form but then allow users to modify and re-submit. Think through the implications of what this means, and don't implement a feature just because it's possible. In general, remove the ability to make changes to submitted work.
  


• 6 Don't let the tail wag the dog
  It should be straightforward to give users 90% or more of the functionality that they need. The remaining 10% is likely to consist of "corner cases", many, many one-off cases which are hard to anticipate. Your back office system can probably cope with these, and your staff will certainly be able to - a quick phone call or manual intervention often means that things are resolved quickly and sensibly, without the PDA software becoming over-complicated.
  


• 7 Cut data appropriately
  Think carefully about the data that each user needs on their PDA. If you have a customer list of 100,000 then it almost certainly doesn't make sense to store a copy of this on each PDA. Think about what it is that defines the set of data that an individual user is interested in - is it their region of work, job role, etc ? In cases where it's genuinely not possible to know in advance which records the user may need, it may make sense to build in an "online lookup" which can pull down information as and when needed.
  Implementing different sets of data for different users shouldn't be a big problem.
  

Top of Page

Users and Usability

• 8 Make your software easy to use
  Make the software as easy to use as possible for the user. Data input should be through check boxes, drop down lists and "radio buttons" wherever possible. Avoid free text, but where it is necessary, make it easy for users to enter common phrases.
  
  Navigation within an application is also important. Give thought to the tasks that your users need to carry out and how the PDA can blend in with them.
  


• 9 Add user-friendly features
  Give the users features that will improve their quality of life. The ability to fill in timesheets, leave requests, read background documents etc during unproductive moments will remove chores from the users, at the same time as improving your internal communications flow.
  


• 10 Consider 'one-handed navigation'
  Most PDAs now have dedicated hardware buttons or navigation pads design to make it possible to use the device one-handed or without tapping on the screen. Take advantage of these - a well-designed and programmed application should make it possible to use the PDA much of the time without a stylus. This makes things much easier for the user.
  


• 11 Automate common tasks
  If a particular action by a user necessitates a further action, then build this into the software. For example, suppose a user answers "Unsatisfactory" to a question. Presumably they need to substantiate this in some way - in that case, take them to the "additional details" screen automatically, without them having to think about it.
  


• 12 Use sensible default values
  Data entry on a PDA needs to be as simple and quick as possible. In many cases applications are written where the user has to go to the effort of manually selecting a particular value, even though this value is chosen 9 times out of 10. Not only does this waste time and effort, it can give the user the impression that the software is "dumb" and unhelpful.
  

Top of Page

The Project

• 13 Pilot your solution
  When you have a solution, pilot with a representative, but small, group of users. The users should be receptive to the use of mobile technology, but should also be prepared to be critical.
  


• 14 Avoid the 'Big Bang'
  Try to avoid the "big bang" approach when rolling the PDA system out to larger groups of users. Following a successful pilot, it makes sense to gradually expand the user base. A PDA solution lends itself more to this type of rollout than, say, a company-wide billing system which tends to be "all or nothing". Take advantage of this and allow any issues uncovered during rollout to new users to be dealt with in a controlled manner.
  


• 15 Use tools for setting up devices
  If you need to set up a large number of PDAs, look into using a tool to speed this up (we use www.pocketpcinstaller.com)
  

Top of Page

Software

• 16 Build in flexibility
  A well-designed application should make it easy for you to change more minor details. For instance, an application for service engineers will need to deal with things like work lists, visits, customers, job completion etc and you wouldn't expect to make fundamental changes to this basic structure. However, if the user needs to complete a small survey then you should expect to be able to add, update and remove individual questions from that survey without paying for more programming work.
  


• 17 Cope with changing screen sizes and orientation
  You will probably equip your users with a particular device or family of devices. However, it makes sense to ensure that software that you purchase will cope with being run on a different model with a different screen orientation, resolution or size.
  


• 18 Use generic photo capture support
  Ensure that any photo capture support in your software isn't tied in to a particular manufacturer or model of PDA. In older programming environments this was not standardised so you could end up with your software working on some PDAs but crashing on others.
  


• 19 Enable security features
  Ensure that you have a login screen for the PDA so that your data is password protected. Also, there's no good reason not to password protect and encrypt the PDA database itself. PDAs can be easily lost or mislaid - these steps will ensure that your data is well protected in the event that the PDA falls into the wrong hands.
  

Top of Page

Other Systems

• 20 Ask the right people how to interface to their systems
  Interfaces to other systems - do this well ! Ensure that the people who "own" any back office systems or databases have control over how these systems are accessed. A poorly designed interface can compromise the data, cause performance problems and produce a support nightmare. Any interface should be well defined and "clean".
  

Top of Page

Data Transfer

• 21 Don't fire data around just for the sake of it
  Think clearly about when information is needed. Technology exists to push and pull bits of data anytime, anywhere. That doesn't mean that your systems necessarily need to do this. If certain work is processed once a month, then there's no need for changes to be updated every 10 seconds - make sure the data is available when it's needed.
  


• 22 Think about data transfer methods
  The method you choose for synchronising PDA data with other systems will largely be determined by the mobility and needs of your users. If users need to be sent updates to jobs throughout the day, and their works entails them travelling around, you will need to use the mobile phone network and GPRS. If workers receive their jobs once per day and you need the results at the end of the day, then it may make more sense for the user to synchronise via a home or office PC. In other cases a WiFi connection may be more appropriate. None of these scenarios should make a significant difference to the PDA software - the communications medium is largely transparent. Using the mobile phone network is the only method that should cost you money.
  


• 23 Keep a critical eye on synchronisation times
  Once a PDA has been loaded up with data, a regular daily synchronisation of data should not take a long time. Obviously circumstances differ, but if your synchronisations are taking more than a few minutes you should look into where the bottleneck is. The chances are that data is being transferred and updated when it needn't be. This can have implications for your phone bills (if you're using GPRS) and also the load that your servers can cope with. For instance, if sync sessions took 30 minutes then the likelihood is that you will have many users connected at the same time with overlapping connections, leading to a downward spiral of performance.
  

Top of Page