Enhance user experience with customizable dashboards

If this dashboard does come to be - would it be an appropriate place to offer site owners some information on web performance?

For example, automated testing from Webpagetest or Core Web Vitals. Or something like a running total of bytes of JavaScript, perhaps even with a discoverable breakdown showing which modules are adding how much.

See also https://www.drupal.org/project/ideas/issues/3230920

This is exiting!

Adding some issues as background info to help with the discussion:

• Why we don't have a Dashboard anymore: #950956: Remove Dashboard from core
• Why is this idea up for discussion again: #3024584: Directional Feedback for the Next-Gen Admin UI
• Previous and ongoing work for specific roles (Content Editor role is in core, but not the Content Manager yet): #2703367: Add Content Editor, Content Manager roles to the Standard profile
• Related, but just because it's a role-tied menu proposal: #3203618: New “content creation” menu proposal

Back in October, during a thread in Slack, I shared some of my idea as to how this could work:

Could we have a persona-based Dashboards: Admin dashboard, Content Manager dashboard, Content Editor dashboard; These would be slightly different depending on the persona: admin dashboard would be surface important things from status report, whereas content editor dashboard would be a mini version of admin/content (maybe this is how we finally do #2377543: Add "Add" item to toolbar..

However, they could all contain common elements, such as the Messaging/Announcements system that this very channel is focused on. Perhaps a two column layout, where the left column is persona based, and the right column is common across all personas.

Maybe it could be worked in with this issue #3203618: New “content creation” menu proposal which is essentially advocating for a persona based toolbar.

Perhaps, a persona based dashboard, would make it easier for us to do #2862859: Create a top level, extendable, "Content" admin menu route that behaves like "Structure".

[In response to doing this using Layout Builder] Definitely! We have way better tools in Core now to make this work in a sustainable way, compared to the D6/7 days.

Okay so here's a "back-of-the-napkin" model for doing this using existing core components:

1. dashboard module, defines a content entity type called dashboard which supports bundles, and defines a dashboard_variant config entity type;
2. There is a default dashboard_variant which is used as the "default", but admins can add new "personas" or "variants" by adding a new bundle, default cannot be deleted;
3. Each dashboard_variant (or "persona") has Layout Builder overrides enabled by default and we alter the forms to make it not possible to disable overrides, but individual personas (dashboard_variant config entitles) can be disabled or deleted (which would be the equivalent of turning off layout overrides for node or any other entity type);
4. The Standard Profile ships several "personas" to match the roles (e.g. Admin, Content Editor, etc), and we have some kind of way of matching a Dashboard to one or more roles (maybe just used the conditions system that Blocks use for visibility, but with only role based conditions, none of the page stuff);
5. Let's say the user-facing path is /admin/dashboard, on /admin/dashboard the user is presented with whatever "persona" is applicable to them;
6. Optionally the user can choose to customise their view of the Dashboard, they do this by triggering something (e.g. by clicking a "Customise" button), the first time they do this a new dashbaord entity is created, attached to that user, and the Layout from the applied "persona" is copied to that entity behind the scenes;
7. /admin/dashboard now renders that user's dashboard instead of the "persona" dashboard;
8. The user is then able to edit their own dashboard using the Layout Builder UI, maybe there's some kind of curated list of available blocks, because all the normal ones probably don't make sense;
9. The user can also "revert" their dashboard back to the default, doing this would behind the scenes, just delete their dashboard entity, meaning for them /admin/dashboard automatically just falls back to displaying the appropriate "persona" (or dashboard_variant).

There, I just designed a fully featured Dashboard system, with persona and user-level customisations using entirely existent core components. Take that D7 Dashboard!

There were other ideas/responses/discussion in the thread, this is just what I contributed during the discussion, I didn't want to publicly share anything other people said, I will leave it up to those individuals to contribute their ideas.

I somehow didn't know about the existence of this issue but OMG. 😍😍😍 This looks SO great! Excited to see how this evolves, and please let me know how I can help! :)

The latest usability review of #3206643: Project messaging channel in core (as experimental) recommends using a Dashboard for the announcements.

The Standard Profile ships several "personas" to match the roles (e.g. Admin, Content Editor, etc), and we have some kind of way of matching a Dashboard to one or more roles (maybe just used the conditions system that Blocks use for visibility, but with only role based conditions, none of the page stuff);

Roles are additive, so an admin can also be a content editor - if someone has more than one role, and each role matches a dashboard variant, how do you choose which dashboard they get? We also don't have metadata for roles except for the special superuser admin role, i.e. there's not really a way to indicate precedence.

It would be a lot simpler to use the existing block visibility system - i.e. you either have access to a block or you don't, and then the combination of roles/permissions that you have determines which blocks show in your dashboard. This would mean only one dashboard with blocks that might or might not show on it. Would likely be a lot messier for people with lots of roles, but the roles system just doesn't allow for per-role functionality, it's always been only a way to determine permissions, not something to hang logic off itself.

Agreed that the main issue with the old dashboard that there was nothing much on it, and also while it didn't have big technical problems (compared to say quickedit or overlay which were added around the same time) it also didn't provide a basis for contrib to build on. In this case the layouts system is already the basis for contrib to build on, which is good, but I'd be wary about adding a whole layout variant infrastructure to core especially given the above concerns about choosing variants based on role.

Roles are additive, so an admin can also be a content editor - if someone has more than one role, and each role matches a dashboard variant, how do you choose which dashboard they get? We also don't have metadata for roles except for the special superuser admin role, i.e. there's not really a way to indicate precedence.

But roles do have weights, and the UI tells you to weight them from least powerful to most. So we could just say “the heaviest role the user has” or whatever.

Here's the relevant help text at the top of /admin/people/roles on 10.1.x:

Here, you can define the names and the display sort order of the roles on your site. It is recommended to order roles from least permissive (for example, Anonymous user) to most permissive (for example, Administrator user).

Especially given the proposal includes "customize your own" and we're just talking about a default dashboard setup for you, the one based on your most permissive role seems totally fine.

There's a group of people that have been working on this for a couple of months already, and on today's call we discussed that we need to update this idea, but you beat us to do that.

While we work on that, some links:

* We are communicating in the #dashboard channel on slack.
* We have a sandbox at https://www.drupal.org/sandbox/penyaskito/3327580
* You can find a demo at https://github.com/penyaskito/dashboard-initiative
* You can see the demo online at https://main-ps44ayjkzq3gdy5zk1fifpraj8ctkihy.tugboatqa.com/

But roles do have weights, and the UI tells you to weight them from least powerful to most. So we could just say “the heaviest role the user has” or whatever.

That still tracks to essentially security concerns rather than UX. 'User admin' would usually be the 'heavier' role than 'content admin' for security reasons, but this doesn't mean it's the main role of the account. Say I'm a content admin on d.o and have blocks with comments and nodes to review, then I get additional user admin access to block spammers and suddenly those blocks disappear.

I did have one thought which would be to implement the role based dashboards as tabs, and then you'd have access to whichever ones you have access to. Has its own problems but would mean that people don't lose access to stuff they're relying on when roles are added.

So, for context, I think we've moved past the idea of this being based on roles and instead are focusing more on Dashboards which meet specific personas.

So for example, you could have a dashboard focused on content creation/management, or another one focused on site administration. My ideal vision (and this is just my perspective) you could decide to place a dashboard anywhere that made sense, so for example you might decide to place a content focused dashboard under /admin/content, and then it would appear there as a tab.

OK if that's no longer the plan it's probably not worth talking about the drawbacks with it, but tagging for issue summary update.

The effort reminds me #1840500: Add simple blank page creation capability

Updating issue summary with existing plan and proposal. We're organizing ourselves at the #dashboard and #admin-ui channels in Drupal Slack for anybody willing to get involved or with any questions.

It might be an option to consider an initial dashboard that shows various things based on permissions only, and otherwise isn't customisable. Tailored ones per persona are obviously better, but the current state of seeing /user is really bad. So this could be a two-phased approach with the first one being the same for all and later versions being customisable.

Wordpress and Joomla provide standard dashboards and they're not perfect, but still better.

Or maybe this is a separate task to create a nicer destination for login? Since it seems based on #18 this has expanded a bit beyond just the login use case.

@pameeela That's mostly the plan :D

You can see the current progress at https://www.drupal.org/project/dashboard. There is a tugboat link available that you can use for a live demo of the standard profile defaults (admin/admin, editor/editor). Join #dashboard on Slack if you want to discuss, we should shortly update again this idea description.

Ah very cool! I missed that detail in the issue summary that it was building on an existing contrib module. It looks awesome!

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.