Realtime User Interface Design
This is the third installment in a series on Building Realtime HTML5 Apps. Most of the thoughts and ideas from these articles stem from my experience building bone.io, a realtime javascript framework. The previous articles focused on Websockets vs AJAX and Single Page Apps & Realtime. This article will focus primarily on understanding Realtime User Interface Design as opposed to MVC for browser-based applications.
The Evolution of the Browser
As web applications have moved from the server to the browser, there have been a few important milestones in how we think about browser-based applications. Now obviously this evolution has been complex with many actors, organizations, and open source projects, but I’m going to try and condense it down a bit for clarity’s sake.
The first major advancement was the introduction of jQuery and other cross-browser DOM manipulation libraries. This allowed developers to program functionality into the browser with relative confidence that their code would work across the Web. A proliferation of plugins and other goodies soon popped up which made the Web a fertile playground for interactivity.
The next major advancement in front-end development was the MVC-based frameworks that were able to abstract DOM manipulation and data retrieval into a broader structure. This gave developers the opportunity to build larger more complex browser-based applications, and was brought about mainly by libraries such as Backbone and Angular.
As the HTML5 specification grows in features and complexity, what are the paradigms and philosophies that will help deliver the next generation of applications?
The Case against MVC in the Browser
I don’t believe that MVC is the best paradigm for understanding and structuring browser-based applications. The usefulness of the “Model” as a first class concept in the browser doesn’t make sense in many circumstances, especially when the data involved is transient in nature. If your main goal is to get “hot” data to the DOM, then the added abstraction layer of a “Model” often gets in the way of what you want to do.
For instance, let’s take a real life example, “Google” search.
Does the MVC architecture really describe this model of user interaction well?
If I had to break this “Google” search box into its separate concerns, here is how I would describe it:
- [DOM Event]: A user interacts with the Search Box by Pressing Keys on the Keyboard
- [Data Out]: When a Keyboard Interaction Occurs, contents of the Text Box are sent to the Server
- [Data In]: Receive Search Results from the Server
- [DOM Manipulation]: Render Search Results to the Search Results Box for the user to see
In this example, you don’t really “care” about the data for the Search Box, because the data itself is transient and volatile. You just care about rendering meaningful search results as fast as the user can type.
For this reason, I feel like the following diagram, the view.io pattern, provides a better framework for understanding the “Google” search box.
The “Google” search example can be generalized to be largely “data-agnostic”, maybe it’s a search for books, condos, web pages, whatever. “Modeling” the search results or the text box that generates them is largely irrelevant.
How we access Data, Drives how we build Applications
In a lot of ways, how we access data drives how we build our applications. For example:
- A search box is most likely powered by a Search Backend (maybe Lucene or ElasticSearch)
- A data table is likely powered by a SQL database (maybe MySql or Postgres)
- An activity stream is likely powered by a NoSQL database (maybe Cassandra or Redis)
In all of these instances, a generic user interface component largely drives the selection of the underlying “database” technology. As long as the server can send data in a format that fits the “search box” model or the “data table” model, then it can easily be rendered onto the DOM.
Therefore, when working on realtime HTML5 applications, I believe it is a better approach to construct applications in terms of “data-agnostic” user interface components. Components that can be easily reused, regardless of the different types of data flowing through them.
I hope you enjoyed this article, and please read the next in the series on Building Realtime HTML5 Apps.
Brad is a badass JavaScript coder who enjoys building cool stuff and long walks on the beach. As the Founder/CTO at TechPines, he has worked with large companies and startups to build cutting-edge applications based on HTML5 and Node.js. He is the creator of Bone.io, a realtime HTML5 framework, and is the author of Embracing Disruption: A Cloud Revolution Manifesto.