Subscribe via Email

Subscribe to RSS feed


Perry Hoekstra

Posts by this author: RSS

The ‘Businessification’ of Tablets

Apple has always been known as a consumer-oriented organization. It’s last business or enterprise-focused product; the Apple xServe rack servers were discontinued at the beginning of 2011. However, a funny thing happened on their way to consumer electronic dominance, they became relevant to business. The evidence is never clearer than the dominance of the iPad as a lightweight business tool. The iPad and tablets in general fit into the executive and manager work styles. How often have you been in meetings where participants are bringing out iPads (or Samsung Galaxy Tab 10.1) to fire up a spreadsheet or a business intelligence dashboard in order to emphasize a point?Galaxy-Note-10.1

Just as smartphone “phablets” have become popular with consumers to view more web data squeezed onto the screen (does anyone use a smartphone to make calls anymore?), vendors are looking to target business users with larger tablet sizes. Both Samsung and Apple are rumored to be releasing 12-inch tablets with Samsung debuting the Galaxy Note 12 (with their S Pen stylus) in early 2014 and Apple with a 12-inch iPad Air. With notebook sales dropping from 13.8 million in 2012 to a reported 13 million this year (2013), tablets have become the mobile go-to device for business executives and managers and slightly larger tablets with a soft keyboard cover will cause even more notebook users to make the switch. Along with the rise of tablets in business, spending on mobile application development was projected to grow by 50% in 2013, to nearly 2% of total IT expenditure. This spending is strictly software development, i.e. developing new mobile applications and making existing enterprise applications mobile-friendly and does not take into account the purchase of mobile hardware (tablets and smartphones).

Mobile Security Reference Architecture

Just recently, the Federal Government handed out a gift (how often can you say that?) to the mobile community.  As part of the new open digital government initiative, the Federal CIO Council and Department of Homeland Security have published the Mobile Security Reference Architecture.  It is a comprehensive picture of the minimal security controls necessary for a particular government department to begin undertaking the support of mobile devices by the agency staff. From a business perspective, it is also important due to the fact that here are comprehensive, best-practice documents vetted by various federal agencies including the Department of Defense.  Imagine, you are a technical architect with some mobile experience and your department head stops by and states that the firm wants to support the sales staff with mobile applications and you are assigned the task of coming up with an enterprise-wide mobile security strategy.  Instead of panicking (queue the picture of Edvard Munch’s painting “The Scream”) and wondering where to start, this document along with the companion documents; Federal Mobile Security Baseline and the Mobile Security Decision Framework provide the building blocks of a solid mobile security architecture that your IT group can utilize to deploy through the enterprise.

Are Tablets Truly Mobile Devices?

No, I am not trying to make a Thorsten Heins-like splash (the BlackBerry CEO who recently stated that “In five years I don’t think there’ll be a reason to have a tablet anymore.”).

If you pose the above question in one of those Jay Lenoesque “Jaywalking – Man on the Street” episodes, the response would undoubtedly be “of course”. Since their debut, both con­sumers and busi­nesses have gen­er­ally con­sid­ered tablets to be a form of mobile devices.  The interfaces for both the iPad and its Android brethren cer­tainly look and feel more like their smaller smartphone siblings than a Windows 7/8 desk­top.  But does that really make sense considering how tablets actu­ally used?

While growing nearly 50% in Q1 of 2013, cellular-enabled tablets still only account for 12% of the tablets sold. So, what’s my point? Tablets are not primarily mobile devices and should not be treated as such.  When creating a mobile app, quite often, tablets are looked at as an oversized smartphone.  Instead, they are truly their own platform and designers/developers must create a differentiated tablet experience or risk dissatisfying the very consumers (either customers or internal business people) they are targeting and thus, missing an opportunity.  As an example, for a given business app, the smartphone version can be seen a summary/quick perusal of a certain set of business information while the tablet should be used to discover and the plumb the depths of whatever the business person is investigating through the tablet.

You Need Mobile Development as a Skill Set

If you have been sitting on the sidelines, looking at the mobile space and wondering if it is worth your time to learn mobile development, think again. According to a recent Gartner report, Android mobile device sales outstripped PC shipments in the third quarter of 2012. Obviously, if you throw in the iPhone/iPad ecosphere, Windows Phone 8 and even the dying RIM devices (queue Monty Python line: “DEAD PERSON:  I’m getting better!”), mobile devices now dwarf PCs in sales and the gap will only get wider. What does this mean? Back in the day, we as software developers were on the forefront on the web application wave.  Businesses were moving from standalone, PC-based applications to web applications hosted in a browser in order to support their diverse and far-flung work force. Depending on which way you fell on the technological divide (Java or Microsoft), you quickly learned how to use JavaServer Pages or ASP.NET to create web-based applications.  images

I think again that front-facing, UI developers are now again at that same crossroads. If you make your living writing business-based, web-based applications, it is now time to understand and acquire development skills in the mobile space, whatever flavor you choose (Objective-C, Java, HTML5/CSS3/JavaScript, or C#). Businesses rarely ride the cresting wave of any technological shift but they have woken up and are looking to their development teams to create externally-facing, customer-focused apps or internally-facing, business-process apps.  You want to be one of those “go-to” people or get relegated to the mundane task of updating all of the copyrights on the web-based applications from 2012 to 2013.  BTW, backend developers are not left out, you need to be able to do more that understand what AWS or Azure means but that is a blog post for another day.

Linking to Mobile Consumers Through APIs

The recent purchase of Mashery by Intel and Layer 7 by Computer Associates highlights the importance that APIs (Application Programming Interface) have become in exposing internal corporate services to mobile developers, both corporate and outside. Corporations are beginning to understand that one of the keys to users interacting with their services is through mobile and mobile applications.  A robust, well-crafted and well-documented API is the gateway for a network of developers to begin building mobile apps that engage consumers.  Corporate mobile developers are a scarce commodity and are normally tasked with critical, internal mobile projects. By building out an API, it allows the creativity of outside mobile developers to build unique and engaging mobile applications that draw new customers to a firm’s products and services.  There is the concern by a firm that there could be a loss of control over the firm’s brand by allow third-party development against their services.  The first step in mitigating this concern is the creation of a Terms of Service agreement that all developers who wish to use the firm’s services must abide by in order to receive an authorization key to gain access.

Using software such as Mashery, Layer 7, and Apigee will not automatically create compelling API’s, the onus is still on the developers to craft those APIs but it is a key piece in a firm’s business to consumer (B-to-C) strategy.  This new breed of API management software (also called a Service Delivery Platform) eases the creation and management of developer portals, key and authorization management, metering of service requests and the linkage between the externally-facing service (usually REST-based) and a firm’s internal SOA platform that may contain a significant amount of SOAP-based services.

New Class of Prototyping Tools

If you believe you are a good software designer, the great news about creating mobile applications is that with mobile apps: design is everything. Time and time again, it has been show that users value good design and its impact on usability. As with everything else in life, we’re all individuals, with different preferences and ways of approaching design.  There are a number of mobile developer/designers who don’t believe that “paper is dead”, instead, take the position that they come up with more fluid layouts when not in front of a computer.  Other designers prefer to work in Photoshop, creating designs that seem ready for the App Store.  For me, one is too hot, and the other, too cold.  In the case of Photoshop or Axure, I would find too much attachment to the work I put in to the screen mockups to readily change them based on user input.

In my case, I find rapid prototyping beneficial to meet the following limited goals:

  • Investigate the key points of the proposed solutionbalsamiq
  • Test the navigation and overall content structure

This is the point of this blog post, to call attention to a new set of rapid prototyping tools for the creation of mobile applications.  Using my favorite screen prototyping tool, Balsamiq, I was able to export my mobile screen mockups to *.png files.

Using the tool InVision, I uploaded the *.png files into the Build Mode. From there I was able to identify clickable zones in my screen layouts and link them to the other screens that I uploaded. From there, I can export a link to the screens to a smartphone and bring up that link in the smartphone browser and navigate through my screens testing the application navigation.  Other features include the ability for other users of the functional mockup to make comments to specific points of the screens.  The tool supports both the Android and iOS environments.

Once you use the tool, the benefits become immediately apparent when users can touch and navigate through a facsimile of the proposed app.  If your tool of choice is something like Photoshop, you users could touch and play with what would seem to be the real app. Either way, having an app that could function on a phone is considerably better than looking at screenshots on a computer or looking at wireframe documentation.

Will It Play in Peoria?

If you read any blog post or article on cross-platform mobile development, one of the top arguments for going the cross-platform route is that it offers developers with HTML, CSS, and JavaScript skills the ability “to build innovative, device-neutral mobile apps that work on the iPhone, Android,” etc.  However, a funny thing happened over the past couple of years in that the Android UI has come out from shadows from the peoria then-leading iOS interface design to establish its own set of platform guidelines and has even begun to establish its own set of idioms that is being adopted by iOS applications (ie. sidebar menu).


Starting out a mobile project that looks to target both iOS and Android, one of the key questions that need to be answered is whether to pursue native or hybrid/cross-platform as it drives what skillsets you will look for in your development team.  One input into that decision is: should the mobile app adhere to each of platform’s user interface guidelines or should the app be consistent in look and functionality between the two platforms?


The argument for consistency in look and functionality is two-fold; lower cost of development and lower cost of app support.  However, how often do users actually access the same app but on different platforms? Not often, but I admit that I am an aberration in that I use Evernote both on an Android phone and iPad.  It has been shown that in the case of mobile apps, users are brutal in terms of quickly dropping apps that are difficult to master because they don’t follow platform style guides and idioms. It is helpful if the application on different platforms function somewhat similar, but if you are focused on providing a great user experience, do you want to end up with the lowest common denominator on each of the platforms? Quite often, if you take a successful iPhone app that has been developed and then try to make a version for Android, you will find that you need to completely rethink the user experience design in order to provide an Android app that would find acceptance in the market place. While the core functionality would be the same, the whole feel of the app will end up being different.


So, to appeal to users on a particular platform (Android or iOS) with a user experience design based on that platform’s interaction guidelines, only the core functionality can be considered “cross-platform”.  So, you may come to find that there is very little savings in terms of time to market when your developers are having to craft individual platform UIs in HTML, CSS, and JavaScript, with very little cross-platform code sharing.  That is not to say that you still can’t go down the cross-platform route but if one of the key decision points is time to market across multiple platforms, the savings may not be as significant as you think. To increase that savings by implementing a consistent look and functionality may put at risk user acceptance and to the question of “Will It Play in Peoria?”, the answer for your new mobile app would be no.

If You Build It, They Will Come

As an IT leader, you have read the articles and have gone to the conferences where presenter after presenter has stood up and discussed how important it is for enterprises to develop a mobile strategy in order to ensure a competitive advantage and enable a more productive workforce.  Getting back from these presentations, you have worked to create a mobile strategy that identifies the outcomes you need to deliver both to your employees and customers, opportunities to use mobile technologies to support those outcomes and the best ways to achieve success.

At some point in time, you will need to decide what type of mobile app to create that is both useful and valuable in order to jumpstart your mobile initiative. As part of your mobile strategy, you have identified key areas where mobility could be most impactful. If you are unsure, there was recently a survey published by IDC/IFS  that polled 450 CIO/CTO/CEO executives and the dominant mobile app desired was CRM.

The study shows that the top-three business apps companies would like on their smartphones are:

  1. Customer relationship management (CRM)—31 percent of companies indicate CRM (e.g. management of sales, contracts, activities, and opportunities) is the mobile business app that would most significantly impact their business.
  2. Business Intelligence (BI)—13 percent of the respondents favored BI capabilities, for example KPIs and reporting.
  3. Approvals and Authorizations—10 percent chose functionality such as approval of requisitions, purchase orders, and supplier invoices as the most wanted business app.

CRM is an ideal as an initial mobile app for an enterprise due to following factors:

  • immediate boost to sales productivity which impacts the bottom line and gets the attention of key leaders in the organization of how mobile can impact their organizations.
  • is aggressive enough in terms of functionality and visibility that it requires key skilled people such as UX Architects and Visual Designers which sets the bar for follow-on mobile applications.
  • ties into corporate data which means that key conversations around API’s, existing services, and service security are held with key stakeholders rather than ignored.

One danger of using CRM is that that the CRM space is complex and the most successful mobile apps are those that accomplish one or two tasks incredibly well.  As designers and developers, we have a tendency to place a considerable amount of functionality into whatever application we are creating.  As with most mobile apps, it would be better to identify a single key task, release the app and let the app evolve as the sales team works with the CRM app and provides feedback.

It’s Going To Take How Long – Part Deux

This is a follow-up to my blog post “It’s Going To Take How Long?” and the problem of managing client expectations around building out a mobile app.  In the first post, the client cannot understand why it is going to take X amount of money and X amount of time to build the given mobile application. Maybe the problem is both the client and you as the project manager are rooted in the past where you always looked at timelines and cost for a soup-to-nuts project where at the end, the 1.0 application is released to production with all of the defined functionality and you begin to think about release 1.1 for the following year.

If nothing else, mobile apps have changed the way we look at releasing software to production.  Consumers expect bi-monthly updates to the software to fix bugs and add new functionality.  Instead of saying it is going to take X amount of money and X amount of time to build all of the functionality the client desires in a mobile app, the approach should be to build enough functionality to meet the base needs of the consumer with a series of bi-monthly releases adding additional functionality until the mobile app fully meets the goals of the client.  This evolutionary approach to software release allows a lower barrier of entry in terms of startup costs, a shorter time to market and allows for software corrections based on consumer feedback.  The costs and time to market savings will not be significant, there is quite a bit of work to get to that base 1.0 release but an evolutionary software development approach can ease the concerns that a large chunk of money may be spent and the mobile app does not meet the needs of the client’s target market.

Implement BYOD – That’s The Way to Innovate

In my spare time, I am an adjunct faculty member for an online university and teach a class each semester.  This week the topic was IT innovation and one of my learners was using as their example, the phenomenon of mobile and ‘Bring Your Own Device’. The learner supported their argument that BYOD was a key IT innovation with a blog post on CIO Insight that stated that BYOD culture inspires employee innovation. My response was that while BYOD may be a key ingredient, but by itself, BYOD will not accelerate innovation. Mobile devices, whether they are personally owned devices used in the workplace or corporate-provided, are not inherently ‘innovative’.  They are business tools, similar to any other business device sitting on your desktop.

Innovation, in this case, is driven by how the mobile device is used.  I am not talking about being able to read and respond to your business email while watching your son at a swim meet (though, what else do you do when your son swims the 500 Free?).  Innovation is the hard work by both business and IT, sitting down and figuring out how to take advantage of the significant technological advances offered by mobile.  Quite often, firms don’t even need to sit down and come up with ideas.  Employees are coming to their managers and IT coworkers with impressive ways on how access to real-time enterprise data can make a significant impact in their lines of business.  Our industry loves statistics and one I thought significant was published by Webalo that stated that “98% of corporate users said productivity would improve if they had mobile enterprise access”. Obviously, there is no concrete ROI behind such a statement but if you think about it, you can come up with a number of positives in terms of sales, client satisfaction, and business decision-making that would come from efficiencies in extending enterprise data to mobile.

As I pointed out to the learner, the only thing our industry loves more than statistics is silver bullets and in this case, the idea that a BYOD initiative will inherently spur innovation within a firm.  Rather, the ability to have access to enterprise data whenever and wherever is the key to innovation.