Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Perry Hoekstra

Posts by this author: RSS

Android Version Deprecation

The latest version of Adobe Cordova was released today (v. 3.5) and perusing through the release notes, I saw that they had dropped support for iOS 5, leaving only one major previous release (iOS 6) and the current release. In the past, Android developers have been plagued by the slow release of new versions of the Android SDK to existing Android phones. It has only been in the past year or so that a significant number of developers have moved off supporting 2.3.3 (Gingerbread) and below, making the lowest androidversion number supported being 4.0.3. The question for Android developers is: how aggressively can they move off of 4.0.3 to the next major release, 4.1?

Taking a quick check of the Android smartphones available through the various carriers, none of the phones are lower than 4.1 but a number are at 4.1 (example, the LG Enact and Motorola Droid RAZR M) so, unlike Apple, we as developers cannot move back to only 4.2 and eliminate phones that are still being sold by the major carriers. In all likelihood, the 4.0.3 phones are those who are waiting for their 2-year contract to come up, knowing that the phone will be not be updated by the carrier or OEM. Dropping 2.3.3 loses a developer about 16% of the market but gains in terms of lower bug count (quite a few issues are performance related, trying to use a modern mobile app on older hardware) and a wider selection of third-party tools (which have abandoned 2.3.3 and many are 4.1 and above).

The key issue is supporting 4.0.3 and its 13.4% share. The developer has to determine how resource-intensive the app is and what is the risk of users trying to run it on 4.0.3 (which are also resource-limited) and the subsequent crashes due to memory errors. It is difficult to justify to management a proposal that shuts out almost 30% (2.3.3’s 16.2% and 4.0.3’s 13.4%) of a customer base but the bigger question is: does it make business sense to support a project when the funds required exceeds the return of investment and the risk of poor acceptance in the marketplace when the app’s performance requirements exceeds the user’s hardware at the low end of the curve?

One other consideration I failed to mention is usage by the international market. If the mobile app is targeted outside of the United States/Canada, many lower-end Android phones (white-box, introductory) sold in India, China and Africa are still using 2.3.3/Gingerbread. In the case of tablets, even the low-end 8 GB/under a $100.00 models are supporting Android 4.1 and above (source: Walmart.com).

Minimal Viable Product

In a conversation the other day, the focus was around the integration of the Agile methodology with Lean Startup and the cycle of build > measure > learn and how concepts from Lean Startup can complement an Agile software development process. One of the intriguing ideas that carry over into enterprise mobile development is a Minimal Viable Product or MVP. Quite a bit has been written this year about moving to a “mobile first” Minimal Viable Productenterprise, especially as the threshold of “7.1 Billion people and 7.1 Billion mobile phone subscriptions worldwide” has been reached. Corporate IT needs to adapt to this new way of working or run the risk of employees and managers bypassing the IT organization and creating a large shadow IT environment. There have been numerous examples in the past, the one that comes to mind is the Microsoft Access-based systems that cropped up in enterprise departments in the 1990s when IT could not meet the needs of business and so departments created their own IT systems and thus, silos of data with no interoperability. Corporate IT needs to get ahead of this new wave and demonstrate to the business that they are the right organization implement and manage it. It is imperative for IT to embrace mobile by examining how to enable mobile applications and understand the challenges of a “mobile first” environment. The question becomes, how does IT do that?

So, back to the original topic which was the Minimal Viable Product or MVP. IT needs to work with business to identify problems that are occurring within the organization and look to solve it through mobile. In the case of software development, a minimal viable product (MVP) is a software product that meets the minimum requirements of the end user so that these users can test the product and offer immediate feedback to the mobile development team to iterate on. The feedback is reviewed and incorporated into the next build of the product. Releasing the MVP frequently demonstrates to the end users that a) they have a voice into the mobile app’s design and b) the IT organization is attempting to meet the mobile needs of the business. Creating a number of MVPs targeted at various segments of the business user community with an organization allows IT to understand what these groups are looking for, what is useful and how the IT infrastructure needs to adapt to support mobile. Those MVPs that “scratch the itch” of the user community can be further developed into a valuable enterprise mobile application and discard the ones that do not add value.

One word of warning however, as Abraham Wallin pointed out in his article: Lost in Translation: The Minimal Viable Product, the word “Viable” seems to be pushed into the shadows of “Minimal”. A minimal viable product cannot be poorly designed, all of the learning and feedback from the end users is lost and it will be difficult to get the end users engaged for any subsequent releases or other mobile products created by IT. Creating an MVP requires an entire team of UX, interface design and development so that, even though the product may only have a subset of functionality, it meets base quality and usability standards.

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.