Simplifying Drupal's Admin Experience (AX)

MARTIN ANDERSON :
So, it will let me record. So, recording has started actually I guess before I did that, I should ask, does anybody have any issue with me recording it? Speak now and I can stop it, but I think hopefully everybody's cool. Alright, so maybe what we should do is while we're getting warmed up, maybe just go around everybody, you know, say who they are, maybe how long you've been using Drupal, and any particular sort of passion or reason for being enthusiastic about this topic. So, my name is Martin Anderson Clits. I work at Northern, which is formerly digital kidnap, and been using Drupal for a while. And in fact, I realized a while ago that sometimes on sites, I probably spend more time on the Admin UX in terms of trying to make that sort of easy and intuitive than I am doing on the client-side, because I think it can be much more complicated, but it can also be made to be very easy and intuitive, but it's really at least it used to be much harder. I feel like as Drupal has matured, some of those things have gotten easier, but still require, I think the I don't know, attention to detail or the desire to invest the time to sort of make those kinds of changes.

So, that's way longer than it should have been. So, let me pass it off to Benji.

BENJI FISHER:
Hi, Benji Fisher. I've been using Drupal a little more than 10 years. I'm a member of usability teams. So, we meet on zoom once a week. So, we talk about things like this and how to make the admin experience better. It is something that's so often is neglected and projects I work on for work and it could be so much better. So, I'm always looking for ideas. I remember a few years ago at a conference I saw a presentation on some work being done to the mass.gov site by last call media, I think. And I think they did a really nice job of improving things for the many content editors who are going to be spending hours and hours on the back end of the site.

MARTIN ANDERSON :
Cool. So, maybe we should just go down the list here. Ralph, do you wanna go next?

RALPH :
Hi, I'm Ralph, I am using Drupal for four or five years now. I'm still learning and finding my way and yeah, I'm interested in the whole usability topic and I've also over the years headed points to a list. So, I've already copied an excerpt of those for today.

MARTIN ANDERSON :
Great, just on the topic of sharing. OK, did put the link in there, but I'll put it again, 'cause I see we've got a couple more people join. So, try and remember to post that a few times through the session because I think as you join, you don't see the past chat, you only see the things that appear after you joined. So, if I forget, by all means, if anybody else wants to pick up the Slack and do that, that would be great. So, why don't we go to Brian next?

BRIAN CLEMENT :
Hey, I'm Brian, I've been working with Drupal for eight or nine years now and I feel like the admin area and the admin experience is kinda always ends up on the lower end of the list of priorities. So, I'm just really interested to kind of see what everyone's doing to make that better for the content editors.

MARTIN ANDERSON :
Alright, and Manav.

MANAV :
Hey guys. So, I'm using Drupal (INAUDIBLE) for the last eight or nine years. OK, and I will not say I liked (INAUDIBLE) I haven't seen. I like to say I like each and every part of it. So, most of (INAUDIBLE) I mean, most of the time I worked in (INAUDIBLE) I need some front end and back end things and so whatever they need, I do. And I like each and every part of it.

MARTIN ANDERSON :
Cool. Alright, so in terms of a format, overall, I wanna keep it conversational. But I guess going into today, I didn't really know that this was gonna be more of a bar format. So, I had actually prepared a few slides. Let's maybe think of these as discussion points. So, maybe this is a list of ideas that we can add to maybe also talk about for some of these ideas where like some concrete examples of like either modules that we could use or like ways that we can configure Drupal to better embrace these if we think they're even worthwhile. So, in that spirit, maybe I will start sharing my screen here and just kick this off. So, first off, shout out to the Drupal marketing initiative, I kind of sold their templates for the slide deck. So, here to talk about the Drupal admin experience and ways that we can make Drupal easy for all the people who use it most. I feel like, if you've got very loyal visitors to your website, they might come two or three times a week whereas an administrator might use it that many times a day or more, right.

So, they're spending a lot more time than even your most avid users. And so, it only makes sense to make sure that it's gonna be really easy to use for them. I feel like Drupal has a reputation of being hard to learn. You hear people talk about the steep learning curve. And I mean, I feel like part of that is that Drupal is built to tackle more ambitious kinds of projects and applications. And so there's naturally a bit of a tradeoff, but there are definitely ways that we can, you know, as site builders and developers sort of craft Drupal to be easier to use for the administrators. And hopefully, we can share some ideas and see what we all can do to make Drupal better in that regard. So, as I say, these are some ideas that I have just sort of principles in terms of ways that we can Drupal easier to use. So, the first one being appropriate complexity I've seen a number of sites that we've started dealing with the customer had a site built for them by somebody else, and really only had like one user role that could do everything.

And so from a user standpoint, that can be incredibly overwhelming, right. It's like drinking from a fire hose to all of a sudden have all of these menus with all of these, like configuration options, they can make any kind of content. Some of them might have 30 or 40 different fields to fill out all of these things and you can see why being sort of dropped to the deep end that way that people can get overwhelmed, whereas you can have different roles for different users of, you know, based on their level of sort of technical expertise. And you can have something that, you know, if you wanna follow that pool analogy it's almost like the kiddie pool, right. So, like you can make a basic page. You can use simple HTML as the text format. What you're saying is probably going to be similar to like the WordPress experience where you can like make a page, you can dump content in and not do a whole lot else, right. But for people getting used to working with that kind of an online content management system, maybe that's a great way to let them sort of dip their toe in the water, get comfortable, and then gradually maybe you move them up a level in their role, or maybe you adjust those roles over time as the people using them get more and more confident in kind of the permission and the access that they have.

So, as I say here, I think there's a balance between the power that people need. But also the idea of having things kept really simple. And then the other thing too, is I feel like when we're building sites sometimes, like, I know I've built things for, let's say like layout builder, well, define this custom block type, that's really configurable. So, you can say like I'm gonna use this dropdown to say whether the text is on the left or the right. And you can do all these cool things so that it is like one block type can be configured in like 18 different ways. And to me, it's super cool and that's really powerful. But then to try and train somebody who's not technically sophisticated to use that thing, it's like they just get lost within 10 minutes of trying to really understand like how this one thing can end up being rented out in all those different ways. And so depending on who the audience is that you're building for you, it may be better for them to actually build those out as separate block types of like image on the left or image the right. And then that way when they go in to build something it's like really obvious of like, yes, that's the thing that I need, as opposed to, like, I have to get this thing and then configure it and whatever else.

And so part of the challenge is that there's no one right answer. It's always about who the audience is of who you're building for. And I think that also will change over time. As I mentioned before, if somebody starts off, they may be easily intimidated, but over time as they get to use Drupal more and more, they may be more confident and willing to take on additional levels of complexity. So, part of that is really about understanding who you're building for. The other thing is I feel like it's really easy to end up building out things that are super complicated because we're designing for like all of the edge cases, right. Like most page nodes only need like a title and a body field. But we know that two out of 3000 need PDF attachments and like five of them are gonna need to be associated with a contact, which is a separate content type, and all these other things, right. And it's OK to say, we need to have those, but I feel like it's also possible to sort of minimize the day-to-day impact of those edge cases being available.

So, you could like have almost like two tabs where one is like the typical use case of like, sure, I'm gonna make this page and I'm gonna put it in the title and body, but then I'm gonna have a separate tab, which is where I put all of those things that people are only gonna need, like once a year or whatever, right. And so the day-to-day experiences that you've kept it nice and simple. But then they also kinda know like where they can go to find all of those extra things that they're very rarely gonna need. Same thing with the WYSIWYG. It's very easy to take all of the cool different things that you can make WYSIWYG do, and then have this giant like ugly word thing that has like 300 different buttons. And then they can never parse out like which button does what whereas I feel like there's a lot of value in keeping at least the default experience really simple. And so when people go there, they're like, yeah, I'm gonna drop in some content, maybe online bold and link some stuff. And most of the time that's probably all they need to do. And then you can have a different text format that gives them the extra complexity if they have a particular piece of content that needs tables or footnotes or whatever the extra complexity is.

Again, if that's really more of the edge case, you can keep the defaults simpler so that on the day to day basis, it's easy to use. And then they can tap into that extra complexity when and if they need it. Consistency, I know I've seen this in projects that my company has worked on where they built out all of the fields. They've styled it look great. And then you go into to edit a note. And it's weird because there's kind of a logical flow of things on the view side. But nobody has given any attention to the flow of things on the admin side. And so it's this like alphabetical thing or whatever. There's no correspondence between the structure of the form on the view side and on the edit side. And so I feel like if we can make an effort to at least have some level of consistency between those two things it's easier for people. I think to parse when they go into the edit side, if there's, again, that consistency of like, OK, well, the body is the first thing that appears on the view side.

So, it makes sense that its first thing on the admin side, as opposed to like 10 fields down underneath a bunch of different taxonomy widgets what have you. And even in terms of how things are named, it's very easy to let there be sort of, kind of a separation between some of those things. But the more you can keep that consistent, I feel like that again for users is gonna make it much more intuitive because they don't have to sort of like mentally make that adjustment or that translation of like, OK, so this field that I see on the back end actually is this thing that appears on the front end if you make those two things really tightly coupled especially around the language, then I think that's gonna make things easier for your editors. One thing I've been trying to do more and more is the idea of keeping people in context. So, we as seasoned Drupal users know that at any point, particularly if you've got sort of your admin toolbar installed, you can just go up to the content menu and then go over and create whatever content it is that you need. But especially for people who are new to Drupal, it shouldn't really be necessary to like force them to memorize that convention, right.

So, if you're looking at a page of news articles, you could have a button at the top of that page of news articles that only appears to people who have the permission to add news articles. That's just a big prompt that says, like add news and they click that and they get right to the article you know, create an article node forum, right. And so by doing those kinds of things, when they're within a system we can keep them there. And there's no like they're not having to do that. That sort of, again like the mental work of trying to remember, Oh, yeah, I have to go to this other place to be able to add content to this thing, right. If you make those prompts really obvious and in the context of where people go to consume that, then from an editor standpoint it's really gonna be super self-evident. And I can show some examples of these later on, but I figured maybe it's worth just going through these as a start in terms of, of page loads. There are lots of ways that Drupal can make the page loads much more useful.

So, I know oftentimes in the sites that we build, once you log in, if it just takes you to user page, there's really nothing on there. That's gonna be of any value. So, there are there's a module I'm trying to remember the name of it. It's sort like Login Toboggan, but like the DA version of that, if you're familiar with what that was from D7 but it basically will redirect you on login and you can set that by role. So, when an editor logs in, why not take them directly to that content list interface as a really simple example, right. As opposed to having them see this page that just has their username on top, and then they have to remember to go to the content interface. So, I feel like there are really simple ways like that, where we can say let's not take them someplace useless and then force them to remember that they need to go somewhere else. And Drupal has these destination parameters. So, as like a site builder or a module author you can leverage that to say, after they've done the thing that I want them to do, where's the useful place that we can have them end up, right.

And so just getting thoughts to some of those little details, I think can make a big difference in terms of how Drupal feels in terms of it being intuitive to use. For anybody familiar with Jakob Nielsen there's this UX law called Jakob's law. And the idea being that most people are spending most of their time on other websites. And so when they come to your website, they're expecting your website to follow a lot of those same conventions. And so it's not a bad idea to try and think of innovative ways to do things but understand that people have these mental models and if you can leverage those and at least build on top of them, then you're going to make your site much more intuitive for people. So, if almost every site on you know, if people, I think this maybe ties a bit into some of the talks that were done yesterday around, like what can Drupal learn from other CMSs? But I feel like this sort of ties into that idea of like, if there are best of breed, ways of managing content then let's try and follow some of those models. And one that I've been kinda passionate about the last couple of years is specific to a date modules and really trying to have a date widget within Drupal that works a lot more like the way calendar applications would.

So, if people are used to using Google calendar or Apple calendar and those work a particular way. Why would we use something in Drupal that is like puts a lot more onus on the editor to manually populate? Like I forgot it's like 14 different fields before they can enter a simple date range, right. So, if we can have things that better align with against some of those conventions that people are used to in the software they use every day. Again, that's gonna help to make Drupal much more intuitive. And I think, again, this one was touched on a bit yesterday. But like from a language standpoint, if we can avoid using Drupalisms like nodes, entity, media, and make them more sort of tangible and specific. You know, talking about the specific content types, alerts, events, images, and so on its gonna make it a lot more obvious to people. One of the things I really like about the... What is it? Inline entity form is that it gives you the option to actually put labels in there for those things.

So, as opposed to saying, like add another media item, you can say, add another me image, because it's an image reference field that you built there or whatever. So, I think by again, making those things much more specific, it makes it more concrete for people and it's easier for them to parse. There's the classic usability book don't make me think. Again, this is just a super high-level principle but try and make things as blindingly obvious as possible in terms of how people are going to administer the website. And again, I can show a couple of examples of ways that to me make sites easier to use. But definitely interested to hear what other people are doing in terms of how they build websites and some of the solutions that they like. And then the last one is really as much as you can gather feedback, understand ways that you can make your sites easier to use. And even sometimes I'd say in very small ways, add up over time and really improve that user experience. But getting that feedback from the people who are actually using it and potentially struggling I think is one of the keys because it's too easy as developers to say, I understand how this works and so to me, it's no problem to go through the seven-step workflow, but it may be completely bewildering to some of your editors.

So, getting that feedback from the people who are actually doing the work and using it, I think it's really critical. So, that's kinda my list, but definitely, before I do anything else, would love to open this up and see if anybody else has any other kinds of principles that they like to follow as far as what things they try to bake into their admin interface to make them easy. Anyone have any thoughts

BENJI FISHER:
I pasted a few notes into the pad that you set up in there. There's a link in the chat. So, a few of the things you said at the start about having customized navigation for people who are using the site all the time. There are a few core issues designed at doing the same sort of thing. So, maybe in Drupal 10, we'll finally have a content editor role in the content manager role in the standard profile. And I also pasted a link to the session I mentioned, which talked about a really nice job of I think of customizing the admin UI for mass stock outside.

MARTIN ANDERSON :
Awesome. Yeah, thanks for doing that. Any other thoughts? Alright. So, I'm gonna just show a couple of things that I like to do as I build sites, and again, would be awesome to hear from other people in terms of what they like to do. So, one of the things that I've been trying to do again, this is the idea of allowing people to manage a site in context, and particularly because we've got the contextual menus and Drupal eight, there's some cool things you can do in terms of you know, so as an example, this site is built so that you can do the configuration for this header block without even having to leave the homepage. So, you could go in here and swap out. Live demos are always fun. You can do that. Similarly, we've got a quick link here. You could add a new one or even do stuff like reorder them. So, let's put the road work first, tax notices last. Let me say that (INAUDIBLE). Again, without having to leave the context of the homepage, you can make all those changes, alright. Personally think the settings tray is pretty cool.

I like it a lot for that ability to let people do updates to the site without losing the context of where they were. I'd be interested to know how other people feel about that. I know Drupal, I think it was a Drupal 6 where one of the big new features was that overlay for admin. And then a lot of developers that was like the first thing they would do after the installed Drupal was to disable it, right. So, I don't know if the settings tray is like the new overlay, but as I say to me, this is really powerful in terms of giving people the ability to have these like really obvious prompts directly within the context of like when you come to the homepage, you don't have to remember, oh, if I go up to configuration and then down to system, and then over to here, there's this form that I can get to that lets me configure that and then go back to the homepage and see if my changes are the way that I want them, right. If you make those right where the content is that they wanna manage then it's really like, I think self-evident and more intuitive.

So, yeah, there's a couple of modules that allow you to do this piece of like put the add content. So, this is actually in the view, it's like a view header item. And this is another one so that the one interesting thing in Drupal core is you can link between views, but for some reason, it seems like it doesn't do a permissions check. So, if I use the core link between displays to add, so this is actually let me just go here. So, this is actually a sorting display for this view. And if I just use the core link for that, it would display for everybody, even though it depends on specific permission to be able to do that. And so I ended up making a separate module because I really I'd say like this idea of having the links right there for editors, but only editors. So, if we go in and look at the same page, so as an anonymous user, you can see like those buttons don't display they're really only show for the people who have access to access or the permissions required to perform those tasks, right.

SPEAKER :
Is that a module available to everyone or something you did just specifically for this site?

MARTIN ANDERSON:
I'm trying to remember, it's a module that I made, but it is a country module. So, this one is called, add content by bundle, Let's see here, (KEYBOARD CLICKING). So, this is one where you can basically add as many of these buttons as you want. So, if you had a view that had three different content types, you could have three separate buttons, you can add classes on them. They're technically just links, but you can obviously use your like button classes to make them look like buttons. And then it has configuration options to say, do you want it to just take them to the regular node form, do you want it to open in the settings tray, or do you want it to open in overlay? And then if you use one of either the settings trigger the overlay, then you can actually set a parameter for like how many pixels wide you want that to be. And I think by default, it also sets the destination parameters so that if you use that link to go off and add, let's say a new article then once you save that, it'll take you back and you'll be able to see your new article in the view as an example.

And the other one is (KEYBOARD CLICKING) I have to go. It's too late in the day on a Friday for my brain to still be working, unfortunately. It's display link plus because the plus is the permissions check, but also it does add these configuration pieces. So, you can basically say which display you wanna link to the texts that you want in the link. And then again, you can say the target, if it should be just the regular form if it should be, you know, in this case, a little dialogue, or you can use the settings tray and then set its interest in. I think if you set modal dialogue, it should open up a separate field where you can configure that, but you can use the class again to give it you know, make it look like a button there, or whatever you need to be that way. The other one actually before I forget, I believe the add content by bundle also has integration with the form mode plugin, which I think it's kinda cool because I think I'm pretty sure Drupal core still doesn't have a UI for... You can create view modes for forms but there's no built-in way to say in this context use that form versus this other one.

So, it's form mode control. Yeah. This is the one, maybe it's form mode manager. Anyway, the idea being that so again, if in the context of, let's say creating an event in the sidebar, you wanted to have a simplified version of that form, you could create that extra form view mode with fewer fields exposed and then say only when it's opened up in that sidebar use that simplified version of the form.

SPEAKER :
Thanks, that's helpful.

MARTIN ANDERSON :
That's good to hear that. Anybody else have certain things that they like to do when they build websites that they've found has made it easier for their editors?

SPEAKER :
One of the things I've done is when people need to add an image, I'll put in a note in the directions that say the ideal dimensions for this image are X by X. And that if it's larger than that, or it will be cracked so that people know ahead of time, what's gonna happen.

MARTIN ANDERSON :
Yeah, that's a great one. Sort of a tangent on that idea is sometimes if let's say I've got an image style, that's going to crop, let's say hero image to a specific proportion, I'll make a thumbnails image style. That's the same proportion, but a smaller size. And then you can set your you know, whatever media widget to use that smaller thumbnail so that people get a preview of how that's gonna look cropped, basically, instead of showing them just a square one or the same thing, like not cropping. And then they have to save the node and then see it and go, Oh, no, that looks terrible and I have to adjust the cropping using, let's say you're using focal point or something like that. So, giving them that feedback right away means that they can adjust it without having to save it and see the full note.

SPEAKER :
Sounds good.

MARTIN ANDERSON:
Anybody else? It is late in the day in the last session slot of the day. Definitely appreciate everybody who's come out. As a reminder for anybody who came in recently and not seen the link, we do have utopia part started for this session that includes the slides we covered earlier. But just trying to get to the chat. Maybe I have to stop sharing my screen.

RALPH :
I've already pasted it.

MARTIN ANDERSON :
Ah, OK, thanks for that, Ralph. So, yeah, the link to the slides is there, there's already been a couple of suggestions in there, by all means, feel free to add other suggestions that you might have. Yeah, let's treat it as a collaborative document, and hopefully, we can use it as a place to collect some good ideas.

RALPH :
You mean ideas for content or news?

MARTIN ANDERSON :
It could be ideas for new modules. It could be just ideas of like the way I think it was Mary just said in terms of like, you know, this has helped text that I always put in and that helps people to know those kinds of things. So, it doesn't necessarily have to be something really fancy, but sometimes, yeah, even something as simple as help text can really be useful to people in terms of making it really obvious how something is gonna react. And it's not like they create a note and then save it and they're like, why's it look all messed up, right? If you give them the ability to anticipate how it's gonna behave, sometimes even that in itself could be a big improvement.

RALPH :
Yeah, because the points I've written down and noted were more on the regards of which functionality or user experience in the context of the Drupal admin could be improved over flaws in my humble opinion. And it wasn't that fitting to name flaws right now, I guess, 'cause get them misread the topic of the session. So, it was OK and interesting, definitely.

MARTIN ANDERSON :
I mean, does anybody have anything’s that in their own personal use of Drupal that they find this, like why does Drupal have to do that thing every time?

RALPH :
I have a few.

SPEAKER :
Not really. I've just adapted to what's been there in Drupal. But has anybody use a different admin theme other than the default ones that's better in this regard because it sounds like Martin a lot of your ideas I think are excellent. But it seems to me that they would need an entirely built from the ground up restructured admin theme. And so that you can incorporate roles and permissions. I mean, all I've ever done was to control permissions for different user roles. But that doesn't change the interface really that much, it just doesn't let people do certain things.

MARTIN ANDERSON:
Well, so actually lemme see if I can open up the same site as a different user role. Let's go. Alright, so this site is using the Gin Admin Theme, which is sort of built on top of Claro but meant to be, I don't know. I wanna say a little fancier. Sasha Eggenberger, who is one of the designers who worked on the Claro theme, also built Gin as a way to, I dunno, I feel like to some degree try and build out some ideas that he had for what he hopes Claro will eventually be. So, I think that the module is still in a beta phase. But we use it a lot and we really like it and it has this Gin login which gives you a much nicer login form. And then you'll see, once we log in, I've used that other module that I talked about where basically as soon as you log in, it takes you directly to your content dashboard effectively, right. Which is much more useful than just saying a blank page with your username. So, you can see we built the site so that as an author, it's really super simple. You can only add like one of these four content types.

And then when you go in, it's all just super simple. I really liked this Gin Admin Theme. I like the fact that the save button is like always visible on screen. So, as a user, you're not having to like fill out two and then scroll all the way to the bottom. I like that idea that always been obvious. But then we can contrast that if we go back to what we were looking at before the level of complexity that's exposed to a full administrator is obviously, a couple of orders of magnitude higher in complexity, right. So, all of these different options. And I think if we can have the appropriately level of complexity that we expose to users then I think we have the opportunity to make it much less intimidating, right. So, as somebody is getting used to the site for the first time, maybe they only get that authoring experience until they get that experience. And then you either add permissions to that role, or you say, OK, now we're gonna move you up to, I don't know, an editor role where now you can start to use workflows and some other things, right.

So, I feel like, yeah, even without necessarily like having a fancier admin theme or some of those other things, like just how we configure the site there's a lot of things that we can do.

RALPH :
One addition.

MARTIN ANDERSON :
Sure.

RALPH :
Could you go back to the author window, please? And one step back to the add content, for example, if you go there, there's one problem in my humble opinion for people new to Drupal, it's some sort of cognitive load, it's basically most of the time reading and it's sort of abstract. So, if you take a look, most of the admin theme, you have lots of texts and labels to read. It's important for sure, but it's an overload and there are mostly no visual cues and no affordance in most parts and how to orient and that's difficult. And for example, based in part on the talk yesterday about the Drupal admin experience at (INAUDIBLE) right now on her name...

MARTIN ANDERSON :
Susanna.

RALPH :
Susanna, yeah. Right, sorry. The idea of when entering the content, you provide a split on the left, you get the form with all the fields and on the right. You have a field for the preview of the content, which is entered and you could extend it to for example if you provide a select box with all available view modes for the particular content type though you can switch off switch between. So, you can see, for example, for the view mode X, you get that view that the user gets author visual representation, how the content he's entering or she's entering is used on the side. So, wouldn't be even necessary to edit it on the front end, like you showed before. And once additional idea is when instead of providing simple texts in the context of add content, you could also do little previews to get a preview of the page. So, the office sees, OK, that is for example page, or that is, for example, a team member or that is page or whatever so that people get some kind of visual cues also. It's OK for people using a screen reader to have much text, and it's all accessible, that's necessary and good, but also for the people relying on visual cues, there should be also some sort of opportunity let's put it that way.

MARTIN ANDERSON :
Sure, I mean talking about that whole experience of like this button taking you to a place where then you have to choose a content type, theoretically, if this could be a drop button, instead of just a regular link button, I feel like from a usability standpoint that would be a big improvement, right. So, you could like click the thing to open it and then click a content type and be right there, as opposed to, again, having to click this, get to another place, and then OK.

RALPH :
It never clicks. Or you should always basically, what you need would be some sort of top tasks for each role and most tasks, the top tasks should be reachable at a maximum of one or two clicks or the main top tasks even directly with maximum one click.

MARTIN ANDERSON:
For sure, alright. We're getting low on time here. And I know the big raffle starts at quarter to, Ops, basically now. So, I guess we should wrap things up. Maybe we should drop the utopia part link in one last time. Let me check here. Alright. Well, thanks for that. And thanks everybody for coming. And I hope you've had a fun day MidCamp. I've definitely enjoyed it. So, I guess we'll see you all in the main ballroom for the raffles so...

SPEAKER :
Thank you. Thanks again, Martin.