A Quick Primer

First let’s quickly review the two pure avenues available to us when developing a new mobile app:

1. Developing a Native Mobile App:  in this approach we develop the app similar to the way native Windows or Mac OS software applications are developed.  This typically means that we write code in a language supported by the target platform (e.g., Objective C for Apple iOS) and we use the specific software development kits (SDKs) for the target platform (e.g., Android SDK published by Google)  Once such a native app is developed, it is distributed via the platform vendor’s own app store or third-party app stores in some cases.  In either case, the end user must download and install a native app which resides and executes on the given mobile device.
2. Developing a Mobile Browser App: these types of apps are in essence developed using the same tools and techniques used as good ole’ regular websites and web apps.  The app is accessed on the mobile browser and is designed and optimized to work with the constraints of these browsers.   With the increasing popularity of the HTML-5 standard, mobile browser apps are providing functionality that in many instances rivals that of native apps (see recent LinkedIn iPad app as an example)   Consider for instance that with the HTML-5 apps can now cache portions of user data on the mobile device and provide offline access to this data when no cellular connection is available, a type of functionality that used to be exclusive domain of native apps.

Pros and Cons

So how are native mobile apps better or worse than their browser brethren?  Here’s a quick list of pros and cons:

Native Mobile App Pros:

• Better application performance;
• More attractive interfaces (less generic);

Native Mobile App Cons:

• Need to install software on device (added step for users);
• Need to develop for each platform separately; duplicates development, QA and upgrade efforts (big con for app developers)

Mobile Browser App Pros:

• No software to install or upgrade; always access the latest version the moment it is updated on the server.
• From the developer perspective: write once deploy on many platforms.  It is worth noting that this is not always the case.  For instance if the app in question needs to take advantage of not-commonly-used functions on a given platform then most likely it will need to be deployed as a native or at least a hybrid application.   As an example think of an app that needs to capture users’ complex gestures on the device touch interface and couple this with input from the device accelerometer to rotate 3D drawings on the screen.  Such an app would almost definitely need to be developed as a native app.

Mobile Browser App Cons:

• Relatively lower performance.  A mobile browser app may for instance experience more delays when loading  a list of items or pictures than  a native app.

• More generic user interface/experience: native apps provide designers with maximum control over the look, feel and behavior of screens with the design adapted to the specific platform and its capabilities.   Given the need for cross-compatibility with various mobile browsers, mobile browser apps are limited to more of a standard, generic experience consisting of standard list elements, picture boxes and other standard controls.

Split the Difference

A third option that makes sense in many cases today is to develop a hybrid app.  Hybrid apps let developers strike a balance between the pros and cons of the above ‘pure’  approaches.   Although a hybrid app still needs to be installed and updated on the user device, it provides the opportunity to access more nimble functionality i.e., get access to the ‘bare metal’ on each given platform.  For many less demanding or common screens of the app, hybrid apps take advantage of HTML pages that essentially act like a web page except that they are displayed and integrated with the rest of the app.

Guidelines to Inform Your Decision

In summary, the choice of how you build an app (i.e., pure native, pure browser or hybrid) is largely dependent on the nature of the app being developed.  The chart below visualizes how such a decision is affected by various factors.

• Importance of Performance/Speed ->  High (go native)   |  Low (go browser)
• Importance of Unique User Interfaces ->  High (go native)   |  Low (go browser)
• Users Ability to Install and Update App ->  High (go native)   |  Low (go browser)
• Need to Access Deep Native Functionality ->  High (go native)   |  Low (go browser)
• Number of Platforms on Which App Must Work ->  High (go browser)   |  Low (go native)

Please let us hear your thoughts and feedback via the comment section below.

About the Author: Babak Sardary is a veteran of field engineering and founder of Trusterra Technologies. Trusterra develops the Scoop™ mobile software platform helping thousands of users in distributed teams record, alert, collaborate and resolve issues across field and office.

John may not be a real person but this kind of scenario is and by no means unique to industrial machinery.  It happens thousands of times a day across a variety of industries: a construction project manager notices a structure is not built to spec, a refinery field engineer notices a major deficiency during a walk-through, an HVAC installer is puzzled by the plumbing configuration at a new job site…

The fact is everyday field workers come across issue and situations that need to be decided and solved quickly often under time pressure and often when these folks are isolated from the rest of their team.  In the absence of quality and timely advice from their peers, seniors and managers, workers can make poor quality decisions that adversely affect customer and project outcomes or worse yet result in serious safety incidents.

So for someone like John what determines the decision to get help or to go solo?

The factors may seem complex and dependent on the specifics of each case but in my experience they can be categorized into three categories:

• Availability: if I decide to get help, what are my chances of engaging the right resources?
• Speed: if I can reach the right people, how fast can I explain the problem & get a solution?
• Perception: if I reach out to get help, how would I be perceived by my colleagues and management?

These factors are affected by the choice of tools and technologies available in the given organization but also by the type of culture that governs interactions.

Below are a number of practices to use to help promote an efficient and healthy collaboration atmosphere focused on efficient problem solving:

1. Formulated Judgement: a culture that recognizes and balances the value of taking initiative with the importance of recognizing when one is over one’s head on a given issue is key. However the culture without clear guidelines is not enough.  Establish guidelines (ideally written) and train your people to recognize the signs to make a call one way or the other. In one of my past companies we came up with a score-based system including checklists.
2. Recognize Goals and Assists: when a customer issue is resolved or an ingenious solution to a tough project issue is proposed, make sure you explicitly ask for and recognize not just the lead but also the contributors.
3. Select the Right Tool: the importance of using the right IT tools cannot be overemphasized.  In a distributed team environment you have people and issues strewn across work sites, offices and time zones.  A nerve system is needed to connect people and make them available to one another.  Once you establish availability, the communication platform needs to take into account the unique needs and pressures of people working in the field.

For a description of the attributes of such a nerve system have a look at my previous post titled: Field Team Coordination Can Be Simple

Please let us hear your thoughts and feedback via the comment section below.

About the Author: Babak Sardary is a veteran of field engineering and founder of Trusterra Technologies. Trusterra develops the Scoop™ mobile software platform helping thousands of users in distributed teams record, alert, collaborate and resolve issues across field and office.

When it comes to distributed teams, coordination takes on a whole new  dimension. It becomes an even more interesting problem for teams dealing with field work on machines, equipment, structures and other physical things–subject matter that is not easy to transport, email, ship and show to others.

Coordinating the work of these individuals is no mean feat.  For even a medium sized infrastructure project it can easily take a platoon of project managers, coordinators, field inspectors and others to just keep the data on issues and work progress mildly up to date.  The sad part is that after all this effort, the vast majority of the data collected simply gets archived at the project office, never seeing the light of day and finding its way to the actual people who would benefit from it.

Legacy methods of team coordination (paper-based, manual processes) are a huge drain on  resources and leave numerous opportunities for waste, delays and mistakes.   At the root of their shortcomings is a common element: they fail to remove the barriers in space and time between the information in the field and the people who need them most.  Without timely access to pertinent  information field workers cannot send / receive the often small yet significant signals (input, advice or support) needed for others to make decisions, resolve issues and in  general move the project ahead.  These effects are cumulative and therefore a great deal of success and  failure of field projects depends on removing these barriers and achieving a fully-coordinated team (you see when you get rid of time and space  differences between team members and what each of them knows you achieve coordination)

Sounds  simple enough right?  Well in fact it is simple as long as the right tools and approaches are  employed.

To achieve real time team coordination in the field, the collaboration tool you use must possess these attributes:

1. Must be designed for and aligned (religiously) with mobile worker needs: because field people work differently and face different pressures than those sitting in an air-conditioned office with a big monitor and full-sized keyboard.
2. Must be issue-centric to provide self-organization of information: because email and phone and excel sheets create mucho chaos and it is a full time job to coral them.
3. Must allow for asynchronous even offline communication and contribution (work-shifting): because our schedules are harder to mesh each day and because we’d rather finish up tending to those pesky issues on the plane ride back from the field (rather than watching Mars Needs Moms and drinking a lukewarm beer)  That way we can have more family/personal time when we land.
4. Must allow for symmetric communication across organizations:  Because we increasingly work with colleagues across other organizations and a system that takes 2 requisition forms and 3 signatures to give an outside contractor access just won’t be practical.

So you see, the tools we use don’t need be complicated with a million features and charts and graphs that trip us over.  They just need to observe some basic philosophies.

This focus on human-friendly communication and simplicity forms the basis of our Scoop platform.  Check out the Scoop tour for more information or simply start your free trial.

Please let us hear your thoughts and feedback via the comment section below.

About the Author:  Babak Sardary is a veteran of field engineering and founder of Trusterra Technologies.  Trusterra develops the Scoop™ mobile software platform helping thousands of users in distributed teams record, alert, collaborate and resolve issues across field and office.

Basically the calculations showed that a field team of 30 could save over $1M/year if they follow some pretty basic communication practices.  I plan to flesh this out more and and post it in a future blog entry but for now here are the practices we compiled to effect this whopping savings:

1. Ensure issues are reported when they happen (not 2 hours later, not 2 days later)
2. Have the report be accompanied with a complete description (hint: a phone call/email is not enough)
3. Get the right people for that issue or decision involved from the get-go.
4. Find a central place for discussion and keep all data for future reference (it’ll happen again)
5. Make it possible for people to contribute to the solution on their own time (meetings are not very productive & don’t produce the best solutions when it comes to this sort of thing)

Please let us hear your thoughts and feedback via the comment section below.

About the Author:  Babak Sardary is a veteran of field engineering and founder of Trusterra Technologies.  Trusterra develops the Scoop™ mobile software platform helping thousands of users in distributed teams record, alert, collaborate and resolve issues across field and office.

Mission Update

Here’s a quick selection of most recent Scoop developments to bring you up to date:

• Scoop Android App
  After several months of intense development we are getting very close to releasing the Scoop Android App.
  sign up for automatic alerts
  
• Scoop Labs: Intelligent Search
  Trusterra has partnered with researchers at Simon Fraser University to develop intelligent algorithms that sift through content you generate to make it easier for you to search and find comments and media related to issues easier and faster
  read full press release
  
]]> http://www.scoopapponline.com/1346/feed/ 0