OEG Best Practice: Card templates: Some best practices
Why use them?
When building out your apps in the UX, there are often instances where there is a requirement to replicate a card on multiple pages. For example, you may want to surface a grid card displayed in full on a board as an additional insight into the primary grid on a worksheet. Similarly, KPI cards could be useful for multiple user personas interacting with different pages.
A card is associated with one page only, and therefore to do this duplication, you can either recreate it from scratch or pull it from the template library. Bearing in mind that it may have taken some effort to apply filters, conditional formatting, sorting, grouping and pivoting to a custom view, it is inefficient to reinvent the wheel every time you need to reuse the view in a new card.
Building out a card template library in your app can really help to organize your cards and save time in building your pages. You build out your custom view when creating the initial card, save it to the library, and reuse it as often as required on other pages.
Cards created from templates are also editable, so they can also be used as a base from which to edit a pre-existing view without the need to start again.
Are there any best practices to consider?
Naming convention
The names of card templates are freeform text. Without a good naming convention, the flexibility of freeform can lead to a disorganized mess as your template library grows. On creation, if the card in question has a title, the template name will default to that, but it can be amended afterward. Beware of duplicating names, since Anaplan does not prevent this.
Including the category in which you have organized your pages is a useful prefix, followed by a clear unambiguous description. If your app utilizes multiple models, you may want to include a reference to the model the card is based on too (see Planual UX Principles – Use consistency and standards).
In the example below we have an App called Connected Planning with pages grouped into two main categories, Sales and Finance. The pages are linked to one of two models, Connected Planning 2022 and Connected Planning 2020.
When editing the board shown here, the page builder is presented with the card templates associated with the Connected Planning 2022 model.
The naming clearly shows the model and the category as prefixes to a clear name that describes the card. The symbol to the left indicates the card type (grid, chart, etc).
On this next board, from the same app, Anaplan presents only the templates associated with the Connected Planning 2020 model, since that’s the one the 2.2 Sales Targets 2020 page is source from.
Use Custom Views in most instances
Cards that use custom views offer much more flexibility than those based on module saved views. Whilst saved views do offer a single place to maintain a view which is repeated in multiple places, it is important to note that cards based on them are not available in Management Reports. Using card templates based on custom views provides a similar level of efficiency when building apps, but exposes richer functionality, now and in future releases.
Page types
In addition to the saved views limitation, not all card types work on all page types. For example, grids on boards and worksheets are not available for use on a Management Report page. Similarly, presentation tables on a Management Report do not work on Boards and Worksheets.
For more details, click here.
To illustrate this, in this Management Reporting page, you cannot see the grids, the field card and the notification action which are available on the 2.1 Sales Target 2022 board above. But you CAN see the presentation table CP22.Finance.Inc Statement by Month, which does not appear on the other page types.
Migrating from Classic
If you are looking to migrate to the UX from classic dashboards – and let’s face it, you should be – then the dashboard import tool is a useful accelerator. Dashboard by dashboard, you can import the bulk of the elements into a UX board as individual cards, based on Custom Views spun up automatically by the Import Tool. Since you will be redesigning the user experience as part of your migration project, it makes sense to save your imported cards as templates for use in the new pages you will be building. Using the tool means you won’t have to create the custom views from scratch, and you can always amend them if you wish.
Author AJ Balsamo.
Contributing author Andrew Martin.
Comments
-
Thanks for this article @annejulie @andrew_martin_1
I have already shared it with my colleagues.
It's pretty easily can get messy in the templates section and naming convention is the number one thing to start with.
0 -
Hi, I have been using these for a while and like them a lot. Yesterday I noticed one ting that I ammissing. The customer did want me to chane the header name in one of the grid which is used in a lot of pages.. so I edited the card template and thougt the header should be changed in all pagers.. it was not. I needed to remake all of the pages. is this the way it should be?
Kind Regards Caroline
0 -
@CarolineJosefsson Yes that's expected. Once you have utilised a card from the template library on a page, it becomes detached from the template library and is independent of it. This enables you to then make amendments to the card if you wish.
Regards,
Andy
0
