Overview

Where the Noesis technology really shines, is that when employing Data-driven techniques where the Data layer is separated from the presentation, navigation, and interaction layers, only one interface needs to be built. As a result of this separation, these layers of the interface have the ability to seamlessly switch between various Data contexts without any loss of functionality.

Noesis Studio's interfaces in particular, run off what is called 📑 Design-Time Data. This can generally be thought of as high-fidelity 'mock data' that can be used to drive the entirety of an interface within from the application itself, without any external dependencies.

Driving an interface with Data revolves around two core components:

📑 Data Structures and Properties, which can be created directly within Noesis Studio as Design-Time Data Structures. In addition to this, it is also possible to use an Engine's own Data Structures as a base to work from in Studio. This can be done by exposing them to the application as 'read-only' entities using the techniques outlined in 📘 Data Technical Implementation (Coming Soon).

📑 Data Sets and Values, which creators have the choice to populate from any admixture of Data Structure sources, using a powerful suite of native 📘 Data Configuration tools.

Design-Time Data

Within Noesis Studio, Design-Time Data provides a robust set of tools in which UI developers can simulate and preview how interfaces will look and function in different contexts or circumstances.

Design-Time Data exists separately to the Engine Data used to drive the end-product's systems, and only exists within Noesis Studio. Because of this isolation, it provides immense amounts of freedom to developers to configure Data to serve them best outside of the constraints of the Engine itself. This means that creators can freely work with Data in Studio without risk of adversely impacting the end-product.

In the Noesis Development model, since the UI itself, as well as any included Data Bindings, are the exact same between Design-Time and Engine Data contexts, any Noesis Interface is able to seamlessly translate between Studio and the Engine, without having to invest in creating two different versions of the UI compatible with each Data source.

Data Structures and Properties

Within Noesis Studio, Data Structures and the Properties they contain, can manifest themselves in two different forms:

Firstly, Design-Time Data Structures and their Properties can be entirely created within Noesis Studio using the techniques outlined in 📘 Data Structure Creation.

These Data Structures exist exclusively within Noesis Studio, and can be populated with Design-Time 📑 Data Sets and Values.

This level of accessibility empowers creators to autonomously build, preview, and test Data-driven interfaces without any external dependencies needing to already exist. In certain workflows, many Data structures may even be created within Noesis Studio first, before then being replicated in-Engine to meet the demands of the interface.

Secondly, it is also possible, using the techniques outlined in 📘 Data Technical Implementation (Coming Soon), to expose Engine Data to Noesis Studio, from where it can be used to create Studio-exclusive Design-Time 📑 Data Sets and Values.

As this Data Structure exists in-Engine, it cannot be directly edited within Noesis Studio, and will display as a 'read-only' Data Structure within the visual editor. They are however still incredibly powerful in this form as they provide the highest parity between both the Engine and Studio environments.

Typically, these 'read-only' Structures will be used as a base to populate with Design-Time Data Sets and Values, creating a model where the Data Structure itself is fixed, but its values can be freely edited and manipulated.

It is additionally possible to create Design-Time Data Structures derived from the 'read-only' Engine Data Structures, allowing creators to extend the Engine's Data Structure with new, Studio-exclusive Data Structure Design-Time Properties.

In this example, the 'read-only' Engine Data Structure SolarSystemObject used for all space objects, is extended to create a SolarSystemObject_Spacecraft Data Structure which contains both the core SolarSystemObject Properties, plus a selection of brand-new Design-Time Properties specific to Spacecraft.

Data Sets and Values

One particularly powerful feature offered, exclusive to Noesis Studio's Design-Time Data featureset, is the ability to generate multiple Data Sets, which allow creators to store, individual collections of Data values.

Using Data Sets allows developers to easily and rapidly swap values within a UI to simulate how an interface could look under different circumstances which would typically be driven by dynamic in-Engine systems.

For example, Data sets, each containing unique values can be used to

• Preview what a screen looks like to a brand new player, versus a veteran of the game.
• Verify that an interface adapts well to changes in content sizes.
• Test how different Elements look when different values are routed through them.

Noesis Studio Data Sets and Values can be created using the techniques outlined in 📘 Data Set Creation.

Working With Data

• 📘 Data Introduction
• 📘 Data Sources
• 📘 Data Configuration
• 📘 Data Utilization