Our brain is very attentive to moving objects: many websites have realized this and now use CSS to animate the way their content appear on the screen. What if instead of integrating the « movement of inanimate objects », we choose to modify the data in real-time? Impact on the users would be much bigger. The good news is, real-time is not strictly reserved to NYC traders in suits & ties anymore! Real-time data is everywhere: In social media, transportation, the collaborative economy, private sales, etc. Updating data is both very practical, and has a real business value for both the broadcaster and the receiver of that data.
Animated UI
Nowadays, we find animated graphical user interface (GUI) in most Web and Mobile applications. It can be animated buttons which have small effects and change shape when the user clicks on them, or animated text fields that change background color when selected, etc. The question is: can we go a little bit further and also animate the data?
Naturally, the first thing everyone does, including me while writing this blogpost, is to start by looking at the moving stick figure above. It is the role of our « reptilian brain » to draw our attention to moving things. The reason is simple and dates back to the beginning of humanity where anything that moved was either food or danger.
In our case, animation is meant to catch the user’s attention. For example, a button is animated to show that an action has been performed. The same way, data can be animated to show the user that important information has changed.
Tired of waiting?
Animation of your application is also a great way to fight this new illness commonly known as “Repetitive Refresh Syndrome”.
The refresh button and spinning wheel are breaking the relationship between the application and the user because it forces the user to perform an action then have to wait. You can find this in most current Newsfeed applications with the pull-to-refresh gesture, or the countdown before refreshing the data. Animation can help fight this negative effect and create an even stronger bond between an application and its users.
If we’re going to animate data, we might as well do it in real-time. But what does that really mean?
Real-time data
Just 5 years ago, real-time mostly related to the world of finance and trading (variations of the stock exchange prices, share quotations, financial transactions, etc.). Today the world has changed, and we all consume more and more information which we would like to access in real-time.
This image presents a few examples of current or potential real-time data usage:
- Social networks: With Twitter and Facebook, receive & read messages in real-time.
- Newsfeeds: Read the latest news as soon as it becomes available; News providers such as the NYT, or L’Express in France, are currently investigating methods to provide the latest news to their readers without refreshing.
- Online sports betting: Our client BetClic provides real-time quotations for customers to be able to place bets with the best odds possible.
- Transportation: Order the Uber car closest to you and be able to know the estimated time of arrival to your destination with regular updates, depending on the traffic conditions. Also, get the number of Velib bikes available in stations near your location with the JCDecaux API (see Demo in the image below)
- e-Commerce: With private sales like Vente-privée or Gilt, many customers have felt the frustration created by adding an item to their basket only to have their checkout fail because the product was out of stock, in the meantime. The immediate solution to this is the integration of a real-time stock indicator, because an informed customer is a happy customer. In addition to this, the real-time stock indicator can also aid in sales transformation as it has been proven to increase the sense of urgency purchasing for customers.
- Collaborative tools: Example of Google Docs (multiple user document edition) or Agile-like applications (moving post-its on a shared task board).
- Dashboard: For monitoring & alerting.
- Internet of Things (IoT): We are surrounded by more and more connected objects that generate data either collected in databases or directly exposed via API. A Web or Mobile application can then easily display this real-time information.
Real-time is real money
As we have just seen, displaying real-time data in your applications makes for a richer user experience, but it can also make you richer… well, at least it can allow you to save money.
Two examples:
- In an A/B testing experiment, Amazon found that every 100 milliseconds of apps latency cost them 1% in sales. And 1% of Amazon sales would surely make a nice Caribbean retirement!
- In a study, Google VP Marissa Mayer found that an extra 0.5 second in search page generation time dropped traffic by 20%, obviously, leading to big revenue losses.
The perception of real-time is, of course, a notion relating to the individual, and in human perception, this 0.5 second has a tremendous importance. There are three origins to this concept.
On the importance of 0.5 second
The first origin is linked to the reaction time of our brain. The reaction time of reflexes in a human being is between 100ms and 0.5s.
A man stepping on a pin, for example, will first experience pain, then a primal reflex taking 100ms which will lead to him removing his foot. Primitive reflexes acquired during childhood get closer to the 0.5 second mark.
The second origin is linked to human interactions. Interactions between two human beings is in the range of 0.5 second as well.
Scientific studies have found that a yes or no question will get a response in about 100ms, whereas an open question will get a response in around 0.5s.
It is also important to note that human interactions are interactions which carry the most emotions.
The third origin is linked to the way our memory functions.
There are three types of memory in our brain:
- The sensory memory that is of very short term (about 0.5s) which enables us to receive an enormous quantity of information (sensations and contextual information).
- The short-term memory, which lasts a little longer (about 0.5mn).
- The long-term memory.
Moving from one memory to the next, there is a huge degradation in the information that the brain will keep.
In summary, both primitive reflexes, human interactions and sensory memory, are always in the order of 0.5 second. Why is this important for us? In order to develop Web & Mobile applications which will convey the most emotions to the user, we need to reach this 0.5 second threshold in terms of response time.
The graph above shows the scale of the emotional impact on a user depending on the application’s response time:
- Below 0.5s, the instant response often creates the Wow! effect on the user.
- 0.5s is the threshold for which the user feels like interacting with a human being. If your application has already reached this threshold, don’t bother investing more money to get even faster, because chances are the users wouldn’t even notice the difference.
- Up to 1s, there is no feeling of waiting. Above this limit is when you start losing money and/or customers.
- Above 4s, computer users feel like the application is slow and you lose 40 to 60% of those users.
- Above 6-8s, mobile users start to feel like the app is slow also, and you lose 30 to 40% of those users. Users are more tolerant on mobile because bitrates are often lower. However, with the broader usage of the 4G networks, mobile users become less and less understanding, and soon the threshold will be the same for computer and mobile usage.
- Beyond this point, your users will start to lose attention, quickly followed by frustration, eventually losing them for good. Remember, behind every screen there is a real human being!
Reducing latency
Since about a year and a half, mobile Internet has superseded computer Internet. Nowadays, most Internet data is received in real-time on smartphones, and the main challenge faced is the latency, mostly network latency.
The graph below shows the round trip delays (ping time) in transporting the data:
Data round trip over mobile 3G is about 150ms, so 5 times slower than over optic fiber.
And for HTTPS, you have to multiply these figures by 3, because data will require 3 round trips: the first for SSL negotiation, then the second for securing the connection, and the last one to transfert the actual secured data. So for a secured connection over 3G, it already takes about 450ms just to receive the first useful piece of data, just under the 0.5 second threshold.
In order to reduce the latency as much as possible, we will have to fine-tune our application depending on the context, a bit like a Formula 1 car:
- User perception: Display the most important data first.
- Network latency: Important for a mobile application when network quality can be inconsistent.
- Bandwidth: Transfer the smallest possible amount of data in order to avoid additional costs in the user’s mobile data plan.
- Communication protocols: Use consistent protocols throughout the application.
To summarize, we consume more and more data primarily via mobile, using HTTP 1 protocols dating back from the 90’s when mobiles didn’t even exist, with the need for secured connections adding even more latency.
Conclusion
In this article, we have learned why animating data in Web & Mobile applications are important in order to attract new customers and even more so, to maintain them. We have also seen how real-time data can help avoiding the frustration of having to refresh & wait to receive the latest information, and the importance of the 0.5 second mark to create a relationship between an application and its users. Finally, we have seen that our online world is shifting from computers to mobile devices, introducing new problems to solve.
So, do we have ways to overcome these problems and be able to efficiently push & animate data on both Web & Mobile? The answer is YES! With the rise of the WebSocket and Server-Sent Events (SSE) technologies, we now have some powerful tools to transform polling APIs into push APIs. For a sneak peek, you can read a previous article on our blog: Push: SSE vs WebSockets