We made a mistake and we’re fixing it. There I said it. The four hardest words for any PM to say. Something was wrong in our product, and we are changing the behavior to what it should be. Change is scary, and doubly so with enterprise products. To really understand how this happened, and why we’re fixing it now, perhaps it’s best to start at the beginning…
In the beginning, there were dashboards. Dashboards had queries (then called “steps”) and those queries could have selections. We didn’t have global filters yet, but they would be added later. We created a way to pass state to a dashboard. State being a set of selections (And later filters). This state is specified in the form of JSON text. We used this format to persist and load state for sharing a dashboard link, saved dashboard views, embedded starting values, and even to programmatically get and set state directly.
As we started with embedded dashboards, that’s exactly how we thought of them. Fully functional dashboards embedded into a contextual point of reference. For convenience, those dashboards could start in a contextual start state. One could embed a sales dashboard in an Opportunities record page, then specify a filter to start with all the content and analysis drilled down to the current record. Users could analyze the current record or remove filters to go to a high level, cross record analysis, and to make that easier, we made the reset button go back to that global starting state, and that was a mistake. We expected authors to create fully functioning mini-dashboards that would work just as well for high level and record level analysis and want these mythical unicorns inline with all their other record content, but that’s not what happened. That’s not how you used it.
I think the flaws in our logic were:
1) We assumed most dashboard authors could develop content that worked equally well at the record level as at a high level. This is a challenging task. Often the optimal view at a high level is very different from that for record level. Even if you can build something that applies to both, you may have to make trade offs that will hurt usability, and quite often you need more screen real estate to create a good view for high level analysis. The best content I’ve seen has separate pages, or sometimes even separate dashboards, for these very different use cases.
2) We assumed users wanted an “embedded dashboard”. In the immortal words of Theodore Levitt, “People don’t want to buy a quarter-inch drill. They want a quarter-inch hole.” Instead, authors wanted relevant analytic content on their record pages. They wanted this content to melt into the page, and be a native part of the page itself, not some mini portal into another world of data analysis. The embedded dashboard is just one tool of many to get relevant content on a record page. The Chatter widget doesn’t have a view all of Chatter button. The record details widget doesn’t have a way to view details for other records. All of these use cases are handled through navigating to other pages. This keeps each individual widget light, and the context implicit by the fact that the user is looking at a page about this record.
3) We assumed more flexibility is good. Users came back to us with all sorts of feedback. Some said it’s a little weird or confusing you can remove an embedded filter. Some came up with elaborate and creative ways to block their removal. Some said it was a security risk for users to be able to remove these filters at all. One user even said that being able to remove these filters misses the whole point of the filters! In this case, too much choice or flexibility can be bad, especially when the user in question is a busy, intensely focused user trying to do their job, which in many cases, is not “analyst”.
4) We assumed users would need contextual information like knowing all of the applied filters. So much of this information is implied by the page context. We underestimated the expectations around page context, underestimated the cognitive overload of additional breadcrumbs redundant with page context, and overestimate the need for end users to perform free form analysis in context.
So what are we doing to fix it?
Reset — we are changing the behavior of reset. Starting in the Winter ’21 release, reset will no longer go back to the default starting state of the dashboard (i.e. the state had you opened this dashboard directly from Studio). In Winter ’21, reset will always return to the initial state from when this page loaded (basically the same state if you were to use the browser refresh button). Furthermore, we are applying this change to full page dashboards too, so if you navigate to a dashboard through a shared link, a dashboard link with state, or using the Open in Studio button, reset will go back to that starting state. Also previously, there was another hidden Easter Egg with saved views where if you selected a saved view, and then did further modifications, reset would from then on return to the last chosen saved view. To keep consistent we have removed this behavior to ALWAYS return to the initial state. The additional work to return to the last specified view is now only 2 clicks instead of 1, so the trade off seemed tolerable.
Locked Filters — Page authors will now be able to specify an embedded filter as locked. This means that the breadcrumb in the header cannot be removed by the viewing user. This will be great for situations where being able to remove contextual filters does more harm than good.
Hidden Filters — Page authors will also be able to specify an embedded filter as hidden (independently from locked). Hidden filters will not show up in the external filters list. Use this in situations where the page itself provides enough context that the filter breadcrumb seems redundant.
Do note that both the locked and hidden attributes are only available with embedded content. If you allow users to open this dashboard full page in Studio or a Lightning tab, then all filters will be displayed and editable as they were before Winter ’21.
Authors using the SDK or otherwise programmatically creating widgets will also be able to use these settings. With this and the hide or redirect the Open in Studio button options for the embedded dashboard header from Summer ’21, we hope this will enable more content developers to utilize all of the other features the embedded header allows.
We hope this will help you to create intuitive and simple pages where the analytic content melts into the rest of the page content, and I, personally, hope that this helps us to jointly strike the word “dashboard” from our vocabularies. Nobody wants dashboards, they want insights at the point of engagement.
Happy Designing,
Ed Mengel
Director, Product Management — Einstein Analytics
