POC: Dynamic Dashboards / Dashboard apps

[madsrasmussen]

Dynamic Dashboards / Dashboard Apps

Context: #19575 (comment)

Register a dashboard

{
  type: 'dashboard',
  kind: 'default',
  alias: 'My.Dashboard',
  name: 'My Dashboard',
  weight: '1000',
  meta: {
    label: 'My Dashboard',
    pathname: 'my-dashboard',
   },
  conditions: [
    {
      alias: 'Umb.Condition.SectionAlias',
      match': UMB_USER_MANAGEMENT_SECTION_ALIAS,
    },
  ]
},

Register an app

 {
  type: 'dashboardApp',
  alias: 'My.DashboardApp',
  name: 'My Dashboard App',
  weight: 100,
  element: () => import('./my-dashboard-app.element.js'),
  meta: {
    headline: 'My App',
    size: 'small',
  },
 }

App Element

import { html, customElement, property } from '@umbraco-cms/backoffice/external/lit';
import { UmbLitElement } from '@umbraco-cms/backoffice/lit-element';
import type { ManifestDashboardApp, UmbDashboardAppElement, UmbDashboardAppSize } from '@umbraco-cms/backoffice/dashboard';

@customElement('my-dashboard-app')
export class MyDashboardAppElement extends UmbLitElement implements UmbDashboardAppElement {
  @property({ type: Object })
  manifest?: ManifestDashboardApp;

  @property({ type: String })
  size?: UmbDashboardAppSize;

  override render() {
    return html`
      <umb-dashboard-app-layout headline="My Dashboard App">
        <p>My Dashboard App</p>
      </umb-dashboard-app-layout>
    `;
  }
}

export { MyDashboardAppElement as element };

declare global {
  interface HTMLElementTagNameMap {
    ['my-dashboard-app']: MyDashboardAppElement;
  }
}

[warrenbuckley]

I love this concept. Hopefully it transitions from a POC to a real thing 🤞

[enkelmedia]

Context

I wanted to add some context to this PR so that people who have not been involved in the discussion can get up to speed about our initial ideas/plans for this.

Background

As the author of The Dashboard, which provides a simple dashboard targeted for backoffice users, I wanted to expand the feature set to allow other package developers to build "widgets" for The Dashboard. This would allow e.g. uSync, Umbraco Forms, Translation Manager, Skybrud Redirect or other packages to provide widgets that could be shown in the dashboard.

A very big problem with this approach would be that each and every package would have to ship another NuGet-package for the widget with a dependency on their own package and "The Dashboard" to provide the widget.

With this in mind, I talked to Umbraco HQ and @madsrasmussen about the idea of putting the core foundation for these "widget-based dashboards" into the core, and this PR is a first draft of how this could look. In this PR, a "widget" is called dashboard-app to align with the current naming conventions in the core.

The "roadmap"

@madsrasmussen and I talked about this during the MVP Summit at CodeGarden 2025. The initial goal, and the most important part is that the foundation/framework for this is included in the core. Most likely, the default behavior for a vanilla Umbraco site will be to not show anything related to these new dashboard-apps by default.

But. a package like The Dashboard could configure both the dashboards and provide a set of dashboard-apps. This way, the feature will be "opt-in" and the complexity and workload of maintaining the dashboard-apps will be handled by the package community.

With the foundation for dashboard-apps in the core, any package developer can just ship one or more dashboard-apps with their default NuGet package if they want to.

Some more thoughts that we've discussed:

• dashboard-apps could come in different fixed sizes, like small, medium, large much like how iOS and the Homey dashboard works https://homey.app/en-us/news/introducing-homey-dashboards
• The layout of dashboard-apps could be stored on the user level using the user-data API

My feedback on initial PR

I've been playing around with the source code and I have a couple of things that I think needs to be discussed. I appreciate the idea of keeping the scope as small as possible so some of the things that I raise here might not be included in "v1" but I think it would make sense to ensure that we have a roadmap.

Sizes

I like the idea and simplicity of having fixed sizes, but when I was looking to implement some of the "apps" from "The Dashboard" I was left with limitations that I could not get around.

The proposed approach with small, medium, large would look something like this:

"The Dashboard" package has several boxes that take up 1 column but more rows - I think we're missing something here.

I think we need to find a way to support these "higher" apps that might not need a lot of width. So maybe if a dashboard-app could provide it's width and height as columns or rows or if we could introduce more sizes like small-high or something.

User specific and defaults

The current implementation (which I know is just a POC) just lists all registered dashboard apps that matches the conditions. In the "real world", it would be ideal if the user could choose the apps to show and save these settings. maybe using the user-data API.

This brings up another issue about defaults. Let's say that we're running a website for a customer and they add a new User, when this user logs in for the first time - it would be ideal if there was a way for me as the developer to provide a "default" dashboard configuration so that we're not just showing an empty canvas for them.

It could be as simple as showing all registered dashboard apps until user makes any changes, but ideally it would be nice if there was a way to configure defaults for this, even better if this was extendable so that implementors could create defaults based on e.g. the user group. Maybe a dashboardAppsDefaults extension point where this could be done from code.

Default "look and feel"

I'm conflicted about this one but I want to raise it. Forcing the dashboard app to be inside a umb-box makes a lot of sense to provide a consistent look and feel, I'm wondering if this is limiting the possibilities. For example: It would be impossible to implement something that looks like the counters or the expandable box here:

I'm thinking that maybe we should leave this up to the implementor to decide, maybe provide a base class like UmbDashboardAppElement or something that is used in examples etc. but also provide a way to drop the wrapping box if someone wants to.

Anyone that is interested in this, please feel free to drop any comments, feedback and or/ideas.

Multiple Instances of a dashboard app

If a dashboard app provides configuration (say that we want to create a dashboard to show a certain Google Analytics property) would it make sense to allow multiple instances of the same type of dashboard app? So that each instance could have different configuration?

Charts

I'm guessing that there will be several dashboard app implementors that wants to use charts in some way. Right now, Umbraco does not ship with any chart library, if we leave it up to each developer to include a chart library we might end up with having 10 dashboard apps with 10 chart libraries shipped and bundled with is not optimal. I know that including this in the core is probably not something you want to do but I wanted to raise the issue.

Mood board

I wanted to share this "mood board" that I cranked together with the help of Lovable. To be able to allow the "freedom" used in some of these apps, we probably need to ditch the uui-box and allow the implementor to set this up.

[madsrasmussen]

Thanks for the very nice summary @enkelmedia. I think you are on point in more or less all of your cases. I will address a couple of them in this comment, and then we can go through all of them during the next period. I think you already have suggestions for many of them in your PR. 🙌

Default "look and feel"

I have pushed an update to the PR that allows for more flexibility. We now have an UmbDashboardAppLayout element you can use inside a Dashboard App. It will give the "Default" look and feel with the uui-box, headline, and at some point some actions. I have updated the description of the PR to include an example.

Sizes

We might want to try out some different options for the general layout and size options to figure out what works the best. It might also make sense to use some more descriptive size names so we have room for adding more in the future. Thinking out loud here: "Tall," "Landscape," "Portrait," "Wide." 🤔

User-specific and defaults

I think it is really interesting how we will support the "Default" setup. It could be the three-step system that you mention:

1. weight and conditions
2. some configuration
3. user customizations.

I am open to giving all of them a try.

I would like to introduce some good DX around the "Custom User Data" endpoints. With a repository, a good way to store data for the correct key, and maybe some additional helpers in the CurrentUserContext when we want to store something for the current user.

Moodboard

Thanks for the very nice moodboard. When we can make that, then I think we are in a pretty good state. 😃

[enkelmedia]

✅ Look and feel

Great stuff with the UmbDashboardAppLayout!

✅ Sizes

Thinking out loud here: "Tall," "Landscape," "Portrait," "Wide."

I like that as well, sounds like we should use words like that.

✅ User-specific and defaults

About the Custom User Data I think it sounds great to improve this, I just used the service directly for the POC but I suspected that we needed to change that.

About defaults, personally I would love if Administrators could store as default and maybe choose either for all users and/or a specific user group. But I'm not sure where this could be stored. Maybe in umbracoKeyValue, but not sure if that is exposed in the API. The User Data API is implemented on the server side to automatically set/return data for the current user so I don't think that's a viable option without changes.

🔮More "stuff"

I've been thinking about a couple of more "things" that we might need to address.

Remove apps

I just slapped in a remove button, but since we now support different layouts where maybe the uui-box is not used, we might need something prettier :)

App specific settings

I'm talking about something like "Which metric to show" for a KPI-app or "Number of items to show" for a list and similar. In my POC, each instance of an app have a unique key, we could just expose this key and leave it up to the developer to store any settings if the app supports settings. Another option is that we spend some time to provide a unified UI and API for this, maybe by providing a "settings" object that we store together with the layout in User Data.

Layout settings

Here I'm talking about e.g. the size to render. If a single app should support more than one size (which they probably don' have to) we need a way to change the size.

This is how it looks in iOS

Personally I think that it would be cool if we could avoid adding a resize-handler, feels like that might make things complicated.

Maybe my remove icon should be replaced with some kind of edit menu or something.

[enkelmedia]

Figured I'll add the screenshare of the current state of my PR-branch (that hopefully will be merged into this) so that anyone that is following along can pitch in feedback.

This shows:

• A dashboard in the Members section
• How to add new dashboard apps
• How to enter edit mode and re-order apps
• How to remove apps
• That the state is stored in User Data and loaded when dashboard is revisited.

[nathanwoulfe]

I have nothing to add other than this looks brilliant.

[madsrasmussen]

@enkelmedia "App-specific settings."

Should we go all the way and make it "Data Type"-like? You pick an App (Property Editor), it comes with flexible configuration defined through the manifest, and we store it in the database. It will require a Management API and all of that jazz. It is out of my area of expertise, so it would require you or someone else to want to do that part.

[enkelmedia]

@madsrasmussen

Hmm, did not think about that as an option. It would be really cool. I mean, technically, that could be implemented by:

• Adding a meta field to the dashboard-app manifest so that devs can indicate settings (much like settings for a Property Editor UI)
• Rendering these properties in the UI when an app "edited"
• Storing the values in User Data

Maybe I'm missing something, but given the setup above, that would not require anything from the Management API?

[enkelmedia]

I've been thinking about the default layout for the dashboard apps, if we use the uui-box and it's headline that might stear people into always adding a "regular" headline which would also add the gray border underneath.

I'm kind of inspired by the mood board

Maybe we should have a "special" kind of uui-box for the UmbDashboardAppLayout that would allow for:

• A optionalk "pre-header" that would be presented in a lighter gray color
• A "header" that would be presented as the main

This way we could ensure that we have a more consistent look and even even if someone creates a dashboard app that does not have a "headline" in the same way as a uui-box needs.

@madsrasmussen let me know what you think, would be happy to implement it to try to see how it looks.