I want to open up a discussion about Page Selectors and Item Selection within Anaplan.
What are peoples thoughts in this area?
Today in Anaplan:
When you login the item selected by default is the first base-level item in the hierarchy. (Login Default)
When you change the item selection, via a page selector or by clicking an item label in a row or column header, it updates the item selected and applies that selection across other items I can see, and to other dashboards that I navigate to (Context Update)
All Components (Grids and Charts) are bound to the Global Context by default when they are created, and a builder can choose to stop individual components syncing to the Global context.
In the future we could change some of this, I have some questions:
Question 1: Should the Main default behavior follow what happens today (First base level item) or would you prefer it defaults to the "Top Level item" (or First member when I sort the hierarchy with Totals at the Top if there is no Top Level Item)
Question 2: If we add additional options that Builders could select for the opening default here are some ideas, please order based on your priority, which would you use most often?
Builder selects a single item which everyone sees on login (if there was no access then we would use the Main default behavior (see Question 1)
Builder is able to manually assign a specific item for each user (e.g. Builder could setup which specific Cost Centre the users sees as default when they log in)
First top level item
First base level item
Persist from previous session - The first time a user logs in it uses the Main default behavior, in subsequent sessions when they log in it selects the item they were looking at in their previous session
List of items in a Page selector
Today you can't filter the items shown in a page selector but you can use subsets, or filter the page selectors shown on a module grid.
Question 3: How often do you want to filter the list of items that are shown when you activate a page selector drop down? What % of the time would you want to do this?
Page Selector Location
Question 4: Do you generally add Page selectors to the top of each dashboard?
Question 5: In the current product you can have Selectors on each Grid/Chart. How would you feel if we moved all the selectors up into a Filter pane at the top of the Dashboard, and removed them from the dashboard components?
Question 6: As a builder would you appreciate the ability to add actions or triggers that update other selections when a user makes a selection.
Example 1: If you select a specific Version it automatically knows that you should also be looking at a specific time period - e.g You select the version "Forecast 3+9 2018" and it should trigger a time selection of "April 2018" Example 2: If you choose a country it automatically selects a different "currency" - assuming there is a link between these two - The Country list has a property that is the Currency for that Country Example 3: If you select a number list item that represents a combination of a Product & Customer, it automatically syncs to the relevant "Product" and the relevant "Customer"
How useful/not useful would that be, when would you use it?
Thanks for reading. Look forward to hearing your thoughts.
If you have any other suggestions pertinent to this topic please add a reply, interested to hear your ideas.
Simon, the response below is a compilation of our model admins: Nick, Matt, Leila, and myself.
It was unanimous that defaulting to the top level is much more desirable than the current state.
We had some mixed responses from the team. Options 5 and 3 were the favored options. Option 4 was chosen by all as the least useful option.
Assuming this is not multi-select for users, then low usage. Leila indicated maybe 50-60% of the time. Personally, I can’t think of when I would need to use this as I rarely use page selectors.
In one of our two primary models we rarely use separate page selectors but instead use the page selectors from the published module. Those give us more functionality such as allowing for filters, allowing us to choose a default option, and showing only the subset used in the module (we use a lot of subsets).
In the other model, the page expense center lists are published as page selectors, primarily due to the 1000 item limitation on lists.
Responses were a bit varied on this one. This could reduce the number of clicks for users and allow a better focus of the dashboard.
However, we do see a couple of issues with this idea. First, there is a concern that users may have to scroll up and down through the dashboard multiple times to make selections – would this part of the dashboard be frozen at the top so that it’s always visible to users? Second, we often have multiple modules on the same dashboard that share some, but not all, dimensions and we are unsure of how this would look and if we could differentiate which selectors apply to which modules.
Nick did bring up that it would be nice to have an improvement that would allow us to freeze certain areas of the dashboard, such as the selection pane.
Multi-select actions would be appreciated; the triggers would be helpful for proactive logic sequencing. We may not have a lot of places to integrate something like this in our current models, but with the options it’s possible that we could use it in new builds.
Multi-select has been a much-requested function of both our model builders and users. For instance, publishing a year selector to a dashboard and allowing a user to select two years and see the totals in the grid. As Nick states, this would be the biggest improvement Anaplan could make to the dashboard UI and would get used very often.
Not as related to this topic but related to dashboard design: when a module is published to a dashboard, the scroll button on the mouse does not work to scroll through the dashboard when hovering over a grid. This has been a nuisance brought up by several users.
Happy to expound upon any of our comments here or answer any follow questions. Thanks Simon!
I realize I'm coming a late to this, but just saw the threaad and wanted to provide some feedback, as some of these ideas would be hugely appreciated by both me as an admin/model builder, but also a number of my users.
Default shoould be top-level line item. Hands down. I have been specifically asked for this by a number of users. Personal views accopmlishes some of this, but requires every user to do it themself and get blown away when we make changes to the dashboard.
Here the more flexibility in design the better. In order of preference of your options: 5,3,2,1,4.
Very small percentage of time in current models. Selective access takes care of this for most of our use cases.
The idea of a pinned or frozen filter bar that I could put page selectors into and would always be at the top of dashboard would be wonderful. Would allow for dashboards to contain more content without having to scroll back to the top or publish redudant selectors in various sections of a dahsboard.
I will echo bdeaton that this would be a great feature to have and would simplify things for users where we could define logical relationships.
The idea of allowing multiple selections would be great. There are a lot of scenarios where users want to look at results of multiple list members, but not a full parent roll-up in the hierarchy. For example, I may want to look at results for two or three sales reps, but not the full territory team. Would be much more dynamic.