Design Drivers

A list of design drivers was originally written to provide a clear and concise definition of the primary objectives for the Fluidapps design. These design drivers lead to the discovery and patent of the technology behind the application.

The following is a list of the design drivers used during the Fluidapps design process:

Simplify Software: The application must eliminate the need to build volumes of complicated code. This will reverse the trend of monolithic applications; simplify software; provide a better platform for agility and flexibility; and most of all, provide technology resilience.

Web-Enabled: The client-side application must operate within all of the leading web browsers in order to take advantage of existing web browser technology.

Small Footprint: The client, application server and database must fit and operate on a PC for the initial installation.

Consistency: The user navigation, layout and functionality must be brutally consistent across all forms.

Intuitive Navigation: The application must have an intuitive navigational environment, similar to spreadsheets, with an intuitive spiral learning process. The spiral learning process will provide the user with the ability to become immediately productive with little expertise, building more and more expertise as needed in a simplistic and intuitive way.

Flexibility: The application must provide the ability to alter or enhance exiting forms with ease, along with the ability to create new forms by copying and modifying existing forms. The process to add, change or delete columns, alter data selection and change layout and functionality must be simple, consistent and intuitive. In addition, forms must automatically change based on the user and where the form was accessed.

Security: The access to forms and the ability to view, add, change and delete data within all forms, along with the ability to copy and alter forms, must be based on the user definition. Form and data access, visibility and functionality must be automatic, based on the user accessing the form and the point from where the form was accessed. Security must be carried down to the cell level. The control of security must be at a high level. For example, the visibility of a specific product cost might be automatically allowed to only a few individuals and blocked for all of the other users, even though the product cost column is on a variety of forms.

Scalability: The application architecture must allow full scalability, starting with a PC implementation, to a large scale, industrial strength, distributed, and multi-tiered application. To support this design driver, the application must operate on all of the leading operating systems and connect to all of the leading databases with the ability to migrate data between databases.

Relational: The application must be relational in three aspects. First, data relational integrity must be brutally maintained automatically across the entire enterprise application. This means if a specific parent data cell is deleted, all related child records to the parent must also be automatically deleted with the appropriate warnings. Second, whenever a column of data is deleted, all related child columns and data must also be automatically deleted with the appropriate warnings. Third, forms must naturally be related together via data relationship links, providing the ability to zoom up and down parent and child data links from any data cell.

High Data Visibility: All forms must have a consistent multi-record, scrolling layout, with the ability to change fonts and toggle to a single record layout while on a specific row.

Independence: The application must be designed to be independent of hardware, operating systems and databases. In addition, the application must be independent of computer languages by providing the ability to use standard computer languages when it is necessary to extend functionality, including data validations and events.

Upgrade Friendly: The application must be designed to automatically capture, track and classify all changes to the enterprise application, and use this change history when applying patches and upgrades to the application.

Optimum Performance: The design of the application must optimize performance at the client level by providing a quick response time for the opening of forms through the reduction of network traffic and server resources.

Design Challenge

The design challenge behind the Fluidapps project was to resolve the opposing objectives of simplicity, flexibility and power. Usually with most traditional enterprise applications, power translates into rigid complexity, with thousands of programs, written in several languages and running on layers of technology. The dilemma was to design an application with the simplicity and flexibility of spreadsheets, but with the power to develop industrial strength enterprise applications. This means Fluidapps must provide the ability to create rich business transaction functionality in a simplistic and flexible way.

The solution to the design challenge of simplicity, flexibility and power lay in the idea of developing a single device with all business navigational activities. This way, only enterprise data and logic would be considered unique, providing the maximum re-use of code and eliminating the lion’s share of development. This approach would simplify software, provide the power to address all business activities and deliver the flexibility required to satisfy the ever-changing needs in the business community.

The design approach was a time consuming analysis of thousands of unique business transactional activities for data maintenance, inquiries and reports. The objective was to keep adding functionality to a single device for each business activity encountered, avoiding the creation of new devices for unique activities (common in today’s development approach). Any new functionality discovered along the way, kept being added to the same device, until eventually over years of adding functionality and tweaking the single device, all navigational business activities were addressed.

It was discovered that the number of business activities addressed by a single device goes up exponentially as additional common functionality is added, until eventually all business activities are covered. The design process was long and tedious, but the effort was well worth it. The result was the creation of a single device called the “Universal Data View” that has the power of unlimited application development, data maintenance, inquiry and reporting capabilities; thus, one element with unlimited forms.

The Universal Data View concept provides a small, simplistic and powerful approach to enterprise application development and deployment: small — to resolve scalability; simplistic — to eliminate complexity; and powerful — to address nearly all business data maintenance, inquiry and reporting activites.

The Universal Data View is cached on the client and operates within the Fluid Manager. The Fluid Manager operates within a browser and is distributed between the application servers and the client, depending on the resources available on the client. The data view definitions and enterprise data are all stored in one or more databases. The servers may reside on the same client for a single user, or may be structured as a multi-tiered, distributed model with several layers of applications and database servers, supporting multiple clients. The entire application may be deployed and accessed over the Cloud with multi-tenant capabilities, or may be locally installed.

The combination of the Universal Data View, Fluid Manager and supporting application servers, comprise a unique patented technology which is the essence of the Fluidapps product. This unique design will revolutionize the enterprise application industry, ending the rule of monolithic applications, by eliminating the need to create volumes of complicated code.

Fluidapps solved the design challenge of simplicity, flexibility and power.

Data Views

The Data View is the primary point of all development and business activities. This is what makes Fluidapps simple, consistent and intuitive, because the same device is used for all user navigation activities. Data views are dynamically created at the client level and presented to the end user. There may be many data view variations for the same set of data. These variations are derived from the data view definitions as defined by the originator or users who have the appropriate access. There are over 200 data view definitions available for the data selection, sorting, layout, visibility and operation of a specific data view. These data view definitions are used to dynamically alter the selection, sorting and presentation of data within a data view based on who the user is and where the data view was accessed (usually from within another data view). If allowed, end users may also alter and save a particular data view for personal or public use. This eliminates the need to develop individual forms for every possible use of a specific data set.

For example, there may be only one data view defined for the customer data set. However, the data view definitions for the data selected, sorting, visibility, layout, operation and access for the customer data set may vary depending on the user or where the data view was accessed. Therefore, specific AR users may have full customer view and maintenance access, whereas order entry users who are viewing customers from the order header may have limited visibility and access. All of this is dynamic, eliminating the need to specifically program each data view variation.

All data views are derived from a single device, operating on the client, called the “Universal Data View”. Built within the Universal Data View, is the ability to address nearly all development and business activities. When a data view is requested, the Universal Data View is replicated, defined and loaded with the appropriate development or enterprise data, eliminating the need to generate and submit a form to the client. This is why Fluidapps is simple and consistent. Whenever new functionality is required, it is built into the Universal Data View, providing the new functionality to all data views instantly, eliminating the need to alter volumes of code.

The following screen shots highlights the primary data view layouts and features:

Multiple-row Data View with collapsed column groups and rows (select for a larger view):

Multiple-row Data View with expanded column groups and rows (select for a larger view):

Single-row Data View with expanded column groups (select for a larger view):

Data View Creation

All enterprise application development and business activities are performed within data view instances (or data views). The display, layout, data selection, sorting, maintenance and operation may be fluid for a data view depending on the data view definition. There are over 200 possible data view definitions for each data view, where each data view definition may be fixed or dynamic resulting in an unlimited number of variations for a specific data view depending on the user and where the data view was accessed. For example, the display, layout and maintenance of warehouses may vary between organizations, users and where the data view was accessed.

An exiting data view may be copied and altered to produce a new child data view. The original data view is called a “Parent Data View”. Both child and parent data views will share the same column set. Data view definitions derived from a specific parent data view, are related together in a hierarchy structure with parent and child data views. Each child data view is traced to a parent data view. For example, the parent warehouse data view might have a child data view for management with additional columns and totals, such as cost, price, added labor, inventory value, turnover, etc.

There are two methods available to create a new data view. From scratch, using the graphical point-and-click environment by defining a new column set and unique data view definitions. Or, by copying an existing data view and altering or adding-to the data view definitions.

The following outlines the simple steps involved with the creation of a new data view from scratch using the graphical point-and-click method:

• 
  

  1. Open Fluid Manager

  Before creating a new data view, the Fluid Manager must be opened within a web browser. The Fluid Manager is the main environment used for all development and application activities. In this example, the Fluidapps menu is automatically opened on the left within the Fluid Manager. However, the menu is optional.

  Note that the menu is a data view as well, demonstrating how the core technology is used to develop the Fluidapps product.

   
• 
  
  

  2. Create a New Data View

  Create a new data view by opening the “File” menu and selecting the “Add Data View” option.

   
• 
  
  

  3. New Data View is Created

  After selecting the “Add Data View” option, a new data view will be created with a default title. In this example, the default title is “Data View 1”.

   
• 
  
  

  4. Define Columns

  To define columns within a new data view, open the column menu by right-clicking on the empty column bar. You may define one column at a time by selecting the “Add Column” option, followed by defining the column type and all other column definitions including the column label. Or, another option is to create multiple columns at once by selecting the “Add Multiple Columns” option, followed by selecting and defining each column. You may also add pre-defined columns by selecting the “Copy Column” option. This will natuarally create column relationships between data views.

  There are over 80 possible column definitions and over 20 column types, including character, integer, decimal, date, logical, formula, image, video, event, etc. Column definitions may be fixed or dynamic depending on the user and access point. Column data validation may be defined by using one of several pre-defined point-and-click options. However, if a column data validation is unique, a component (or validation logic) may be defined. Also, if required, column event components may be defined and associated to a column as well.

   
• 
  
  

  5. Save Column Definitions

  Save the data view column definitions by selecting the “Save” icon or “Ctrl-S”. The columns within a data view may also be moved and sized using drag-and-drop mouse activities.

   
• 
  
  

  6. Define and Save Column Groups

  If required, columns may be grouped together into Column Groups for column organization, visibility and management using the same column menu. Column groups may be expanded and collapsed within a data view.

  Each column group may be defined using over 20 column group definitions, including group label, width, position, layout, operation, visibility, etc. Column groups may be grouped into other column groups creating a hierarchy of column groups. Save the column group definitions by selecting the “Save” icon or “Ctrl-S”. Columns and column groups may be moved out of and into other column groups manually using drag-and drop mouse activities.

   
• 
  
  

  7. Define Data View Definitions

  The data view may be defined by right-clicking on the data view header bar and selecting the appropriate data view definition options, including title, access, column layout, font size, positioning, column group layout, row hierarchy definition, row hierarchy mode, totals, events, etc. Data view definitions may be fixed or dynamic depending on the user and access point.

  There are over 70 different data view definitions, including layout, data selection, sorting and operation using one of several point-and-click options. However, if the data selection and sort are unique, data selection components (or selection logic) may be defined for the selection and sorting of data. Also, if required, data view event components (or event logic) may also be defined.

   
• 
  
  

  8. Save Data View Definitions

  Save the data view definitions by selecting the “Save” icon or “Ctrl-S”. The data view position and size may also be defined using mouse activities.

   
• 
  
  

  9. Enter and Maintain Enterprise Data

  After the data view is saved, the new data view will be automatically added to the bottom of the Fluidapps menu unless specifically assigned to a row order or under an existing parent row. The new data view may now be accessed for the entry and maintenance of enterprise data from the Fluidapps menu or from any access point defined in the data view definitions.

   

Singular Polymorphic Software

Fluidapps was developed using a new and innovative patented system and method called “Singular Polymorphic Software” (SPS). True SPS technology is unique to Fluidapps. However, a few aspects of SPS design have been in use for decades in the software industry. For example, the first spreadsheet application called VisiCalc used a few elements of SPS design. Since then, nearly all of the killer apps have used similar approaches including spreadsheets, word processors, graphics tools and browsers. Most of the truly successful software applications employ some aspect of SPS design. However, true SPS design carries the “singular” and “polymorphic” nature of software to its peak. Fluidapps is the first enterprise application development and deployment product using true SPS technology.

SPS technology encompasses the following design requirements:

Single Device
All enterprise data navigation activities must be contained in a single device, operating at the client level. The single device is referred to as the “Universal Data View.”

Replication of Single Device
A copy of the single device is used to create a unique form for data maintenance, inquiry and reporting referred to as a “Data View Instance” (or just “Data View”). When a data view instance is created, the universal data view is copied and the data view definitions and event logic are pulled from a database and added or linked to create a unique data view.

Dynamic Functionality
The fluid and polymorphic nature of SPS technology is mainly provided through the definition of dynamic functionality for a specific data view instance or a group of data view instances, where the dynamic functionality is defined, activated and/or implemented when a data view instance is accessed. This provides data view personalization. Dynamic functionality will be coded into the universal data view to provide the appropriate modifiable functionality for all data view instances. Dynamic functionality will be automatically defined from layers of data view definitions based on multiple criteria including the user and access point. Users with the proper access may define any of these dynamic functionality options within the data view definitions for any possible data view instance or group of data view instances. Examples of dynamic functionality are: data selection, sorting, layout, visibility, access, grouping, validation, security, relational links, events, etc.

Relational Linkage
When a data view is created from the universal data view, it may be linked to another data view in operation. This approach provides a relational link between open data views in order to link navigation and share data. This is necessary for parent and child relational data, such as a sales order header and line detail.

The process of creating a unique data View instance from the universal data view, defining data view definitions and linking data views together is the SPS patented technology within the Fluidapps product.

Technology Overview

Fluidapps is a true point-and-click, rapid enterprise automation (REA) platform containing a combined and seamless integrated development environment (IDE) and integrated application environment (IAE). The product contains all of the necessary functionality for creating and customizing large-scale, robust, distributed applications for the definition of data structure, data maintenance, inquiry and reporting within a web-enabled operating environment.

The proprietary technology behind Fluidapps resolves the leading problems with most business applications, regarding the size, complexity, rigidity and excessive use of system resources, by combining all user interface and data management activities into a single device. The information transmitted to the client has been minimized, eliminating the need to generate and transmit code, objects and forms. Fluidapps will lead the industry in simplicity, flexibility and power, by allowing users to quickly create or change data view layout, data selection, sorting and operation with ease.

Fluidapps Primary Elements

The Fluidapps product consists of several primary elements, including the universal data view, data view instance, fluid manager, application server and database server. The following explains each of these elements:

Universal Data View
At the heart of the Fluidapps product is the universal data view, capable of handling nearly all business application activities, including data display, maintenance and processing. The universal data view is a single device used for the creation of all data view instances (or data views). The universal data view is the primary graphical device, used for the presentation and maintenance of enterprise data. All development and business activities are performed with a copy of this single device. Dynamic functionality is built into the universal data view and used to automatically alter the data view based on the data view definition, user and access point.

Data View Instance
A data view instance (or data view) is a copy of the universal data view existing on the client, coupled with the data view definition, client components and enterprise data. Data views are used for all development and business activities involving the display and maintenance of enterprise data. Multiple data views may be opened at the same time and chained together for relational activities. The layout, data selected, sorting and operation within a data view is dynamic and may vary based on the data view definition, user and access point.

Fluid Manager
The primary graphical user interface within Fluidapps is the fluid manager, which operates on a platform-independent client. The fluid manager combines proprietary Singular Polymorphic Software (SPS) technology with spreadsheet functionality and is supported by a back-end, multi-tier system architecture consisting of application and database servers. The fluid manager is a full-featured, comprehensive, end-to-end integrated development environment (IDE) that allows users to build robust, transactional applications quickly and easily. The fluid manager is also an integrated application environment (IAE), working seamlessly between development and execution. Users will be able to seamlessly define, test, deploy and execute applications within the same environment. The fluid manager owns the universal data view, creating and managing data view instances as directed by the user.

Application Server
The application server is used to support the fluid manager. The application server may be combined with the fluid manager on the client or may reside on a separate server located on the network, supporting one or more open fluid managers. There may be multiple application servers defined for the distribution of the client load.

Database Server
The database server is used for the storage of data view definitions, components and enterprise data. The database server may be combined with the fluid manager on the client or reside on a separate server located on the network, supporting one or more application servers. There may be multiple database servers to distribute the database access load.

Fluidapps Data View Creation Process

The following outline provides a brief description of the process used to create a data view on the client within the fluid manager using the primary elements:

1. Create a Data View Instance from the Universal Data View
When a user requests a data view within the fluid manager, the system copies the universal data view, creating a unique data view instance.

2. Load Data View Definitions
The data view definitions are pulled from the database server and passed to the client through the application server. Data view definitions make the data view instance unique by dynamically defining the layout, data selection, sorting and operation of the data view instance, based on the data, user and where the data view was accessed.

3. Load Client-Side Components
If defined, client-side components are pulled from the database server and passed to the client though the application server and plugged into the data view instance. Client-side components are packets of business logic, required at the client level, supporting specific user activities; for example, a unique and unusual column validation or event.

4. Load Server-Side Components
If required, server-side components are pulled from the database server, loaded on the application server and connected to the data view instance. Server-side components are packets of business logic for an event, which may be launched from within a specific data view; for example, a cost roll-up process.

5. Load Enterprise Data
After a data view instance is created within the fluid manager, enterprise data is selected, sorted and transmitted to the client from the database server and displayed within the data view instance, as defined by the data view definition.