A Dashboard that Works: Giving Editors What They Want, But Focusing on What They Need

Uh well, welcome to Drupal Con 2026 in Chicago. [applause] >> Glad you could all be here. Let's kick it off talking about dashboards. This may be the only session that you go to this week that is not about AI. [laughter] >> So, uh here comes some some water. Uh I am Dave Hansen Lant. I'm the director of technical strategy at Four Kitchens and I have been crafting stuff at Drupal for about 20 years. Thank you, Jojo. >> You're welcome. >> And uh I'm Albert Hughes. I'm from Houston, Texas. Uh I grew up on AOL. I learned HTML through library books. Uh I was I learned about Drupal in ' 06 07. uh attended my first Drupal Con in 2010 in San Francisco and I was here in Chicago for Drupal Con in 2011. Um and I appreciate everybody uh who attended the session. >> Glad to be back in Chicago. >> What we're sharing today um we're sharing what we know. This is about something that we learned. This isn't an endorsement of a company uh software or particular module but we want to share what we know and then hopefully you can take away something that you can apply to the work you're doing back at home. >> Yeah. Uh nor an endorsement of a particular high red institution. Uh so sharing what we know this is one of our core values at at four kitchens and yeah leaning into that. So, first off, when we're talking about dashboards, we we want to set the stage of the context that we're working in here because we think it's important to for for how you look at dashboards for your own implementations. We don't want you to to just slap something on your dashboard just because Stanford did it. Uh you're going to have to think about your own context and how that's different from ours and and how what may or may not transfer directly. Well, I didn't mention it, but I work at Stanford in the school of human humanities and sciences in the IT web services team. Um, the school of humanities and sciences is the premier under was the main undergraduate college at or the undergraduate school at Stanford. U the HSDP or the humanities and sciences Drupal platform is a shared platform um for for HSN. So if you're a department, a unit, a lab, uh one of the dean's office offices, you can get a free website. We provide free support. Um there's over 500 editors. So these sites, so we have 130 sites on these sites. There could be one to two editors or 30 20 to 30 editors. So we have about 500 editors across the platform. And then we do continuous maintenance and updates and bi-weekly deployments. And what is HSR HSDP trying to do? So with this site, we want to give editors something where they don't have to worry about the development. They don't have to worry about hosting. They can just get in and do the things that they would need to do. Um, as we said, this is like for compliance. So we want to make sure that they're compliant. We want to make sure that they have integrations with the different systems across the university and be able to just have a have a website where they can take off running and promote the things uh that they want to for students. >> Well, let me tell you [clears throat] about the different teams of people who are working on this platform. So, first off, there there's Albert and his team that's management and sciences web team. uh Albert and his team think about things like product and project management QA got some people who spent a lot of time uh QAing the the changes that we're making overall strategy of of what this platform needs to be >> and the product is the product management of this HSDP platform and then our projects are typically onboarding new units onto the platform or kind of doing a redesign any inside of that particular the platform. And next up is the Stanford web services team. This is uh the wider Stanford IT department and they own the or they they manage the the infrastructure the any backend development and any uh upgrades and technical reviews. And lastly is for kitchens team. We uh spent a lot of time thinking about project management, design and technical product management. So taking the ideas from design and Elbert's team and turning them into a plan and then engineering mo mostly on on the front end. Okay. What do we mean by dashboards? We're not talking about your car. just when you you log into a website and you get an overview of the most important things for for you to be looking at >> life before the dashboard was a little chaotic. When I first started at at Stanford, I would attend a team meeting and we had a full-time contractor and every every week every weekly update I would hear like I'm working on the maintenance report like okay next week I'm working on the maintenance report. And so I didn't know what this maintenance report was. And so when I figured it out for our 130 sites, we would do exports of uh broken leaked reports out of sight impeding room. We would ask our dev to run a report to give us every user with a certain role across every site. We do accessibility checks. So this would take up to 100 hours quarterly to gather this information and then email it out to the units and then by the time they get it, it's out out of date or by the time we circle back with them to see if they opened it, they never even took a look at it. So we would have that and then we would have the same questions come up through support. Uh who has who has editing access on our site? Uh what importers are running on our site? So from that we decided maybe we can surface this information so it's more real time. It's in their face. They can take actionable items immediately when they've seen it. And so that's where we came up with the idea of the dashboard. >> Yeah. And if if you're just getting a a quarterly PDF of something, chances are that may not actually get addressed. Okay. Okay. So, let let's take a look about what's on our dashboard. >> So, we're looking at this. This is a screenshot of the desktop version of of of the dashboard. We started with a long list of blocks. Hey, here's all the here's all the stuff from the maintenance report. Here's the things that uh we want the users to have. Here's the things that users and editors have asked for. And we narrowed it down to 10 blocks that kind of give users what they want as well as giving users what they need. Uh here's here's a view of the mobile version of this. Uh you may notice that there are some non-standard things with with in our screenshots here some little front-end flare and little design flare. If you want to find out more about how that stuff is created, come to the session this afternoon at 4 uh by Andre Zen here in the front. Uh and I believe your title is more immersive experiences with vanilla JavaScript, something close to that. Um, but the the dashboard as a whole is built with the dashboard module singular different from the dashboards plural module. Uh, singular dashboard is pretty new and was included in Drupal CMS. Uh, 1.0 was was when the 1.0 release for dashboard module list and um yeah mostly it's it's just built with Drupal blocks. We're going to go through these one by one and tell you how how we came came to them and uh yeah some custom branding and custom interactions. >> So when we have new features roll out um maybe we've interested a new feature called curriculum maps or we've we've made enhancements to the way that users could create private pages. We communicate these updates in a variety of places. Maybe in a Slack channel. We send out a newsletter. Um we tell it in our monthly office hours oneonone when we speak to clients. Um so we we have these announcements in different channels except for the one place where they're at when they maybe need a help file or need to actually take action. So, we wanted a place to put these announcements and that's why we created the HSDP announcements block so that we can show the latest updates and and link to documentation about them as well. >> Yeah. And for other sites, other big platforms like this that I work on, sometimes people get nervous about making changes that are going to impact content editors and people people don't want to get get complaints about, you know, that suddenly someone can't do something with the website. Something like this really really helps that. just making communication is often the the key in in these kinds of breaking changes that as long as people know that it's coming and and how to deal with it that um you're you're then able to make more impactful changes and and not just always moving stuff by two pixels or whatever. Oh. Uh so on on the back end of of that if if this were just one website then then this thing this could just be like custom a private content type that maybe only uh the developer role could could create but since we got 130 websites here uh and and there's no real like content sharing between them what we do is is this is just a a Google Google sheet on the back end and uh if you change the URL of a Google sheet you can get get it in CSV format. And so then there's just a bit of custom code to to add to turn that into into a Drupal block. See there's some markdown here for creating links to our documentation system. >> And that's been helpful because the same person that does our documentation, they're they have they don't have a lot of coding experience or or getting to the web. So this allows if they want to make updates that goes out to the 130 sites, all they have to do is open this Google sheet, add the new new documentation um update and link and then it's on all 130. >> Okay, for for each of these blocks, we're going to have a slide like this which just summarizes the things that we talked about. So if you want to download the slides later, that's all right there and we're just trying trying to be accessible with it. Okay. Um, my latest edits. So, we all know if you're familiar with Drupal, you know you have the content screen that shows all the content on the site. But with our with the HSP, a lot of our sites do a lot of importing of content from Stanford system. So, it could be full courses and uh all the staff, faculty, it could be events. So, typically when you log in, you're going to see all the imported content. And so if you're an editor coming back to make edits, it's hard to pick up and see, okay, that was the page or this is the page I was working on. So we decided to come up with this my latest edit spot, which allows uh editors to see, okay, this is exactly what I worked on. This is when I worked on it, guys. And then I can get back to work as soon as I log into the site. >> And under the hood, this this is just uh simple Drupal views powered block. And then this gets into, you know, I don't know, we didn't say the title out loud, but we wanted to give a lot of we wanted to get blocks to give users what they want. You know, stuff that they've asked for, stuff that they bring up in support, but now we're getting into what they need. So, we want to keep them and help these editors stay compliant. So, we came up with this block pages with the most accessibility issues. one of the main things that we put in the maintenance report. But now, instead of looking at a PDF a month later and then trying to go back into the website and have the two up, you could just open the site to the dashboard, get to the pages with the most accessibility issues and take action from there. >> Yeah. And what may be a little bit subtle, the the first two blocks that we looked at, that's like definitely not not compliance related stuff. And now we're trying to get into the the more compliance stuff. We we intentionally didn't put this at the top. We're we're not trying to hit people over the head with compliance. It's more like a nudging behavioral economics to just get them knowing that that it's there. And uh so under the hood, this is built by editorially module. Shout out to the folks from Princeton who have put a lot of work into that. I I love editorially module. It run on every every website. It if you don't know, it's it's a tool to help content editors know when they're doing something that is not accessible. Maybe they put headings in the wrong order or something something that that engineering had control of. And and this is basically just the the stock plot that editorially provides >> staying in that same in the same lane of of of giving them what they need pages with broken links. Um we wanted to be able to surface that again and and give them a pathway to see that report and then be able to take action. >> And so under the hood, this one is is definitely more complicated. Uh this data pulls in from site improved. Uh yes there is a Drupal module that handles broken links but we we already had site working with with site improve. If if you don't don't know what site improve is it's like an external platform used for like quality assurance. It'll it'll track tons of different metrics um and even custom ones. uh and we we know that in in the long term we we want to pull in some more stuff from it too. So we decided, well, let's start with the send group stuff. Maybe we'll be able to build on that later. And yeah, this is just a custom block that accesses the send group API. What you see here is on the left a imported profile and on the right is a profile that was created manually by a site editor. What that creates is duplicate profiles or duplicate content on the site. So a lot of time new staff join or like a new faculty member joins a department. They want to get them on the website. An an editor may not know if this if the site has an importer set up or the steps to get them in the right work group to get imported into the site hasn't been set up. So they may go create a profile and then somebody else goes set them up in the work group. Then that profile gets imported and so then they don't know which one should go live on the site. And then you have instances where they're like, we made updates on the Stanford system, but we don't see that reflected on the site, or we made the update on the site, but the profile on the staff page doesn't match that. So we wanted to pro provide a a way with the duplicate profiles block where they can quickly identify okay we have pieces of content for people profiles with the same name and then take a action u which we we try to put in the block to unpublish or edit and make those changes. So this was one of those tools to to help them with those issues that they come across. >> Yeah. Uh, and we're we're definitely trying to, like Albert said, nudge content editor is, oh, there's an unpublished link here. Oh, that must be what I'm supposed to do with with the one that I don't want. Uh, you might think that this is created by views. It when we get into like uh finding duplicate content, that that's a little bit more complicated than you could easily do with views. I'm sure you could do it if you really tried. Um, but because we're like matching on things like email address or first or last name and and try and find multiple duplicates. Uh we did this with with custom queries and entirely custom block. Anybody familiar with entity cues? >> Okay. Yeah, we are too and we use them. But when our editors see them, they really don't know what that means. Uh and what they really want to do is reorder a list of staff. So maybe the program leader is at the top and everybody else they want listed in alphabetical order or some type of way. Uh so we would use instues and allow them to go to those pages to see uh but they'd have to drill down in the menu and then the names could be confusing. So we did two things on this block. One, we renamed uh the interface so you see a different name that that's more common like a reorder and reorder profiles and other listings. And then the users can see, okay, here are all the lists that I have access to. And then they can quickly get to that list and reorder as as they would like. >> And this is one of those scenarios where if we were to go back in time, eight years when this platform was created, maybe we wouldn't use any cues, but uh we're here now. But so so let's like try and make that technical complexity as as straightforward as we can for for our editors. Uh if if you're unfamiliar, there are ways in settings.php where you can do quick translations. So what we did here is it just like translate the term entity cues into reorder profiles and other listings. And so then that that phrase becomes our new phrase all across the website. But other than that, this is pretty much the the stock block that is provided by any >> common a very common question that comes across. Who has access to make edits on our site? Uh and and this is I know that may sound uncommon, but within these departments and and uh programs, you know, there's certain people they might working on this part of the website and another group working on another site. So they don't always know exactly what's going on or hey somebody new to lead the lead the department comes in and they want to kind of know hey who does have access or when the last time did did a certain person u log into the website. So that's this block and when we say site editors it's actually a any user with two different uh with certain roles. So I think the site manager role and the contributor role is what we're calling a site editor. Um, but that's that's how we got to the site editor block. >> And this is also useful for for us where we can log into a site and see is is someone actually maintaining this site? Does it fall to just one person or is it a team of people? [clears throat] And uh under the hood, this is is just pretty simple use block. Uh if you're noticing the the usernames there, you know that for all of these screenshots, we we sanitized and came up with with fake uh names for for the sensitive data importers. So at at Stanford, we're we're importing Stanford events, Stanford profiles, and courses. And that's really a common question for that people want to know as well as on support when we're debugging especially like what importers are running why isn't this profile coming in why don't we see it this allows editors as well as the HNS web team to quickly log in and see oh these are your courses you can have certain what what course tags are being used to pull in certain courses what tags and what type of work groups are pulling in people and then from what departments are being pulled in. >> Yeah. Uh and and this is definitely where the most custom code is on on this dashboard. Under the hood, all this stuff gets imported into the the sites via the Drupal [clears throat] map migration module. Um and but there's like a lot of complexity to to those migrations. Those of you who have worked with the the migration model before, you'll you'll know that the the standard Drupal interface for for the migration stuff, it's it's pretty complicated and can show you some pretty confusing things. Like, for example, it can show you that you have a negative number of items that have been imported. So, we we didn't want to just expose that kind of stuff to our content editors and like that would that would just make them more confused and not less confused. So, we we really worked hard to figure out oh, what What is kind of the the bare minimum that we can do to to help them understand what when and how and from what criteria is is content being being imported into their website and then get this gets back to uh more more of what they need design settings on our platform. users can choose or sites can choose between two themes, colorful or traditional. And then within each theme, you can have a variety of about six different color pairing options. So when it comes to debugging or figuring out like what's what theme are they on, which color pairing, uh usually you'd have to take a journey through the admin menu and appearance theme and you know about 10 10 different clicks and this just puts it right here on the dashboard. So I I've used it more so where it's like okay what what theme they have I could just go to the dashboard see it right there and and get to debugging or communicating. Uh so we wanted to bring that as well as we have a few design options now like in u animation enhancements and we may have more in the future. So this kind of gives us a base to um communicate those site options that are going on on the site. And then the university policies block is more that giving them what they need. Uh links and common links that are that are asked or can we do this or are we allowed to do this? Uh within the university guidelines, we put those common links right there on the dashboard block as well. Yeah, that and that first block on the on the left, the design systems. Uh, this is some sitewide settings that we want them to know about and know that they're there, but not change on their own. We don't just want them to change the the site theme willy-nilly. Um, that we want them to start a conversation with us. And so this this gives them that kind of information so they can come to us and start with what what what could be maybe just changing the theme or or maybe like a full redesign or who knows what. Uh both these blocks are are just hardcoded. Um, again, if if this was just one website, maybe these could be some used content blocks, but uh because we want to these are rarely going to change and uh so this is custom code that you can just push out to all all the sites. >> Yeah. Right there in the design settings, there's a link. We have a like a test reference site where you can go to that site and then change the theme and change the color appearance and get a preview. So, like Dave was saying, that's a place where they can go and say, "Okay, I'm currently on colorful Cardinal. Let me look at a reference site, look at some different color pairings, look at some different options, and then start that conversation if they want to look at something different. What we wanted to say about us, so with the dashboard, our whole goal was that we want to we want to come off and make sure our editors know that we want them to be successful. We want them to be compliant. We want them to have the tools that they need. We want them to know we got your back. We're giving you the stuff that you want that you've asked for that that the questions and then we're giving you stuff that you need things that like again to help you stay compliant to help you know what the content help you know what editors are on the site. So that's what we wanted to do and that's that's the what we want them to say about us or kind of feel from once they see and know the dashboard. >> Yeah. Because the the the dashboard is is gonna implicitly explicitly say what what's important to you your organization and so yeah as you're all think about your own dashboard is what what do you want it to say about you >> so the question of has the dashboard been successful well one thing I know it has eliminated the need for manually generating those maintenance reports that was 100 hours a quarter so I think being able to move that time away from generating maintenance reports to maybe even taking that time to help units, you know, debug or fix the stuff that's on the maintenance reports. We can shift that time from just communicating and telling you what you need to fix to maybe having more time to help these units fix those those issues. Um, I think that's been tremendously successful. And then site editors when they when they know about the dashboard, every every site editor I've talked to uh that either saw it or when I showed them for the first time, it's like, "Wow, all everything I need is right here and they love it." But there is a piece of they love it when they know about it and when they see it. So, we'll talk a little bit about that. And then it's been a huge help for the HNS support team. So when we get support requests again, whether that's digging through the admin menus to get down and see what their theme is or try to go into the migration settings and figure out which migration ran and uh when the last time it ran, we can use the dashboard as a quick way to get answers and and get that back to the clients. And then um our executive director of web services on our team, she meets with a lot of the lead. So it with each department or college within HNS, they'll have like a DFO or a lead admin person. So when a new person comes on and they meet with with Marion, the question is like what's happening with my site? So she's able to sit down with them on a Zoom call, go through the dashboard and kind of provide an executive summary of like here's all the site editors on your site, here's your importers, here's where the links. So now they have a quick reference to go and see all the information and the questions that they may ask to get up to speed. >> And I think another way to say what you're you're saying, Albert, is it yes, it's been successful for both editors, it's making their lives easier, it's also making our lives easier and and making the the whole platform more more effective. Let's talk about what's not on our dashboard. You may have already been thinking, "Oh, well, I didn't see any of it. Let's uh let's go through that." So, some of this is just a matter of what's not yet on our dashboard. We I I think we're calling this dashboard 2.0. We started with even a slightly simp simpler version. We Some of this is is ideas for dashboard 3.0. you notice there there isn't any marketing kind of blocks on here about like uh conversions or or something like that and this is definitely comes back to the what what context are you in for for some of our other clients uh that that sort of thing would definitely be foremost in their mind for for a different kind of platform. Uh there isn't any analytics about site visitors. I I would love to get something on here eventually about like which pages are people spending the most time reading so that faculty are trying to share their work with the world. Uh we can see what which kind of articles are getting read the most. There's nothing here about technical performance site page speed or anything. Uh that's probably not useful to our editors. also don't have any overall site stats like your site has 432 articles. Um that's probably not useful for them either. Um yeah, so part of it is stuff we want to do in the future. Part of it is it's not here because it's not useful in this context and part of it is well maybe it's just not all that useful. >> Yeah. I think the initial uh we wanted to focus on like again what they wanted and what they need at that at that time. A lot of the people a lot of the people logging into the site are editors. They they are actually coming into doing some type of action on the website. Mo many of times it's not their full-time role to do website stuff. So they're they're they're on there to add an event. They're on there to uh update a person profile and you know look at that kind of stuff. So we our initial steps were let's let's get the stuff from the maintenance report. Let's make sure that's on there. Let's get some stuff that people ask for through support and then let's start there. And so like I said I I I think we have some ideas and some things that we want to continue to expand out especially around those analytics of of pages that are performing. >> Well, let's take a look at what's next. Yeah, I think I I I I briefly mentioned it. Communicate and educate is a place that we really want to continue. So, we did a lot of lot work on the dashboard. People who see it love it. But I have talked to units in there like, "Oh, I didn't know about this." So, a place that we really have to do a better job is continues to give people educate the mindset because I think a lot of our users again, they come to the website to make edits. So, they may have a certain pathway or they they're looking at some instructions. log into the site, go to this page, make an edit, and they may not know, okay, I have this dashboard that I can go to to get this information. Uh, so one of the places that we really want to continue to do is to communicate and educate. And then as we're talking to these units about the dashboard, getting feedback, what's worked, is there some other information that we missed that you would want or or or maybe even need to get on there and then continuously refining the blocks. I think as Dave mentioned, we started off with a simpler version and then we've moved to you had a one column layout, then we moved to a two column layout. We've added a a little a jump link navigation menu to the dashboard. So, we want to continue to refine the dashboard itself as well as the individual blocks and then ex explore some of those newer blocks. Well, let's step back a little bit and look at the big picture. Like just think about kind of dashboards in general. Why are dashboards important right now? Uh there's a lot of people in this room and so like you all must be interested in it. Why why right now? And let me first speak about why is it important become important on this particular platform right now? And I think part of it is that um that the platform is getting fairly mature and we're in a pretty good groove on the front end stuff. Uh we're creating new components. We're refining existing components. Um but yeah, like we're kind of in a groove about that we through our design and engineering cycle. [clears throat] And so it it feels like we are have solved the problem about how to make it look good. And so now we kind of need to think about more bigger questions about are we successful overall and look at what does successful mean from many different vantage points and and so that that's why I I think the the dashboard on this platform is is important for for us in this phase of of life. [clears throat] And then thinking about lit for you all and and the wider web community. I think this topic is becoming more and more important because in general we're not just tearing down sites every four years anymore and rebuilding them from scratch. You're all working on long lived projects that um you're encountering the same sorts of things. H how can you make sure that the the product overall is is being successful? some takeaways. Um, I think one thing to think about is is there any repetitive things? Is there repetitive questions or things that you have to continuously go back to that you may be able to offload to put onto a dashboard? Can that save you some time? Uh what are some of the important things that editors keep forgetting about or like you know like every time like ah they need to you know put there certain c something with accessibility or some something that they should keep in mind. Is there a way you can take some of that that stress and move that to a dashboard? Uh what and then I think for us that was very helpful is we just did it because there was a lot of talk at first of like okay what can we get all of these blocks on there should we wait and it was when we just decided to say let's start small let's figure out some blocks that could just save us some time whether that's the starting with the announcements block let's do the reports from from site improve or editorially we know that that would help us eliminate time even if we just started with that by itself that would be a tremendous help. So when you when you go about this and you're thinking about what you can do at home, it's like is there some is there a way you can just start small today? Is there something very simple that you can get started with to create a base and then you know build on build from? >> Yeah. And if you think back to those 10 blocks that we showed you screenshots of, they're not flashy. They're they're mostly just tables. And yet we we feel that that it's it's been successful and helping the the platform be more successful. And so don't feel like you you need to over complicate things definitely if you don't have a dashboard at all right now. Like anything that you come up with is is going to be better than with what you got now. And and so yeah, don't overthink things. Don't feel like you have to make it 100% perfect. Uh just just take things in in small steps. Keep iterating. All right. Uh, thank you very much. Through throughout the conference, you're going to see at the end of every uh, presentation a QR code like this. Please uh, this is your opportunity to give us feedback, Albert and I, about what could we do better in our presentations for next time. I'd love to get your feedback. And u, also let's open it up for questions. See one question in the back. Can you go back and show the dashboard one more time? >> His question was, can we go back and share the dashboard one more time? Oh, yes, we can. Thank you. >> You mean this one here top the top to bottom view? >> Gentleman here in the black shirt in orange. >> Thank you. I uh I had a question about the uh dashboard migration module. Um and I was wondering what it looks like when the migration fails. >> Yeah, that's a great question. What does the migration look like on the dashboard when it fails? So like do we have a mechanism on the dashboard that alerts users that this migration has failed? Is that the is that does that sound correct? >> Basically yes. >> Yeah. So uh sorry for the flashing but we'll come back to the dashboard once the previous one. So you you see we have a column here for last imported time. Uh there's not going to be any like red flashing error messages or anything. Uh the only impact here is going to be that that they'll see like oh this hasn't been imported in two weeks. What's what's going on here? Um yeah, >> for the most part I don't think our migrations do fail. >> Yeah. [laughter] >> Uh depends on how you want to say that, right? So uh I I think that I appreciate the question because I think that's something we may want to take back with us cuz like Dave said I don't there's no mechanism that says this has failed. So we're based off of the date. So if it's if we know that because the typical question will come on like we added a user to a work group, we notice that they're not on the site or we're importing events from the Stanford events website, that event is on the Stanford events website, but the event isn't on our website, so obviously it didn't get imported in. So, it does require us to go check the last imported time and say, "Okay, it was like there it was it was imported two weeks ago." But there's no notification that's like this is out of the date or or it hasn't been. So, I think that's some something we may want to look and see if we can refine to to help with that process. But, I think right now it's it's basically the last imported date that we're using as a mechanism to see if it failed or or it's failed. It hasn't imported content. >> Way in the back next to the wall. Hi, thanks for your presentation. Have you experimented with data visualization? If so, why is it not there? >> Good question. Have we experimented with data visualization and then why isn't it not there if we have? >> Yeah. So, I I think some of these blocks maybe lend to like more charts and graphs type presentation, but some of these maybe not like they're like let's just look at the one we got on the screen here like I I don't see how you would turn that into like a pie chart or anything. Uh but coming back to what we talked about earlier about different kinds of organizations are going to need different things on the dashboards. If you've got things where your content editors need to think about more traditional marketing metrics for those types of things, I I can definitely see more charts and graphs and kind of presentation. I think that's the in in our what's next when we get into the stats and we get into metrics we want to move into some some data visualization that's like a piece but like Dave said I don't think currently the blocks we have I haven't found saw any that like could utilize a chart or a graph but it's some it's definitely something to think about thank go integration we use it a lot for our site for So I was wonder >> okay the question was with site improve and our site improve block >> we have a site improve integration and the question is what's the user experience after a user clicks from the action of the block to go to to with like what's the next next experience it goes off to that report page and site improve. So right now it's it's it's just it externally goes to site improve versus having something internal within the site specifically for that for the program as well. >> Yeah. >> Go ahead. >> Um you talked about the maintenance report drove some of some of what you did here. Did you also do stakeholder workshops to get like live feedback from people or other types of feedback? >> So the the question is did we just take this off of our uh reports, quarterly reports that went out or did we do any sort of interviews or stakeholder feedback with with our content editors to find out what they what they thought they might want on the dashboard? >> I think we used historical data that we had a lot like from previous conversations and previous questions. We've had conversations with some units to see what we have. But I would be honest, I don't we we haven't I think that's that's the the next step and the things that we're doing now to hey, how now that we have this now now going through the process of having those workshops and getting feedback from what we presented. So we kind of took the historical data, took stuff that the questions and the and the things that previously came up, created the dashboard, and then now that we have something to show them, we're then having those conversations in those workshops to now see where we can refine and where we can make it better. >> Yeah. I wonder if wonder if it would have been hard to get like really useful data from content editors. We we have to phrase questions like if we had a dashboard and I know you don't really know what we mean by dashboard but if we did what do you think should be on it like now they have something that where they can like actually see and respond to. >> Yeah I I agree with I think that and that was the thinking is like with our audience with the editors that the the people who were using it without showing them something it may have been harder to get get really good information. Uh so we wanted to get something out so that they can see and Heather, >> this is really cool. A lot of workflows they are like current on redirect. >> Yes. >> The question was when editors log in, do they always see the dashboard? U and the edi the answer is no. Um, and that's one of the reasons why we got to continue to educate because of that workflow. When we first launched and we were first trying to start it, we did have that type of workflow, but one of the one of the issues we ran into is a lot of the time we have somebody will send a a person a link to log in to make an edit on that particular page. So, you may send a person a link to um a programs page, they log in, they go to the dashboard, then they're like, "Oh, what page did I get sent to?" So, we had to change that. where I think right now it's you you when you log in like your regular login you get there but if you get if you log in from any page it just logs in to that page and editing screen. So that's actually that's a tweak the the logging experience and trying to see how we can refine that in the best way. This is a balance. We want them to go straight to the dashboard but sometimes they don't want to go straight to the dashboard because they're trying to get to the page. So um currently no the answer to the question is no. They don't always go to the dashboard when they log in. >> Yeah. And and like uh like I was describing like that that has made it [clears throat] a little bit harder for some people to discover the dashboard. Uh currently on these sites on every page in the footer that there's a login button. And so when people are logging in on a deeper page, they probably want to do something on that page. So we don't send them to the dashboard. We are going to tweak this a little bit. Currently when you log in on the front on the homepage you stay on the homepage. We want to twe tweak that one so they end up on the dashboard so that more people find find the dashboard >> and all our sites you log in with SSO. So just going out that threw a little challenge in there too because it's not just the regular Drupal login experience. You're logging in through um SSO. So that kind of added an extra wrinkle to it. >> Right. So, a lot of site users are part-time site editors. Um, does your road map include a way to help prompt users to take actions through either like notifications or emails sent whenever there are things that they should take action on? >> Yeah. So, question was uh not all editor maybe no editors are full-time website editors. uh are there any sort of prompts or uh things to to help them be more successful? >> Um I I don't think so. If am I answering the question honestly? I think that's those are great ideas that we want to explore to see like is there some type of notification? if there's some additional, you know, something blinking if they're not on the dashboard that maybe gets them to the dashboard and see uh currently we do not have that, but I think it'd be a great place to explore. So, thank you Chris. >> And and also on this platform, if you are like a full-on content editor, you've you've gone through some training about like what the site is, how to use it, what how to be compliant. So the the dashboard is isn't the only thing setting them up for for success. >> Go ahead, purple hair. >> Uh so a lot of you know people using dashboards they want to be able to like show or hide minimize drag and drop. Is that kind of functionality available? Uh the question is some dashboards allow you to like move things around, remove blocks, add your own blocks, anything like that that we're thinking about. Uh short answer is no. Uh yeah, we're we definitely maybe someday I I think we would be a long ways away from that sort of thing. We we do have an idea about maybe our different uh levels of of content editors. Our highest is is site manager, but there's lower ones like contributor and uh maybe those different roles need to see different things on the dashboard. That's probably the closest thing that we we're thinking about that what you're describing. I mean, I think the show and hide, not completely showing hide, but we did add a feature to like minimize the block or like show it smaller, but then like going to Dave's point, I think the next step would be more customizing the the dashboard experience per role as like certain roles may need may not need certain blocks or certain roles may need certain blocks higher in priority. So, I think that's probably the next step in our road map. >> Go ahead. Um, so do you do you use groups and then I guess followup question how does that how does this like perform are there any like special caching things >> yeah uh so first question was [snorts] is groups involved here I'm assuming you mean like the Drupal groups module and then is is there any like performance or crashing issues here uh let me talk about the last one first yes uh with the API calls to site improve mostly that's probably the one where we had the the biggest performance challenges. Yeah, there's some layers of caching in there so that like uh we don't hit the the API on every time the dashboard visited. >> Your other question, Dang it, now I've forgotten it. Uh okay. Yeah. Uh no these uh these 130 websites are uh the the kind of topography there is that it's one code base and 130 separate databases [clears throat] running it runs on a cloud next but do the same sort of thing elsewhere and so they're they're the sites are not really connected in the same [clears throat] way as if you used >> are are they I don't think you mentioned this but is it pulling are all useful just contextual filters and user >> uh yeah contextual filters no because most of these blocks are like overall on the site as a whole here's the top whatever in this case top broken links >> I I think we're at time >> [clears throat] >> Well, I appreciate everybody. [applause] If you have any questions, follow up. I'll be happy to talk to to you all more about it. But thanks again for attending. >> Absolutely. >> Thank you.