Spoiler alert! Most websites and web apps are not real-time and that is okay. Most websites don’t need to be.

In this article, we will explore what it means to be real-time and whether it makes sense for your business model. For many businesses, real-time functionality can be overkill, while others may be missing out on critical leads, conversions and actionable metrics.

Real-time functionality can either be a game changer or a liability that saddles an organization with technical debt and overhead. It can be hard to recognize where that threshold is.

Is it worth it? Well that depends.

How does a traditional web application work?

A web application that is not updated in realtime, requires the user to refresh the page or navigate to a new page to get the latest data. In this model, all the data is passed up on the initial page load and doesn’t change until a navigation or input action occurs on the client side.

Most websites and apps you come across online are not realtime. We’ve all come to expect that we have to reload websites to see the latest data. While this is ok for many business models, some models are being underserved.

What is a real-time web application?

In contrast, a real-time web application updates immediately when new information is available without having to reload or request new data for the page. This is accomplished through a constant two way communication channel that remains open throughout the life of the user session.

This constant connection allows the application server to send messages to the web browser and kick off actions using javascript.

For example, when a new record is added, a hook can be kicked off to notify the user interface to update any relevant tables and notify the user that a new record has been created without a page reload.

While this may only be a minor nuisance to the users of some applications, it could mean losing money and time for the users of other types of applications. Many ticket, chat, social and communication applications are real-time. Users don’t want to wait for messages or comments; they want to know when something is happening without having to remember to check.

For example, what about an auction? Imagine you are a customer and you’ve bid on an item or good and think you’re in the lead but come to find out you’ve been outbid and have lost the item at closing time. This scenario has cost the consumer not only time but potentially money. This only becomes amplified if the transaction model is business to business.

Had this theoretical auction site been built with real-time technology, the page would have updated in real-time and notified the user that they had lost the lead. The consumer is more informed and is provided actionable information that helps the bottom line.

eBay: A case study

An example of the difference can be illustrated by examining the evolution of Ebay. When Ebay first started it was very similar to the functionality you see today with one key difference: It wasn’t realtime.

Early adopters will remember when you had to constantly reload the page to see if you were still the high bidder on an item! Today Ebay is closer to realtime and users don’t have to reload the page to get critical information. They recognized that the auction and bidding models required realtime functionality.

Does my business model need a real-time web application?

Your business may benefit from real-time if your web application fits into one of the following categories:

1. High volume online store or ticket system with volatile inventory quantities.

Users may be racing to reserve or checkout with items.

2. Competition based apps like an auction.

Requires user interaction and communication to complete a transaction.

3. Chat or social based applications relying on messaging or feeds.

A need to keep users engaged and on the site.

4. Monitoring, polling and reporting applications.

A need to see the current state of data on a persistent basis.

Generally speaking, if your users are waiting on your application to give them data, real-time functionality may be a good option. When a site moves and changes based on the interactions of other users it makes a site feel utilized and populated. This fluidity makes it feel more organic, evolving and engaging; ultimately keeping users in the application longer.

Great, let’s make everything real-time!

Sounds good but buyer beware, realtime functionality isn’t free, it typically requires a supplemental server and some extra development effort. This extra cost in effort and maintenance keeps many sites from adopting real-time functionality; the cost may simply outweigh the benefits.

Deciding whether the wow factor is worth it depends on the bottom line. Figure out how to quantify what time or money would be saved with the feature. If the cost can be justified, realtime functionality is a great way to breathe life into an application or may even justify an entire rewrite.

Not sure whether it’s worth it or how to move forward?

No problem, these things can be hard. Airship staff are experts at mapping out and planning projects around your desired value add, budget and needs. Feel free to reach out for a consultation so we can learn more about your use case.

If you think that adding real-time functionality could benefit your organization, contact us and let's talk.

Problem-Statement-Webinar-PDF-no-date

Start with: What problem are you trying to solve? 

One of the activities we work through revolves around refining your problem statement. A problem statement is the key business problem that needs to be solved. In software development, it states “what has to be done” for a project to succeed. It does not say, “how it has to be done.”

We use the 5W’s + 1 H format as well as the SMART Framework when establishing a problem statement. In fact, you can draft your own problem statement by using our free download. This download will get you thinking through some of the questions and answers prior to starting your project.

Download: Problem Statement
 
Ready to get started?