Is it time to eliminate the refresh button?
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?
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.
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, new software tools and libraries are coming on the scene and removing the excuse.
Image via Istock.com
Doug Bannister Doug is Chief Executive Officer and Chief Technology Officer of Omnivex Corporation. Doug founded Omnivex after 7 successful years in the LED sign software business to take advantage of the newer screen technologies. Recognizing the potential for a revolutionary signage market, Doug embarked on developing software to capitalize on the graphic potential of the emerging technology.