Patent Description:
Currently, any user of a computing device such as a smartphone or tablet can download an application (or 'app') from an application store and install the app onto their computing device. Such applications are often referred to as 'native applications' or 'native apps' as they are configured to run directly on the device using the operating system of the computing device itself. An example of an application store is the Apple App Store for users of computing devices produced by Apple and running Apple's operating system for the selected computing device, e.g. iOS for the Apple iPhone or macOS for the Apple Mac. An app that is available in the Apple App Store for download and installation on a device running iOS is written specifically for iOS devices. Analogously, an app that is available in the Apple App Store for download and installation on a device running the macOS operating system is written specifically for macOS devices. iOS and macOS apps can be written in the same programming language, namely Swift or Objective-C.

Consequently, a developer aiming to create an app for use on multiple different Apple devices, wherein each device is running a different operating system, needs to write a different app for each operating system. Furthermore, the developer when writing an update for an app has to write a different version of the same update for each different operating system. At the user end, a user that requires use of the same app on different devices, for example on both an Apple iPhone and an Apple Mac, needs to download and install a different app for each device. Also, in use, the user is then required to download and install different updates for each of the apps on the devices being used.

This problem exists not only for the creation and use of apps written in the same programming language for different operating systems, as per the above example, but also for the creation and use of apps that need to be written in different programming languages depending on the operating system of the computing device. In the latter case, each operating system (e.g. iOS, Android, Windows) has its own specific native programming language (e.g. Objective-C for iOS apps, Java for Android apps, and Visual C++ for Windows Mobile apps). A developer creating an app for use on multiple different operating systems that each require the app to be written in a different language, is therefore required to perform multiple programming tasks and this is particularly apparent for a single update, where multiple different versions of the update need to be written.

In addition, the developer needs to write each update to the apps in different languages such that the updates can be applied to the apps being used on different devices. This process is cumbersome not only for the developer but also for the user. For example, a user of an Android phone, a Windows PC and an Apple tablet wanting to use the same app across all three devices needs to download and install a different app on each device, followed by downloading and installing corresponding updates to each app on each device when the updates become available.

A further problem for the developer is that a significant amount of programming knowledge is required in order to create the user interface (UI) of an app. The apps discussed above are 'native apps'. An alternative to a native app is a web app. In contrast to a native app, a web app is written in a suitable web app language (HTML5 or JavaScript) and the web app is accessed through a web browser and does not need to be downloaded and installed on the device itself. Updates can be made to the web app via a web server without user input. A problem with web apps is that they can access a limited amount of the device's native features, such as geolocation and media, whereas native apps are able to interface with the device's native features and hardware. Furthermore, web apps are typically slow and power-intensive in comparison to native apps. Native apps typically perform faster and more efficiently in comparison to web apps, and are dedicated to the device, so they can interface with the device's native features and hardware.

However, the UI of a native app is more difficult, time-intensive and skill-intensive to create. The problem of requiring a significant amount of programming skills to create a UI is exacerbated by the current need for the developer to write a native app and the native app's updates in a different programming language for each and every operating system, as discussed above. Supporting multiple different operating systems therefore requires the developer of the app to maintain multiple code bases. As a consequence, native apps are generally more expensive to develop, maintain and update. In addition, users may be on different versions of the app, which can make it more difficult to provide support for the app.

<CIT> discloses a system that accesses an application development user interface ("UI") through a browser. The application development UI is hosted by a web-based application development server in a cloud system that provides an application development framework ("ADF"). The system develops the application through the application development UI. The application is developed with the ADF and is configured to be downloaded from a download location in the cloud system. The application is configured to be downloaded on a device as a native application.

The present invention aims to overcome or at least partly mitigate one or more of the above-described problems.

In the following description the term GUI (Graphical User Interface) and UI (User Interface) have been used interchangeably. Both terms should be considered to relate to a computer-generated user interface which, in use, is generated on a user device and which comprises textual and/or graphical elements.

In accordance with embodiments of the present invention, generally there is provided a system including a creator device for specifying a new user interface (GUI) and a configuration server for storing the elements which enable the specified GUI to be created on other user devices running different operating systems. In use, a creator (user) can create and specify the GUI by use of an easy-to-use GUI creation application ('creator app') provided on the creator device. The creator app can be embodied in several different ways, but in this embodiment, it is provided as an application for the creator device which is downloaded from an application server. The creator app, in use, generates a universal configuration data file (hereinafter referred to as a 'Configuration') defining a configuration of the GUI. The Configuration describes the appearance and behaviour of the GUI being specified, and particularly its behaviour in relation to data it requires to make the GUI operable. The Configuration has a scalable data structure which includes definitions of GUI elements, such as buttons or switches, and defines requests for data directed to a server. The Configuration is created to configure a copy of the GUI generated by a UI generator on any user device for an end user. However, the Configuration does not contain any programming commands. Rather, it is just a data file which has a specific data structure to represent data. The data structure (described in detail later) is specified such that it can optimally be used (with the UI generator) to generate a GUI on a user device. Also, the data structure is scalable as is has a hierarchical structure which enables more complicated UI elements of the GUIs to be defined within other UI elements. The UI generator can be embodied in several different ways, but in this embodiment, it is provided as a downloadable native application for the user device. The UI generator uses the previously defined Configuration in run time to generate the GUI and connect to a data storage server, which in this embodiment is the configuration server. The GUI is generated by displaying GUI elements on the screen of the user device, submitting the requests for data to the data server, parsing received data, and populating UI elements with relevant data items.

More specifically referring to <FIG>, there is shown a system <NUM> according to an embodiment of the present invention. The system <NUM> comprises a creator device <NUM> on which a user (creator) specifies or designs a GUI <NUM> having a particular layout of graphical elements <NUM>. The creator, also using the creator device <NUM>, specifies the data which is to be pulled into the GUI <NUM> by way of data requests. The look and positioning of each of the GUI elements <NUM> making up the GUI and the data which needs to be pulled into them (or its location), is specified in the Configuration <NUM>. The Configuration <NUM> is created by use of the creator app <NUM> which has previously been downloaded from the application server <NUM>, such as the App Store (iOS) or the Google Play Store (Android). It should be noted that although only a single application server <NUM> associated with a single data store <NUM> is shown in <FIG>, the system may comprise multiple different application servers, each application server being associated with its own data store. The way in which the creator app <NUM> functions to enable relatively easy creation of GUIs by creators who have no previous programming knowledge will be described in greater detail later. However, the result of the use of the creator app <NUM> is a Configuration <NUM> which is uploaded to the configuration server <NUM> and stored in the data store <NUM> of the configuration server <NUM>.

The system is configured to support different user devices <NUM>, <NUM>, <NUM>, running different operating systems. In the present non-limiting example shown in <FIG>, three devices are provided. The first device is a tablet <NUM> which has iOS installed on it as its operating system, the second device is a smartphone which has Android installed on it as its operating system and the third device is a PC <NUM> which has a Windows operating system running on it. Each device <NUM>, <NUM>, <NUM>, has a respective generator 18a, 18b, 18c, which has been downloaded from the application server <NUM> which acts as an application store. In this regard, the application server <NUM> has a plurality of applications 18a, 18b, 18c stored in its data store <NUM>, copies of which are made available to be downloaded by user devices <NUM>, <NUM>, <NUM>. In use when each generator 18a, 18b, 18c, is run on its corresponding user device <NUM>, <NUM>, <NUM>, the respective generator 18a, 18b, 18c downloads a copy of the Configuration <NUM> from the configuration server <NUM> which is then interpreted by the generator 18a, 18b, 18c and used to create the GUI <NUM> on the respective user device <NUM>, <NUM>, <NUM>, operating its specific operating system. In this regard, each generator 18a, 18b, 18c acts as a native application. The Configuration <NUM> not only specifies the layout of the graphical elements of the GUI <NUM> but also the data <NUM> which is required to populate the GUI <NUM>. This data <NUM> may be also be downloaded with the Configuration <NUM> from the data store <NUM> of the configuration server <NUM>. In this regard, it is to be appreciated that the Configuration is generally a file between a few Kilobytes and <NUM> to <NUM> Megabytes in size, in other words, the Configuration <NUM> is relatively small and therefore does not take much time to download. This is important as the Configuration is often downloaded each time a GUI instance is to be generated. All of the user devices, the servers and the creator device are interconnected via a wide area communications network <NUM>, such as the Internet.

In use, when a creator downloads, installs and opens the creator app <NUM> on the creator device <NUM>, the creator app <NUM> is used to create the Configuration <NUM> which defines the GUI <NUM>, namely the form and appearance and also the positioning of the GUI elements <NUM> of the GUI <NUM> as well as the required data calls to obtain data to populate the GUI <NUM>. This information is stored within the specific data structure of the Configuration <NUM> and is in this embodiment handled in a JSON (JavaScript Object Notation) which is a standard text-based format for representing structured data based on JavaScript object syntax. The information is subsequently converted into a raw binary data and then uploaded to the configuration server <NUM> and stored in the configuration server data store <NUM>. However, the data can also be stored in JSON format in other embodiments or in any other suitable form. However in these other embodiments, the stored data needs to be converted into a raw data format before being sent to any requesting generator 18a, 18b, 18c. Accordingly storing the configuration <NUM> in a raw data format means that it is ready to be provided to any requesting generator 18a, 18b, 18c.

The configuration server <NUM> makes the Configuration <NUM> available to all devices <NUM>, <NUM>, <NUM>, so that they can generate the GUI <NUM> which has been defined by the Configuration <NUM>, when the Configuration <NUM> is obtained and executed by the generator 18a, 18b, 18c on the user device <NUM>, <NUM>, <NUM>. The user is then able to utilise the generator 18a, 18b, 18c, on their user device <NUM>, <NUM>, <NUM> whereby the appearance and behaviour of the GUI of the app is defined by the Configuration <NUM>. The Configuration <NUM> has a specific data structure which is optimized for generating a UI and this data structure is discussed in greater detail later. As a result, the creator of the Configuration <NUM> is not required to perform any programming tasks or to generate update files for execution by the app, and the app does not require update files to be downloaded and installed by the user. Rather, when an update in a GUI of a user application is required, the creator only has to generate a single new Configuration <NUM> which then is uploaded to the Configuration Server <NUM> and made available. This single updated Configuration <NUM> then can be used by all the different user devices <NUM>, <NUM>, <NUM>, running different operating systems, This updated Configuration <NUM> is called when the user application 18a, 18b, 18c is run on the user device <NUM>, <NUM>, <NUM> to generated the updated GUI. In an embodiment, the Configuration <NUM> is fetched from the config server <NUM> in the form of raw binary data which then are translated to JSON format and then converted to a Configuration model (instance) that the application (generator) <NUM>, 18b, 18c uses to generate the GUI. JSON is one of the most commonly used types of data representation in web/mobile environments.

As mentioned above, the creator uses the creator app <NUM> to create the Configuration <NUM> which defines the GUI <NUM>. The Configuration <NUM> is shown in greater detail in <FIG>. As it can be seen, the Configuration <NUM> comprises essentially two data structure elements a UI Layer <NUM> and a Data Layer <NUM>. These layers are shown in greater detail in <FIG> and <FIG>, respectively. The UI Layer <NUM> quantifies the number, type, size, appearance and positioning of the UI Layer elements and the Data Layer <NUM> quantifies the location, type and number of Data Layer elements.

The UI Layer <NUM> comprises one or more Modules. As shown in <FIG>, each Module <NUM> comprises a model that describes a logic group or list of Screens <NUM>. Each Screen <NUM> comprises a list of 'View Instructions <NUM>', alternatively called 'View Instruction models <NUM>', or 'UI elements <NUM>'.

A Screen <NUM> comprises a model representation of all of the elements that are required for an accurate display of the UI on a page. These elements are configured, rendered, and displayed by the list of View Instructions <NUM> that belong to the Screen <NUM>. Each Screen <NUM> also comprises a set of properties that can be used to indicate behavioural preferences such as navigation and display.

The View Instructions <NUM> include properties that are used for appearance purposes, such as fonts, colours, and shadows. The View Instructions <NUM> include common UI elements such as labels, buttons, lists, text fields, images, web-content containers, switches, and sliders. Some of these UI elements allow for user interaction, namely buttons or lists.

Each View Instruction <NUM> comprises a 'Layout <NUM>', alternatively called a 'Layout model <NUM>'. The Layout <NUM> is responsible for the coordination and appearance of the View Instructions <NUM>. Each View Instruction <NUM> further comprises a list of Child View Instruction models or Child View Instructions (not shown in <FIG>). The Child View Instructions are displayed within the Layout <NUM> (discussed in further detail below).

Each View Instruction <NUM> further comprises a list of 'Layout Instructions <NUM>', alternatively called 'Layout Instruction models <NUM>' or 'Layout View Instructions'. The Layout Instructions <NUM> include information required to apply a layout constraint on a view, e.g. to align, layout and display associated View Instructions <NUM> as applied to the UI elements of that screen For example, the Layout Instructions <NUM> indicate a Type 110a (e.g. width, height, aspect ratio), a Value 110b (e.g. <NUM> pixels), and a Priority 110c (e.g. a priority value on a layout constraint is used by a layout engine that solves a constraint satisfaction problem for User interfaces (see for example https://en. org/wiki/Constraint_satisfaction_problem , and https://en. org/wiki/ Cassowary_(software)). It is used to determine how important is the constraint when there is a constraint conflict). If the View Instruction <NUM> has API model and dataPath values, the Configuration instructs the data represented by the API model to be fetched and the value in the dataPath of the response to be applied to the View Instruction <NUM>.

The View Instruction <NUM> includes common UI elements such as labels, buttons, lists, text fields, images, web-content containers, switches, and sliders. Some of these UI elements allow for user interaction, namely buttons or lists. Therefore, the creator of the GUI can optionally set a target screen on a View Instruction <NUM> with which the app will show a Screen <NUM> from an existing Module <NUM> in its Configuration. In this way, Screens <NUM> can be displayed to a user in a navigation stack on the resulting client app.

Turning to <FIG>, a Data Layer <NUM> for use in creating an app using an embodiment of the present invention is shown. The Data Layer <NUM> may be referred to herein as a Data Layer model <NUM> or Data model <NUM>. The Data Layer <NUM> is created to represent Application Program Interface (API) requests. The UI Layer <NUM> uses the Data Layer <NUM> to populate itself with data.

The Data Layer <NUM> comprises an API model <NUM>. The API model <NUM> describes an HTTPS Request that is specified and configured by the creator. The HTTPS Request comprises a uniform source locator (URL) <NUM>. The URL <NUM> includes one or more URL components <NUM>. A URL component <NUM> can be added by the creator to the API model <NUM>. Each URL component <NUM> is associated with a Data Path API ID <NUM>, Contents <NUM>, a Data Path <NUM> and an API Key <NUM>.

With regard to the API Key <NUM>, an API model <NUM>, <NUM> might require information from a previous API model <NUM>, <NUM> to construct its URL <NUM>, <NUM>. The Data Path API ID <NUM> is used to identify the API response (APlltem) <NUM> that has already been pulled and cached, and in that data, by using the Data Path API ID <NUM>, it possible to obtain the value the API model <NUM>, <NUM> requires to construct the URL.

Once a HTTPS Request has been made and the data from its response has been received, the data is mapped into an APlltem model <NUM>. The APlltem model <NUM> includes a parent APlltem <NUM>, one or more children APlltems <NUM>, a value <NUM>, and a key property <NUM> (described in greater detail later).

A method of creating a Configuration using the Creator app <NUM> is shown in <FIG>, in accordance with embodiments of the present invention. Firstly, the creator specifies, at Step <NUM>, the position and layout of UI elements <NUM> within a new Configuration <NUM>. For example, this specification can be performed by the creator dragging UI elements <NUM> in an empty canvas. The creator then specifies, at Step <NUM>, the data that is required and should be obtained using one or more API requests <NUM>, whereby the one or more API requests <NUM> allow the required data <NUM> to be retrieved from a server, or sent to a server, which in the embodiment shown in <FIG> can be the config server <NUM>. The Creator app <NUM> receives the creator inputs provided in Steps <NUM> and <NUM>.

The Configuration <NUM> of the UI within the Creator app <NUM> comprises a UI Layer <NUM> and a Data Layer <NUM>, both of which have been introduced above and are discussed in further detail below. The Creator app <NUM>, updates, at Step <NUM>, the Configuration <NUM> based on the UI Layer <NUM> and the specification of the position and layout of the UI elements by the creator. As part of this step, the Creator app <NUM> implements the UI Layer <NUM> for the Layout <NUM> of each Screen <NUM>, for the list of Screens <NUM> within the Module <NUM> or app. The resulting Configuration <NUM> includes the Screens <NUM> and metadata for the app.

In addition, the Creator app <NUM> updates, at Step <NUM>, the Configuration <NUM> based on the Data Layer <NUM> and the specification of the data required in respect of the one or more API requests <NUM>. As part of this step, the Creator app <NUM> implements the Data Layer <NUM>. Subsequently, the Creator app <NUM> generates, as Steps <NUM> and <NUM>, Configuration <NUM> for the UI Layer <NUM> (including the UI element properties such as types, appearance, layout, screens) and the Data Layer <NUM> (including the API model), respectively.

Next, the creator connects, at Step <NUM>, the relevant UI elements <NUM> to the desired API data items <NUM>. The Creator app <NUM> receives the creator inputs provided in Step <NUM>. Subsequently, the Creator app <NUM> updates, at Step <NUM>, the data path of each APIL data item in the UI Layer <NUM>. Each time a UI element is to appear on the page, the Creator app <NUM> fetches the API data and provides, at Step <NUM>, the required API data item based on the specified data path.

The Creator app <NUM> then quantifies (converts), at Step <NUM>, the UI Layer <NUM> and the Data Layer <NUM> into a Configuration <NUM> and stores the quantified Configuration on the configuration server <NUM>. For example, the Creator app <NUM> can generate a JSON configuration for the app and store the JSON configuration on the server. For speed of loading, the JSON configuration is stored as raw binary data on the configuration server <NUM>. Following this, the Creator app <NUM> publishes (makes available), at Step <NUM>, the configuration. One further step (not shown in <FIG>, as it is not part of the configuration creation process), is the creation of the different generators 18a, 18b, 18c and storing them on the data store <NUM> of the App server <NUM> e.g. Apple's App Store or Android's Google Play Store, on behalf of the app creator. These generators 18a, 18b, 18c then become available for download at the respective devices <NUM>, <NUM>, <NUM>. It is also to be appreciated that the creator can use a creator app <NUM> on a new device (different to that of the creator device <NUM>) to preview the published configuration.

Once the generator 18a, 18b, 18c has been published on an app store <NUM>, it can be used by an app user on their device <NUM>, <NUM>, <NUM>. A method of using a generator 18a, 18b, 18c and the configuration <NUM> created using the method shown in <FIG> will now be described with reference to <FIG>.

Firstly, the user installs, at Step <NUM>, the UI generator 18a, 18b, 18c. Different versions of the UI generator 18a, 18b, 18c may be available depending on the type of device being used, e.g. phone, tablet, PC. The UI generator 18a, 18b, 18c fetches, at Step <NUM>, the quantified Configuration <NUM> from the server. In this embodiment, the Configuration <NUM> is obtained via a HTTPS web request from the configuration server <NUM>. As has been mentioned previously, the Configuration is typically between a few Kilobytes up to <NUM>-<NUM> Megabytes in size and, accordingly, is relatively small which facilitates faster data transfer of the Configuration file to the user device <NUM>, <NUM>, <NUM>. The Configuration <NUM> is stored on the user device <NUM>, <NUM>, <NUM>, typically in a designated space for the application's (generator's) documents.

In an embodiment an HTTP/HTTPs request is used to pull and post raw binary data between a device <NUM>,<NUM>,<NUM>, and the Configuration server <NUM> (also referred to as a 'backend system'). Those raw data, among other things, can represent encoded text in the form of JSON or XML. These are the primary and standard file formats that are used throughout computer systems to represent data in a human readable form.

When the creator app <NUM> wants to send configuration data to the backend system, it converts the Configuration Model being created into JSON format and then encodes it into raw binary data and sends that data to the backend system with an HTTPs request. Conversely, when a generator 18a, 18b, 18c wants to fetch the Configuration <NUM> from the configuration server <NUM>, it creates and executes an HTTP request and receives raw binary data. Those received data are then converted to JSON format text, which is then converted to the version of the Configuration <NUM> which can be understood by the specific generator 18a, 18b, 18c running in it specific operating system (native computing environment). This is the reverse process of the previous step of sending data to the Configuration Server <NUM>).

A configuration can be stored in any format on the config server <NUM>. For example, it could be stored as a JSON file. Alternatively, the Configuration <NUM> might be stored in a database on the configuration server <NUM> in the format of the database. Regardless of the way the configuration server stores the configuration <NUM>, the communication between the user device <NUM>, <NUM>, <NUM> will be the same as described above, namely using a raw binary data. For example, if the configuration server <NUM> stores the configuration in a database, the configuration server will fetch the data from the database, convert the data to JSON format, then to the JSON format data into raw binary data and then send it to the Generator 18a, 18b, 18c in response to a request from that Generator.

The Configuration <NUM> is fetched each time the user opens the application so that the latest changes can be displayed. Steps can be taken to determine if an existing Configuration on the device, has changes and only then fetch the updated configuration and this is explained below.

Each local configuration can have a property that is of type string and contains the hash key (SHA-<NUM> https://en. org/wiki/SHA-<NUM> ) of the changeset of the current revision. Namely, the Hash represents the current version of the Configuration file on the device. When a request for the latest version of the Configuration file is made, the hash key is also transmitted to the Configuration Server <NUM>. At the server, the hash key is compared with a hash key which has been generated of the latest stored version of the configuration in the data store <NUM>, namely the hash of the latest version of the Configuration. If the hashes are different then the latest Configuration will be pulled from the data store <NUM> and provided as a response to the request from the user device <NUM>, <NUM>, <NUM>. However if they are the same then there is no need to send back a copy of the configuration file as the user device already has the latest version. In this case, the Configuration server <NUM> just indicates this in the response to the user device,
As has been mentioned above, the Configuration <NUM> is fetched from the configuration server <NUM>, in the form of raw binary data which then are translated to JSON format and then converted to a Configuration model that the generator 18a, 18b 18c uses to create the GUI. JSON is one of the most commonly used types of data representation in web/mobile environments.

The UI generator 18a, 18b, 18c then applies, at Step <NUM>, the UI layout based on the UI Layer <NUM> of the Configuration <NUM>. The UI generator also fetches, at Step <NUM>, any associated API data <NUM> from the Internet, in this embodiment data <NUM> which is stored on the configuration server <NUM>, though any other sources of specified available data can be used. Lastly, the UI generator provides, at Step <NUM>, the API data item <NUM> based on the Data Layer <NUM> of the Configuration <NUM>.

The components of the UI Layer <NUM> and the Data Layer <NUM> will now be described in further detail with reference to <FIG>.

<FIG> illustrates an exemplary hierarchy tree structure of a View Instruction model <NUM> of the UI Layer <NUM>. The Creator app <NUM> launches itself with a root Module and each Module has a root Screen in its flow. Each Screen has a root View Instruction <NUM>. A tree of child View Instructions can be rendered and displayed recursively from the root View Instruction <NUM>. Thus, all View Instructions except for the root View Instruction have a parent View Instruction and a parent Layout. Each View Instruction in the tree structure represents a UI element <NUM>, and each View Instruction has a Layout.

As shown in <FIG>, in the present non-limiting embodiment, the root View Instruction <NUM> has a root Layout <NUM>. The root View Instruction <NUM> comprises three first generation child View Instructions <NUM>, <NUM>, <NUM>, whereby each of the first-generation child View Instructions <NUM>, <NUM>, <NUM> has its own Layout <NUM>, <NUM>, <NUM>. In addition, each View Instruction in the tree structure has a unique identifier or tag that is derived from its position in the tree structure. Namely, the root View Instruction <NUM> has a unique identifier of <NUM>. The first-generation child View Instructions <NUM>, <NUM>, <NUM> have tags of <NUM>, <NUM> and <NUM>, respectively.

Each of the three first generation child View Instructions (<NUM>, <NUM>, <NUM>) <NUM>, <NUM>, <NUM> comprises a plurality of second-generation child View Instructions and corresponding Layouts <NUM>. The second-generation child View Instructions are associated with unique identifiers according to their position in the tree structure. For example, the second-generation child View Instructions stemming from the first-generation child View Instruction <NUM> have unique identifiers of <NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM> and <NUM>. Two or more View Instructions may share the same Layout. For example, second generation child View Instructions <NUM>. <NUM> and <NUM>. <NUM> share a single Layout between them. Some View Instructions may not include their own Layout, for example second generation child View Instructions <NUM>. <NUM> and <NUM>. <NUM> do not include their own Layout. It is to be appreciated that a View instruction (parent) will have a layout if it has children view instructions, and the layout will be used to determine where the children are placed and how the co-exist within the parent's coordinate space in the user interface.

Some of the second-generation child View Instructions (<NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM>, <NUM>. <NUM>) comprise a plurality of third generation child View Instructions and corresponding Layouts <NUM>. The third-generation child View Instructions are associated with unique identifiers according to their position in the tree structure. Furthermore, one of the second-generation child View Instructions (<NUM>. <NUM>) comprises a fourth-generation child View Instructions and corresponding Layouts <NUM>.

The parent Layout of each child View Instruction, apart from the root View Instruction <NUM>, defines the positioning of each child View Instruction with respect to its parent View Instruction. The Layout is responsible for the coordination and appearance of the View Instructions. The unique identifier is used to apply layout constraints between the parent View Instruction and the child View Instructions, and between siblings within the child View Instructions.

Using this unique identifying system, all UI elements can be accessed and mapped in a hierarchical tree structure and the layout constraints and their sizing behaviour can be specified without prior knowledge of the contents of the Screen itself. Use of this hierarchical structure and inheritance of layout constraints obviates the need to individually code the appearance of each element of the GUI.

An exemplary View Instruction <NUM>,<NUM> and its UI element representation is shown in further detail in <FIG>. The View Instruction <NUM> comprises a View Instruction Type <NUM>. The View Instruction Type <NUM> defines the kind of UI element to be represented by the View Instruction <NUM> and is used by the Creator app <NUM> to create the UI element when the View Instruction <NUM> is about to be displayed on the user device display. For example, the type of UI element may include, but without limitation to, any of the following: Label, Text Field, Text View, Button, View, Web Container, Horizontal List, Vertical List.

The View Instruction <NUM> further comprises Contents <NUM>. Contents <NUM> includes static text content that is defined upon creation of the View instruction <NUM> by the creator of the Configuration <NUM>. Contents <NUM> may be used to populate the UI element represented by the View Instruction <NUM> with text data or image data (see also Contents <NUM>).

The View Instruction <NUM> also includes a Tag <NUM>. The Tag <NUM> is a unique identifier, e.g. a unique integer, that defines the View Instruction <NUM> in the View Instruction hierarchy (discussed above). The Tag <NUM> is used to position the UI element in relation to its sibling UI elements and its parent UI element.

Furthermore, the View Instruction <NUM> comprises a Target Screen Identifier <NUM>, or Target Screen ID <NUM>. The Target Screen ID <NUM> is a unique identifier, e.g. a unique integer, that describes an optional Screen as navigation target. When a user-driven user interface interaction occurs on the generator 18a, 18b, 18c by a user, the method of the present embodiment searches for a Screen with the same identifier, and presents the new Screen in a navigation stack of the generator.

In addition, the View Instruction <NUM> comprises a list of Properties <NUM>, or a 'Properties Model <NUM>'. The Properties model <NUM> describes the appearance of the UI element represented by the View Instruction <NUM>. The Properties model <NUM> is able to describe any UI element property that exists currently in a computer system. The system translates the UI element property <NUM> and applies it to the UI element. The properties may be similar between different computer platforms and may be added/removed and adjusted based on the platform.

In some embodiments, most View Instruction Types <NUM> share a list of common properties, but some Types of View Instruction <NUM> may include properties that are specific to the UI element. As an example, the Label and Horizontal List View Instruction Types <NUM> share the following common properties: background colour, border width, shadow. However, the Horizontal List View Instruction Type <NUM> may also include properties unique to the UI element, e.g. selection style, headers/footers, show scroll indicators.

Each Property <NUM> has a Name <NUM>, a Property Type <NUM>, and Contents <NUM>. The Name <NUM> of the Property <NUM> is displayed on the UI generator 18a, 18b, 18c. In embodiments, the Name <NUM> cannot be edited by the creator of the Configuration <NUM>. The Property Type <NUM> provides a description of the Property <NUM>. Exemplary Property Types <NUM> include, but are not limited to, the following: Background colour; Font; Border Width; Border Colour; Content Mode (for scaling purposes etc.); Corner Radius. As described in the previous paragraph, some Property Types <NUM> may be unique to the UI element. Further examples of such unique Property Types <NUM> may include: Text colour; Text alignment; Number of lines. The number of Property Types <NUM> that can be present in the Configuration is unlimited and can vary from one computing device to another. The Contents <NUM> comprise the value of the Property <NUM> that is used when the computing device applies the translated Property <NUM> to the UI element. The value of the Contents <NUM> may comprise text, number, Boolean. Some text value Contents may be translated to define colour, font, or image such that the translated colour, font or image is applied to the UI element.

A View Instruction <NUM>, <NUM> along with its Layout <NUM>, <NUM> and Layout Instructions <NUM>, <NUM> will now be described in further detail with reference to <FIG>. The relationship between a View Instruction <NUM>, <NUM> and the layout and positioning of a UI element represented by the View Instruction <NUM>, <NUM> when it is displayed on a display of the user device <NUM>, <NUM>, <NUM> is described, in accordance with embodiments of the present invention.

An exemplary View Instruction <NUM>, analogous to that shown in <FIG> as View Instructions <NUM>, and its corresponding Layout <NUM>, which is analogous to the Layout <NUM> shown in <FIG>, are shown in <FIG>.

The View Instruction <NUM> comprises a Layout <NUM>. The Layout <NUM> is responsible for the coordination and appearance of the View Instruction <NUM>. More specifically, the Layout <NUM> provides the information required for the positioning of the UI element representation of its View Instruction <NUM> within the coordinate system (boundary) of the UI element representation of the parent View Instruction. In some embodiments, the Layout <NUM> may have reference to a reusable View Instruction (not shown) if the Layout's parent View Instructions <NUM> is of collection type (a collection type is a horizontal or vertical scrollable list that displays a set of UI elements). The Layout <NUM> is linked to a plurality of child View Instructions.

In many cases when a View Instruction <NUM> is of collection type (i.e. horizontal or vertical list), the number of UI elements contained in that list can be large (actually the exact number is not known as this information is coming from an API data request <NUM>). Therefore, the reusable View instruction is used to display those items in the layout of a collection View Instruction.

A simple example of a reusable View instruction can be seen on an email app on a smartphone. The email items have the same UI element (also referred to as a UI element container), with the same layout. That list has a specific UI container that is reused and displays different data for each email. Same logic applies on the Layout with its reusable view instructions.

The View Instruction <NUM> further comprises a Layout Instruction <NUM>, or 'Layout View Instruction <NUM>', or 'Layout Instruction model <NUM>'. The Layout Instruction <NUM> includes information required from the Layout <NUM> to position the UI element that is represented by the View Instruction <NUM> correctly within its coordinate system, with respect to its parent UI element <NUM> and its sibling UI elements. The Layout Instruction <NUM> effectively applies a layout constraint on a view, e.g. to align, layout and display the View Instruction <NUM>.

In the present embodiment, the Layout Instruction <NUM> indicates a Type property 610a, which is used to determine which UI layout constraint to apply to the UI element that is represented by the parent View Instruction <NUM>. It is to be appreciated that whilst <FIG> only shows a single Layout Instruction <NUM> associated with a View Instruction <NUM>, typically this is one element of a list of Layout Instructions <NUM> as is shown in <FIG>. A layout instruction can be applied either solely on the view instruction or between two view instructions. If for example the layout instruction is of type "width" or "height" it will be applied to the view instruction itself. If on the other hand the layout instruction is of type top/leading/trailing/bottom/center, it is being applied to two view instructions, therefore the receiver is the second view instruction. Examples of the Type property 610a include but are not limited to the following: Top (top margin from the receiver); Leading (left margin from the receiver); Trailing (right margin from the receiver); Bottom (bottom margin from the receiver); Width (width of the UI element); Height (height of the UI element); CenterX (the margin from the x-axis of the receiver); CenterY (the margin from the y-axis of the receiver); EqualWidths (equal width to the receiver); EqualHeights (equal height to the receiver); Horizontal Margin (the horizontal margin from the receiver); Vertical Margin (the vertical margin from the receiver); and Aspect Ratio (the aspect ratio fraction to the size of the receiver).

The Layout Instruction <NUM> also indicates a Value property 610b, which has a numerical value. The Layout <NUM> uses the contents of the Value property 610b, e.g. <NUM> pixels, to apply the corresponding layout constraint to the UI element. The Layout Instruction <NUM> further comprises a Priority property 610c, which has a numerical value. The Priority property 610c indicates the importance level of the Layout Instruction <NUM> compared to other constraints, in case of a constraint conflict. The default value is <NUM>. The system will not apply the conflicting layout constraint that has the lowest priority value.

The Layout Instruction <NUM> further comprises a FromVITag 610d, or From View Instruction Tag 610d, which is the identifier of the View Instruction <NUM> that the layout constraint is to be applied to. The Layout Instruction <NUM> further comprises a ToVITag 610e, or To View Instruction Tag 610e, which is the identifier of the target View Instruction <NUM> for the Layout Instruction <NUM>. The FromVITag represents a View Instruction (its tag) and the ToVITag the receiver View Instruction. The ToVITag 610e applies only to certain types of Layouts, such as leading, trailing, top, bottom, horizontal/vertical, margins, aspect ratio, etc..

The Layout Instruction <NUM> further comprises a FromEdge property 610f, which indicates the type of edge from which the layout constraint is to be applied. For example, the type of edge may be top, left, right or bottom. Also, the Layout Instruction <NUM> comprises a ToEdge property <NUM>, which indicates the type of edge from which the layout constraint is to be applied. For example, the type of edge may be top, left, right or bottom. It is to be appreciated that the FromEdge and ToEdge properties both provide information on which edge of the receiver the layout instruction constraint is applied to. For example, a layout instruction of leading is applied between two View instructions, A and B. The layout instruction will have FromEdge the right edge of A and ToEdge the right edge of B.

The Layout Instruction <NUM> further comprises a Factor property <NUM>, which has a numerical value. The Layout <NUM> uses the value of the Factor property <NUM> to multiply the value of the receiver's constraint, to obtain a value for the layout constraint to the be applied. The default value is <NUM>. The Factor property <NUM> may be applicable to certain types of constraints, e.g. width, height, or aspect ratio.

The UI element representations of the plurality of child View Instructions will be placed within the Layout's <NUM> parent UI element representation, using the information is that provided by the corresponding Layout Instructions <NUM>.

The structure and properties of the API model and the URL model of the Data Layer <NUM> will now be described in further detail with reference to <FIG>.

The Data Layer <NUM> comprises an API model <NUM>, <NUM>, a URL model <NUM>, <NUM>, and one or more URL components <NUM>, <NUM>. The Data Layer <NUM> may comprise a plurality of API models <NUM>, <NUM>. Each API model <NUM> comprises the information required from any programming language to construct a URL request that will fetch the requested data from any server that the creator of the Configuration <NUM> has access to. Properties of the API model <NUM> are as follows. The API model <NUM> describes a Hypertext Transfer Protocol (HTTP) method <NUM>, which is a request-response client-server protocol. This HTTP method is used by the URL request to send a request message to a HTTP server, and in turn to receive a response message. The HTTP method can include, for example, 'GET' (retrieve data), 'PUT' (retrieve and store data), 'POST' (accept the data for storage). The API model <NUM> also describes a Universal Unique Identifier (UUID) <NUM>. The UUID is a random <NUM>-bit number that is generated to specify an API model uniquely in the Configuration. The UUID is used to cache the data that is returned once a URL request has been executed using the API model <NUM>.

The API model <NUM> has a one-to-one relationship with the URL model <NUM>. The URL model <NUM> provides the URL information necessary to fetch the required data and thereby includes a reference to a web resource. The URL model <NUM> constructs the required URL using a plurality of URL components <NUM>. The URL components <NUM> comprises the data that forms a URL. Namely, the URL components <NUM> include: (i) an API Key <NUM>; (ii) Contents property <NUM>; (iii) a Data Path API Identifier <NUM>; and a Data Path <NUM>.

The API Key <NUM> is used to specify the type of data that is included in the Contents property <NUM> and will be part of a URL in the format: "https://www. com/?<API Key>=<Contents>".

The Contents property <NUM> comprises any form of text data that is required to create a URL request. This data can be provided by manual input by the creator of the Configuration <NUM>. Alternatively, this data may be provided to the Contents property <NUM> from the system when using the Data Path <NUM> and Data Path API Identifier <NUM> properties.

The Data Path API identifier <NUM> is used to identify the response from a request that has already been executed or to trigger a new request for the API with the corresponding response from an already executed request. The creator of the Configuration <NUM> can include multiple URL requests in a chain of URL requests, and data from a first URL request can be used to construct a subsequent second URL request. In some embodiments, the first and second URL requests may be constructed simultaneously. Alternatively, the first and second URL requests may be constructed on different UI Screens. In this example Screen <NUM> can create and execute a URL request. The data will be cached within the application (generator). When Screen <NUM> is displayed its API will generate a second URL request using data provided by the first URL's response which are cached, using the Data Path API Identifier <NUM>.

The Data Path <NUM> is provided as input to the URL component. The Data Path <NUM> is a text description of the path of the API response associated with a particular Data Path API Identifier <NUM>.

Once a URL request has been made and the data from its response has been received, the data is mapped into an API Item model <NUM>, or 'API Item <NUM>', which is analogous to the API Item model <NUM> shown in <FIG>. The properties and usage of an API item in relation to the UI and Data layers will now be described in further detail with reference to <FIG>.

The API Item <NUM> is used by the View Instruction <NUM> to display data in a UI element. The API Item <NUM> describes any type of data structure that can be sent to or received from an external database or a URL request. For example, the API Item <NUM> may describe data structures such as lists, has tables, trees, or linked lists.

The API Item <NUM> comprises a Value property <NUM> and a Key property <NUM>. The Value property <NUM> indicates the type of the API Item <NUM>. The following types can be used: text, numeric, Boolean (true/false), List (collection) or Hash Table (collection). If an API Item <NUM> has a value of type List or Hash Table, then the API Item <NUM> comprises child API Items. The View Instruction <NUM> uses the Value property <NUM> of an API Item <NUM> and displays the content of the API Item <NUM> in the UI elements represented by the View Instruction <NUM>. The Key property <NUM> is a text property that is populated in the event that the parent API Item has a Value property <NUM> of a Hash Table. The Key property <NUM> is used to create the Data Path. In use, the Key property <NUM> of a list API Item <NUM> will be used when the View Instruction <NUM> is of a collection type (horizontal or vertical). For a regular API item, the Data path value <NUM> will be calculated recursively towards the parent until a parent is a list (that key will not be included on the data path).

If the Value property <NUM> is of type List (collection) or Hash Table (collection), the API Item <NUM> can include a plurality of child API Items (not shown in <FIG>), and any child API Item has a reference to its parent API Item. This creates a recursive tree structure. View Instruction <NUM> uses a Data Path to populate the represented UI element with data according to the Data Path. The Data Path uniquely identifies a specific API Item within the data structure. It should be noted that a root API Item <NUM> will not have a parent API Item <NUM>.

The API Item <NUM> further comprises a Runtime Identifier <NUM>. This is a random <NUM>-bit number that is generated to specify uniquely an API Item <NUM> when the View Instruction <NUM>, with which its Data Path is associated, uses functionality that is described by a Feature (Features are discussed in detail below). For example, a Basket Feature requires the Runtime Identifier <NUM> to uniquely identify the items that have been added to a basket and are selected for display in a basket list screen.

An example of the API Item tree data structure described above is shown in <FIG>.

Any data response from a URL request is mapped onto an API Item tree as shown in the example. The data responses may be in JSON or XML format, or any alternative suitable data format. As an example, a data response in JSON format is shown.

More specifically, <FIG> explains how JSON data are converted to APlltem models. A JSON structure has a root element which is either dictionary or an array of dictionaries, which have keys and values. These values can be of type text, numeric or key-value dictionaries or arrays of key-value dictionaries, and so on.

This gets translated to the API model which has key values (which can be empty/null) and children (if the value is a dictionary or an array of dictionaries). If the APlltem has a key and a value that is of type text or a number, that means that the APIItem is a leaf on the data structure tree and has no children. If the APIItem's value is of type dictionary or array of dictionaries, then the APlltem will have children APIItems.

Each APlltem has a runtime identifier property which is used to uniquely identify the specific instance between any that have been generated in the runtime of the application.

As outlined above, a View Instruction <NUM> represents a UI element. The View Instruction <NUM> comprises properties that represent the appearance of the UI element, including several properties that relate to the Data Layer <NUM>. As shown in <FIG>, properties of the View Instruction <NUM> that relate to the Data Layer <NUM> include an API Identifier <NUM>, a Data Path <NUM>, and Contents <NUM>. The API Identifier <NUM> is a UUID property that is used by the View Instruction <NUM> to indicate which API <NUM> the View Instruction <NUM> is expecting to receive data from. The Data Path <NUM> is a text property that describes the path of the data that is provided in the API response, whereby the API is associated with the API Identifier <NUM>. Contents <NUM> is a text property that is used by the View Instruction <NUM> to populate the UI element with data that is not provided from an API model. The data may be text data or image data.

In the present embodiment, a plurality of View Instructions <NUM>, <NUM> are represented on the display of the user device as UI elements. If any of the View Instructions comprises an API Identifier <NUM>, the generator in combination with the Configuration <NUM> first searches, at Step <NUM>, the cache of received API responses from any previous API requests for an API response associated with the API Identifier <NUM>. The cache comprises a list of received responses from previously executed API requests. The Creator app determines, at Step <NUM>, whether a cached API response associated with the API Identifier <NUM> has been located. If a cached API response associated with the API Identifier <NUM> is located, then the process continues to search, at Step <NUM>, for the API Item <NUM> that matches the contents of the Data Path that is included in the API response. The Creator app then applies, at Step <NUM>, the contents of the API Item <NUM> to the UI Element that is represented by the View Instruction.

However, if a cached API response associated with the API Identifier <NUM> is not located at Step <NUM>, then the process continues to search, at Step <NUM>, available APIs in the Configuration for an API associated with the API Identifier <NUM>. The generator determines, at Step <NUM>, whether an API associated with the API Identifier <NUM> has been found. If an API associated with the API Identifier <NUM> is found, then the process continues to execute, at Step <NUM>, the URL request that is described by the API found in Step <NUM>. The generator then receives and caches, at Step <NUM>, the response that is received as a result of the URL request. The generator then proceeds to perform the process from Step <NUM>, namely behaving as if the cached response had been found. If a matching API is not found at Step <NUM>, the process continues to Step <NUM>, and the application (generator) applies the value that is on the "contents" property of the View Instruction for that UI element. It is to be appreciated in this regard that each UI element upon its creation by the creator has a default value on the property "contents" which can be changed by the creator from within the application. If after Step <NUM> no matching API is found, then the contents of the UI element will have the value which is stored on the "contents" property.

At the end of the process shown in <FIG>, the contents of the API Item <NUM> are applied to the UI element that is represented by the View Instruction. If the UI element is a text container, a text content is applied to the UI element. If the UI element is an image container, the contents of the API Item are used to generate an image URL request for the image data. Once the requested image data is received, the received image content is applied to the UI element. If the UI element is a list container, the Value property <NUM> of the API Item <NUM> is used and if the Value property <NUM> has a list type, then the list of items contained in the Value property <NUM> is applied to the UI element. Each item in the list is passed onto the reusable View Instruction and the process shown in <FIG> is repeated recursively for the tree structure of the View Instructions.

The Configuration <NUM>, which may also be referred to as the Application Configuration, or Configuration File, that is created by a creator using the creator app <NUM>, and that is subsequently executed by the UI generator 18a, 18b, 18c to generate Configuration model instance (or Application Configuration model instance) which in turn is used to generate a UI, will now be described in further detail with reference to <FIG>. The Configuration <NUM> comprises all of the information that is required by the UI generator 18a, 18b, 18c to generate the Configuration model instance which in turn defines the UI. In this embodiment the Configuration <NUM> is stored in a data store <NUM> of the configuration server <NUM>, though it could be stored on any server so long as the generators 18a, 18b, 18c know where to access it. Accordingly, the Configuration <NUM> is accessible by the creator app <NUM> as well as all of the UI generators 18a, 18b, 18c, as described above with reference to <FIG>. The creator may create multiple Configurations <NUM> using different accounts of the same creator app <NUM>, and switch between the Configurations <NUM> as appropriate.

The Configuration <NUM> comprises an Active property <NUM>, an Identifier property <NUM>, and a Name property <NUM>, as shown in <FIG>. The Active property <NUM> describes whether the Configuration <NUM> is the active one amongst all of the Configurations <NUM> that the creator has created using the creator app <NUM>. The Active property <NUM> also describes the Configurations <NUM> that are accessible by the UI generators 18a, 18b, 18c. The Identifier property <NUM> is a unique identifier that describes a specific Configuration <NUM> among all of the Configurations <NUM> that the creator has created using the creator app <NUM>. The Name property <NUM> comprises a name that describes the Configuration <NUM>, whereby the name is defined and editable by the creator for the purpose of distinguishing between Configurations <NUM> easily.

The Configuration <NUM> further comprises a Screen Container <NUM>. The Screen Container <NUM> is a model that describes the container of the root or default Screen <NUM> of a Module <NUM> (see <FIG>), as well as the navigation type between Screens <NUM> of the Module <NUM>. The navigation types vary between different user device types and operating systems. Whilst the Configuration is usable universally by all devices, the types will be interpreted differently on the different operating systems. An example would be that a navigation type of "push", on iOS would cause a screen to appear from the right onto a navigation stack and on Android would cause a screen to overtake the current screen as a presented overlay. A navigation container (not shown) is used to describe the navigation types. The Screen Container <NUM> comprises the information that is required to generate the correct navigation container in which the Screen <NUM> will exist when the Screen <NUM> is displayed in the UI of the particular user device <NUM>, <NUM>, <NUM>.

Each Screen Container <NUM> comprises a Type <NUM>. The Type <NUM> of the Screen Container <NUM> varies between different operating systems and the navigation types between the different operating systems. The Type <NUM> is therefore described by the corresponding navigation container. By way of non-limiting examples only, the Type <NUM> of the Screen Container <NUM> may include a Navigation Bar or a Tab Bar.

Each Screen Container <NUM> further comprises a Title <NUM>. The Title <NUM> comprises a title that describes the Screen Container <NUM>, whereby the title is defined and editable by the creator for the purpose of distinguishing between Screen Containers <NUM> easily.

<FIG> shows the Module <NUM> and the Screen <NUM> of the Configuration <NUM> in further detail. The Module <NUM> is a model that describes a logic group of Screens <NUM>. A Configuration <NUM> may have multiple Modules <NUM>. A Screen <NUM> can redirect to another Screen <NUM> associated with the same Module <NUM> or to another Screen <NUM> that is associated with a different Module <NUM>. The Module <NUM> comprises a Boolean property <NUM>, referred to as 'isRoot <NUM>' in <FIG>, that describes whether the Module <NUM> is the root Module of the Configuration <NUM>. The root Screen of the root Module will be the first Screen <NUM> to be rendered and displayed on the UI when the UI is generated by the UI generator 18a, 18b, 18c. Accordingly, when a Module <NUM> is started or where the Module <NUM> is the root Module of the Configuration <NUM>, the root Screen will be displayed. The Module <NUM> further comprises a Module Name <NUM> that describes the Module <NUM>, whereby the Module Name <NUM> is defined and editable by the creator for the purpose of distinguishing between Modules <NUM>.

In the present embodiment, there is an unordered list of Screens <NUM> within the logic group of the screens of the Module <NUM>. The Screens <NUM> are created by the creator using the creator app <NUM>. The Screens <NUM> can redirect to other Screens <NUM> within the same Module <NUM>, or to Screens <NUM> of different Modules <NUM> within the same Configuration <NUM>. The Screen <NUM> is a model that contains all the information that is needed for a UI generator 18a, 18b, 18c to display the contents of the Screen <NUM> on the UI. Each Screen <NUM> comprises a root View Instruction property. The root View Instruction property is used to display the view hierarchy tree of the UI elements in the Screen <NUM>, as described above with reference to <FIG>.

Each Screen <NUM> comprises an Identifier property <NUM>. The Identifier <NUM> is a UUID, e.g. <NUM>-bit UUID, that uniquely identifies the Screen <NUM>. The Identifier property <NUM> is used for the purpose of navigating between Screens <NUM>. Namely, the Identifier property <NUM> is used by the View Instruction <NUM> as a Target Screen Identifier <NUM>, as shown in <FIG>, when the UI element that is represented can have user interactions, such as tap or swipe. Furthermore, each Screen <NUM> comprises a Screen Name <NUM> that describes the Module <NUM>, whereby the Screen Name <NUM> is defined and editable by the creator for the purpose of distinguishing between Screens <NUM>.

Each Screen <NUM> further comprises a single root View Instruction that is used to display the UI elements when the Screen <NUM> is first displayed. Each View instruction <NUM> comprises a Feature Identifier <NUM> and a Feature Action Identifier <NUM>. The Feature Identifier <NUM> comprises a unique identifier that represents each Feature type. The Feature Action Identifier <NUM> comprises a unique identifier that represents each Feature Action type. The View Instruction <NUM> uses the Feature Identifier <NUM> and the Feature Action Identifier <NUM> to determine the functionality of the UI element that is represented by the View Instruction <NUM>. Features and Feature Actions are discussed below with reference to <FIG>.

As shown in <FIG>, the Configuration <NUM> comprises a plurality of Features <NUM> and a plurality of Feature Actions <NUM>. A Feature <NUM> is a model that represents a logic component that can be enabled or disabled on a Configuration <NUM> by the creator of the creator app <NUM>. The Feature <NUM> provides a certain closed functionality to the UI generator 18a, 18b, 18c. By closed functionality, it is meant a pre-defined business logic that is currently not available for modification. Certain Feature Actions of that feature can be turned on or off if they are not critical for the feature. An example would be a Payment feature which has the following functionalities: <NUM>. Basket list, <NUM>. Add/Remove products, <NUM>. Checkout, <NUM>. Previous Order, <NUM>. Add payment option, etc. The Feature <NUM> is configurable by the creator and is predefined. An example of a Feature <NUM> is a Basket feature, which enables a user of the UI generator 18a, 18b, 18c, which is provided as a downloadable application for the user device, to add items or products to a basket and then to 'checkout' by performing a payment transaction to pay for the items in the basket.

Each Feature <NUM> comprises a Feature Identifier <NUM> and a Boolean property <NUM>, also referred to herein in as 'Feature isEnabled <NUM>'. The Feature Identifier <NUM> is a UUID, e.g. <NUM> bit UUID, that uniquely identifies the Feature <NUM>. The Feature Identifier <NUM> is shared with all Configurations <NUM> and is used to determine which of the logic groups will be used when a Feature <NUM> is enabled and used within a View Instruction <NUM> to display a certain functionality. The 'Feature isEnabled' <NUM> property describes whether a Feature <NUM> is enabled and thus whether the Feature <NUM> can be used within a UI representation of a Configuration <NUM>.

A Feature Action <NUM> is a model that describes a piece of functionality within a logic group that is described by a Feature <NUM>. As with the Feature model <NUM>, the Feature Action <NUM> is predefined and can be enabled or disabled by the creator. Any Feature Actions <NUM> that are enabled can be used by a View Instruction <NUM> to perform a certain functionality (e.g. showing items of a basket as described above) or to perform a certain action (e.g. adding items to a basket as described above).

Each Feature Action <NUM> comprises a Feature Action Identifier <NUM> and a Boolean property <NUM>, referred to herein as 'Feature Action isEnabled <NUM>'. The Feature Action Identifier <NUM> is a UUID, e.g. <NUM>-bit UUID, that uniquely identifies the Feature Action <NUM>. The Feature Action Identifier <NUM> is shared with all Configurations <NUM> and is used to determine which of the logic groups will be used when a Feature Action <NUM> is enabled and used within a View Instruction <NUM> to display or perform a certain functionality. The Feature Action isEnabled <NUM> property describes whether a Feature Action <NUM> is enabled and thus whether the Feature Action <NUM> can be used by a View Instruction <NUM>.

<FIG> show a series of screenshots depicting steps that a creator may take whilst using the creator app <NUM>. Examples of how the creator can use the creator app <NUM> on the creator device <NUM> to specify or design a GUI <NUM> having a particular layout of graphical elements <NUM> and to specify the data which is to be pulled into the GUI <NUM> are shown. The specification of the GUI is thus provided in the Configuration <NUM>. Therefore, the creator app <NUM> functions to enable relatively easy creation of GUIs by creators who have no previous programming knowledge.

The creator begins by downloading the creator app <NUM> from the application server <NUM> (in this embodiment) onto the creator device <NUM>. As shown in <FIG>, the creator logs in, at Step <NUM>, via a Login page. The creator then selects, at Step <NUM>, a Configuration <NUM> ("Configuration-<NUM>"). The creator then adds, at Step <NUM>, a Module <NUM> to the Configuration <NUM>. After a Module <NUM> has been added, the creator adds, at Step <NUM>, a Screen <NUM> to the Module <NUM>. In order to add UI elements to the Screen <NUM>, the creator selects, at Step <NUM>, the "Enable" option on the Screen <NUM>. If desired, the creator can select, at Step <NUM>, the "Disable" option on the Screen <NUM> to prevent any further UI elements from being added to the Screen <NUM>.

In "Enable" mode, the creator then drags, at Step <NUM>, a UI element from a list of available UI elements onto the Screen <NUM>. The selected UI element is of a UI element type which has been selected from a commonly used element types (such as Label, Image Container, Text Field, Button, etc.). The creator then drags, at Step <NUM>, the edges of the selected UI element to resize it. Once the UI element has been created, the creator applies, at Step <NUM>, layout constraints to the UI element. For example, the creator can specify the width, height and/or aspect ratio of the UI element. The creator can also specify that the UI element is aligned with the top, left, right and/or bottom edges of the Screen <NUM> (as shown in <FIG>), or specify that the width of the UI element should equal its height, or vice versa, or apply a layout constraint to position the UI element at the center of the Screen <NUM>.

Once the layout constraints have been applied, the creator enters, at Step <NUM>, the API selection area of the creator app <NUM>, as shown in <FIG>. At this stage, the creator adds, at Step <NUM>, an API request. As part of adding the API request, the creator defines, at Step <NUM>, API input parameters, such as a URL. The creator then executes, at Step <NUM>, the API request and receives a API response accordingly.

As shown in <FIG>, the data is then presented as a list <NUM> within the Screen. The creator then adds, at Step <NUM>, a reusable View Instruction and enables, at Step <NUM>, the reusable View Instruction such that UI elements can be included within it. Next, the creator drags, at Step <NUM>, an image UI element into the reusable View Instruction, and applies, at Step <NUM>, layout constraints to the image UI element in order to resize it as desired.

The next step for the creator is to select the API for the image UI element and simultaneously set up the View Instructions properties. The creator selects, at Step <NUM>, an API from stored API configurations. The creator then executes, at Step <NUM>, the selected stored API configuration. After receiving the API response, the creator expands, at Step <NUM>, the API response. From the API response data, the creator selects, at Step <NUM>, the API item for image contents, such that the image data can be used within the reusable View Instruction, as shown in the next screenshot.

The creator can then proceed to add, at Step <NUM>, a second screen, as shown in <FIG>. As per Steps <NUM> to <NUM> as applied to the first screen, the creator creates, at Step <NUM>, a list UI element and applies appropriate layout constraints to the list UI element. The creator then adds, at Step <NUM>, a secondary API with a URL component.

Next, the creator selects, at Step <NUM>, the origin API model for the secondary API having the URL component, and subsequently selects, at Step <NUM>, the API item from the origin API model for the secondary API having the URL component. Once the API item has been selected, the creator executes, at Step <NUM>, the secondary API. The creator then selects, at Step <NUM>, the API item for the list UI element from the secondary API response. A preview of the Configuration is then shown (Step <NUM>) and a second screen is shown (Step <NUM>) with data after selecting an item in the root screen. Configuration settings can then be viewed and amended accordingly.

The creator then selects, at Step <NUM>, a target module for the UI element, and subsequently selects, at Step <NUM>, a target screen for the UI element, as shown in <FIG>. The creator edits, at Steps <NUM> and <NUM>, the UI element properties. Lastly, the creator selects, at Steps <NUM> and <NUM>, the desired marketing option, e.g. Facebook Audience Network, where the selected marketing option can be configured at Step <NUM>.

In a further embodiment of the present invention, it is possible to make the interface with the creator even simpler to use. Rather than the creator physically interacting with the creator app <NUM> to manually place UI elements on a canvas and define child/parent relationships between UI elements, it is possible for the creator to hand draw a structural diagram of the UI elements and their relationships in a similar manner to that shown in <FIG> and then to use a mechanism which uses machine learning to identify the images and use then to construct the data structure of the UI. The mechanism would typically be an application on the creator device <NUM> which captures images of hand drawn diagrams and then uses a vision shape algorithm to determine the UI elements hierarchy. Once this structure had been determined, the Data Layer of the Configuration <NUM> could be created by use of a parser which would create the parent/child relationships from the relationships determined by the vision shape algorithm. The specific data which is to be fetched for each UI element would still need to be specified, as would the appearance and position of each UI element, but complicated Uls which have multiple hierarchical layers child UI elements could therefore be created much more easily.

In a further embodiment, the creator application has an additional testing functionality. This embodiment provides a mechanism to test possible user experience (UX) flows in an application. As such the mechanism proceeds to check all possible user interaction pathways using the UI and then reports back on any problems encountered for the user. It can also provide feedback on how much time an effort it took the user to achieve a certain task such as a 'checkout' from a website (number of clicks required and time it takes to achieve task). The results of such testing enable the creator to get feedback and have testers/collaborators perform tasks that will identify problems in the UX/UI that has been created and added as designs into the system. This enables the creator to identify which UI flows are problematic or not, and which Uls are more suited for the type of the application that they are creating.

Claim 1:
A method of creating a configuration file (<NUM>) for use in generating a page of a computer-generated user interface (UI) (<NUM>), the configuration file (<NUM>) representing a data model and describing a plurality of UI elements of the UI and their appearance within the page of the UI, the configuration file (<NUM>) comprising a UI Layer (<NUM>) for specifying the plurality of UI elements which each comprise Screens (<NUM>) and View Instructions (<NUM>) which define the appearance and functionality of each of the UI elements to be configured and displayed and a Data Layer (<NUM>) for specifying, for each of the plurality of UI elements, a respective remote location of data to be obtained to populate the UI element, each Screen (<NUM>) comprising a model representation of all of the elements that are required for an accurate display of the UI on the page and the Data Layer (<NUM>) comprising a plurality of data retrieving models; the method comprising:
Selecting (<NUM>) a UI element from a plurality of icons of UI elements displayed on a graphical user interface;
Positioning (<NUM>) the selected UI element on a canvass that represents the page;
Configuring the appearance of the selected UI element on the canvass;
Updating (<NUM>) a configuration file (<NUM>) based on the position and configuration of the selected UI element on the canvass;
Defining data (<NUM>) to populate the selected UI element by specifying a remote communications address where the data is to be fetched from;
Updating (<NUM>) a data retrieving model of the plurality of data models in the Data Layer (<NUM>) with the remote communications address where the data is to be retrieved from; and
Linking together (<NUM>) the data retrieving model and the selected UI element such that, in use, data obtained via the data retrieving model can be used to populate the selected UI element linked to that data retrieving model in the Data Layer (<NUM>) when generating the UI (<NUM>).