How Web Application UI Behave as Systems

Understanding that UI components of a web application are actually subsystems of views, view fragments, composed, compositional and primary components, we need to understand now how a system behaves as all systems have a few things in common.

System Inputs

A system's input is an infinite and continuous function of U(x), where U is a live user input into the system and typically we can normalize the inputs between two ranges, we call those ranges the function of U(dx) (A function of u with respect to the first derivative of x, and the 2nd derivative of x). Between the range of derivatives is the range of all possible known and expected user inputs to the system, and in our case, a UI system of a web application. This can be at any level within the UI hierarchy, and really, we should actually consider this during the planning phase when building a UI element of the system (primaries, compositional, composed, view fragment or a complete view).

Beyond the ranges of the derivatives of expected user input exists areas of user inputs that could potentially happen that we do not know about, have not planned for or do know about, but think it is very unlikely that a user will perform that input, and so we do not include those inputs in the possible ranges of inputs that the user could do "this action" between the two derivative range of "expected behaviour".

Any input not within this expected range, could have wild and unexpected results in the system state, the system's output or in the various asynchronous requests, data processing or events emitters and event listeners within the system and so a lot of attention needs to go into what are the possible inputs to the system are and how are we going to control the inputs to enforce a user within the derivative range of expected input. Otherwise, we must think how do we account for a larger range of inputs and thus add the complexity to deal with the bad input.

The System State

The systems state is correlated to the system's input and is the result of various other processing within the system, but for sake of clarity and understanding, we simply can say, the system's state at any point in the function of the entire system, is at point X, or rather, the function of X (f(x)). That for a given correlated system input of U(dx) we are then going to result in a system state of (f(x)). But how does this relate to the error or unknown inputs of the system with respect to the state of the given system?

Well just because we don't know about the error or unknown inputs, or care not to know by choice, it does not mean it is not correlated to the same resulting state of point X in the system. You see, it does not matter if we perform an error or an unaccounted for input, the result of such action will always reduce down to the same correlated X point for that given system state. The state may cause the system or cash, have malformed data, a wrong value in some field, but regardless, the same exact u(dx) will result in the f(x), every time, with exception to any external system that is involved in the correlation of u(x) to f(fx) (async) -> such an example can be given, as when a server is down where U(x) pings an API before f(x) can be known (fetch user profile -> user profile).

System Outputs

A system's output is the function we expect that entire system to produce. With a car, we expect when we hit the ignition, the car will start and we can perform other events that will start and stop the system of that car. However, what happens if we fill the gasoline tank with an improper fuel? What happens to the system's output? Perhaps if the amount of water input into the tank of the gasoline chamber is so small, that it has a grand effect of zero in terms of diluting the gasoline within the tank, then the result of such input with respect to the whole output of starting the car, is negligible, in that the car will start as normally expected.

That is an unknown error prone user input to the system, in which the system can accept without harming the function of the system. But what happens if we load the gasoline tank with 3/4 water and 1/4 gasoline? I think you can appreciate, this will not only harm the function of the entire car's system, but other component parts will fail and will be unable to handle such input and as a result, the system crashes.

This is very similar to what will happen when we give users a range of various UI inputs to do the same thing, meaning we give them a UI to filter a result, but place various forms of UI on the page that ultimately perform the same function, to filter results. No system in nature behaves like this, and for good reason! A car has one input for gasoline, not various inputs for gasoline, a humming bird has one beek to extract nectar, it does not use its feet for extraction!

Our hands however, we have two inputs and what does that lead to? Say I give you two baseball gloves, and on the first instance I throw the ball to you and ask you to catch the ball, with your dominant hand, and you do so with ease and least amount of effort as you can expect the input of the ball approaching. Now, I think you can appreciate, if I ask you to do the same thing with you left hand, you can't catch as well with that hand and you exert more effort, try to think what to do and so the input of the ball approaching may hit the glove in such an awkward manner that it bounces off the tip of the glove, hits your face and you fall down. Your system has crashed due to the inability to handle that input in the same way your other hand does. The same input from the user, to a different form of UI to perform the same function, has crashed the system.

And so we can deduce, that much in the same way, various forms of UI elements that act as inputs to the system should not have more than one way of doing the thing we want, otherwise we risk having the system fall down, with a bad bruise! This is because, if we are not careful to equal out the balance of how to ensure the input can be handled by both systems, the complexity if not abstracted to a root the two inputs share, will have a variation in logic that can cause the crash. In the example above, the variation of how your left hand catches the ball with respect to how the right hand does, caused you to fall!

Feedback Loops

The concept of feedback loops is very much a natural phenomena in all of nature and we try to replicate that in our UI systems. For every good user input, we progress the user and give them feedback the input is good, in the case of an error input in which we expect, it is still considered good input but results in a feedback loop which tells the user that this is bad input, but the system had accounted for that error so we can perform such an action every time, say a user does not enter the right format for an e-mail, which is a small part of a sign up feedback loop, and so on.

Feedback loops with UI are all about encouraging good behaviour and discouraging bad behaviour within that system. This topic is so large, so incredibly complex, due to its non-linear nature, that it simply cannot be discussed in this article. I will write another article in some time to discuss how we can use feedback loops to grow interactions of users at different stages (or levels) within a UI system to reach an end goal that the system can accept and wants to perform. The goal of the feedback loop is to reduce the sum total of the ranges of error or unknown inputs through enforcing good input. For tech heads, the sum of the limit of 1dx and the limit of 2dx can be reduced by use of expanding the range of both derivatives of x outward slightly by generalizing those outward bound errors.

-Dan