 Hello everyone. Thank you for such a warm welcome. We didn't expect such a packed room and there's still people coming in. So we are here for talking about the dashboard initiative. This is something that we kicked off like maybe eight months ago. So the session is called, so I logged in. Now what? The dashboard initiative and we are, I'm Christian Lopez. I'm Penya Skeeton, Drupal.org. I work as a freelancer and I come from Seville, Spain, and here we have And I'm Christina Chameleas. I work for Lulavot. You can't find me on Secrena or Lulavot. Sorry, Drupal.org and I'm a front-end developer and usability maintainer, core maintainer and provisional front-end core framework manager. Okay, so let's start. Yeah, we are trying again to have a dashboard in core. Yeah For those of you as me, well actually it happened before I actually started or even I didn't know that it happened before until I actually tried to do that. So Drupal 7. There was this attempt. There wasn't no customization by default. It was the same thing for site builders, for content editors. It basically provided the dashboard page in the administrative interface and that was it. You could see who was new, which is super important, who's online and at the beginning it don't make sense and probably the idea was actually to come up with a lot of things and people would provide its own things, but actually the reality and I don't want to destroy people's work on the past because it actually was a really good idea. But the problem is that for whatever reason it didn't end up like the way we wanted and even a lot of people created ways to actually disable it by default. Yeah, just somebody told me that it still exists anyway. So and I'm gonna just say that it it's not good to say bad things about what happened in the past because the effort was really good. So the thing is that if we didn't want to fall in the same problem that actually people would disable what we were doing, we needed to figure out which were the problems that we wanted to solve for people. And one of the first problems is that come on, we would log in and you're redirected to slash user. Hi, you've been a part of this site for two seconds. So okay, so if we actually change that what are we going to do? Yeah, great idea. Let's move let's redirect people to admin slash content and actually this would work for for content editors, but it might not be suitable for like administrators or site builders. So it wouldn't be useful actually. So, okay, I stepped in. Well, you're redirected to a user and basically the problem that we are trying to solve is different for each user. Each user will want to start on a completely different point and they will actually have completely different tasks that they want to achieve. So there isn't nowadays any centralized place that gathers most of the user tasks for per each users. So what if you want to go to, for example, slash admin? There's nothing there for most of the people neither. So seeing relevant content for users that actually want to see content even that needs several steps. For example, if you want to see the content that has been edited by a specific user, your own content, for example, what if you want to see content that is not published? Probably the default experience is not going to solve that. There also isn't a place for site-wide communications. What if we want to say there is going to be a maintenance happening at some point in the day or next week or please stop sharing whatever. I don't know. There isn't a way like where we can actually communicate to all users. So, well, together with all these questions, the bigger question was like which is the content that we have to have in there? If we want to have a dashboard, which things, which things are we actually going to give? And we've actually been working on that and we will love your feedback, but this is going to come after. We started the work to get there, defining user personas. We needed to define what people want to see and which kind of content, which kind of blocks, and for whom, like which thing each user wanted to see. So, historically, the user, the admin interface for Drupal has been for site builders and there hasn't been that many things, only focus for content authors, for example. And actually Drupal gives a lot of flexibility to do stuff for content authors. It is that most of us actually don't customize the site for the final users, for the content editors, content managers. Or whatever content related. So, we came up with these four main personas. The administrator, site administrator will be one of the personas, the site builder will be the other one, and then we have the content editor and the content manager. And we actually needed it, needed to find which tasks would solve the 80% of cases, because as you, as we know, each Drupal site is a completely different story. But as you might know, we have the page, basic page on all sites, or the article content type on all pages, on all sites. So, we might disable that, but at least this gives some clues to people. So, we need to come up with this 80% of cases and then people can decide if that's good enough for them or not. We started doing that by defining what actually moved people inside the interface. We did that for each of the four user personas. For the site builder, we started to see defining the behaviors, motivations, frustrations. We did that for each of them. It's not that much, that important each of them like being perfect. In here, we basically wanted to see what they would actually need. And that actually took us to a place where we saw that it's not that much about users, what would group them into different places. It actually was the tasks that they attempted to do, or they were actually trying to do when they locked in a Drupal page. So, that's the thing that actually makes the difference between site administrators or maybe site builders compared to content authors or content, any content-related user. So, this is the initial idea that we came up with. What you're seeing here is for the MVP that we're thinking. We are not defining staff for after the MVP. And this is actually thinking about the 80 percent of cases and not thinking with country modules that, for example, could be Google Tag Manager, which is not analytics, it's Tag Manager now. So, these kind of things are CEO-related models or whatever. So, this would be the basic things that each of the dashboards would actually solve for each of them. So, this is actually happening, not as an isolated thing. We are trying to improve the administration itself, how the usability, trying to make the usability better for the whole administration. So, several things that actually we're going to make the administration itself better were happening at the same time. So, for example, the user personas is something that has been used on several of the initiatives that you've seen today. There is no other things that are among here. So, now about the technical implementation. So, we've been working on this for some months and we discovered some stuff in the process. So, first, something that we want to do is having progressive enhancement, like you would think about the front end where, if a browser has some capabilities, you can provide further functionality. So, this is somehow the same. We want to provide some way that you can have useful blocks for your different user personas on your Drupal site, but maybe if, I don't know, layout builder is installed, then you allow people to customize them or something like that. If there are some models that are providing blocks that you can place on the dashboard, you can use them for your users. So, basically a dashboard will be or is just a config entity. We found out there's also some validation of the problem, like we've seen there's some stuff happening on Contrib Space for this. We found there's a dashboard module on Drupal that dates Vienna. We did this talk and there was the author of the Content Planner module. He told us that we are providing dashboards on the Content Planner module. So, it's a problem that it's already validated. It's something that we really want to solve. So, a dashboard will be just a config entity and one of the reasons is because it makes sense, but another one is that we want to provide a way for people that might be using these models to grade to the core initiative one. So, we started with a config entity that can store references to blocks using layout builder. Then we figured out, as you saw on the list note, that there are a lot of movement in terms of the UI of layout builder. There was this pitch work where Gutenberg was getting some funding and it might replace layout builder. So, we decided that we should try to be agnostic about what we use. So, we will provide some way to be defined about how you pick and place those blocks, but if layout builder is installed, you will be able to customize your dashboard as you would do with any content template. Another thing, so initially, this idea was about having role-based dashboard. But in the process of working on this, we figured out that people usually wear different hats and perform different roles. So, at the end, we want to give roles permissions for different dashboards, but I might have, like in my personal site, I'm probably a content author, I'm the content moderator, I'm the content translator and I'm the site builder. So, I would wear all of these hats. In some other sites, you might have different permissions or different dashboards. So, we want to provide some defaults for the standard profile in Drupal Core, but we also want to allow people to customize these for the users. So, yeah, we will have some permissions, administrator dashboards, which allows you to create or edit or delete dashboards. Probably we will make this more granular at the end and then if I can access a given dashboard. And because on the standard profile, we have two user roles, the administrator and the content manager that somehow unifies content editor and content manager. We will have these two default dashboards. So, when I log in on my site, I will go to a dashboard. Which dashboard should I see first? People probably want to customize that. So, they will be defined by weight. Because, yeah, at first we tried to do that by role, but it didn't really make sense. So, we will have, like, the standard list builder that you know from Drupal where you can see all the dashboards you can edit. And because I have layout builder here, there is an edit layout operation so I can edit my dashboard. And I can reorder them, drag them around and reorder them. So, yeah, so one thing that was really hard is finding and doing some research on what should be the core defaults for the standard profile. Probably at the future we will look at umami maybe. And what should be the roles in umami so we can demo how you would expand this for your own site. Yeah, so defining what and for which kind of users. Yeah, so this is a screenshot for excuse my French and my frontend skills. But yeah, so this would be like a default dashboard for content manager, sorry, for a site builder or site admin. They can see the recent comments. Maybe it doesn't fit here. But we didn't have defined all the blocks that we actually wanted to have here. So you would have like blocks, like recent comments, recent content, your round drafts, some admin stuff like clear the cache. I can run Chrome here manually. So yeah, basically you could think that at the end we might want to speak like the typical admin reports status page, convert everything into blocks so you can actually place the blocks that might make sense for you here. And for a content manager, you would see my round drafts. Yeah, content related ones comments. Who was the last user that registered who is online, this kind of stuff. A problem that we found is defining what is available in terms of which blocks would make sense for a dashboard. And there's already an existing issue on layout builder, like the list of available blocks is overwhelming to users. So this is for the content templates, I think. So it was based on the content templates. So when you create your article and you decide that you can customize that with layout builder, it provides a lot of blocks and you can add your custom inline blocks. So now we are adding the layout build, the dashboards, and the dashboards will probably like if we succeed, people will make a lot of blocks. So this list will be even bigger. And not only for the content, but also for the dashboards themselves. So we need to figure out how to work with the layout builder team on a solution for this. And this is something that we didn't define yet. We thought about having our own layout builder block that sends blocks. But then we would need to use that in views. So that means that the blocks, the views blocks that you already have, you will need to duplicate them for the dashboard if you want to reuse them. It's like a lot of burden for administrators or editors or people who is customizing the dashboards. If you have your own blocks in code and you have to extend a specific class, this will probably make harder people to expose stuff to the dashboards, which I think in some way is what made this solution not work in Drupal 7. If people really need to think on the dashboard for providing blocks, maybe they don't. And if there are no content that you can place, maybe the dashboard will die before even getting into code. So this is something that we have to take into account. But yeah, we still didn't reach a conclusion. By now we are just using regular blocks. And we will figure out how we solve this problem together with the layout builder people. We hope to have some conversations here at Drupal.com. And if you have opinions on that, yeah, we can use the Q&A and we will be at the spring rooms during the week, especially on Friday for the full day. So we will welcome all of you. So yeah, we welcome you. We planned some issues to work for the sprints. We are in the dashboard channel in Slack and we have already tagged some issues on the issue queue. So we welcome you there. And yeah, we want to thank a lot of people that already participated here on the initiative. And we are really hoping to put your name here too. So find us at the sprints. Yep, so that's it. Do you have questions or suggestions? So I was curious the Okay, the home box module is what Drupal.org uses. Can you repeat that? Yeah, there's a home box module that Drupal.org uses to allow sort of like per user configurable dashboards. Is there maybe like a further out thought that the dashboard's initiative might include that kind of more like per user as opposed to per role? We had this conversation at the very beginning and we had a very hard know at the beginning on the MVP, especially because most of the time the complexity that Drupal has, it's already too much like to add that we are used to as developers or people that actually have been using Drupal.org for years to know what we want. But for most of the people, it's not usually the main thing. So as an MVP know and we expect if we get that into core, probably it's going to be like an extended thing on country or something like that. So that's not on the roadmap. So as she said, it's not for the MVP, but we are having that in mind. Like with content you could have your articles template and then for note four, you can customize that. So what we are using good allow to do that in country. So we are not providing that, but we are thinking about it for the future. Thank you for the question. Any more questions? I would love to add that we've been working on the content that we mentioned. We created issues for each of the blocks and we will need hands during the contribution day and they are ready to be worked on. So if anybody wants to help on that, we will be around on Friday for sure. And those issues are ready there. So we have work. And if you never contributed to Drupal before, these I think are very affordable tasks in terms that they are very self-constrained and maybe it's like some of the blocks you could do it with views and just export the config and provide that patch with the config. So if you never contributed to Drupal before, I think it's a good first experience. Thank you guys. My name is Dain. I'm just curious how much inspiration is your team taking from other platforms because some other CMSs and especially e-commerce platforms, some of them have really, really great dashboards out the box you install them. They have like some informational charts although that doesn't really make sense when you first install because you don't have information to have charts or views of. But they have next actions and some information and even community news and things like that. So I'm just curious how much inspiration we're getting from other platforms. A lot. A lot. I mean actually the module is basically not just built already because it's not everything is done but we ended up with the list that you just see there. Like we finished the list two weeks ago. Meaning that we've been doing a lot of research things around here and make that wasn't able to come. It's taken ages actually to reveal what other people do. And the most not problematic but the thing that we wanted to do is to be sure that whatever we provide people actually might not use it because as you were saying like for e-commerce doesn't make sense most of the time whatever we do. And that's why we ended up into the conclusion that dashboards shouldn't be per role but per task because then if you want to have a dashboard just for the commerce of or if a distribution wants to have its own dashboard as a config entity and provide that with the distribution itself. It's going to be their dashboard maintained by them but it's something that Drupal core will provide. So already the idea all the time in our head was like trying to lay the base for people to work on top of that. So no e-commerce yet on core but Thank you. So since you've done all this research looking at other systems that have dashboards have you learned anything about the actual dashboard blocks or content that they're creating where you would look at as like good guidelines for people who might be thinking ahead to like how do I build the blocks that might fit into this later or any common anti-patterns that you observed where you're like you know these systems do this in their blocks and we really would encourage the community not to create blocks and contribute that follow these patterns. So when you say other tools you mean other frameworks? You were saying that you looked at a platform for inspiration. So I'm curious like if you have any lessons or takeaways from like how they put them out. Yeah, I have no idea about how they actually and we on the content side we research what was in there not how they actually build that but I'm not sure if you have. Yeah, we didn't take a look on how they technically build that because I'm not talking about e-commerce. I mean from the content side that's what I'm like like what makes a good dashboard block and what makes a bad dashboard block. That's a really good question but the thing is that it depends for the person that has that the task that the person wants to do like what's the goal for that person I want to log in and and see how many new orders they have then that's going to be a task for whoever is going to do that so that's a dashboard that's going to be dedicated to that and we can't provide that in core and go down. Yeah, the thing is that we are really restrained with what is in core in terms of the models enabled by default and this kind of stuff like for the standard profile we are quite constrained but for example Gabor gave a lot of feedback in Vienna about how to make those very visual like you can see a lot of information on a first chance instead of like having just boxes of listing of contents. So yeah as I was saying before this is integrated with all the other things on the I mean UI or I mean UX changes one of the things that will happen in there it's actually we're trying to redesign a lot of things like part of the navigation itself we want to change the layout of the admin interface and change several things and that includes a redesign of several things and dashboard is in there so the new designs are going to land at some point but we don't have that done yet. Are you speaking about the admin UX initiative by chance this week? Maybe you want to do some spam here. Well yes there is going to be a Thursday another session I'm going to give. I didn't want to self promote. I'll do it for you. Thank you. Okay there is another session about admin UX and admin UI changes that we're proposing. She was before sorry. Thanks and this is not so much a question but more a question because I really like the way you're now starting to think of tasks rather than of roles and permissions because we have all seen the sites where you end up with 27000 roles and in the end nobody knows which role is where and everybody gets every permission and you basically build a site that becomes insecure because you're giving the basic content editor the right to destroy the whole site because you need to give them the right to destroy the whole site. So I think the idea of thinking tasks will also make it easier for site builders afterwards to say how do we structure who needs to have what role and I think that would be a really good step forward also to the usability of the site afterwards but thank you very much for that approach. Thanks. Well actually one of the things that we were thinking about was how do we build a site that is like a Google CEO or like Google analytics Google manager whatever. So you needed like several of them. So my question is actually if we are doing this why don't we step take a step back and core will just provide us with a dashboard that is something that I then need to put on a dashboard for either admin or for somebody else. I will as a module developer also write the plugin or something or a block or something that will then be available for that dashboard instead of thinking this just as something so if we do that we can have because you were just saying that if we have commerce it's hard to have commerce because it's not part of the core. It's hard to have commerce dashboard entities within the dashboard but if we just make it a pluginable thing it really doesn't matter if it's core or not I mean it's just dashboard you will have tasks based on roles. There are two different things here one is providing something so people can build dashboard and then we can achieve that and the second one is what should be the default for the standard profile which we have in core so what you are saying is that you want people to be able to provide blocks that they can place in the dashboard we can do that as well as having the standard one that comes out of the box yeah I mean if you install standard you will have that if you like a module can provide a config entity so it could provide a different dashboard or it could provide blocks that you can place on your dashboard maybe you cannot provide like you cannot alter an existing dashboard because maybe you don't know the roles that they already have on my side or the dashboards that they already have on my side because maybe I customize that already but the idea is that yeah you can provide blocks so people can customize that and I can think that maybe commerce could provide like their default dashboards like I have a commerce manager or I have an order manager or I have an order manager or I have a pro and I have a manual payment or if I need to check the manual payments or something like that so yeah so the idea is that we are providing a way to provide those blocks for concrete that right now is just a regular block so you will just provide a regular block it might be a specialized block we want to solve. I think it's time, right? We're over time. Hi, just to add one thing. Hi, I'm Aaron. One of the things that we, I think, because there's a couple of things touching it that could be really powerful is when recipes combine with dashboards. So as a site, because dashboards are config, you could provide a recipe that has a dashboard or like, you know, if Google Analytics, for instance, provides blocks. And if we, you know, graphs came up as one thing, maybe that's something we should talk about as like, you know, what's the standard for like providing graphs for dashboards. So some things there, I think we can, we can think about for sure. Thank you.