The UI Development Process

The UI Development process can be broken down in to stages, where the output of one process of synthesis becomes the input to the next stage, each stage has specific goals and sub-processes which are really about adding more about fashioning the UI elements in each stage in some arrangement of relationship with respect to space.

It is important to understand that throughout this entire process, none of the functionality such as event handlers or 'onClick' events are ever implemented, instead in each stage those parts of the functionalities are left open for implementation. In a much more technical sense, it becomes a functor function 'connection'. Where the layer outside the final view implements the functor function for the view and that function is passed through the systems of each level of the UI down to the areas that need them, this relationship is defined in this process.

The goal or output of this entire UI development process is to develop a partially configured UI element at each stage of the process that feeds into the next. You may notice the words 'feed' as in feedback, and that is an actual fact of this process, and very much mimics the phenomena that occurs in nature, where synthesis of various parts, like cells, synthesize together and form complex relationships and new entities, such as tissue or organs and it's through this feedback driven process of synthesis such complexity can be predictable, managed and regular.

UI Configuration Time

Goal

Develop a low level partially configured UI element that has a specified style and dom structure but does not specify its own behaviour of functionality, but merely allows the input of such functionality, and thus this becomes the connector to other UI composition in a later stage. It's the same as trying to define a custom <p>, <h1>, <img> tag with a configured set of styles and constants defined by UI/UX.

Processes

1. ) Ensure the configuration of the style is available and ready from the UI/UX system, if not, configure those files and import them as a dependency. This is a 1-to-1 dependency to that configured UI system component. (CTA_BUTTON_STYLE = {defined fonts, sizes, colours, etc that can be rules found in other files.}}
2. Create a specific composed DOM Object of UI/UX rules, any constant files leaving implementation of any event functions undefined. A partially configured UI Element.
3. Give a specific name for this component that closely describes what 'this' is in terms of a UI/UX perspective. Examples are <CTAButton /> , <LogoTextCopy/>. Keep in mind, that any constants that we don't expect to change in the DOM should be part of the configured UI element, not expected to be passed in as a dynamic property input, hence the self terminating structure. If the DOM element was <Subscript>{somtext}</Subscript> where subscript is a defined set of styles set by the UI/UX system and is used in various places in the application, similar to how a <p class="subscript-styles"> tag, then that would make sense.

UI Composition Time

Goal

The goal of the compositional process is to create a spatial relationship of parts developed in the configured process and link the undefined functional behaviours between the container itself and its singular parts. The rules sent from the UI/UX system here are about defining the spatial relationship of UI elements in that compositional view. We can think of a brand logo as the spatial relationship between the[ <img> <p> ], however with our configured components we would compose them in this way instead:

<BrandLogo> <Logo> <LogoCopy> </BrandLogo>

Where BrandLogo is what we are defining. I apologize for the one-line view in the example above, as LinkedIn doesn't allow for code examples and I cannot give a better explanation of the final view we want for the composed UI element, but the concept is described in the figure above.

Processes

1. Import the UI/UX rules that describe the spatial relationship of what a BrandLogo is. It is important to make a distinction between what a configured component and a compositional component is. The UI/UX rules that define a configured component defined the relationship of styles for that specific element, the UI/UX rules that define BrandLogo describe the relationship of space between and other rules between what contains that configured component.
2. While the functionality will not be defined in this step, we do know that a <BrandLogo> is often clicked and so the question becomes. "Does UI/UX want the singular components within the BrandLogo container to 'DO' anything on an event of click?" and If that is so, we then do the work to connect the undefined DOM event listeners of the singular configured components to the container components in a relationship we loosely define as just the passage of the future implementation. In such a way, we can have a 1-to-1 handler, a 1-to-many handler, a 1-to-none handler but in any case, the definition of that handler is never present but the connection remains. This is partial configuration.
3. Again we define a name for this component that describes what "THIS" is in regards to a UI/UX perspective, such as <BrandLogo/>, <Links horizontal>, <Links vertical>. You may ask, "Why does the configuration inputs o links have a horizontal or vertical property? Isn't this composed component complex on the inside?" and I may remind you, that because these components are using configuration files, we simply switch out the configuration of the Link component in that instance of it with another configuration file for vertical links defined by the UX/UI system in that very case, and if in the future UI/UX defines diagonal links, well then we can extend that to a configuration file used by the <Links> component.

UI Fragment Construction Time & View Construction Time

Goal

In this process of construction, the goal is to define the larger spatial relationship between different compositional components in relationship to each other and the container itself.

The main difference between compositional and fragment spatial relationships, is these particular ones are much more prominent to the end-user who experiences them and really is often subject to a lot of change from UI/UX based on feedback in the wild. These are also often the topic of UI refreshes and to keep up with modern changes or allow for space for new extensions, devices, etc.

We also continue to manufacture the pipelines between any events but leave them undefined but ready for future use. The spatial relationship in this process is again defined by the UI/UX system and the implementation of DOM events will come after the final view construction layer.

I will not describe that processes here or that of the View Construction Time as we can now see the similarities between the processes is growing larger than the are different. This is the feedback loop of the non-linear systems in UI development that mimics the processes in natural systems found in nature and social dynamics, etc.

The process begins to be more about spatial relationships defined between fragments, the view container itself, and etc. Pipelines of functionality to be implemented also carry out in the processes below. The main difference is the output of this process in which the view and relationship in total has become a complex, interwoven and interconnected, interdependent system processes, that is configurable now, in the future and is extensible. Also notice, there is no one single component that defines the system of UI relationships, there are many and some build-upon others. However, when it comes to data and information, there is such a structure, but that is another article and discussion.

If you are able to follow this process, congratulations, you now have a UI system that is not dependent on it's DATA but that is dependent on its configuration rules for spatial relationship and the interactive relationships between other UI systems within the whole UI system! These rules are so simple, so easy to extend that your UI system is easy to maintain, reason about and can grow in a sustainable way.

-Dan