The Universal User Interface

Have you ever taken a journey that ended up with you approaching a familiar district from a completely different direction and felt that it all looked different? I hope to give this feeling of jamais vu with this post, but with an architectural journey instead.

One of the holy grails of many enterprise architects is the universal user interface. With this, a company only needs to install one user interface on its end devices and this can be used for every application. In the last decade, many EAs thought about this and often came up with architectures that looked something like this:

This has a number of components:

• A view component to display the screens etc.. This could be customised by a look and feel specification that usually adhered to corporate standards.
• A component that handled the behaviour, i.e. validation rules. workflow etc.. The wish was also for a specification “language” that enabled this to be customised.
• A model of the data (echoes of the model-view-controller paradigm here). The structure could also be customised by a model structure specification to the application at hand. 
• Some local persistence so that the user could work offline (a favorite requirement from business users). 
• And finally, a communication component so that the universal user interface can communicate with the server.

So far, so good. In the last decade, a lot of thought was given by a lot of EAs in a lot of companies as to how a universal user interface (let’s call it a UUI) could be implemented. Various attempts were made to implement them. Often these resulted in failure as the skills necessary to build something like this were not in-house. Sometimes, external frameworks (such as Eclipse) were used to create user interfaces and these went some way to reaching the goal of a UUI.

And now back to a familiar district with hopefully a new view on it. I contend that we already have (or nearly have) the UUI and it is installed almost everywhere. Its called a browser and it’s come a long way from its humble beginnings as a mere viewer of information. Mapping current browser standards to the architectural model for a UUI clearly shows this:

Some of this has been there for a long time and is used extensively. HTML for the model structure is an example. However, this is changing. With single page application architectures this can end up just being a set of tags with class information that is processed by the CSS and JavaScript. 

Some is new. For instance, the local storage standards for IndexedDB and FileAPI are still not W3C recommendations. However many browsers are already supporting the current versions of these.

Understanding that the browser really is the long sought after UUI - jamais vu no less - isn't really widely acknowledged (try googling “universal user interface”). However, accepting this means that EAs can start thinking about the skills they need in-house to exploit the advantages of a UUI  they already have installed.