BOARD Functionality for Screen Identifiers/Versioning across Capsules?

unknown

We're running a number of differing Capsules for different Clients, and in order to assist our Support Desk with quickly identifying where a Client's issue may be, we're wanting to implement a Screen Identifier system, the same you would if you were running and maintaining a complex website (which we kinda are by default).

 

Is there any functionality in Board that we can not only apply an Identifier to each individual screen in a Capsule, but can also track version numbers of that same screen. I ask this as we are also running a number of Servers for our content: Development Servers for building/maintenance etc, and the Client-facing live server. Tracking changes and versioning of screens/pages across these has become an important aspect too.

 

As Capsules in DEV and LIVE share databases, tracking this developer data in the parent database would be problematic; has anyone else invented this wheel, and care to save us the re-invention?

 

screens versions capsule design identifiers capsule_migration

Paul Wyatt

Hi Lukas,

 

I really like what you're outlining here and would strongly recommend that you submit this as an idea. 

 

We (mostly) have a shared SQL source database for all separate cloud BOARD servers on DEV, UAT and LIVE and provide models for external clients.  These models are governed by Service Level Agreements (SLA) relating to service, support and maintenance as well as outlining how we manage faults and upgrades. So, screen version and alteration tracking would minimize my liability to manage changes and so providing me more time to develop solutions and upgrades.

 

BOARD breached the wall between a traditional BI Application, where the focus was on the analytical outcome drawn from a simple 'Take it or leave it' interactive process, and dedicated applications where every feature, function and component can be molded to fit precisely the needs of the user. 

 

BOARD, using data-entry, ROLAP, NEXEL, work-flows and logic gates, procedures, drill-down & drill-through, coupled with input objects like user definable labels, buttons and even dataviews as control panels, has allowed BOARD software to be used for RAD projects.  The impact of this is that BOARD developers are capable of actually disrupting the software application developers.  this is further enabled with the integrations BOARD is capable of, such as directly to Google maps, the complete MS OFFICE 365 suite and linking to third party storage locations such as BOX and through third party password managers such as OKTA.

 

If we are to become the hybrid application developers, there are some more tools we need to make this truly viable and version tracking is one of them.  We will be losing the 'snapshot' capsule feature in WEB ([Shift]+[Ctrl]+[Alt]+[T]) that allows us to store exact zipped copies of a model prior to upgrading it.  I want to see this feature expanded upon and to incorporate what you have suggested.

 

I currently perform a manual version control process using the snapshot feature and recording manually entered model info using 2 dataviews.  The image below shows the first dataview used to capture data.  The second dataview has been formatted and is used as a control panel to launch any one of several sub-procedures in the layout configuration.  I could expand this manual process to incorporate every screen but I will not as this is too much effort and prone to error; lapses in maintaining updates manually.

For completeness,here is the procedure used by the second dataview ([Load] - [Save] - [Backup] - [Restore] 'buttons':

The above process would be greatly enhanced if we were able to capture screen versions automatically and with summaries of the changes that took place.  I do, however, think that we are a long way from BOARD implementing such features but I think they will have to at some point as delivered models must be maintained to formal SLAs. 

 

Currently, without a very cumbersome formal software engineering management plan (which is so  20th century and not in a BI,Finance or Business Analyst's required skill-set), BOARD models carry an inherent project RISK where they are offered to external clients and changes/upgrades (including BOARD software upgrades to v11, etc) are governed by SLAs.  Integrated Development Management would mitigate this risk and complete the pivot of BOARD BI into a credible app development platform.  This in turn would open new doors of expansion for the product.

 

This is only my subjective opinion but, in short, please submit the idea, I will vote for it and support it with my own post based on my opinions as above.  If you'd prefer, we could even submit a collaborative Idea together.  Please feel free to contact me via this forum or directly via email.

 

Kind regards,

 

Paul Wyatt

email: paul.wyatt@avisonyoung.com