Home

How Hollywood Thinking Can Help Mobile App Development

Right brain versus left brain

Analytic versus creative

While everyone uses a bit of both sides, would most agree that software programmers by training and disposition exhibit more analytical than creative tendencies?

Not that long ago – less than ten years – nearly all enterprise mobile apps were text based. And, of course, the wireless Industrial mobile devices were primarily monochrome at that time (and many are still in use today). Software mobility programmers didn’t have to worry about graphics or colors or visual designs because it was all text. All they had to do was program mobile code to reflect Visio logic flow charts. These were straight forward programming tasks.

The exact date of when the world of mobile programming was turned upside down is debatable. Many would argue it really started in earnest on January 9, 2007 when Steve Jobs introduced the iPhone at MacWorld. It changed once again on January 27, 2010 when Steve introduced the iPad at a press conference in San Francisco.

Since then, mobile software programmers have been forced to consider and include visual design elements as they never had before. Abruptly, the analytical programming guys were also tasked to be creative. Talk about fish out of water!

So, how can IT managers today help those analytical programming guys address creative design image concerns and needs?

Take a hint from Hollywood.

Movies are complex visual creations, just like mobile apps. And, with the advent of computer created graphic special effects, movies have increasingly become huge technology IT projects.

However, movie directors don’t use Visio logic flow charts to construct the plot outline of a movie. Why? Logic flow charts don’t convey much information beyond what to do next if the answer is yes or the answer is no.

Movie directors need more contextual visual content and information. They use story boards.

Story boards are short-hand visual representations of all of the design and graphic elements that may be included in a single scene on the silver screen. Story boards are collaborative efforts from and used by graphic artists, designers, editors, and many others.

A storyboarding technique can be employed to assist programmers to aid their development of a uniform look and feel for their mobile screens, too. The best news is that everyone already has a handy tool on your desktop for just such a purpose: PowerPoint.

PowerPoint is a nifty graphic tool that can be utilized to create storyboards for an entire mobile app – screen-by-screen and function-by-function. And, using the embedded hyperlink capabilities in PowerPoint, one can simulate simple navigation to show what will happen if one pushes a screen button or enters a specific value.

The best part of using a PowerPoint storyboard is that it is a realistic visual representation of your mobile app that can quickly be created so that executives and other interested parties in your company can grasp intent, review content, and give final approval prior to any code being written.

Image
Mock-up menu screen created in Powerpoint

Your company may save both time and money if you have collaborative meetings with your creative marketing team and your analytical programming team to hash out what is possible and what not possible before you have expensive project creep.

As the saying goes, one picture can be worth a thousand words and storyboards are a simple way to move forward with complex mobile application development.

Mobile Apps Need Mobile Style Guides

Mobile app development should first start with a mobile style guide in place.

For better or worse, your mobile app presents an image of your company’s brand excellence.

And, the effort your company puts into protecting and fostering your company’s brand image should be no less when developing your mobile apps. Programmers may find they need to work closely with graphic designers, marketers, and, maybe even lawyers to provide a polished and completed product.

There are four key considerations that all mobile style guides should contain to help provide consistency: (1) a consensus user interface for navigation techniques like swipes, pinches, etc.; (2) visual placement guidelines for images, graphics, colors, menus, icons, and text boxes; (3) allowances for font usage for readability – and perhaps support for multiple localized languages, too; and (4) guidelines for the use of legal descriptions, notices, and version releases to protect your product.

And, if your app is to be supported by multiple mobile operating systems and screen sizes, then specific considerations for each system option may need to be included within your style guide.

Style guides for mobile apps may be similar in concept to other corporate style guides used for company logos and other graphical presentations. However, mobile style guides may quickly become multiple page documents to cover the various elements found in mobile apps.

If your company employs remote-based programmers, or if your company hires third-party consultants / programmers to provide custom mobile application software, then a corporate mobile style guide should be mandatory and required if your company wants to have a consistent look and feel for all of your mobile apps regardless of the original point of coding.

Continuity, consistency and creative design can all merge hand-in-hand with a bit of pre-planning. Mobile style guides are a simple and efficient way to help your company manage your mobile development efforts.

Business Mobile Apps: Planning and Strategy – Five Key Matters to Consider

The mobility parade is gathering steam and rolling down Main Street USA. Where are you viewing this parade? From the street corner watching as it passes by, or are you an active participant sitting on the main float that everyone else admires? The reality may be a bit of both, depending on where you are in your mobility development cycles and in setting your business goals strategy.

Here are five matters to consider:

User Matters – Who will use your app and what will be the end-result of their usage? For example, do you have a user’s group that provides feedback for your products or service offerings? How do they communicate with your company? Got an app for that?

Competition Matters – What are your competitors doing in your market space and does their efforts give them any advantages? Are you being proactive or reactive to your market environment? Are you playing catch-up or leading your sector? Got an app for that?

Collaborator Matters – Unless you live and work in a vacuum, your company interacts with other companies in many ways: suppliers, partners, logistics, sales, channels, marketing, and much more. What can you do to make your collaboration efforts better and easier? Just because you always have done it one way does not mean it can’t be improved. Got an app for that??

Compliance Matters – In the supply-chain world of business, mandatory compliance issues are an everyday reality. Proper labels for this, correct documentation for that, serialized markings here, and security/anti-counterfeit features seem to be popping up everywhere. Sharing information freely, quickly, and rationally is not just good business, it is has become required, mandated and increasingly regulated. So, how are all those additional business processes and procedures working for you? Need help? Got an app for that?

Executive Matters – Rarely does any pipedream mobile project become reality without an executive sponsor. That’s because pet-projects and software development budgets are controlled by executives who set company priorities and objectives. Executive discussions for mobile apps often come back to financial issues of cost vs. perceived benefits received. But, is it always about dollars or should it also be common sense? Perhaps someone should develop a mobile business app to assist in making mobile business app decisions. Who’s got an app for that? No doubt it would sell well.

Return on investment is always crucial in mobile app development conversations. But, the problem is that tangible and intangible returns are not always easy to calculate or quantify – especially with regard to some of the matters above that may be thrust upon an executive team (especially matters are government or industry regulated as a cost of doing business). And, not every team member executive is qualified to discuss or understand all of the tangible or intangible matters.

As my friend John Schiff at Oracle is fond of saying, begin your mobile app planning and strategy with the end in mind. I believe John is exactly right. If your executive team determines that the end results are justified, then make a strategic corporate decision to live with it, regardless of the perceived ROI economics. Go make your mobile apps!

Enterprise Mobile Apps: Location and Accessibility

Pick your favorite mobile carrier and check their coverage map. While over time cellular coverage provided by Verizon, Sprint, ATT, and others, has improved, there are still significant gaps where cellular or WiFi coverage is spotty or non-existent. Why should this concern you or your IT department’s mobile Enterprise strategy?

The answer is simple: accessibility.

As discussed in previous entries, the audience and their location for your app’s usage may dictate how to prioritize software development. Perhaps more importantly though, is how accessible does your app need to be to function properly?

Generally, there are two common approaches for mobile business apps: real-time and store-and-forward.

Real-time

As the name implies, this type of mobile app is fully interactive and demands a “live” connection either directly to an Enterprise environment or to an Internet connection that, in-turn, links to an Enterprise environment. Apps that feature look-ups or inquiries require live accessibility all the time.

Store-and-forward

As the name suggests, store-and-forward mobile app are generally self-contained to capture unique information on-demand and/or to interact with a downloaded data file for “real-enough” validation. Perhaps the best illustration for this type of environment would be mobile route accounting sales apps that may have downloaded customer files or vehicle inventory files that allows the user to perform sales transaction tasks with a number of remote clients throughout the day. Then, at the end of the day, all captured information is uploaded into an Enterprise environment for final processing of all financial transactions and to update and/or relieve Enterprise inventory quantities on-hand.

Accessibility Matters

So, how and why does accessibility really matter to your mobile Enterprise application development strategy?

Suppose your IT department decides that your company’s mobile apps should all be created on only one common development platform. And, suppose your IT department determines that a cloud-based real-time development strategy offers the best development flexibility.

If your company discovers that a mobile app might conceivably be used in geographic areas lacking in robust cellular connectivity – which will interfere with the app being able to function properly in real-time, then your entire app development strategy may be flawed from the start. And, the last thing your IT department will want to do is support two different mobile development platform strategies.

Examine where your mobile audience works and lives, and then factor-in the role of accessibility in your Enterprise mobility development strategy. In this case, the old real estate axiom applies: location, location, location matters.

Two Ways To Prioritize Mobile Software Development Needs

Okay, your company has strategies in place for MDM and MAM. Now what? How do you prioritize your mobile software development projects?

The best way to start a prioritization process is to examine two critical issues: (1) audience impact and (2) economic impact to your business. Let’s examine each in turn:

The broader the intended audience, the more likely the application will be immediately successful. A good place to start is with your internal audience – your employees! For example, if your HR department has determined that every employee needs to have sexual harassment training, then the app becomes a mandatory requirement. Everyone within the company needs this training regardless of job description. Next, stop and ask these delivery questions: is the best choice for this specific app development to be geared for individual training or for classroom training; can it best viewed via a mobile device, desktop, or large monitor projection; should the style be interactive or lecture; and, finally, do you have remote users that can’t be easily reached or is everyone in your office location? The answers will help point you in the right direction for your company.

Economic impact implies that the use of an app may result in some type of financial gain. If, for example, you discover that purchase order requisitions are not being approved in a time manner because of executive travels and there is a back log of orders, then there is a definite issue that potentially impacts your bottom line. It may make sense to build a mobile app for traveling executives who can approve orders from anywhere. This app may be geared for on a chosen few within the company, but the financial impact may be very serious for the financial health of everyone at your company.

Before You Start Any Mobile Software Development Project, You Must Do This First

Before your IT department or independent software developer starts cranking out Enterprise Mobile software code, there are two foundation core steps that first must be addressed.

You’ve probably already seen their core name acronyms elsewhere: MDM (mobile device management) and MAM (mobile application management). Simply put, MDM will be your rules on which mobile devices will be managed, controlled, and supported. MAM will be your rules on how the applications loaded on supported mobile devices will be managed, controlled, and supported. Your company should  discuss and agree in detail on what these two core steps will be – prior to any code being created or mobile software distributed.

There are too many Internet articles providing in-depth details and advice for both MDM and MAM to repeat their recommendations here.  A recent deep-dive and comprehensive article I recommend is by Galen Gruman, downloadable from InfoWorld:

http://www.infoworld.com/d/mobile-technology/infoworlds-guide-successful-byod-and-mobile-it-strategy-179111

Your intellectual property, in the form of Enterprise app content, has to be protected. This content is just as valuable as any other intellectual property your company creates or owns; but, it is at greater risk and perhaps the most vulnerable property category your company will ever create. That is because, by definition, mobile “property” can’t be easily locked down, tracked, traced, or deleted without a significant degree of upfront planning.

The proliferation of BYOD, in an age of a very mobile workforce, means that control of Enterprise apps loaded on personal devices will immediately be at jeopardy when trusted employees become former employees.  BYOD means the devices and all of their loaded software departs the premise when the former employee does.

As Galen points out in his deep dive article, common sense guidelines and employee usage policies may offer practical solutions; but, if the nature and use of specific apps is company sensitive – for executive use only, for example, nothing may protect your company interests better than company-issued devices that must be returned by departing employees. Ownership always remains with your company in this regard.

Your MAM and MDM rules should address as many business usage scenario specifics as one can imagine. And, don’t write any code until you can provide a basic framework for where and how your mobile apps are to be deployed, managed, updated, or revoked!

Audience Matters – Five Steps To Consider

Planning an enterprise mobile software application can be daunting to the uninitiated. There are, however, a few planning tips that may help.

Suppose, for this example, that the proposed mobile application is to be related to mandatory sexual harassment training for all employees.

First, step back and clearly identify the intended audience. Do you need app versions to support more than one language? Do you need to support non-literate participation? Do you need to support special needs staffing? Establishing corporate goals based on the answers to these questions will help one to build a consistent, repeatable, computer-based system, with measurable analytics.

Second, with established corporate goals, one can start the program analysis to define the components that should be developed, managed, and, later, archived. If one of the design components is to utilize video clip examples of good behavior versus bad behavior, then scripting, filming, editing, and converting the video into a usable format is near the top of your to-do list. Over dubbing additional sound tracks may provide other language support and closed captions may address those audience concerns. The video presentations probably will need to be placed into a mobile software presentation framework that can easily provide a high quality user navigation experience.

Third, with measurement goals in mind, one can establish a series of questions and answers that the users must successfully complete to demonstrate their participation. Computer-based training is straight forward programming in concept; however, crafting meaningful questions should require the assistance of HR or legal professionals.

Fourth, management of participant records may be critical to remain in compliance with local, state, and federal guidelines for sexual harassment. Your HR or legal affairs staff can provide guidance as to what is required for your location. Sign-ins and unique identifiers are common software techniques to track who has successfully used the mobile app. Is one of the program design criteria to send a reminder to individuals who have not completed the required training? Does your company require periodic refresher courses with email reminders in the future? Will your app need an email interface? Will your app need a separate data base? How long will your organization keep the participation records? Five years? Seven years? Forever?

Fifth, having integrated analysis tools that can provide contextual information may be critical to the success of this example app. Executive dashboards are a highly recommended technique to provide instantaneous feedback on the use of mobile applications. At-a-glance screens with graphs and charts can provide real-time meaningful analysis. Of course, what should be included in the dashboard must be part of the initial design concept in step two.

 

All Enterprise Mobile Apps Are Not Equal

Like it or not, enterprise mobile apps should not be created equally.

Design and usage considerations aside, there may be many varying criteria for how enterprise mobility apps should be modeled, created, and perhaps licensed.

There are at least three emerging classes of enterprise mobility users: (1) industrial mobile users [industrial mobile devices within the four walls – with constantly working connections], (2) occasional mobile users [in-the-field or remote users on tablets or smart devices – dial-in or WiFi connections], and (3) casual mobile users [middle management or executive users on tablets or smart devices doing inquiries or approvals – dial-in or WiFi connections]. 

Major ERP vendors, like Oracle EBS and SAP, are in the development and roll-out process of extending the footprint of their ERP software to mobile devices. These ERP vendors contend that users of their software should be licensed regardless of how the information is accessed – from a desktop PC, a tablet, or a smart phone. Their licensing schemes to date for these new mobile ERP offerings seem to be gravitating towards a “transaction” specific license so that only the users with that specific mobile transaction need are licensed.

BYOD users have grown accustomed to downloading free or inexpensive apps with very cool interactive features. Imagine the sticker shock when downloaded ERP licensed apps cost hundreds or thousands of dollars for a single ERP transaction!

The jury is still out on how this per transaction licensing model will stand because this is an important economic consideration by IT departments as they try to manage, control, transfer, and contain the growing cost of Enterprise Mobility.

The Roots of Enterprise Mobility Run Deep

If you think enterprise mobility is a relative new phenomenon you might be surprised to discover that its roots run deeper than one might think. Many companies have been using industrial wireless mobility devices, with bar code ERP-connected software, to manage their business and supply-chain operations for over thirty years.

Industrial hardware vendors like Intermec, Motorola, and many similar companies have been providing wireless mobility hardware and software solutions since the mid-1980’s. Those early devices had proprietary text-based programming languages, like IRL (Intermec Reader Language) that allowed for the creation of very simple programs for basic supply-chain transactions. Bar code technology was in its infancy in acceptance as the standard for identifying products.

Those early enterprise mobility devices in the 1980’s and early 1990’s had limited functionality and capabilities for four reasons: (1) Chip technology has clunky, expensive, and power-hungry. Those early devices had variations of the 8080 chip design, which were the heart of early text-based PCs. Battery-life for the early portable wireless devices might go 4-6 hours. (2) Operating systems were primitive and also proprietary by each vendor and CPU. Those early vendors like Telxon, Symbol, and Intermec  hoped that their proprietary marketing schemes and hardware deigns would lock customers into using only their systems and programming tools. That strategy didn’t work out as well as they hoped. (3) Wireless and wired connectivity was problematic and expensive. There were VHF and even a few UHF wireless networks offerings in those early day before the recent advent of WiFi and robust cellular networks. And, (4) software data integration into Enterprise environments was cumbersome and ODBC standards were in early stages of development. 

Despite these shortcomings, wireless enterprise mobility devices became increasingly popular with corporations that faced the prospects of supply-chain mandates. There were two stand-out projects that helped shaped the early acceptance of mobile enterprise technology:

(1) The US Department of Defense LOGMARS (logistical marking) project in the 1980’s mandated that defense contractors add unique bar code identification labels to every product purchased. There were two notable results from this project: Unique ID label standards were formalized and mobile hardware was ruggedized to withstand repeated drops on concrete for field utilization. This project impacted literally thousands of contractors to use bar code technology. Soon, these contractors realized that the labels they were applying for the US Government could also be used for their own internal enterprise tracking use as well. 

(2) The automotive industry, in a major shift in manufacturing practices, moved to a “just-in-time” techniques for their parts suppliers. The hundreds of parts used in building a car would only arrive at the assembly factory just-in-time for their usage. The only way to provide enterprise visibility of the arrival and movement of these parts internally was through the use of enterprise automated data collection technology. Using a label standard still employed today, AIAG (Automotive Industry Action Group) labels provided an automotive industry standard that all automotive suppliers employ. And, the need for immediate visibility of arriving products led to significant improvements in real-time enterprise data  software integration. 

It is hard to imagine today, but until very recently “batch” computer operations were common place. Enterprise main-frame and mid-range software programs ran overnight to refresh tables and programs for management usage. Inquires and look-ups were hours or days-old information at best. Still, batch information was a vast improvement over manual paper methods were information was perhaps weeks and months old. Can you imagine what an Internet environment would be like if this were still a predominately batch computer world? Do a Google inquiry and then wait a day for the answer??

The primary evolution impetus of today’s enterprise mobility can be traced to the introduction of smart devices which were first brought to market about seven or eight short years ago. The first mobile enterprise apps were primarily focused on delivering email outside the enterprise’s four walls.  Palm and Blackberry devices were the popular rage in the early 2000’s and they helped forge a new demand and need for corporate enterprise apps. I have both devices gathering dust n a drawer with other forgotten, now out-dated technology.

Fast forward to today with the now three-year old introduction of tablets, smarter-devices (like Android, iPhone), and full-featured mobile operating systems (like Android, iOS, Windows CE) with native, embedded graphic and video technology and one can easily understand why there is such an interest in extending and expanding the footprint of real-time enterprise software. There are new classes of enterprise users that mobile apps can assist.

What was merely a dream 15-years ago with enterprise mobility technology is now common place. Where will we be in another 15 years? Stay tuned.