Best Of

Thanks for your help Bjorn. I will now raise it with the support desk.

Can I take it from your reply that the screen sizing feature is working as expected for you?

For completeness, I created a brand new capsule with a different database

   -   One screen only. 

   -   No masks

   -   No screen setup in any way

Same outcome when selecting 'Fit to page':

Image: Yellow area indicates the amount of screen lost when selecting 'Fit to page'

If Björn Reuber is getting a successful outcome with this feature but other users are able to document adverse outcomes, it should be understood under what conditions the features operate as designed.  This can only be described by BOARD Intl.

There are functional issues with this and a number of the new features of BOARD 10.3, features that were presented at BOARDville promising that developers needed only to wait for the release and not waste time fixing or mitigating functionality that has become native. 

For test script purposes, the release notes describe the expected behaviour of the new features and so it is very simple to evaluate this and the other new features.  

As I cannot switch off these features, I cannot recommend that GVA upgrade to BOARD 10.3 as we have external customers to whom we would have to explain the issues, and admit where we did not know the solutions to such platform features.

Hi Etienne. 

I explained this issue to BOARD UK on Thursday in a meeting to discuss this and other issues with 10.3.  They agreed to raise the point of display sizing with BOARD Intl and I am hopeful that a resolution will be implemented by, or in, the 10.5 release.  

I was also able to discuss:

1.  URL as a value not recognised as a URL. 

2.  Persistent top border line in a dataview object with all formatting removed. 

3.  Various other points. 

I’ll let you all know if I get any feedback. 

This is now a non-issue as dynamic web screen sizing is usable.  It does highlight a few points though.  The first is that we all interpret behaviour in different ways which leads to varying expectations and a breakdown in common understanding; I, for one, did not understand how to use the sizing tools and screen development together.  The second point is that new features should really be demonstrated by the developer and not left to interpretation by the user.

I now understand that the BOARD developer can set their 'canvas' size and that the sizing tools act in this pre-determined sizing.  Also, I now fully understand how using a mask as the controlling factor, it is possible to create uniform capsule screens and change their size globally if required.

The screen sizing feature is a very power one and allows for models to be displayed on various devices with greatly varying pixel resolutions. 

Well done BOARD Lab, you have allowed me to develop and effectively demonstrate to existing and future clients that they can be sitting on a tropical beach, ipad in hand, reviewing their property portfolios - it's a winner, seriously.

Regards,

Paul Wyatt

Hi dirk magerkord, In short, No.

I am not aware of any way a nexel configuration can be reused in a reconstructed object as changing the dataview layout will break the link to the NEXEL file.

Each Nexel configuration resides as a file in the [database].hbmp folders but a nexel config is a part of the object which gives the NEXEL config its context, not the other way round. 

A dataview/object with a nexel config can be duplicated and allow the user to select the nexel config from the saved library.  Also, the layout of a dataview containing a nexel config can be copied and pasted into a new dataview and, using the Fx menu option, allow the user to re-apply the nexel from the saved library.

Deleting and re-creating any block on any nexel configured model, however, results in breaking the link of that object to the nexel config.  Only with the original block layout can a 'new' nexel config be saved to the library either as a new config or overwriting the original one by using the same name.

NEXEL is amazing and allows for some fantastic modelling to be achieved but it really should come with a caveat:

Hi Jonas Trompeter

You could display the total number of selected entity members using native BOARD objects, namely a dataview using the ranking function and a label to display the SUM of the selected entities.  This solution would be fast, simple and dynamic; updating whenever the selection changes. 

I do not know for what you use your procedure but if a part of it returns a count value, you could simplify and use the approach that follows:

The image below is a simple example of as screen with:

   a.   Selector

   b.   label*

   c.   dataview*

(* I've formatted the label and dataview to appear as one object.)

By selecting any number of cities, the SELECTED CITIES count automatically updates and the list of selected cities is displayed without procedures or having to refresh the screen.

The only calculation involved is the dataview used to identify the number of selections and also the list of those selections.

Construction of Dataview

The dataview uses any cube that has the key entity to be counted within the hierarchy.  However, there are several other ways to achieve this, such as creating a single count cube with only the dimension required to be counted.

The dataview, once created can be formatted to appear as a list as well as being copied into a label to display the total number of selected members. 

1a.   The dataview has a minimum of 3 blocks; Cube, Ranking & Algorithm:

1b.   To list the entity members selected, include the entity in the row axis, and switch off Down Totals.  Also, hide all three blocks.

1c.   Copy the layout

2.   Construct Label

   2a.   Place a label on the screen and enter the setup:

2b.   Select [Layout] > Paste Layout

2c.   Select the filters tab and

   1.  insert block c into the SORT By

   2.  Edit the value in the Keep Top area to [ 1 ]

You can now format both the dataview and label as you need.  An expansion of this approach could be to use a dedicated count cube to hide the label if no selection has been made.  To achieve this, you could save the maxvalue of the entity count and hide the label if 1/b*100 = maxvalue.

Without understanding what your procedure is doing, I hope that this may be of interest.  I'm happy to address any queries you may have.

regards,

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