GUI Rendering via Variation Metamodels for Geographical Adaptability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software systems face challenges in supporting variability across different geographical regions, requiring frequent changes to application source code, recompilation, and maintenance of multiple code bases, which is time-intensive and increases maintenance work as operational requirements change.

Innovation Solution

A method for rendering user-interface elements based on a variable metamodel received in an API response, allowing the GUI to handle variability without hard-coded templates, using metadata to determine how to display data and separate the variation schema from the source code, enabling a single code base to handle multiple variations.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If operational requirements are hard-coded in application source code, then the application can function correctly for specific geographical regions, but supporting variability requires frequent source code changes, recompilation, and maintenance

Engineering Contradiction:
Improvefunctional correctnessVSAvoidsupport for geographical variability
Core Design Contradiction:
ReliabilityVSAdaptability or versatility

Solution Approach 1:

The patent extracts operational requirements and formatting rules from the application source code and stores them in an external data service. This separation allows the source code to remain unchanged while supporting multiple geographical regions, eliminating the need for recompilation and reducing maintenance efforts.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The application source code is designed to be universal and region-agnostic, capable of functioning across multiple geographical regions without modification. The code retrieves region-specific operational requirements dynamically from the data service, enabling a single code base to serve multiple purposes and regions.

Inventive Principle:
Principle #6Universality (Multi-functionality)

2Adaptability or versatility

If new workflow variations are supported by generating new application source code, then the application can handle new geographical regions, but the amount of code to maintain increases

Engineering Contradiction:
Improvesupport for new workflow variationsVSAvoidcode base size
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent extracts workflow variations and operational rules from the source code into an external data service. This allows new workflow variations to be added by updating data in the service rather than generating new source code, keeping the code base size constant and maintenance efforts low.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The application dynamically adapts to new workflow variations by retrieving updated operational requirements from the data service at runtime. This dynamic approach eliminates the need for static code changes, allowing the system to flexibly support new geographical regions and workflows without increasing code complexity.

Inventive Principle:
Principle #15Dynamics

3Adaptability or versatility

If application source code is changed to reflect changed operational requirements, then the application can adapt to new rules, but developers need to debug, recompile, and provide update packages

Engineering Contradiction:
Improveadaptation to changed operational requirementsVSAvoidtime for debugging and recompilation
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent extracts operational requirements from the source code into an external data service. This allows operational changes to be implemented by updating data rather than code, eliminating the time-consuming processes of debugging and recompilation while maintaining adaptability to changed requirements.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system performs preliminary actions by pre-defining workflow variations and operational rules in the data service. When operational requirements change, the updated rules are already prepared in the data service, allowing immediate application without the need for debugging or recompilation, thus reducing time loss.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentEP3532923B1Rendering user-interface elements based on variation metamodels
Publication Date: 2023.09.06 INTUIT INC
  • EP3532923B1 patent drawingFigure 1
  • EP3532923B1 patent drawingFigure 2
  • EP3532923B1 patent drawingFigure 3

AI summary

Embodiments presented herein provide techniques for rendering user-interface elements for an entity type based on a variation metamodel received in response to an API request. When a user invokes a function to access or create an entity, a user interface sends the API request to an API service. The API request identifies the entity type and is associated with context information about the user. The variation metamodel is selected by the API service based on the context information. The user interface receives and parses a response from the API service. The meta model includes metadata describing at least one aspect of a corresponding property of the entity type. Using the metadata as a guide, the user interface renders elements for the properties of the variation schema in a graphical user interface (GUI).