Mobile developers need to be different than enterprise developers

Please take a moment and re-read this blog title. Internalize it. Ask yourself why and how?

I'll wait. <pause for effect>

This seemed like a silly exercise, but I wanted you to take some time in order to prevent you from filling your mind with the reasons why you disagree with the statement. Instead of coming up with excuses like:

  1. We will be using the same workforce
  2. We don't have anyone with mobile experience
  3. Mobile development is just another language in their toolbox
  4. Any developer can work in the mobile space

Let me explain a little more why I think mobile developers are different than the classic, enterprise developer. I'm not saying that the physical person is different, however, the style of approach and the framing they bring to a project is definitely different. It needs to be different or it would be the same. Due to its nature, mobile development is different because of the following. That's besides the to move content onto a mobile device.

Security

Enterprise developers are spoiled. Most applications land on an environment that is isolated with firewalls, corporate malware protection and multi-layers of validation and authentication. Even when some innocuous item explodes into a monster with many arms on the inside, it is short-lived and minimal in impact. We write very little internal validation routines and depend greatly on an ever present infrastructure. In the mobile space this does not exist. These devices are in the wild and oftentimes even belong to the employee who manages their own application stack on the device.

What needs to change?

  • Form-level validation before submission
    • Re-check submission on the server side
  • Multiple levels of encrypted authentication
  • Use of encryption devices/containers
  • Manage encryption keys - do not hard code anything
  • Understand pattern recognition, protect when exploit detected

Know your data

We like to reuse and connect different data stores in order to deliver all the data that will be needed. On the enterprise, there are different layers of data protection through classification. In the wild, outside of the protection of our enclaves and firewalls, we want a higher level of control over what is transported and exposed in order to protect our intellectual property. Data will be needed for the mobile applications, you need to be very smart and decisive about what we push out there.

What needs to change?

  • Establish a parallel data classification for mobile
  • Determine where your threshold is to expose
  • Put in place controls if going above the threshold (encryption, VPN, etc.)
  • Remove data at rest to avoid loss (sensitive data)
  • Minimize cache

Screen size

Ten years ago, developers working on the web or most desktop applications were building for a very small screen size. As monitors became cheaper and as the underlying hardware/software stack matured, screen resolutions grew. As such, most enterprise applications that target a desktop/laptop client (web or native) does so with a screen size that exceeds most (if not all) mobile devices.

What needs to change?

  • Auto-sizing GUI
  • Segregate content
  • One function, one screen

Overly complex navigation

We are creatures of habit, and over the last decade our designs have been driven based on the needs of our customers. With our habit may come a tendency to implement overly complex and bulky navigation. Too many choices means too much to display on a mobile device screen. We must learn to simplify. We need to compartmentalize what we deliver.

What needs to change?

  • Reduce displayed navigation options (horizontal)
  • Reduce the number of options in drop-downs (vertical)
  • Only provide those which will be needed for the immediate function/feature

Bloated applications

The mobile space is one of limited horsepower and limited real-estate. With that thought, you need to also understand how () you migrate over. Breakdown your solution to discreet options based on use-cases of your consumers. Minimize how much "extra" you place into the application because of assumed need or false opportunity.

What needs to change?

  • Create use-cases; validate there is opportunity in the mobile device
  • Partition based on functionality
  • Target the right consumers with the right application at the right time
  • Keep out fluff
  • Validate with consumers (before delivery)

Multi-functional

The Jack-of-all-trades is a nice person to meet, but not necessarily a nice application to deliver. If you consider that "Bloated applications" have no place on mobile devices, you can then think about targeting certain features/functions/groups, and focus.

What needs to change?

  • Review "Bloated Applications above"
  • Focus, focus, focus

Large datasets

When you deliver a native application into the mobile space, you get the flexibility of working with some local storage. But each device is different and you shouldn't consider your consumers devices as your storage space. Think of it this way; do you want someone using all your available storage simply to store content you may never use or do not see value in?

What needs to change?

  • Consider keeping content in the cloud somewhere
  • Cache is one way to minimize the delay in content for the user
  • For the enterprise space, consider a Content Delivery Network, as a faster middle-ground, to accelerate cache delivery
  • Delivery a picture instead of a large dataset

Complex processing

Although many of our devices now have multi-core capabilities, they still lack the full computing power of our desktop and server systems. Distributed computing tenets state you should utilize many systems to perform tasks faster, giving the perception of speed. However, avoid doing this inside the mobile space. Using off-device computing services can help your consumers experience a fast application regardless of device and regardless of the size of the payload that is being processed.

What needs to change?

  • Off-device processing (through services implemented in server systems)
  • Stage pre-processed content (reports,summaries, images)
  • Offer preferences for on-device processing
  • Use idle-time (on device) for processing, if the consumer selects this in preferences

Distribution methods

Typical internal application stores may not have high levels of "signing" and packet checking, to ensure that no malware has modified the content. We fall under the umbrella of a protected environment (see Security, above), and use open environments.

What needs to change?

  • Signing code
  • Verification method, separately maintained from signing mechanism
  • Distribution methods which uses code verfication

Data entry

We use applications to create and manage our data. The use of keyboards are integral to that data entry. Our training and ergonomics allow for effective keyboards which accelerates data entry. Two hands, nice and comfortable, rapid typing. Our mobile devices do not have that capability, even those with keyboards.

What needs to change?

  • Know that data entry should be minimized
  • Use other mechanisms/sensors (camera, barcode, location) to facilitate data capture
  • Present options for selecting vs. asking for specifics through data entry

Personal safety

When someone has a laptop, and some data is stolen, we don't often worry that the thief can track you back to your home and harm you. Of course that depends greatly on the level of data that the individual stores as well as how enterprise solution is protecting it. On a mobile device, in addition to data which may be similar to our PC's, we have sensor data. A motivated  person could easily assemble a map of your usual activities and try to cause harm.

What needs to change?

  • All data should be protected
  • Personal information needs

How is your mobile strategy shaping up?
Do you have any learning's you would be willing to share?

This is a very exciting time to be alive and developing content for consumers (internal and external to your company).