retro tools

The web browser may still play a key role in everyday customer transactions, as long as much of the process of monitoring and managing those transactions continues to take browsers — specifically, the various brands of browsers — into account.

Last week, in my regular Friday op-ed, I made the case for moving online transactions off of the web browser model, and more toward the apps-based model. It wouldn’t leave the web itself behind, but it would ditch the component that everyday users associate most with the web: the browser.

This week, I’m attending the Dynatrace Perform 2015 conference in Orlando, where yesterday morning I sat in on an IT administrators’ training session. The session was devoted to using Dynatrace, a web application performance monitoring tool, for the express purpose of improving digital experience (DX).

There, I heard some questions and discussion points from everyday IT professionals that made me wish I had waited a week to make my case.

A Clearer Signal

First, let me fill you in about what all this is about:

The content management systems and e-commerce servers of the world actually pay far less attention to the signals produced from customer interactions than you might believe.

Dynatrace produces applications performance monitors. The simplest of these are JavaScript components that are inserted into client-side web pages.

These components are designed to listen for many of the same events that trigger the execution of JavaScript code on the client side, and report these triggered events back to a server. There, Dynatrace listens for these events (or for the absence of those events), and can be programmed to issue alerts to people in IT when certain conditions warrant.

Let’s say customers of your e-commerce site get to the checkout page, where they review their orders and either cancel or proceed, both of which would trigger an event that closes the page. If a few hundred of these folks haven’t done anything that would close the page, something may be wrong.

Monitoring for events or discrepancies at this level is absolutely critical to the maintenance of a modern online service. The capability of monitoring at this level is brought to you, almost exclusively, by Web browsers.

While mobile apps, as I have argued, provide for more satisfactory DX from users’ perspectives, native mobile apps (written in Objective C or Swift code for iOS, something-close-to-Java for Android or.NET/WinRT for Windows 10) lack the mechanism for generating a set of events as rich as those that Web browsers already produce today.

There are ongoing efforts to alleviate this problem, the biggest one of which being mentioned here is Splunk, a performance monitor that works to bridge iOS, Android and HTML5.

But the “ongoing” nature of these efforts seems quite evident, at least from what I’ve heard thus far. Right now, the browser-based web application appears to be perceived as the use case that reaches the broadest base of users, even though fewer mobile device users today explicitly launch their mobile browsers.

Breakdown of a Buildup, or Buildup of a Breakdown

What struck me square in the face yesterday (luckily my face is already pretty square) is the realization that kiosks represent sizable enough pluralities of a customer-facing company’s user base to warrant an all-Web approach to performance monitoring.

The implications of this are huge, so let me spell it out step-by-step.

  1. We frequently advise readers to carefully consider an omni-channel strategy for reaching customers on the many devices they’ll use to make contact with merchants.
  2. Such a strategy takes multiple device classes into account, and kiosks are one such class. There is no “native code” for a mall kiosk; when your brand addresses an online customer in-store or in the mall, the facility for that communication (however hidden) is a Web browser.
  3. The proliferation of mobile apps has already forced software development shops to split into “native” and “Web” teams, often reluctantly.
  4. However, it may not be possible for companies to divide and subdivide their IT departments along similar lines. The people using performance monitors — the core users of Dynatrace — are IT professionals who may have DevOps skills, but who typically are not the creators of online apps.
  5. The core selling point of Dynatrace is its all-in-one approach to performance reporting. You may think it’s an omni-channel strategy that you and the CMO are working with, but what the CIO prefers to see is an all-encompassing report of total online activity.
  6. Because IT retains a critical seat at the table where purchasing and strategic decisions are being made, companies will continue to execute their omni-channel strategies (as counter-intuitive as this might seem) using the single conduit that enables the greatest level of consistent monitoring of all channels.
  7. This means the Web will remain a force, which native mobile development cannot supplant. Just as there are few, if any, separate “kiosk development teams” within organizations, there will likely be no “kiosk performance monitoring teams.”
  8. As IT personnel and DevOps professionals made clear during Tuesday’s training sessions, the companies that determine which events are triggered by Web page interpreters and how they’re triggered, are browser makers.
  9. As I’ve mentioned before, apps that look native to mobile users can still be rendered by Web browsers, using HTML5 and JavaScript. There are mobile apps today that can easily report events back to performance monitors such as Dynatrace.
  10. However, browser makers (especially Mozilla) have an interest in maintaining some measure of visibility in their users’ lives, in order for users to choose to install them in the first place. Subjugating browsers to becoming mere renderers of native-looking mobile apps, works against manufacturers’ interests.
  11. Thus IT personnel who monitor performance must take into account certain events that exclusively pertain to browsers — for instance, clicking on the Back button, creating a bookmark, moving backwards or forwards in history, changing the window size or aspect or zoom level.

When we talk about implementing an omnichannel customer strategy throughout our organizations, these are the factors we must consider — some of which technology forces us to consider, whether or not they’re what we would prefer.

The web is a fact of our existence, and that’s a good thing. HTML5 and JavaScript can be a bit convoluted, although JS extensions enable them to be more powerful together than any online exchange system conceived heretofore.

But until some other incentive for service differentiation manifests itself, the mechanisms that make performance monitoring possible will be dependent upon the necessities of browsers ... even though fewer and fewer people are using browsers as browsers.

For More Information

Title image by Dustin Lee.