Best Of

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

Hi Jack,

You may need to approach the problem from a different angle.  To carry out actions on the results of calculations with NEXEL, those results should be stored in a cube - committed.  To carry out the work on the fly, you would have to also use a procedure to save (commit) that work.

I haven't time to go through the steps right now but here is a solution I proposed to another community member for an entirely different issue but in which I outline how to configure Nexel and procedures to work as you describe.

https://community.board.com/thread/2126-count-days

Also,Pietro Ferrari recently explained the reasoning for committing the results in another user issue.  You may find his explanation helpful with understanding Nexel more thoroughly:

https://community.board.com/message/5239-can-we-get-checkbox-count-when-data-entry-enabled-without-saving-into-the-cube

Please reply with any queries you may have and I will assist you in achieving what you need.

Regards,

Paul Wyatt

Hi Nigel,

Sorry for taking so long to reply.  

MASK LABELS

The mask labels are simply labels in the mask which have been formatted to look like a menu bar.  On selecting a label, the user to taken to the relevant screen, running a procedure if required.

SHOW SCREEN LIST

I cannot use the 'show screen list' feature as there are a number of admin and maintenance screens we do not want the user to see.

SCREEN SIZING CONTROL

The master mask is first laid out to determine the optimal 'canvas' size.  Once complete, the pixel width and height is entered and all screens are associated to that mask.  Leaving the setting on 16:9 or 4:3 will result in the 'canvas' being the maximum width and height.

BETAS FEATURE: Background

The background features differs by allowing for URL sourced background image to be used.