Here are a few practices I follow when using page selectors on dashboards.
For module page selectors:
Hide module page selectors that don't add clarity or value by setting them to Hide Label, Hide Page Selector.
If it will add clarity to what the user is editing, change the page selector to Show Label, Hide Page Selector (i.e. read only). Note that the standard module Search (Ctrl+Shift+S, or via the module menu) will still navigate through the page items if needed.
Leverage synchronize selection to change the selected page in lower level modules by clicking on higher level modules, rather than forcing users to search through a long list of items.
In all other cases, use individually published page selectors (i.e. Publish List as Page Selector).
For individually published page selectors:
Place all individual page selectors at the top of the dashboard.
Include a text label for each page selector (my preferred format is Heading 3).
Use at most one page selector per hierarchy (i.e. don't add 5 page selectors for each level of a 5-level hierarchy).
I generally place multiple page selectors along a row rather than stacked vertically. This makes better use of screen real estate.
1. I often have a "context" dashboard, where all of the page selectors can be set initially
2. For deep, multi level hierarchies, we sometimes advocate a series of "selector" modules for each level in the hierarchy and have each one syncing off each other. This provides a clean navigation path. I also would put this on a separate dashboard and toggle back and forth |(as per the atttached)