Virtual Experience System (VES): The Perpetual Evolutionary Vision

What is VES is first thing people ask me, and it is a good question.  It is hard to explain even to myself somedays, but it is not difficult to understand.  It just flies in the face of traditional philosophy of design and development.  VES (Virtual Experience System) is a self-evolving mobile/web engine.  This engine operates off VNA schematics which are created and maintained using a VES schema management tool.  But how do we get a VES schema management tool without a VNA schematic.

It is the classic what came first the chicken or egg conundrum.  This like all perpetual machines it has to have momentum to start its running cycle.  So in this case we are going to use our VFS (Virtual Forms System) and Spinach to create the initial 2 things needed to get the VES engine running.

First we will use VFS and its Form Template Manager to create a VES Schema form.  This form will then be used to create our first VES based User Experience.

Secondly we will use the VFS system to create a can of Spinach.  This can of Spinach will contain only the basic logic needed to render the initial VES Schema.

Once we have this Basic VES Engine running the next step will be to use the VES Engine to build a VES Schema using VES.  Then we will also build a VES Schema of Spinach type that will contain the same rudimentary logic that the original VFS Can of Spinach contained.  This will then allow us to create a new Launch Direct Tool Sequence that is specific to VES.  This will be an Ultra-Light Launcher that will bring up the base VES Engine Widget, Load the Requested VES Schema (via URL param).  Once the VES Schema is loaded it will process CSS rules first, then it will process Script onCreate Rules 2nd.  After that we will retrieve any data from the VES database or Local Cookie (if in Edit Mode).  Once the Data is retrieved we will then begin the Rendering portion of the VES Schema.

How do we Render and in what order is critical.  The base VES widget will have no visual DOM presence, no div tag, no content pane, nothing.  the type of Spinach you load will setup the wireframe document which we will then render into.  The typical would be 3 dojox mobile views we will call them Panels (Introduction, Operational and Custom).  The VES Schema will be responsible for putting information into the correct initial Panel.  This will be done by specifying which of these a VES Schema View will load into in the Views metaData (example: Panel:”Introduction”). Note:  A View can have its Panel Attribute set to Item, this will be covered later.  In doing this we can customize each VES Tools Load Sequence (user login, continue as guest, splash page etc…)  you can also put multiple Views into a Single Panel.  The Operational Panel will consist of 2 ContentPanes (Navigation, Dashboard).  This will allow us to build custom Navigation and then Each View we add to the Dashboard will be done using dojox mobile view widget.  We will establish some standardized Navigator examples.  VES Schema Sections will be rendered inside their specified VES Schema View and VES Schema Items will be rendered into VES Schema Sections.

VES Schema Sections are treated as a Collection of Items where you can specify the Frequency.  By default the Frequency (which is in the metaData) is set to 1.  This would mean you would have only 1 set of Items for this Sections Collections.  If you set it to 0 it will be unlimited sets of items, or setting it to any positive value would allow you to have up to that many sets of items.

VES Schema Items are what we would have traditionally thought of as Questions, except now they are a Widget.  Each Type of Item will have a dedicated Widget that will visually and logically standardize what is needed.  List of Widget Types:  Text, Numeric, ComboBox, Slider, Content, Metric, Report, etc…  One of the creative Widgets will be a VESSubView widget.  This will allow you to Render another View defined within this Schema for this item.  This will allow us the ability to Nest our what we classically have called subforms.  A single Nested subform is Handled by just using a Section with the Frequency set to the appropriate value.  If you need to go more than 1 level deep then you can use Item widget Type of View to pull in another layer.  Once again just like we did with Section we can set Frequency in the Item’s metaData to specify the number of sets of Views there will be in the Collection.

Example :

• Parent has a View for Family Information
• The Family Information View as a Section labeled Children with Frequency set to 5 (aka you can only have 5 kids)
• The Children Section has Items Last Name, First Name, etc…, but also has an Item of View Widget Type called Interests
• Interests View has Section for Athletics, Scholastic, Extra Curricular whose Frequency is set to 10
• Athletics has Items of Sport, How Long, etc…
• Scholastic has Items of Sport, How Long, etc…
• Extra Curricular has Items of Sport, How Long, etc…

So with this we can have multiple kids for a parent that have multiple Athletic, Scholastic or Extra Curricular information

How this is all Stored…

A VESView and its Sections / Items would represent a Logical Data Collection and be stored as such.  So if a Schema has Multiple VESViews we would have Multiple Logical Data Collections.  The Collections will be tied together with a Relationship Identifier, but this Rel Id will be a Many to Many so that Individual VESViews can be referenced and Related to other LDC’s.  In addition if a VESView has an Item in it that is a VESSubView this would be treated the same, but in this case the Rel Id would be to the VESView in the parent.  Each VESView will get their own Rel Id, but there will be a LDC that will tie Rel Id’s to one another.  So a Rel Id can be both a Parent to other Rel Id’s, but it can also be a Child to other Rel Id’s.  Another point to be made is not all VESViews are physically rendered into a UX.  Some are there specifically to create a LDC of information that might be comprised of summary data from the current set of VESViews and the user’s interaction with them, but could also include other things that might be environmental, or collected from other sources.  This ability would allow you to build pre-rendered LDC’s for specific applications so that you don’t have to run additional off-board processes to accomplish these tasks.  It can also be used to let you render LDC’s for a single entry that might be used by multiple business processes, but they require the data to be structured differently to fit their needs.

VES is the Logical Representation of VDS using the LDC modeling.  VDS then uses its own VNA Schema’s to concert the LDC(s) into a Physical Data model.  But the next step in this eco-systems evolutionary process is to use the LDC(s) being represented in VES, as they best represent the Business both in Data and Process, to create the correct Physical data model and the VDS VNA to convert that physical data model into the LDC’s the VES is needing.

In closing this is how Virtuality becomes self evolving.  As Virtuality gets introduced into new business practices it become more robust for all business practices.