FieldMetrix for Android

 

At the end of Q1 2012 we will be releasing a version of FieldMetrix for the Android written using Xamarin’s MonoDroid.

The Android version will support Field Service Forms and allow mobile data capture of the following FieldMetrix Tasks:

  • User customizable forms
  • Signature Capture
  • Images/Pictures

As with our Windows Mobile version all tasks and activities are geo-stamped. Data captured using FieldMetrix for Android is automatically emailed out as a PDF to specified stake holders and will also be available on the FieldMetrix web admin console.

Local Stock Mode Enhancement (Direct Store Delivery)

(view the screen cast above in full screen mode to see more detail)

This enhancement was based on a customer request and allows stock or inventory to be loaded onto a vehicle and then scanned off (delivered) at different locations. This wouldn’t be that different from a traditional delivery workflow except for the fact that Local Stock Mode allows the creation of ad hoc sales and automatically creates and emails out the delivery note.

The video grab above shows the following:-

  • A field sales person loads stock onto a van; barcode scanning the items as they load them. (In this demo the client calls the inventory in the van “Boot Stock”)
  • The salesperson then proceeds to a client and completes a mobile sales order against the stock in the van.
  • The salesperson scans the barcode of an item that needs to be replenished and the device shows the “van” stock available.
  • Once the order is complete the sales person does a “Pick” barcode scan of the items in the van and returns with these to the client.
  • The client signs off on the goods received and a delivery note is automatically generated as a PDF and emailed to the client and other stake holders.

Every item of data captured by the device is time-stamped and geo-stamped so you know exactly when and where the activity occurred. Since we know what was loaded onto the vehicle it’s easy to reconcile this against the customer approved deliveries.

Please don’t hesitate to contact me at derek@fieldmetrix.com if you would like further information.

When a Ferrari isn’t fast enough

Most of the time it’s a pleasure to engage with clients that are increasingly becoming technically savvy. I add the caveat though because there are two areas where it’s a nightmare. The first situation is where clients believe that because their iPhone or Android device can interpret a barcode using the built-in camera or save a rudimentary signature as a jpg that it will able to perform adequately as the device of choice for their field workers. My second rant is about HTML5 – I’m building a head of steam for this one, and since I’ve already vented a little on this topic – I’m saving it for next week.

Before I go any further I must also openly disclose that I love my iPhone 4. It is hands down the best consumer device I own, try and pry it from my cold dead hands! (I also own a Windows Phone – Mango but the dalliance is in it’s early days).

So why can’t you use your consumer grade cell phone for field service? Well it’s like saying “My Ferrari has four wheels, a steering wheel and a loads of horsepower so I’m going to enter it into the World Rally Championships!” Yeah right! It will need a service after 500m on the dirt and will spectacularly throw a piston when the oil sloshes to the left in the first hard right turn. If I had been able to say yes for each time I’ve heard “So I can run this on my iPhone?” I’d be rubbing shoulders with Richard Branson on Necker Island.

Now you could argue that clearly this is what the market wants; and you would be right. The street is always going to be enticed by the new cool “kids on the block” but in the world of field service; they aren’t going to cut it for the following reasons: performance, functionality and cost.

Rugged devices offer the following advantages over consumer devices:

Device ROI: drop your iPhone or Droid once on a cement floor and it’s toast, not so for a rugged device with a mil spec rating.

Barcode Scanning: there are some situations where fiddling about for several minutes in low light conditions to get a single image based scan is acceptable; but there are a lot more where you want the reliability of effortless point and shoot barcode scanning that supports both 1D and 2d scans.

GPS accuracy: sophisticated GPS receivers that can still hold a fix beyond first wall penetration

Usability: rugged handheld manufacturers have evolved their devices for use in the field. Have you ever tried to use a consumer cell phone wearing gloves? You can capture signatures on your iPhone but did you know you need a custom stylus to work with the capacitive touch screen? What about fluctuating temperatures, dust, moisture, being left in direct sunlight for extended periods?

After Sales Service: rugged device manufacturers have excellent after service support options. For a nominal service fee you can get a plan that will offer next business day replacement. Most of us regard these “insurance” plans as extra-profit generators, however think of this cost in comparison to the down time costs of unproductive mobile employees with a DOA device.

Call me a tree-hugger but I can’t see the sense in conscripting a consumer cell phone device into service when it’s going to turn and run when the going get’s tough.

A few months ago I read about a company that had equipped a fleet of iPhones to do field service at a cost of $1200 per device. For that price you could buy two Motorola ES400’s or a top of the line MC55 – both of which would out perform an iPhone in almost every area of use. I bet dollars to donuts the exec who made that decision owns an iPhone or a Droid.

Native Mobile Apps are dead, Long Live Native Mobile Apps

I would love to make FieldMetrix device agnostic using a web application that can target multiple device platforms, as opposed to the current approach where native applications are required for each target (device) platform. I am passionate about FieldMetrix’s codebase being elegant and efficient; no doubt the result of twenty years as a professional developer who has produced thousands of lines (of wholly unnecessary) code. Of course the smaller it is, the easier it is to test, extend, maintain and trouble-shoot. I derive a measure of satisfaction from the state of our codebase and I don’t want to jeopardize that by writing legions of Javascript code which can’t be tested at compile time. With these self imposed standards in mind I periodically investigate the “state” of HTML5 to determine whether it is finally mature enough that it will meet my needs.


100% data integrity is critical for us; our native Windows Mobile application deals with intermittent connectivity, high latency and connection dropouts without missing a beat. So I go into full ‘tech mode’ researching HTML5 and it’s offline storage capabilities. This is fueled by the enthusiasm of the HTML5 community and the promising samples on sites like HTML5Rocks. Perhaps this time I will find a best practice approach that will meet the needs of a mobile web app for FieldMetrix? Unfortunately the excitement is always short lived as I discover the numerous caveat’s and pitfalls associated with an actual real world implementation.

Mobile Web vs Native Application Functionality

For applications that focus exclusively on text-based data capture the mobile web and HTML5 offline storage is a very promising one-two punch combination. Using a mobile web application expands the number of platforms your application can target, and HTML5 offline storage can ensure some level of data integrity by caching results when connectivity is compromised. Where the path forward becomes more complicated is when your application requires deep integration with the device’s peripherals such as barcode scanning, signature and image capture as well as GPS location information.

Sure you can access some of these device capability features using HTML5; for example images using the ‘canvas’ element; however there are a number of issues:

  • accessing different device platform capabilities often requires platform specific tweaks
  • robust caching of non text data capture such signatures and images would require a lot of work (for each platform)
  • detecting the online/offline is often not reliable and leads to a whole slew of issues

Full Circle

Inevitably I find myself coming full circle. The efficiency of a single code base, potentially deployable to a multitude of device platforms is hugely appealing but at what cost? Firstly the “store and forward” capabilities of non-text data capture will be compromised. Secondly the eccentricities of different device platforms will require considerable massive coding effort. Finally you’re guaranteed to be chasing moving goal posts as web based access to phone capabilities improve – and you can bet these gains will require platform specific tweaks too!