[UX] Add a useful dashboard to backdrop

[jenlampton]

It would be useful for backdrop to include a useful administrative dashboard.

Remaining items (before merge)

• [x] Add icon for dashboard to admin bar
• [x] Change all instances of 'administer' to 'manage'

• [x] Remove "Powered by backdrop" footer block

Ideas summarized from comments (can be done before or after merge):

• [x] Add icons to blocks (match those in admin bar)
• [x] Change human names for left/right regions (in Sutro layout)
• [x] Add an available updates block (access limited)
• [ ] Copy dashboard permissions into the settings form
• [ ] Add an unpublished (incl. scheduled) content block
• [ ] Add new blocks with more information

---

PR by @docwilmot: https://github.com/backdrop/backdrop/pull/2400 PR by @docwilmot: https://github.com/backdrop/backdrop/pull/2452 PR by @jenlampton: https://github.com/backdrop/backdrop/pull/2524 PR by @quicksketch: https://github.com/backdrop/backdrop/pull/2632 PR by @jenlampton: https://github.com/backdrop/backdrop/pull/2633

[sutibun]

Message center

Would it be a good idea to have a message center of sorts on the dashboard?

I was reading @docwilmot's comment on #1168 earlier today.

Just had a thought, only slightly related: how about a new feature (two actually) to improve discovery of new menu items?:

• A persistent backdrop_set_message that says "New menu link added! "Contact Forms is now at Structure > Contact Forms."
• (Second feature is the ability to have persistent messages with a "dismiss" link, or even an [X] to make this work.)

Later today, I found myself checking out a demo of Joomla (no, it's not what you think. I'm not a traitor) and noticed on their dashboard, "You have post-installation messages."

This immediately triggered what docwilmot mentioned and got me thinking.

What if instead of permanent messages following you around, we have a place on the dashboard that logs all forms of post-installation messages? Or, shows the latest messages and links to the "message center" where you can see the rest.

I remember previously installing a new Drupal module and seeing a notification above the page on how to configure it but I accidentally clicked elsewhere. Afterwards, I had no way to get back to it. Frustrating.

Having a message center that logs them all in one place would be helpful. Modules can possibly show instructions on where and how to best configure them after installation and not worry about users missing them.

On an unrelated note, how about the dashboard being the default page a user lands on after logging in?

[klonos]

On an unrelated note, how about the dashboard being the default page a user lands on after logging in?

This would make sense for site admins, but not so much for content authors I think.

[quicksketch]

What if instead of permanent messages following you around, we have a place on the dashboard that logs all forms of post-installation messages? Or, shows the latest messages and links to the "message center" where you can see the rest.

Post-installation messages in my mind often mean "problems you may need to take care of", which would be the Backdrop Status Report page. We have a place to make an indicator badge in the admin bar to notify users of issues with their site in https://github.com/backdrop/backdrop-issues/issues/639. That might overlap usefulness with this idea of post-installation messages.

On an unrelated note, how about the dashboard being the default page a user lands on after logging in?

This would make sense for site admins, but not so much for content authors I think.

We could have this be permission based(?) If you didn't have access to the dashboard then you wouldn't be redirected to it upon login.

[klonos]

Post-installation messages in my mind often mean "problems you may need to take care of", which would be the Backdrop Status Report page.

Was about to say exactly the same thing ...plus link to #639 of course (because it is "my baby").

[docwilmot]

Reviewing this after discussion at #1225. I note @jenlampton starts by suggesting we see "which dashboard module gets the most traction in contrib and include that in core when ready" but I don't think any of the current dashboard modules are going to be necessary, since we already have the Admin Bar.

For example this image from Total Control Admin Dashboard shows a bunch of panes (create content links, lists of menus etc) which for Backdrop are a hover away. We don't need those.

I think it would be reasonable instead of waiting for a port, then, to simply decide what features in a dashboard, if any, would be useful in our context.

Things that Admin Bar doesn't provide may be a start. I'd suggest maybe the following:

1. Status pages errors
2. New users/users for approval
3. Recent comments (to see if spam)
4. Recent Watchdog errors/warnings
5. New content published
6. Persistent post-install or post-upgrade messages (I see your comments above re this, but listing for completeness as it was a suggestion)
7. Backdrop.org messages/announcements
8. New modules installed (especially where the config page)
9. etc?

I think we can go through and decide whether we actually need a dashboard or not, and close this if not or start building if yes.

[jenlampton]

@docwilmot I often provide my clients with both a dashboard and the use of admin_menu. Whether they are needed or not, the dashboard certainly is appreciated. People like having a single place to go where they can see everything all at once, those hover effects just don't do it for them.

[docwilmot]

Good point @jenlampton, do you have a preference of dashboard module? That we can port/modify?

[docwilmot]

Or could we just have a layout at /dashboard or /%user/dashboard with default blocks and some rules for access?

[klonos]

Or could we just have a layout at /dashboard or /%user/dashboard with default blocks and some rules for access?

I like this idea better because a) we do not have to port a module b) we put in good use what is already in core.

We could even make this a "Create your own dashboard" documentation recipe that would teach people how to use views, blocks, layouts etc.

[cellear]

I've been collecting ideas for the after-login experience -- is this a good place to talk about them?

[jenlampton]

do you have a preference of dashboard module? That we can port/modify?

yes :) this one: https://www.drupal.org/project/total_control

ideas for the after-login experience

If they are related to a dashboard in core, then yes. But if they are simply related to logging in, then probably not. Maybe create a new issue and if it's the same as an existing one, @klonos will probably let you know :)

[klonos]

Screenshots for reference/ideas:

https://www.drupal.org/project/total_control

https://www.drupal.org/project/workbench

[docwilmot]

so it seems we could do

• a layout at /dashboard
• a template for that layout?
• a few default blocks
• some changes to the standard redirects on user login etc

[klonos]

Yep, seems about right @docwilmot

[herbdool]

My recent work on the comment admin page made me think we need a place to list the number of unmoderated comments and the status report page didn't seem right since it only wants to focus on issues. A dashboard is a better location.

[docwilmot]

This came up recently, so brainstorming:

• does it make sense for blocks built for the dashboard to be available on non-dashboard layouts? we could add some logic so these blocks dont show up unless the layout used has a path used as a dashboard path
• which means we should have an admin setting for which path(s) are dashboard paths
• should we allow more than one dashboard layout/paths?

[klonos]

Ideas:

• Have a "dashboard" layout shipped with core. People can clone it and create more dashboards if they want (although I don't see why - they can use block visibility)
• Add all the dashboard-related blocks to a separate dashboard.module (?)
• We could add a hard-coded "Dashboard:" prefix to these blocks. That would not effectively prevent them from being used elsewhere, but it would allow us to group them together in the list of the "Add block" dialog.

[docwilmot]

We could actually have a custom renderer that displays a totally different add block page for dashboards, so then only dashboard blocks will show on there.

That way we could even enforce "mandatory" blocks, if needed.

[klonos]

Yeah, I think that that makes sense @docwilmot (although it sounds like more work).

[jenlampton]

I don't see a reason for a different add block page, or a custom renderer? I think that might just create more confusion for both end-users and for develoeprs who have to work on this.

The dashboard itself should be an (admin) layout, and to be the least confusing, the UI and block selection process should be identical to any other layout.

Add all the dashboard-related blocks to a separate dashboard.module

I don't think this is necessary. The code for Dashboard blocks can easily be placed into each module that provides the block. Most will be Views anyway, so those will end up being an additional file in the config directory for node module, user module, taxonomy module, etc.

We could add a hard-coded "Dashboard:" prefix to these blocks. That would not effectively prevent them from being used elsewhere, but it would allow us to group them together in the list of the "Add block" dialog.

This is a good idea. We don't currently group blocks in any way, but if we ever decide to do this in the future it will be easy to do so. Plus starting with Dashboard will make the search handy :)

Have a "dashboard" layout shipped with core.

Yes please :) The default Dashboard layout code can live in the same place as the default front-page layout, which I believe is in the Standard profile.

People can clone it and create more dashboards if they want (although I don't see why - they can use block visibility)

Block visibility won't change the layout -- only the blocks. In some cases you want the smaller blocks in a "sidebar" and the larger (view) blocks in the main area, on others you might want three smaller columns. There are use-cases for different layouts (not just different block placements).

does it make sense for blocks built for the dashboard to be available on non-dashboard layouts?

Yes. I've seen many sites where dashboard blocks are placed on user profile pages (for personal or role-based dashboards), or other dashboard layouts, so I don't think separating Dashboard blocks from the others is a good idea.

should we allow more than one dashboard layout/paths?

yes please. I've seen this use-case plenty of times.

which means we should have an admin setting for which path(s) are dashboard paths

We already have a (menu) setting for which paths are admin paths. That should be sufficient for this purpose.

[docwilmot]

I think a dashboard.module makes sense to allow users to turn this off if they want to. I agree with not using a separate renderer or UI. It should be just a layout, like every other.

yes please. I've seen this use-case plenty of times.

Just so we're talking about the same thing, this means mysite/dashboard-path and a mysite/dashboard-path-again and a mysite/dashboard-path-once-again all of which are dashboards. I can see this useful for having a dashboard for sales dept, one for accounting, etc.

but

We already have a (menu) setting for which paths are admin paths. That should be sufficient for this purpose.

If we are to have custom redirects (eg with your Total Control dashboard Redirect administrators to Dashboard after log in) and multiple dashboards, we will need some way for Backdrop to know which paths are being used as dashboards to set up these redirects.

[stpaultim]

Very interested in this topic. Can anyone explain what we mean by "custom renderer?"

[docwilmot]

According to Standard renderer:

Given a fully-loaded Layout object, this class will turn its combination of layout, blocks, and styles into HTML, invoking caching appropriately along the way

The Editor renderer extends that class to make the layout drag-and-drop block placement pages. The point was to create a separate one of those pages, with its own special list of blocks that show up when you click an "Add block" link. And then dashboard paths could also not show up in the list of layouts. They'd be a different 'thing' altogether.

[docwilmot]

I suspect I probably didnt quite explain what a renderer is after all. When you attempt to load a URL, Backdrop calls this class to build the page from the layout template and blocks assigned to that path.

[jenlampton]

I think a dashboard.module makes sense to allow users to turn this off if they want to.

I'm not sure a module is necessary to achieve this. How do people disable the home page layout if they don't want it, currently? I think they delete it? They should be able to do the same for the dashboard if it's a layout too.

Just so we're talking about the same thing, this means mysite/dashboard-path and a mysite/dashboard-path-again and a mysite/dashboard-path-once-again all of which are dashboards.

Yep. My use cases are usually dashboard/editor vs dashboard/admin or dashboard/content vs dashboard/comments or sometimes dashboard/articles vs dashboard/news.

If we are to have custom redirects (eg with your Total Control dashboard Redirect administrators to Dashboard after log in) and multiple dashboards, we will need some way for Backdrop to know which paths are being used as dashboards to set up these redirects.

This feels kinda edge-casey. The core checkbox should probably redirect people to dashboard and a contrib module could add an additional select list of layouts if someone needed to redirect editors to dashboard/editor. I'd imagine that if there are multiple dashboards they'll need more logic than the core checkbox can provide on it's own anyway.

[docwilmot]

Did a PR, minimal, based on Total Control Dashboard. I would like this to have more options for redirecting to the dashboard. I Also wonder about an API for the welcome block. Allow other modules to post full HTML messages there, with the option to dismiss messages. Also wonder if we should change /user to a dashboard as well. Different blocks but same concept.

[klonos]

Thanks for the PR @docwilmot ...looking really awesome 👍

Also wonder if we should change /user to a dashboard as well. Different blocks but same concept.

Yes, I think we should 😄

I realise that this might just be an initial take, and I haven't actually looked at the PR code yet, but here's my initial feedback from giving the PR sandbox a spin:

1. I would expect the "Welcome to your administrative dashboard. ..." thing to be a message of type info. So perhaps do that, and lose the "Welcome" block? ...not sure. If we are meant to give site editors the ability to be able to edit the text in that message, then perhaps consider rendering the text of that block as a message. Message blocks FTW anyone (separate issue)!?!

2. I would expect that the "Dashboard" prefix would be shown in the block descriptions when adding them to the dashboard layout, but not in the respective block titles in the dashboard page itself.

3. Operations in the various dashboard blocks are listed in the "Operations" column as a series of links; they should be drop-buttons instead.

4. The settings tab still references a "Have Total Control" permission. Besides the fact that we should change the name of this permission, perhaps it would better if we embedded the permission in that settings form (shamelessly plugging #3332 in 😄)

5. The "Administer content types" block settings have a "Include Create links for Content Types" label, which is the same as the respective label for the "Content creation links" block (btw I really do not like the word "administer"; I prefer "manage" or "configure" instead).

6. In general, there is a lot of camel case used for labels and titles, whereas we do use normal sentence case for the rest of the admin UI (I realise that this has been inherited by the Total Control contrib module - just mentioning it as one of the tasks that we should address).

7. Perhaps content overview and user account overview should be 2 separate blocks.

8. Would be good to have the "New content" and "New user accounts" blocks.

[klonos]

8. Would be good to have the "New content" and "New user accounts" blocks.

Just saw that there exist 2 separate blocks for content and for users (additionally to the combined one). I have tried adding these blocks to the dashboard layout, the "Content overview" block was successfully added, while the "User accounts overview" could not be added (just a spinning throbber after clicking the "Add block" button, and the dialog does not close).

[opi]

Some ideas in this forum post: https://forum.backdropcms.org/forum/typical-day-user-experience-future-state-story And my +1000 for nice admin and user dashboard, such a great UX improvement <3

[docwilmot]

@opi seen that. Some of the available dashboard blocks to enable that scenario would need to be contrib (the graphs, for example).

@klonos re point number 1 (everything else I agree with), For custom messages, the site admin can create a custom text block to post there, or maybe the dashboard should come with a default text block?

What I was considering is to have some API for displaying messages on the Dashboard. To repurpose that "welcome" block to a message block. It could, theoretically, show:

• messages from BackdropCMS.org
• updates from contrib modules
• notices from newly installed modules
• etc.

but maybe that should be a contrib project, actually.

[oadaeh]

I have not read this entire thread (I've actually read very little about it), but a few trigger words in some of the comments prompted me to point out that some of the statistical blocks (number of visitors, page views, etc.) could be provided Matomo Analytics module. It has a REST API that can be utilized to grab and display specific information. I am planning on using it in that way to display some quick overview information with links to more detailed information.

I know the Matomo Analytics module wouldn't be included in core, and I'm not advocating that, I'm just pointing out something that could be planned for and utilized for site builders/developers extending/expanding the dashboard with other things in the future.

(Also, as an aside, I've always felt that the Total Control module was too overwhelming, especially for a busy site, but maybe there are ways to temper it a bit that I never got into.)

[klonos]

but maybe that should be a contrib project, actually.

I think that it is core-worthy @docwilmot

@oadaeh the way that we are implementing this is by providing a "Dashboard" layout, with some default dashboard blocks out of the box. Contrib modules like matomo can leverage that to provide only blocks, which site admins can then use in order to customise their dashboard(s).

Re the dashboard being inheritably busy, because @docwilmot seems to have based his PR on the Total Control module, I urge you to give the PR sandbox a go. Not sure if these things were options with the Drupal contrib module too, but you will find that there are many settings (in the form of checkboxes) for each of the blocks being used. So people can easily tweak things down to simplify the information presented. ...although I personally find the defaults useful rather than noise.

[klonos]

...just to clarify, re my point 1 in my review above:

1. I would expect the "Welcome to your administrative dashboard. ..." thing to be a message of type info ...then perhaps consider rendering the text of that block as a message. Message blocks FTW anyone (separate issue)!?!

...separate issue: #3408

[laryn]

In case it is useful input here: https://www.drupal.org/project/content_planner

(Just found this and haven't looked it over in depth yet)

[stpaultim]

I like to create custom views for each content type to help editors find their existing content easy. I find that using the content page with exposed filter is not always easy for editors that are not editing content regularly.

In my custom case, I like to give them a link for each content type that shows them a few select fields and edit - publish/unpublish - delete links. See below for example.

Each page looks something like this:

I would love for the BackdropCMS dashboard to include at a link for each content type to the respective content filter.

Page links to admin/content/node?status=All&type=page&title= Post links to /admin/content/node?status=All&type=post&title=

Something like this would be nice:

[docwilmot]

As I see it right now we can provide a layout in Backdrop we call a "dashboard" layout.

All the content on this "dashboard" then would just be plain ordinary blocks. The initial PR may provide some default blocks that make sense on the dashboard, but again, they would just be ordinary blocks that could go on any layout.

All of the suggestions that have appeared on this issue could then be just blocks provided by contrib.

The question is what sort of special treatment, if any, could/should we give this layout? So far, it makes sense that it could have a menu item so it appears on the Admin bar. Anything else? I'm struggling to determine if this would serve expectations by just being a plain layout.

[jenlampton]

I think there are a bunch of other things we could do that would be special for the layout, but I'm not sure we can determine if they would be appreciated by all (or, even most?) until we have a layout in place and people begin to use it.

All of the suggestions that have appeared on this issue could then be just blocks provided by contrib.

Yep! And if there are well-loved contrib modules providing dashboard blocks, those can be slated for core in the future :)

The question is what sort of special treatment, if any, could/should we give this layout? So far, it makes sense that it could have a menu item so it appears on the Admin bar.

Yes, but that could be another layout setting so it isn't even really "special treatment".

Anything else? I'm struggling to determine if this would serve expectations by just being a plain layout.

I think if we can place a sensible set of blocks on it initially, it will be a good enough start. Then we'll be able to iterate with each additional release.

[klonos]

All of the suggestions that have appeared on this issue could then be just blocks provided by contrib.

Yep! And if there are well-loved contrib modules providing dashboard blocks, those can be slated for core in the future :)

👍 to that!

I think if we can place a sensible set of blocks on it initially, it will be a good enough start. Then we'll be able to iterate with each additional release.

Yes, baby steps please 😄.

[herbdool]

I think a comments block is the one addition that would be quite useful now, rather than wait for contrib.

[klonos]

I agree @herbdool ...all I was trying to say is that we should not let trivial tasks that can be implemented iteratively block this from getting in 1.12.

I really love were this is heading! Thanks for working on it @docwilmot 👍

...in the beginning, I thought that the blocks placed on this layout should be "special", and allowed to be placed only in "dashboard" layouts. But that begged the question of how would we then denote a layout as one of dashboard type. Things begin to get complicated that way, so I think that we should keep it simple:

• add a single layout, simply called "Dashboard" to start people off.
• redirect people to that dashboard by default when they log in (instead of the account/profile edit page).
• add some useful Dashboard blocks in the default "Dashboard"
• provide a set of additional Dashboard blocks in core, leave the rest to contrib (but continue adding useful ones in core)

In other words, we should try to get an MVP in for 1.12 so that we have something better than the profile edit page to redirect people to, and then iterate for improvements.

I do like the idea of a menu item in the admin bar suggested by @stpaultim. Instead of making it too specific though ("Editor Dashboard"), I would like the top-menu item to be "Dashboards", and then have all children dashboards under it if possible. We should ship the default Dashboard layout with menu settings, so that people can then easily customise it:

...the above missing menu settings could be #2673 😞

@docwilmot I have "hijacked" the custom text block in the PR sandbox to add messages and info as custom classes to see how that would look. If people like it, then I have also filed a PR that makes rendering custom text blocks as messages in #3408 😉

[jenlampton]

The top level link should be "Dashboard" since the initial core offering will be just one. Anyone adding additional dashboards can change the link from singular to plural, but that's not a 80% use case (or if more than one dashboard is, the 2nd-Nth will not be the same)

[stpaultim]

Quick notes:

1) I hope is was clear, but some of my screenshots were meant to provide inspiration only, there were not intended as recommendations. Example - 'Editor Dashboard' is too specific, it was only an example. Also, I was hoping to remove the need for the multiple dashboard I created, by providing a single block that links to various commonly need views for content editors.

I understand the value of getting something simple in core and then building on it. If I understand correctly, the proposal is moving in the direction of:

1) Providing a default layout in core for a dashboard 2) Providing an admin link to the dashboard 3) To have at least one dashboard block turned on by default and potentially others available for users to use. 4) Other "dashboard" blocks can be added through contrib or by individual site builders.

My questions:

1) IF there are some blocks turned on by default, will it be possible to add (or remove) additional default blocks in the future in a minor release? Can we add/remove additional default blocks in an update that will not screw up existing dashboard layouts? (I think that we can, but I want to be sure) 2) How much theming must be done to a new dashboard before we are comfortable releasing it in core?

My concerns:

1) That if we provide a dashboard in core, that we have sufficient features turned on by default to make it useful right away. While the almost infinite flexibility of a layout dashboard is great, I think that users will appreciate having some common use case features working out of the box. I think that for our target audience it is possible and desirable for us to make some assumptions and test them. If we can add default blocks in the future, I assume that we can also remove default blocks that are not popular or useful (based upon feedback). I question the value of a layout that does not provide sufficient default functionality. I don't want to bikeshed which blocks to enable by default, would rather that we make some assumptions and then tweak the configuration later (assuming that this is technically possible) rather than start without much useful functionality.

[klonos]

@stpaultim what we have been doing throughout releases with admin views (like the default content view for example), is to check if configuration has not changed from the default state, and if so, then update; otherwise not touch it (in order to avoid overriding local customisations). In the case of fresh installation, we'd just ship the new version. I imagine that we'll be doing the same with this dashboard.

People that have customised their dashboards will have to find out about new blocks that can be added to dashboards via our changelog, and then do some manual work to get them added to their dashboards. But hey, we have #3155 in core now, so we can pop up 1-time info messages. I liked what they did with the info message of the Webform module:

...and WordPress also does a great job with this too (#1225):

...as I said in #3155:

...I have plans for putting it into good use 😄

[jenlampton]

IF there are some blocks turned on by default, will it be possible to add (or remove) additional default blocks in the future in a minor release?

Yes, though adding will be easier than removing.

Can we add/remove additional default blocks in an update that will not screw up existing dashboard layouts? (I think that we can, but I want to be sure)

Yes, but again, adding is easier than removing.

How much theming must be done to a new dashboard before we are comfortable releasing it in core?

Hopefully whatever we do will already look good in Seven, so we won't need to do much at all.

That if we provide a dashboard in core, that we have sufficient features turned on by default to make it useful right away.

I totally agree. We removed the Dashboard module because it didn't provide any useful functionality.

would rather that we make some assumptions and then tweak the configuration later

👍

I liked what they did with the info message of the Webform module...

Oh jeez, is that the actual text in Webform? ... /me goes and makes an issue to change it...

[klonos]

How much theming must be done to a new dashboard before we are comfortable releasing it in core?

I am of the idea that we should ship this as soon as possible, even if not perfect. As many of us noted before, it will be much better that the redirection to the user profile page we currently have in place 😉

If we can add default blocks in the future, I assume that we can also remove default blocks that are not popular or useful (based upon feedback). ... I don't want to bikeshed which blocks to enable by default, would rather that we make some assumptions and then tweak the configuration later

Yep, #285 FTW!! 😉

[klonos]

I liked what they did with the info message of the Webform module...

Oh jeez, is that the actual text in Webform? ... /me goes and makes an issue to change it...

Yeah, I liked the idea; not the exact implementation 😆

[olafgrabienski]

Quite early in this issue, there was a discussion about the question if the dashboard should be the default page for all people after login, see https://github.com/backdrop/backdrop-issues/issues/495#issuecomment-140176340:

how about the dashboard being the default page a user lands on after logging in?

This would make sense for site admins, but not so much for content authors I think.

We could have this be permission based(?) If you didn't have access to the dashboard then you wouldn't be redirected to it upon login.

For which role(s) or permissions will the current dashboard work?

[klonos]

@olafgrabienski I think that the idea is that we keep things simple in order to ship this with 1.12. So, I think that the consensus is that there will be a single dashboard layout and page for all roles (we can discuss this in more detail during the weekly dev meeting). Blocks within this dashboard will still be configurable via visibility conditions (which can be roles).

People can easily clone that layout and add more dashboards if they want 😉 ...although we could perhaps get some per-role setting in. There's quite a few contrib modules that implement this sort of redirect-on-login:

https://www.drupal.org/project/redirect_after_login https://www.drupal.org/project/login_redirect_per_role https://www.drupal.org/project/login_redirect https://www.drupal.org/project/login_destination https://www.drupal.org/project/login_redirect_to_front

But that should definitely be a follow-up (if not left for contrib).

[jenlampton]

For which role(s) or permissions will the current dashboard work?

@olafgrabienski we will be adding a new permission called "Access dashboard" (or similar) and if people have that permission, they can be redirected there. Check out the setting in the Sandbox on the PR for how it will work :)

[klonos]

Hmm, I'm not sure I agree with this implementation then @jenlampton 🤔...

• We already have an overwhelming permissions page.
• We can already set layout permissions per role via visibility conditions.

I would find it more useful to get a "Path to redirect to after login" field in /admin/config/people/roles/edit/[role], and then have that default to /admin/dashboard for all user roles in new installations, but leave it pointing to /user for existing sites (otherwise we could be breaking things for people that have built custom layouts for /user in their site and want things to remain that way). This would allow site builders to set some roles to redirect to /user, others to /home, others to /admin/dashboard or /some/other/dashboard-or-page etc. In other words, I think that such an implementation would offer more flexibility, while causing less clutter in the permissions page.

My 2c