The dynamic interface as a concept is important to the web today - information changes at lightning pace and so the systems that serve up and parse this information must be adaptable. The human to computer interface is also in constant flux. A user these days may move from device to device all while interacting within a single ecosystem or product. This again requires a flexible data handling model on the end user interface side of things. Experience should not be the same across all devices as not all devices share the same context, however, interfaces should “feel” the same as it is our job as designers to make easy the transition from one context to another. Static metadata, in juxtaposition, is metadata that is highly generalized in its conceptualization of information and is necessary to make such a flexible dynamic system maintainable and extensible (reusable) by humans. An agreed upon and foundational general representation of the data is paramount to building flexible context switchable human and computer usable interfaces.

An example:

Imagine we have some data set, perhaps a shopping list of 100 items. There are many contexts where such a list may be useful.

  1. A user interested in cutting costs would like to know all the prices of items and discover categorical patterns in pricing in an attempt to identify and recontextualize spending from the list. We can imagine this user is interested in doing their accounting at the desk. However, we may also ask the question: What kinds of things would this class of user likes to do on the go via a mobile interface?

  2. A user interested in making a physical shopping trip as time efficient as possible would like the list grouped by locations of items (isle numbers) in the store. To interface with the dataset, they are likely to be using mobile. However, we may ask ourselves: if this person were to find themselves with their laptop out, say in a meeting with an accountant, how would they most like to do the things they need to do.

We can find innumerable, context-specific use cases. We also must assume that the end user is not educated in all the ways of interface design and the end user is not capable of placing interface elements in such a way that is intuitive and with high usability. Thus the interface is not adaptable by end-user customization.

How then do we build interfaces, at all levels in the product use cycle, which are adaptable to various contexts? We design them. Through testing and beta programs, theory and peer discussions we attempt to anticipate the highest value (more on identifying value another time) contexts and produce friction reduction by matching interface to context. But we must design them not just for end users. We must design them for designers, for programmers, for ops, for machines that learn, for the press.

The possibility of this context switching design space necessitates the existence of a constant variable, a foundational system from which contexts reliably share data. Such a system would be omnipresent in the “day to day business.” We say the words “it would be”, but it is. It IS because whether you design it or not, it exists. Like a great mythical dragon waiting to accelerate or swallow business whole, it can be either Falcor or it can be Smaug. Such a system is ideally: small, easy to understand, friction reducing, and reusable across a maximum of business applications.

This system is code.

The ecosystem software -

And the unit function.