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


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

The answer is of course “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-tiered website design model, which is driven by user-initiated content requests, doesn’t always fit the mobile world. The sheer volume of mobile users and the growing ubiquity of mobile devices can result in an exponentially higher number of requests that can stretch network and server resources to the limit.

The mobile push model, on the other hand, automatically sends content to devices, eliminating the reliance on web application servers to pull content updates. Instead of users constantly pulling or querying information about the odd chance that it has changed, updates are sent proactively using lightweight, built-in messaging services that can be scaled to meet the rapidly growing mobile demand.

Image: IBM

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

To be clear, we are not making the claim that web servers are unnecessary in mobile back end services. In fact, we believe hybrid mobile apps that use HTML5 and JavaScript are great ways to deliver 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, especially when your choice can lead to advances in efficiency.

Image: IBM

The push design pattern can be illustrated with a simple scenario example 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 analysis can be used to determine which model, push or pull, should be used in particular business applications.

Scenario: Eliminate the Need for the Check Balance Button

Several large banks have told us that their “mobile apps are crushing computers” and that relatively low value transactions for the bank are frequently, almost fancy, done morning, noon and night. One bank went so far as to say that a feature of its new mobile banking app that allows users to check their checking account balance is overused and fits the profile of fancy, lower value transaction.

To meet the high demand for account balance surveys, 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 reviewing the situation, analysts at IBM suggested that the bank remove the Check Balance button from its mobile app instead. At first, the bank’s CIO looked at us like we were crazy. But we explained that instead 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 around 25 times more efficient than a request-based design.

Image: IBM

This 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 transmitted to the account holder’s mobile device using a push notification from the source transaction system. .

To illustrate the push design model, Greg Truty, one of IBM’s leading mobile architects, designed a prototype iOS Bank Account Pass (see Figure 1) that resides in the iOS Passbook app, which is a tool popular used to host items such as airline tickets and loyalty cards. As shown in the figure, the pass becomes a live view of the user’s bank account. It can even replace the mobile banking app itself. This is because in addition to the checking account balance, Greg has included details of the last posted transaction and added a QR code that can turn 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 template to add push notifications to its existing app so that users always have their latest balance and no longer need to press the Check Balance button. However 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 model and examine how its usage can be improved using usage data and analytics.

Jerry Cuomo is IBM Fellow, VP WebSphere Strategy and Chief Technology Officer for WebSphere. He provides technical direction and strategy for the WebSphere portfolio and leads technical 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 value and has a focus on multiple areas including cloud, mobile, virtualization, workload optimization and advanced analysis..

Robert vila is a senior technical staff member and program director at IBM. He heads the WebSphere Strategy and Emerging Technology Institute. He is an IBM master inventor and has been with the company for 12 years.

A version of this article has already been posted on IBM Red Books.

Go back to the top. Go to: Beginning of the article.


Source link

Previous Real World Design Patterns: Strategy
Next Design patterns: strategy and factory patterns

No Comment

Leave a reply

Your email address will not be published. Required fields are marked *