Overview

Noesis come out-of-the-box with an intuitive, and fully-integrated infrastructure that allows developers to drive their user interfaces dynamically with Data instead of having elements and their content inefficienctly-defined statically, or invisibly-defined in code-behind.

Data values can be displayed as content within the UI (such as displaying a character name that's defined in Data), or Data values can be used to drive changes (such as altering the appearance of an inventory item based on a rarity level defined in Data).

In addition to the ability for an interface to directly read Data sources as above, Noesis interfaces are equally capable of writing to Data (such as an instance of the 📘 Slider Element being able to adjust a 'TextScale' value that exists in Data).

The ability for Data values to flow in both directions makes it an especially strong choice for interactive applications where users are able to exert some level of control over what is displayed throughout the interface, without sacrificing the large-scale flexibility and modularity that Data offers.

Anatomy of a Data Source

Basic Composition

At a fundamental level, "Data" refers to information stored within a Data Structure, made up of Data Properties, which in turn, each have a Data Value.

In this example, the WEAPONDATA Data Structure is composed of 4 Data Properties (WeaponName, WeaponDamage, WeaponAccuracy, and WeaponCapacity), which in turn, each have a Data Value assigned to them (Sniper, 88, 95, and 5)

Data Structure Nesting

One very important concept to be aware of when approaching Data, is that only one Data Structure can be assigned at a time to a particular interface, or interface element.

With this in mind, a critical feature that Data Structures offer, is the ability to have Data Properties and their respective Data Values relayed to the 'main' Data Structure from a different Data Structure altogether.

This essentially allows for one Data Structure to be nested within another, allowing the 'assigned' Data Structure to serve multiple Data Structures at once to an interface:

In this example, the served LOADOUTDATA Data Structure contains two separate Data Structures nested within it: CHARACTERDATA, and VEHICLEDATA.

It should also be noted that the LOADOUTDATA Data Structure also contains a LoadoutName Data Property and associated Data Value directly within it, demonstrating that it is possible for a Data Structure to simultaneously serve self-contained Data, as well as Data relayed from other Data Structures.

Nesting Data Structures within eachother allows for even deeper and vaster networks of inter-related Data Structures to be served to the UI through a single 'master' Data Structure, whilst still allowing breaking up of Data Structures into more modular, efficient, and manageable chunks.

Building Data-Driven Interfaces

Noesis works best using an architecture in which the presentation, navigation, and interaction layers are intentionally separated from the Data layers responsible for driving much of the dynamic content and functionality of an interface.

This approach results in a highly-efficient and highly-portable system commonly referred to as using a ↗️ Model-View-ViewModel pattern (or 'MVVM' for short).

Using this method, since so much of what is displayed on-screen is populated from Data values, Designers are not required to build and maintain nearly as many UI disparate element variants as would typically be the case in other architectures.

A Data-driven approach takes full advantage of leveraging what is common (or 'shared') between variants of a UI element, allowing for the Data to handle the heavy-lifting of what makes each variant different:

For example, in the context of an inventory UI containing a series of item tiles as well as a space to display the details of the selected item; using Data-Driven techniques, it would only be necessary to create a single 'Item Tile' Template, and a single 'Item Details' Component:

In this scenario, all unique variants for each item, and which of the inventory items is shown in the Item Details, would be automatically generated from supplied Data, a method which is far cheaper to manufacture, maintain, and adapt than creating bespoke element variants.

Working With Data

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