[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

[olafgrabienski]

@jenlampton Thanks for the information, that sounds like a good start! (Unfortunately I've no time to test the PR in these days.)

I had asked because I'd like to avoid that people with few permissions get redirected to a dashboard with a lot of blocks which they can't use, e.g. a content editor usually isn't allowed to configure content types, and he or she often isn't allowed to configure menus. Given a role with the new Dashboard permission, will such blocks be visible by default for people of the respective role even if they don't are allowed to use them? Or will single dashboard blocks be automatically rendered (or not) according to roles (permissions)?

[klonos]

... @olafgrabienski I understand your concern, but if we have enough blocks added to the dashboard, then people redirected to it would still get something more useful then what is currently in the /user page ...even if that is just a single block of "create content" links + an overview of content recently added.

[olafgrabienski]

if we have enough blocks added to the dashboard, then people redirected to it would still get something more useful then what is currently in the /user page

Yes, agreed! Let's however keep in mind how to handle permission questions midterm.

[jenlampton]

We can already set layout permissions per role via visibility conditions.

But not in a simple way. A permission is something everyone can understand. Plus, providing the permission allows us to do the dashboard redirect, which is an 80% use-case.

Let's however keep in mind how to handle permission questions midterm.

Also, we solve this ^

I would find it more useful to get a "Path to redirect to after login" field [per role]

this sounds unrelated to dashboard... and complicated. Best left to contrib.

and then have that default to /admin/dashboard for all user roles in new installations

It's much better that people are specifically granted this permission. Viewing the dashboard is not something that's safe to assume for everyone.

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.

Contrib, definitely. not an 80% use-case.

[stpaultim]

It's a few days before feature freeze and it would be great to get a sense of what is needed on this issue for it to make it into v 1.12.0?

If anyone is interested in listening to the 20 minute discussion on the Dashboard during the last meeting: It happens from 7:45 to 36:15 (YouTube).

Here are a couple of simple and practical recommendations (I am assuming that default blocks in current pull request will remain there): 1) Remove either page title or block title from default config. It's repetitive. Dashboard and Site Dashboard 2) Put some useful help text in the top block (assuming it stays). Something like: This special layout provides you with a quick overview of what is happening on your site. You can easily modify this layout with blocks of your own or by editing existing blocks, including this one.

My personal wish (not required to make this useful):

3) On the create content block include a link to manage content for each content type that simply links to a preset filter for that content type. Manage Pages = backdropcms.org/admin/content/node?status=All&type=page&title= Manage Posts = backdropcms.org/admin/content/node?status=All&type=post&title=

[stpaultim]

There was some confusion in Gitter last night about the discussion during last meeting - 7:45 to 36:15 - around "to module" or "not to module."

I went back to the discussion and here is my quick summary. There was some discussion about whether or not the dashboard is owned by a module at all. I believe that the consensus was that it should probably be owned by some module so that users can turn it off without deleting it. If it's owned by a module, it can be reverted.

What was less clear was whether it should be it's own module or be a part of the system module or the layout module. The main argument against creating a new module seems to be that it's not necessary for what would be very little code. I understood the main arguments in favor of a custom module to be that it's just easier to understand and more logical (in terms of what some people will expect) and provides future flexibility. I'm sure that I'm missing some nuances to the discussion.

Personally, I find the simplicity of having a specific module comforting, but I do not feel strongly about this. I'm still confused about where any default blocks for the dashboard will reside if not in a dashboard module. I would think that if I'm using a dashboard, I want access to some default blocks, if I'm not using the dashboard, I don't need access to these blocks. I would assume that I would turn them on and off in the module. Without the module, I assume the default dashboard blocks would be there all the time, even if I delete the dashboard layout.

[docwilmot]

@jenlampton, to module or not to module? It should be quite simple to shift the code to its own module, so pretty sure can get this finished. Unless you are working on it now.

[jenlampton]

to module or not to module?

to module!

Dashboard module would implement maybe only three(?) hooks: 1) hook_permission() 2) hook_menu() (for the settings form) 3) hook_config_info() (for the setting)

... unless you can think of something else?

Unless you are working on it now.

Nope, but I'm happy to review!

I'm still confused about where any default blocks for the dashboard will reside if not in a dashboard module.

@stpaultim The blocks should live in the modules that provide the content. Node module would provide the node stats block, and the node/add links block. User module would provide the user stats block. Comment, the comment stats block. Taxonomy, the taxonomy stats block. etc!

The reason these need to be with their parent modules, is that we'd want the comment dashboard block to disappear when comment module is disabled, likewise for Taxonomy.

Without the module, I assume the default dashboard blocks would be there all the time, even if I delete the dashboard layout.

This could be seen as a feature. Want a different dashboard? Disable the layout (or the module) and use your alternate module instead - the blocks you need will still be there! Or, place the dashboard blocks on your user profile, instead!

[jenlampton]

Hm... After looking at the latest PR - I'm not sure about moving all the admin dashboard blocks to their respective modules.

The reason these need to be with their parent modules, is that we'd want the comment dashboard block to disappear when comment module is disabled, likewise for Taxonomy.

I think as long we a add a ton of if module_exists() checks in dashboard module, they may be okay where they are. It'll be messy, but the same end result can be accomplished.

Without the module, I assume the default dashboard blocks would be there all the time

I suppose you could make your dashboard module depend on the core one if you needed it's blocks...

I could be convinced either way here... so leaving to @docwilmot to decide :)

[quicksketch]

After having looked at https://github.com/backdrop/backdrop/pull/2452, I'm convinced this did need to be its own module. Thanks @docwilmot for putting it together.

I also think having Dashboard module own the blocks makes sense and is a good fit the way it is currently implemented.

I left a short review at https://github.com/backdrop/backdrop/pull/2452#pullrequestreview-188584831.

[docwilmot]

Looking at this again I wonder if the blocks provided by this current PR might be mostly the wrong idea. The way I envision this, (see https://github.com/backdrop/backdrop-issues/issues/495#issuecomment-142334793 above), the Dashboard should be providing more information rather than links to create and configure and manage stuff. i.e. the "Create content" block, and the "Menus", "Content types" and "Taxonomies" blocks are probably not very necessary.

[jenlampton]

I agree the point is to provide information, but after people have the information they usually want to do something with it.

In my experience with total_control, the create content block is the most used block on the dashboard.

My guess is that this is because while people are looking at the status of everything, they then realize that something else needs to be created, and having this block right here helps them do that quickly. The same goes for the links to other parts of the administration. Usually people follow a trip to the dashboard with an action, so making that action simpler for them improves UX in general.

[docwilmot]

Understood, but Backdrop has Admin Bar. Those links are all a hover away.

We can provide the current blocks but not make them all default then. This is too cluttered now, with (my opinion) duplicated functionality.

I'm gonna work on new blocks with information rather than action links meanwhile.

[jenlampton]

All my sites had admin menu, too. FWIW.

[fivepoints79]

hallo, sorry but I've not read all the posts. I'm new in backdrop. I've used drupal from 4.x and now I'm searching something different. to me it would be great to have a UX redesign or just some new features. I think drupal (drupal 8 too) has never changed so much in the user experience (and I think backdrop has taken steps forward). for example have a look at Grav admin panel (https://getgrav.org), LaraAdmin (http://laraadmin.com) or Wordpress for some inspiration to understand what I mean related to the dashboard. my suggestions are: 1 - don't put too much things in the dashboard, but only the "essential" things 2 - in the dashboard rather than textual information, provide (where you can) graphical information in the form of charts (for example system updates or statistics like grav admin panel do) or icons to provide a quick and intuitive "global" information

other things that maybe go beyond the dashboard 1 - put the admin menu on the left and make it expandable to the left with only icons (like grav admin panel do) and maybe give the option to put it on the top (like drupal navbar module do) 2 - I think the admin menu of backdrop is great, but I think there is another very great module: the drupal navbar module. I think it has a great user experience; it would be great to port it in backdrop and maybe use it as a default admin menu, or maybe use a mixture between the backdrop admin menu and the drupal navbar module; 3 - separate completely the backend and the frontend of the website, like wordpress, grav and other CMS do: so you must login in a completely separate page where there are just user, password, a "forgot password link" and maybe a "new user registration link" and there is not the frontend website theme 4 - I think in the backend there should be a direct link to the frontend website opening the link in a new window and the Shortcut drupal module to provide some menu quick links (and the home links in the backend can disappear) 5 - in the content I'm editing there should be a link in a new window to the page rendered in the frontend and maybe a "split view" mode like SilverStripe or ProcessWire CMS do for example (this view mode can do a preview of a page I'm editing)

thanks

P.S.: is there someone who has in mind to port the navbar module to backdrop? I think it's a great module: https://www.drupal.org/project/navbar.

[jenlampton]

Hi @fivepoints79, and welcome!

This ticket is specifically about the dashboard for backdrop core, so I've copied your other thoughts into other tickets, so that the ideas don't get lost or forgotten when this issue is closed: 1) #1842 2) https://github.com/backdrop-ops/contrib/issues/318 3) https://github.com/backdrop/backdrop-issues/issues/3528 4) this is more on point 3, so added to https://github.com/backdrop/backdrop-issues/issues/3528 5) this also is more on point 3, so added to https://github.com/backdrop/backdrop-issues/issues/3528

P.S.: is there someone who has in mind to port the navbar module to backdrop?

If you would like someone to work on a port for you, you can create an issue in the backdrop contrib queue: https://github.com/backdrop-ops/contrib/issues. We collaborate there on modules that are in the works.

in the dashboard rather than textual information, provide graphical information in the form of charts or icons to provide a quick and intuitive "global" information

Charts are hard, as we'd need to decide on and include a charting library (and what needs a chart!). I don't think it's in scope for this issue. It's a great idea, though, so I've created https://github.com/backdrop/backdrop-issues/issues/3529

Icons, on the other hand, would be a great addition! We can use the same ones that are in the admin bar for matching items on the dashboard.

[fivepoints79]

Hi @fivepoints79, and welcome!

This ticket is specifically about the dashboard for backdrop core, so I've copied your other thoughts into other tickets, so that the ideas don't get lost or forgotten when this issue is closed:

1. #3527

2. [backdrop-ops/contrib#318](https://github.com/backdrop-ops/contrib/issues/318)

3. #3528

4. this is more on #3, so added to #3528

5. this also is more on #3, so added to #3528

P.S.: is there someone who has in mind to port the navbar module to backdrop?

If you would like someone to work on a port for you, you can create an issue in the backdrop contrib queue: https://github.com/backdrop-ops/contrib/issues. We collaborate there on modules that are in the works.

in the dashboard rather than textual information, provide graphical information in the form of charts or icons to provide a quick and intuitive "global" information

Charts are hard, as we'd need to decide on and include a charting library (and what needs a chart!). I don't think it's in scope for this issue. It's a great idea, though, so I've created #3529

Icons, on the other hand, would be a great addition! We can use the same ones that are in the admin bar for matching items on the dashboard.

ok, thank you very much!

[jenlampton]

I'm gonna work on new blocks with information rather than action links meanwhile.

I think these will be valuable too, @docwilmot, thanks for getting started on them!

[klonos]

OK, I have finally gotten to have another pass on reviewing this (meant to do it for months now). Here's my thoughts/suggestions:

"Dashboard" word overload:

I would love it if:

• this section and the respective menu in the admin bar was called "Dashboards" (plural), and various dashboards could be added as tabs/submenus here.
• we removed the title from the dashboard help text ("An overview of your website."), but still have it there as a block so that this help text can be edited.
• we provided an easy way to allow the dashboard tab to be renamed (only the tab label; still retain its path, so that we don't mess with the menu system, the context etc.). Using the "Page title" block in the layout settings to achieve that, changes the page title instead of the tab (of course):

Unsure how these suggestions could fit in the whole this being a layout thing (which I do like btw).

[klonos]

I would prefer it if the human names of these regions were "First half" and "Second half". Although English is not my mother tongue, it feels more natural.

[klonos]

...loving this!:

👍

[klonos]

• We should embed the permissions related to the dashboard functionality in the "Settings" tab.

• "Powered by backdrop" footer block is not needed in the admin pages I think. Do you guys see value in it?

[klonos]

Finally, I think that although it looks and feels OK to adopt the admin theme and its style/patterns in the dashboard pages in general, these are more targeted towards non-admin, content author type of users. So this could use some "blink", like icons for example. I personally find the style in the "Configuration" page (/admin/config) more appealing. Here's how the dashboard could look (rough mockup):

[sbgraphicdesign]

Hi, I'm a bit late to this and I have to say well done for getting this into core, it's a great new addition.

Looking at the latest screengrab for the dashboard there's one glaring omission (imho) which is that there is no update information. Surely a block somewhere to indicate which version of Backdrop you're running, plus any information on updates, as well as available module updates is essential information for a site owner. I'd probably go so far as to suggest a button or link to start the update process would be very useful. The dashboard really needs to be the place where site admins can see all the tasks that need attending to when they log in.

That's my two-penneth!

[herbdool]

I'm not sure if I like adding update info to this dashboard. We already have a status page that has all of this.

[klonos]

@sbgraphicdesign if I look at your suggestion from a Wordpress point of view, it does make sense, because there is a single dashboard for everyone, and there are update warnings listed there AFAIK. The dashboard that we are looking to introduce here though is targeted towards content authors, rather than site admins/owners. In other words, what @herbdool said 😄

Having said that, I thought that you might be interested in #1285 😉

[jenlampton]

I agree with @sbgraphicdesign that we should add an available updates block.

Something that lists ONLY the updates available would be quite handy. We can restrict access on the block to those who have permission to view the available updates page, so it wouldn't get in the way of editors -- if that's how the dashboard is intended to be used on a site. But I don't agree that we should limit dashboard functionality to only editors.

We already have a status page that has all of this.

@herbdool we already have pages for everything else on the dashboard too - on the dashboard it's all summarized in the same place.

"Dashboard" word overload

@klonos I agree about overload, but I wouldn't want to add conflicting terminology like Control panel. We should call the Dashboard the same thing in all places so we don't confuse people.

this section and the respective menu in the admin bar was called "Dashboards" (plural)

I'm not sure your use-case (multiple dashboards) is the majority. I think we should start with one (and a single link) and if it turns out that people end up wanting more than one, we can change that down the line. From my experience with Drupal dashbords - I expect that won't be the case.

we provided an easy way to allow the dashboard tab to be renamed

The utility to make this change is the same as it is for any other layout. I don't think having specialized UIs is a good idea, we should teach people to use the tools we already have (and improve them if they aren't good enough).

I would prefer it if the human names of these regions were "First half" and "Second half". Although English is not my mother tongue, it feels more natural.

what about simply 'First' and Second'?

[stpaultim]

I don't know if anyone has mentioned the lack of an icon in the admin menu. If we are adding this to core in the way it is currently implemented, I think it must have an icon.

If we made it a second level menu item, then it would not need an icon. I'm not sure that is a good idea. I suppose it MIGHT be possible to put it under HOME or REPORTS, but I like it as a 1st level menu item. I added "add an icon" to the list of things to do in issue summary.

"Powered by backdrop" footer block is not needed in the admin pages I think. Do you guys see value in it?

I was thinking that the "powered by backdrop" block is primarily useful as a reminder that the footer blocks are there (default content). I assumed that this block was in all the other core layouts, but I see that we don't have it on the default admin layout. So, I think it would be consistent to remove it from the dashboard as well. For the record, I don't mind it being there and can go either way, it's easy enough to remove.

[jenlampton]

I don't know if anyone has mentioned the lack of an icon in the admin menu.

I noticed that, added one in my latest PR: https://github.com/backdrop/backdrop/pull/2524

[klonos]

...I don't agree that we should limit dashboard functionality to only editors.

We already have a status page that has all of this.

@herbdool we already have pages for everything else on the dashboard too - on the dashboard it's all summarized in the same place.

Hmm, I am unsure about this at the moment, but I may come around 😄

@klonos I agree about overload, but I wouldn't want to add conflicting terminology like Control panel. We should call the Dashboard the same thing in all places so we don't confuse people.

No no, the "Control panel" thing in the screenshot was from my attempt to show what can currently be changed from within the Layout/Blocks UI. It was not meant to be a mockup/suggestion at all. See how I said:

...Using the "Page title" block in the layout settings to achieve that, changes the page title instead of the tab (of course):

I'm not sure your use-case (multiple dashboards) is the majority. ...

Well, I guess that this is the same "to each its own" situation as the one we mentioned during the VUG meeting last week, where some people prefer to have a single layout with multiple blocks, and specify visibility conditions in the blocks; whereas others prefer to have multiple layouts, specify the visibility conditions per-layout, and keep only specific blocks in each layout.

The use case here is this: as a site builder, I want to be able to preview what the content-author-specific dashboard I've built looks like, without having to log in as another user with "lesser" permissions (or use another module like https://github.com/backdrop-contrib/masquerade for that). If I keep all blocks in a single dashboard layout, I then need to imagine what it would look like without the blocks rendered because of the elevated permissions I have. Having two separate dashboards, one for authors and one for admins, helps.

If we are adding this to core in the way it is currently implemented, I think it must have an icon. ... I added "add an icon" to the list of things to do in issue summary.

Yes, of course 👍

[jenlampton]

want to be able to preview what the content-author-specific dashboard I've built looks like

More than one dashboard (regardless of how it is built) is the edgecase I'm worried about. I think most sites will only ever have one.

[jenlampton]

No no, the "Control panel" thing in the screenshot was from my attempt to show what can currently be changed from within the Layout/Blocks UI

Ah, right :)

The use case here is this: as a site builder, I want to be able to preview what the content-author-specific dashboard I've built looks like

The "content-author-specific dashboard" existing at all was the edge case (regardless of how it was built). I expect that most sites will only have one dashboard that works for all people.

So this could use some "blink", like icons for example. I personally find the style in the "Configuration" page (/admin/config) more appealing. Here's how the dashboard could look (rough mockup):

I have taken a stab at some initial styling for the dashboard. I added styles like you liked on admin/tasks and some icons from the admin bar.

[findlabnet]

Question: in case we have 10-15 content types: should we display so huge blocks or somehow collapse/scroll them?

[klonos]

I have taken a stab at some initial styling for the dashboard. ...

Looking good for a first iteration 👍 ...would like more consistency (you know me 😄) with /admin/config though. So:

• black icons and inverted
• upper case for the block titles, and smaller font size

I also think that the help text block at the top of the page should be rendered as description (no border - no white background)

Finally, the icons are rendered to the left in RTL, when they should be on the right.

[klonos]

...also not sure about the arrows in the links. We have introduced these in the more/less links in the modules page, so they might give the wrong impression that there is something that will be expanded/collapsed when they get clicked.

[jenlampton]

...also not sure about the arrows in the links

removed those :)

...would like more consistency (you know me 😄) with /admin/config though

My initial version was attempting to match the style at admin/index not admin/config but you do raise a good point that those two pages are also not consistent with one-another.

My latest PR attempts to bridge that gap, and bring the icons used (in both places) into alignment with those added more recently to admin_bar.

The latest version includes a new available updates block.

The latest version also includes the changes for the names of the regions in the Sutro layout. I've left those in a separate commit though, incase @quicksketch or whoever merges this doesn't want it to be lumped together with the dashboard changes.

Here's the dashboard in Bartik and Basis:

[klonos]

...cross-posting what I have posted in https://github.com/backdrop/backdrop-issues/issues/285#issuecomment-469889529

From https://forums.classicpress.net/t/classicpress-1-0-0-aurora-release-notes/910

Admin dashboard. WordPress-specific features like community events and featured plugins have been removed and/or replaced with ClassicPress equivalents. For example, we’ve added a “Featured Petitions” widget to encourage community participation in our development process.

Can be a follow-up, but definitely want a "News" block.

[laryn]

I like this direction! In terms of content, having a list of unpublished (incl. scheduled) content would be useful, I think.

[jenlampton]

See https://github.com/backdrop/backdrop-issues/issues/3566 re news block. Also added to this issue's description.

@klonos I'd love to get this issue to RTBC - can you make a list of all the feedback you had on the PR? even in general, so maybe others can help get those last changes in?

@laryn I love the idea! Added to the list of other blocks we could/should add in the parent issue :)

[klonos]

Hey @jenlampton ...sorry, I got sidetracked this past weekend. I'm working on it today and over this coming weekend though.

[quicksketch]

I'm giving this a look over now and writing some initial tests.

[quicksketch]

A possible idea/suggestion: Should we make all these Dashboard blocks exclusive to the admin/dashboard path? Having these blocks available globally on all layouts seems unnecessary. I believe we can specify a dashboard context in hook_layout_context_info(), which is restricted to the dashboard path only. Then these blocks won't show up anywhere else. Thoughts?

[quicksketch]

Reading through the code I found a number of places where the dashboard is already locked to a single layout, either by checking the machine name for exactly dashboard or by checking the path is admin/dashboard. To allow multiple dashboards at all, we need a way to identify layouts that are dashboards vs. a normal layout, so I think using hook_layout_context_info() will solve that, even if we don't lock down the blocks to just the dashboard.

[laryn]

I think it makes sense to have dashboard-specific blocks only available on dashboards.

[jenlampton]

A possible idea/suggestion: Should we make all these Dashboard blocks exclusive to the admin/dashboard path? ... Then these blocks won't show up anywhere else. Thoughts?

I would like to be able to add dashboard blocks to the user/% page, for the cases where I turn the user page into each person's own dashboard. I think I can still achieve that by using hook_layout_context_info() and as long as that's true, I'll be satisfied. I'm going to give it a try.

[laryn]

Hmm, I like that idea too!

[jenlampton]

Installing with the dashboard PR redirects me to the dashboard immediately after installation. Though I personally like this, it was not intended. I think we need to add an additional check to dashboard_user_login() so we don't redirect after installation.

edit: nate added this.

[quicksketch]

Well after some last-minute scrambling to get the tests all passing and unexpected edge-cases resolved, https://github.com/backdrop/backdrop/pull/2633 seems good to go. I've merged it into 1.x for 1.13.0. Thanks @jenlampton, @docwilmot, @klonos, @opi, @stpaultim, @olafgrabienski, @laryn, @fivepoints79, and everyone for your extensive feedback and help getting this put together!