Toddler Explains the Future of Web Applications

Explaining the Future of Web Applications

My son, Emmett, is the catalyst for my inspiration. Solving our customers’ problems start with interactions and this time it just happens to be watching Emmett play with his trains.

Let’s put Spotify on pause for a minute and regroup around the point that it wasn’t until recently that a user’s experience was considered when developing web applications.

Sound a little foreign today? Maybe, but please bear with me.

In a Not-So-Distant-Past, the Question the Tech Community Pondered Was: ‘Can We Do It?’

Said another way, in the past, we asked ourselves can we build something that solves the problem in front of us? Thanks to the rapid advance of technology, we no longer have to wonder about the possibilities. If we can land a rocket falling from space on a floating barge in the middle of the ocean – we can do anything.

Today, the question has shifted to ‘Can our user leverage this application with little or no training to solve their problem?’ If the answer is yes, we, the software community believe ourselves to be successful. (Queue the soft music as we put our feet up in the evenings…)

But Yesterday’s Innovation Is Quickly Replaced by the Good Thinking of Today.

Yes, our expectation that users deserve a great experience is important, but it is not enough today. We have seen too many instances where UX on the web does not take it far enough. Cost, performance and security are often sacrificed.  

With today’s technology – we truly can have our proverbial cake and eat it too. We do this by decoupling the user’s interface (UI) from the backend services (BackEnd). While separating the UI and BackEnd is not a new concept, native mobile applications (iOS & Android) have always done so. It has been less prevalent in web applications. The tech community has typically shied away from ‘decoupling’ for an easier ‘hybrid’ approach because of the perceived complexity.  (see example #3 below)

So Here Is Where the Train Metaphor Comes In…

When I think of decoupling, I can’t help but think of train cars. As it turns out, train cars are a great analogy (and this isn’t just because I have a 1 1/2 year old). And let’s say you have a bunch of people that need to get from Grand Rapids to Chicago ASAP. And you also have a few thousand tons of logs that need to get from said cities. You have a few options given to you in the form of a story problem:

Option #1: You can throw ‘performance’ out the window and take everyone/everything at once. You would do this by connecting up 4 or 5 ‘working’ train engines to the passenger cars and the logging cars and take everyone/everything for a long meandering ride along the coast of Lake Michigan. Arguably still a great experience – it’s a beautiful ride.

Option #2: You can throw ‘security’ out the window and take everyone/everything at once. You would do this by connecting up a few ‘bullet’ train engines to both the passenger cars and the logging cars. While the chances of you getting there fast are good, you may also find your ride ends in a catastrophic way. Pulling a couple thousand tons of logs at a bullet train speed isn’t exactly ‘secure’. Bad vibes here.

Option #3: One could separate the two loads. Send the ‘working’ engines down the line first with the logging cars. Then send the bullet train with passengers down the line. The bullet train would zip along and catch up to the logging train. The passengers would again enjoy a long meandering ride down the coast. Only now we sent more engines and burned more fuel. Our only benefits being the bullet train departed later, saving folks a few minutes along the way.

Option #4: You could separate the two loads. Send the bullet train out ahead carrying the passengers for a safe, yet quick, ride down the beautiful coast. By decoupling the train cars, you also enable the ‘working’ engines to pull the logging cars to the same destination, arriving a few hours later, nice and secure.

It sounds like option #4 is a solid choice. Have we reached an agreement?

Technology now allows us to decouple the UI and attach it to a bullet train. That bullet train is called a Content Delivery Network (CDN). The CDN is designed specifically to deliver web content (images, videos, etc.) at the speed of a bullet. < Picturing this in my mind is so satisfying… The CDN is so focused on performance that engineers build them to cache data on servers geographically located close to their intended audience. Decoupling the UI allows the backend to utilize ‘working’ servers that provide all the necessary power and security to process and store business critical and sensitive information.

Thank you for thinking this exercise through with me; funny how that’s my day job.