Browse Article

Commercial Application Development in the Age of Mobile

April 6, 2016 | Author: | Posted in Mobile Computing

Google, the powerful arbiter of commerce in today’s virtual world, is now firmly standing on the side of mobile, because customers using Google have proven that they are now spending more time searching on their mobile devices than they do on their desktop computers. Anyone doing commercial application development needs to have the same focus. Even in the B2B world, commercial application development is synonymous with mobile app development. None of us can afford to ignore the universal and dominant use of mobile devices. You need mobile as part of your strategy.

There are shortcuts; plenty of tools are available to make a web application “responsive,” where it can automatically reformat its display to run successfully on a variety of devices. But that doesn’t mean it is optimized for the mobile experience.

People use their mobile devices differently than they do their desktop computers. They are in an “immediate” frame of mind. They want to find something out, fast, so they can take action. They want to be able to “do” something quickly, without wading through the complexity of web navigation. While they might spend time browsing through various sites and subjects on a desktop, they are much more intentional when using their mobile devices. And, because a mobile device can sometimes be disconnected from the Internet, any mobile app has to work even when there is no Internet connection (such as an email app that can be used to compose a message, and the message is sent when the device is reconnected to the network).

The characteristics of a successful commercial application development effort

When analyzing various mobile sites and applications, it’s often obvious which ones will be most popular with users. The content is sparse, and to the point. The choices are obvious, including (and especially) any action buttons. Standard mobile conventions are used – swiping and tapping. Colors and object size are used to make it clear what can be done with a button or object. Only a few options are presented on every screen. Processes are broken into logical modules that present a frictionless flow of related actions to the user.

The interface is consistent throughout the app; every screen has a set of minimal but unmistakable identifiers that confirm that the user is still in that same app and is taking the next logical action. It’s obvious how to get “back” to the home or starting point of a process.

It is, however, possible to be too sparse. If the user has to swipe through three screens to do what could be done on one, you’ve gone too far. There’s a delicate balance between presenting a minimum of choices or actions and breaking a process into too many separate screens.

Today’s mobile apps often include a sharing component, which helps to spread the word about the app, or about what your user is doing with it. There’s nothing wrong with that, as long as the sharing part of the app doesn’t get in the way of the user’s experience with the app itself. Sometimes, especially lately, we can become more concerned with sharing than doing. Don’t fall into that trap.

Competition in the mobile app arena is fierce. The apps that gain momentum are those that can be used successfully at first touch, and that continue to meet the user’s requirements without introducing inconvenience. This is easier said than done.

If you do manage to get people using your app, sometimes it can be the seed of its own undoing. Many designers and developers fail to look ahead to how the app will behave once people have used it for a while. Many apps involved the accumulation of some sort of data – notes, appointments, photos, foods you’ve eaten, carb counts, purchases, places you’ve visited, sales calls you’ve made, orders you’ve taken, and on and on. Your best outcome is that users like your app so much that they end up with too much data to handle. If you don’t anticipate that, and design for it, you may find that over time the user may decide it’s just too cumbersome to scroll through pages and pages of data, will stop using the application, will find alternatives, and will tell others about your application’s flaw.

Testing of the application should consequently include anticipating the behavior of the app after it has been in use for a while. This idea should be part of the usability testing process.

Article Source

Frank Zinghini

Author:

Frank Zinghini is founder and CEO of Applied Visions, Inc. From its base in Northport, on New York’s Long Island, AVI creates Custom Software Applications for the cloud, mobile, desktops, and the Internet of Things (IoT). The company has earned a reputation for applications that are visually exceptional and exceptionally usable. Zinghini founded Applied Visions to deliver the power of visual applications built by a highly skilled team of developers, researchers, and designers. The company specializes in building applicationsx that meet revenue and usability goals as much as they meet technical requirements. Since its founding in 1987, Applied Visions has spun off two other businesses: Secure Decisions, which brings innovative visualization to national security applications; and Code Dx, which sells a software vulnerability management product that helps developers create secure applications. Frank holds an MS in Computer Science from Stony Brook University. He serves on numerous boards, works with local high schools and colleges to promote STEM (science, technology, engineering, and mathematics) education, and is an active member of Long Island technical and management groups.

This author has published 1 articles so far.