1300 593 418 [email protected]

Death To The Refresh Button

By Doug Bannister
March 1, 2017

WHY DO WE TOLERATE THIS ANCIENT RELIC?
We live in an era of instant gratification. Apps summon everything from rides, to food, to dates at the click of a button. Our inboxes push notifications at us in real time and there is a constant stream of data in the palms of our hands. Consequently, we’re accustomed to having exactly what we need exactly when we need it.

But do we really get what we need when we need it? Is what we get current? Is the information accurate right now? We all suspect it’s not. So when monitoring data that could change at any time, we press the refresh button to get an update. And a few seconds later we press the refresh button again. Has that plane landed yet? <Refresh> Did my team tie the game? <Refresh> Are those results in yet? <Refresh> Has that traffic accident been cleared? <Refresh>

It shouldn’t really surprise us that technology exists to eliminate this. After all, there are self-driving cars and trucks on the roads. Then what’s the deal with the websites out there? Why is it that the refresh button still persists and occupies a prominent place on our web browsers and in our lives?

The answer lies, unsurprisingly, in the history of the development of the Internet and the way systems, until recently, had to be designed in order to function. The good news is that technology moves forward and we now have different ways to design systems to eliminate the need for the refresh button. Get ready to raise your expectations.

Stateless Systems are Old School

Early servers on the Internet had to work in what is called a request/response manner. If a client needed some information, it would reach out to the server and request it. The server would then respond with whatever information the client asked for. If, later on, the client wanted some more information it would come back again with another request and the server would issue another response. The refresh button arose rather naturally from this process to re-request the information to get an updated version. Similar in concept to the redial button on your phone.

It was necessary for a server working in this manner to forget what it sent you the last time you made a request. After each response the connection was dropped. This vastly simplified the programming and reduced the hardware requirements for operating a server. We call this design “stateless” because the state of the connection is discarded after each response. Think of phoning an airline, asking if a flight has arrived, getting the answer, and hanging up. Five minutes later you call again, request the same information, get a response (likely the same one), and hang up. Repeat. Redial. Refresh. When you finally hear the flight has arrived, it’s stale news and already out of date.

This is how the vast majority of websites on the Internet work today.

Stateful Systems are Here

With the advances in web-based programming and the increased performance of computer hardware and storage, it has now become possible to design web servers to be “stateful” and maintain connections. An airline agent operating in a stateful manner would stay on the line until the moment the plane touched down and then say “the flight you asked about just arrived”. Instant data updates, nothing is stale, vastly reduced bandwidth, no need for a refresh.

Stateful systems can push real-time information to users rather than waiting for them to pull updates. Since these systems remember who you are and what you need, they only feed you information that is relevant to you at the moment it changes.

To be fair, creating a stateful system is more difficult than creating a stateless one. This means more expense up front. As time goes on however, new software tools and libraries are coming on the scene and removing the excuse.

Does this Really Matter?

At Omnivex, we’ve dedicated the last 25 years to presenting information to users in the most effective manner possible. We know that showing out of date information is often worse than showing nothing at all. If a bank is displaying the wrong exchange rates they can lose millions. If users rely on a website that isn’t accurate, they’ll leave. If a town learns about an inbound tornado or tsunami five minutes late, that’s unacceptable.

Truthful, real-time data is becoming increasingly vital as we advance in technology and expectations. If there is a better way to deliver updates, our position is that the benefits of this far outweigh the effort to add it to the software.

A leading cloud services provider of a cutting-edge platform has actually placed a refresh button onto the toolbar of their brand new web based monitoring dashboard. As if the one built into the browser wasn’t enough.

The constant need to refresh undermines the great technological strides we’ve made as a society.

Why are new, innovative systems still tied to outdated communication designs? The result is an unnecessary and potentially harmful lull in information delivery.

It’s time to eliminate this anachronism from our lives.

DOUG BANNISTER

CHIEF EXECUTIVE OFFICER & CHIEF TECHNOLOGY OFFICER

Doug is Chief Executive Officer and Chief Technology Officer of Omnivex Corporation.

Doug is considered by many as a visionary in the digital signage space. In his role as CEO and CTO Doug is responsible for the long term product architecture and the overall vision for the company. He has always maintained direct responsibility for the architecture of the software to ensure the product remains at the forefront of the industry. Combined with his vision, leadership and experience as an entrepreneur in the LED sign market, Doug has used his understanding of customer requirements and knowledge of technology to create one of the leading software solutions for the digital signage industry.