Mobile Design Patterns: Push, Don’t Pull (Part 1)

Image: withassociates/Flickr

Designers of enterprise mobile apps have the opportunity and responsibility to think differently about application design, particularly when compared to their traditional web application counterparts. Few examples illustrate this better than the debate over push versus pull. Should we wait for users to request, or “pull,” the content they need, or should we “push” content updates when we think that users need them?

The answer naturally is “it depends.” Different situations call for different solutions. But, current trends make us think that the push model has distinct advantages in the mobile space.

The familiar three-tier web design pattern, which is driven by user-initiated requests for content, does not always fit the mobile world. The sheer volume of mobile users and increasing ubiquity of mobile devices can lead to exponentially higher numbers of requests that can strain network and server resources to the limit.

Image: IBM

The mobile push pattern, in contrast, sends content to devices automatically, eliminating the dependency on web app servers for pulling content updates. Instead of users continuously pulling or querying information on the odd chance that it has changed, updates are sent proactively using lightweight,integrated messaging services that can be scaled to meet rapidly increasing mobile demand.

Image: IBM

In short, in the proper situations, a push-based design can be an order of magnitude more efficient than a conventional pull design, while delivering a transformative experience for mobile users.

To be clear, we do not argue that web servers are unnecessary in mobile back-end services. In fact, we think that hybrid mobile apps that use HTML5 and JavaScript are excellent ways to provide services that run on a variety of devices.

However, it is important to think about the right architecture to take advantage of the capabilities of mobile devices, particularly when your choice can lead to breakthroughs in efficiency.

Image: IBM

The push design pattern can be illustrated though a simple example scenario that, if extended to its logical conclusion, could make the Check Balance button in a mobile banking app a thing of the past. This article describes such a design and attempts to quantify its benefits. It also explores how data and usage analytics can be used to determine which model, push or pull, should be used in particular enterprise applications.

Scenario: Eliminating the Need for the Check Balance Button

Several large banks have told us that their “mobile apps are crushing IT” and that transactions with relatively low value to the bank are being frequently, almost whimsically, performed morning, noon and night. One bank went so far as to say that a feature in its new mobile banking app that allows users to check their current account balance is overused and fits the whimsical, lower-value transaction profile.

To keep up with the high demand for account balance inquiries, the bank decided it needed to significantly increase the server and software capacity of its back-end systems. This would have included more application servers,data caching servers, security servers, and MIPS for its mainframe systems.

After examining the situation, IBM analysts suggested that the bank instead remove the Check Balance button from its mobile app. At first, the bank CIO looked at us as though we were crazy. But we explained that in place of the current query-based interaction design, we could try a mobile-oriented, push-based design instead. We estimated that a push-based design would be approximately 25 times more efficient than the query-based one.

Image: IBMThis push design is simple yet powerful. The basic principle is that whenever a transaction occurs in a specific account, the new account balance is then pushed to the account holder’s mobile device using a push notification from the source transaction system.

To illustrate the push design pattern, Greg Truty, one of IBM’s leading mobile architects, designed a prototype of an iOS Bank Account Pass (see Figure 1) that resides in the iOS Passbook app, which is a popular tool used for hosting objects such as airline tickets and retail loyalty cards. As shown in the figure, the pass becomes a live view of the user’s bank account. It can even act as a handy substitute for the mobile banking app itself. This is because, along with the current account balance, Greg included details about the last posted transaction and added a QR code that can transform the pass into a debit card.

Of course, an iOS Bank Account Pass is just one example of how the bank can use push notifications to communicate balances and other information to customers. It can use the same pattern to add push notifications to its existing app so that users always have their latest balance and no longer need to keep pressing the Check Balance button. Regardless of how it is implemented, a push architecture can improve both IT efficiency and the customer experience.

Now that we’ve looked at the example, the next blog will attempt to quantify the benefits of the push design pattern and examine how its use can be enhanced by using data and usage analytics.

Jerry Cuomo is an IBM Fellow, VP WebSphere Strategy, and Chief Technology Officer for WebSphere. He provides technical direction and strategy for the WebSphere portfolio and leads the technical executive leaders and development teams to cultivate the future of WebSphere. He is engaged in a number of advanced technology studies for the next generation of innovation and valueand is focused on several areas including cloud, mobile, virtualization, and workload optimization and advanced analytics.

Robert Vila is a Senior Technical Staff Member and Program Director at IBM. He leads the WebSphere Strategy and Emerging Technology Institute. He is an IBM Master Inventor and has been with the company for 12 years.