Classic > NUX - Select levels to show on page when using same module for different cards

Hi - looking to get some community input on our attempts to transition from classic dashboards to NUX.

The scenario,

A common use case we relied on in the classic dashboards was that we could apply 'select levels to show' on a list within a module, pivot that list into the page dimension and the dashboard would respect the selected levels, irrespective of if a user selected a lower or higher level of detail (either via a selector or column/row selection).

We could then use a single module with 'select levels to show' applied to give a,

  • summarised view of the data (e.g. excl. lowest level of detail), with
  • a subsequent view of the same module, but with the lowest level of detail shown.

The intent of these types of dashboards was to provide progressive disclosure, e.g. start with product line, before looking at individual product.

The problem,

What we're finding is that this doesn't seem to work with the NUX. If you've got dimensions in the page of a card, and you're using the same module for 2+ cards, you're at the mercy of the global selectors and you cannot independently apply selected levels to each cards page dimension (unless you turn off card sync which defeats the purpose)

I will stress that the issue is strictly the flexibility of page dimensions, as there's no way in custom/saved views to apply persistent page dimension rules on a card-by-card basis. Rows and columns seem to allow for a broader array of functionality.

What we don't want to have to do is to create new modules, but with the summary level as the list so that we can force the summary table to remain at that level or higher.

I'm hoping we've overlooked some functionality, but keen to hear your thoughts.

Cheers,

L

Tagged:

Answers

  • Hi,

    I have used level filter described in article below to achieve functionality you described.

    Br,

    Pyry

  • luke_e
    edited June 2023

    Thanks for the response @pyrypeura. Had a look at the link and it seems to faciliate a different use case which was more around rows (and potentially columns), but doesn't address the page dimension in NUX.

    We also didn't have problems in classic with this design approach, so it's more specific to how the new user experience works.

    I may not have fully articulated my problem, so I've built an example model & app to explain.

    Example,

    1 —

    I've created a board using two modules,

    • one without time (used for employee assumptions)
    • one with time (used to calculate salaries and increases over time)

    The list hierarchy is,

    • L3 Department
    • L2 Team
    • #L1 Employee (lowest level)

    By default, the page selector has no filter and will show all employees.

    2 —

    For usability (and given the list can be incredibility dense) we only want to show 'L2 Team' in the global selector, and only want the chart (highlighted in red) to show at 'L2 Team' and above (effectively, the chart shouldn't go down to employee level).

    3 —

    With the 'Show/Hide' on the global page selector updated to exclude '#L1 Employee' (screen a) the chart will (correctly) only show L2 Team and its parents. The register with employees in the row dimension is also fine.

    However (in screen b), the table in the middle (highlighted in red) which was meant to show employee assumptions (with '#L1 Employee' in the page dimension) is now broken and will not allow for anything lower than 'L2 Teams' to appear when synchronised.

    The reason for it breaking is that because we've now adjusted the global page filter to exclude '#L1 Employee', all modules using this list in the page filter it out.

    a.

    b.

    In summary,

    Given this type of design worked quite well in classic, I'm trying to find a way in NUX where we're able to have a filter applied to the global page, but also have custom page levelling applied on a card basis so that users are presented data on a level that is meaningful.

    The only other option I've seen to achieve such an outcome is to build additional reporting modules at the desired levels of detail, but this isn't really viable.

    Cheers,

    L