 Okay, let's get started because of this session is a short presentation. We only have 25 minutes of time. So today I'm presenting with Christina Ankit. My name is Lauri. We will continue the discussion in a both after after this session. We will start at 3.45 and we will have one hour of time over there. So everyone who is interested feel free to join us there. Hopefully as many of you as possible will be there because of I don't think we have that much time here. Anyway, so let's get started with the topic itself. The presentation that we make today is going to be short. We will also make a brief update what has happened so far. But if you are interested to hear why in a more broader scope than what we are giving today, the original presentation I gave one year ago in Dublin is still up to date, I guess. Nothing has changed so much during one year. So you can still watch it from the Dublin event size. So what we've realized last year was that first impressions should be taken more seriously than what we do at the moment. We have a very valuable opportunity that we are not using that well right now to try to convince all of those users trying out Drupal to choose Drupal over our competitors. Many of our CMS competitors actually provide very beautiful get started teams with a lot of effort put into making them suit very well that one use case. So we want to do something to improve this. So this is what all of the evaluators who evaluate Drupal over our competitors, basically all of these different groups. So we have the non-technical evaluators, we have technical evaluators and IT teams who are evaluating Drupal for their companies internally maybe. We have some developers and site builders who are evaluating Drupal as something that they should build their code on or maybe as something that they should build their clients website on and all of them see this as a first thing. And maybe that's not the best way to convince them that we are up to date and that this is something that you should build your things on. So these are the people that we are building something for. This was something that we put a lot of thought on. We limited out some groups of users and we thought that these are the most important groups of people to convince that Drupal is good. A brief timeline what has happened at which point just to give an idea of what is the history of the initiative, like what has happened so far. So the idea was born in Drupal New Orleans 2016 kind of ish since the idea has been around for, I guess, 10, 11 years already that we need default content and that we should put a lot of effort into the first-time user experience. So it's definitely not a new idea invented by this team. It's more of something that has been around for a longer than that. But in the New Orleans DrupalCon we got the idea that this is something that we probably should work on now because of that could help us get more people involved. So since the New Orleans in June we started doing some planning. The planning took quite long. So we were doing planning till February 2017 when we started a designer recruitment. Basically while we were doing planning we were just trying to find the meaning of this initiative. It's kind of interesting because it went back and forth like we had an idea this is what we want to do but then we didn't know why and then we went back to the why and once we got everything figured out we managed to move forward. As part of that part of this initiative we merged multiple different initiatives kind of trying to solve the same why question and then it became the out-of-the-box experience initiative because that's initially the answer for why. We are trying to solve something to make a better out-of-the-box experience for people. We decided during the planning that we are going to try to record a designer. I personally think that it was a good idea. We had more than good number, more than ten of applications. All of them were good applications. I was very surprised of the level of the applications because all of them were something that we could actually consider making a design like this. So definitely there one of the one of the big concerns we had one year ago was that how can we find a designer. I don't think that was a big problem and I think it was a good way to get a designer. Design was done in August 2017 so it took us pretty much six months to get the design done. Now what we are working on from that on is to build a style guide and actually start implementing all of all of these things together. So what we came up with was a scenario where we had this food magazine publisher with different content types. The most important one was the recipe. There were different ways we were working on that. There was the content model part where we defined which content should be there, like the recipe, for example. For example, the ingredients, which kind of feel. It goes taxonomy, it goes a field, a sample field. We worked with that with content of people because they were working for creating default content for they work and we worked together to came up with something that was also useful in a decoupled environment. Later on we started creating the default content that really did a lot of work on that. Then there's also the installation profile. It started some time before and we just get around that again and finally there's a design where it's going to explain that. But the most important thing here is that all of these parts can be reusable by other initiatives. So all this work, it's done for everybody that can use it. So that's your part. So we just talk a little bit about the design process. So the process itself has followed a pretty good pattern actually. As Larry said, we took quite a bit of time discussing it over. We started by creating a content model and taking a look at wireframes. So we took that content model, started playing around with that content model against this imagined scenario of a food magazine and we produced the wireframes. It was a good process of the wireframe is feeding back into the actual model itself. Alongside that we're able to start coming up with this brand, the idea of the Amami brand. One of the things that was really exciting early on is pretty much as soon as we started producing content model and as soon as we had the wireframes, we also had other initiatives starting to grab hold of the idea and run with it. We had the content to CMS. We heard about that this morning. Really starting to just play around with this model. This is really exciting because it means that we can start to see already that as Christine has just said that this whole idea is reusable. So as soon as we had the wireframes agreed on, we were able to create the designs that were shared amongst the community and you can take a look at those designs. They're up on Drupal.org and also at the moment work that's currently in progress is that we're creating a living style guide that's based on those designs. So you may have already seen this. It's been shown around a little bit already, which is great. So we come up with a front page for the Amami theme. You can see it here. Zoomed out and it's a design that's full of sample content to improve the first time user experience of Drupal. And that's what this is all about. It's just using content, really good content, hopefully, to be visually engaging. Really use that to actually just draw the user in and captivate them. Want the users to get a really clear understanding of why they should consider Drupal. There's some seats available in the front, so you don't have to stand up in the back. Yeah, so we want the users to really understand why they should consider Drupal. They're going to potentially be coming to this without a clue about what's going on behind the scenes. They could be coming from other content management systems, whereas a completely different approach, completely different world. So if we could just do something that welcomes them on board, then that's a good thing, I think. And we want to compel them to dig deeper. So rather than doing what we do today, we saw the slide earlier with the really friendly welcome screen that we're all so familiar with, which has been likened to a giant pile of Lego bricks with no instructions. Go make what you like and enjoy it. That's exactly what we don't want to be doing. We want to be doing something that shows Drupal through a bit of a different lens. It's Drupal inaction. We want to present a demo of Drupal inaction. The default content types of article and recipe, they're given the default content, and that looks great for this in that we can use that to provide an instant reference point. If the users come into this, they're seeing that we've got articles, we've got recipes, and that default content is going to be something that's meaningful to them. Hopefully draw them in to look at how we're actually using that content throughout the designs. We don't want the user to do any hard work. The magazine style content provides the design impact whilst the theme remains lightly designed. That's been the approach that I've taken for the design work. The idea is basically that we use the content itself and design heavily around that content, and that we actually insert that into the theme, but the theme itself remains really light. In fact, if you took all this content out, this would be a theme that hopefully could be reused in a number of ways very easily, just some color changes or whatever. It's thinking creatively like that to make this as reusable as possible. The theme provides scenario-based examples that illustrate Drupal core functionality. We're using the actual content and the presentation of those content to start getting across the fact that Drupal is far from limited in scope. The sort of example topics that we can cover through this demo, we're not entirely sure yet maybe whether there's going to be a tour aspect to this or how we might portray some of this, but certainly at the top level, you can already see that we've got the obvious things like content being promoted, content types being presented, image styles, different image styles, view modes, and of course blocks. The blocks system in Drupal 8 is such a big improvement we're able to start exploring how that can be used through the theme. And the recipe page, we just take a look at the design for the recipe page. So Drupal is great for structured content. Our recipe structure follows what you would expect. So this is following the content model, and as I mentioned, it's already being used by the contenter CMS. And in fact, these recipes, the fields that are in the recipes, are being used to really just drive the front end design here. So we've got recipes which are categorized and tagged. If you go and take a look at the designs, you'll see that we're playing with that quite creatively in the way that we present the recipes on the landing page. Lead images are used for cards throughout, so we're reusing content nicely there. For MVP, the ingredients list is planned to be a simple array. Obviously, that's something that we could look at advancing on if we want to extend the scope of our demo, which is the whole point of this. So what's been worked on at the moment? And who to contact if you want to get involved? So obviously we're keen for people to get involved. If you want to get involved, then come and speak to us. For the style guide, Christina and Mark, who's here at the front, has been really doing a great job of getting that up and running. So we're going to have a style guide in the theme. Accessibility, Andrew McPherson's been involved in helping us get the designs in alignment with what we need for accessibility, which is obviously really important. Content, I've made a start on content. There's quite a bit of work that's already been done, but if you're handy at writing articles or that sort of thing, then my only way is come and speak to me, because the more the merrier. Site build, Larry's taken care of all the site build and the installation profile work, and we've still got finalization of design to do. So there's certain assets that we need to do in the design that need to be really customized for this so that we don't have any kind of licensing issues. And we really want to make it apply specifically to the demo that we're trying to create, that demo experience. And that is it. Yeah, so that's pretty much what we wanted to tell about our initiative at this point. And we would like to start with the conversation about the initiative. We have prepared some specific questions that we would like to discuss because of those are important for us to be able to make progress. We will leave some time for the end for open discussions slash ideas if you have some. So let's go with the structured questions first. So one of the big questions for our initiative is that should we make umami based on classy and stable? So basically classy and stable will have a massive busy break on 9.0.0. So everything we make design wise slash in CSS will be practically useless at that point. And I think the lifecycle of the design should be longer than that. I don't know. Can we make it not based on classy slash stable or does anyone has any opinions on that? Do you have experience maintaining teams that don't extend classy slash stable? Any kind of ideas around this topic is welcome. How many teamers do we have here today? We have few. Does any of you have any experience not extending classy or stable if you have raised your hand? Two people. Do you want to tell about your experience? Did you have anything particular that we should take into account when that happened? When you tried that? Did you actually use it on production? Or yeah? Nothing particular happened? It was all fine? So yeah. So the problem is that... Repeat the question please. So the question you asked is what is the problem that we're trying to solve by proposing that it not extend from classy and stable? So the problem is that classy and stable are frozen but the core slash module markup is allowed to be moved. Core markup meaning JavaScript, CSS, everything. And once we call to 9.0.0, it means that classy and stable will be deleted, meaning that all of bardic7 and umami eventually will be based on the eventually the markup in modules that has changed, meaning that the CSS and JavaScript will break. So if we built this on classy slash stable, it means that we don't have to make any changes for the team once we break BC in the modules. But it means that it will break on 9.0.0 and not be compatible anymore. So I'm trying to read in this issue where the issue says that we're going to remove classy and stable from Drupal 9 and it doesn't say that to me. So could you go into that a little more? Because this was very surprising for me to hear. Oh so stable is going to be removed, not classy, but basically classy breaks when stable gets removed. And it's on the... It should be on the initial proposal of stable. So the idea would be in order for the theme from the out of the box initiative to not have its own upgrade path. But if classy's dependencies on stable break, that means that classy would need to be updated and this theme, if it were extending classy, would need to be updated. So you're trying to avoid having to do that rework? Yeah, basically it's... So when we talk about front end, front end people probably know that if you change the markup behind your CSS, it's like everything breaks because you can't really see what things broke except visually. And that's all of the quality control you can do. There are BC breaks in Drupal 9. I guess I still don't understand why for something that could be many, many years in the future. You'd avoid... Because for... So my non-themor, non-designer perspective is that if we want the out of the box initiative to show people best practices around how to build a Drupal site, we want it to be a showcase of how you would actually build a site. And we recommend that people start from either classy or stable in Drupal 8. So why wouldn't we do that for this initiative? Well, those are exactly the... Yeah, those are good arguments why we should do it on classy and stable. On the other hand, if we want this to be supported for longer than what Drupal 8 is... Drupal 9 could be five years from now or never. When we can add new features in a minor release, there isn't a... Yeah. And we don't actually... This massive BC break that we're talking about, that wouldn't even have to happen in Drupal 9. I'm still not understanding where this is in the issue, so you guys need to do it. But that's exactly the purpose of stable, that it will be removed in Drupal 9. And so, was it replaced with a new... For the... Yes, with the new markup, yes. I got you. Okay, so it's not like... It's that the team is rewritten to match the module markup at the time. Yeah. Okay, so I think... Yeah, my opinion is that I wouldn't make a decision now based on something that's a hypothetical problem years in the future, and especially if it slows down work on the initiative and might also demonstrate to people something that's not the best practice that we recommend when they build the sites. On the other hand, I wouldn't like to block the Drupal 9 release on something like not having any shippable teams in Drupal Core. So... I had a similar question. Like, it doesn't matter if it's years from now. Like, maybe you'll have different best practices that you'll want to update it for anyway. Doesn't even need to be the case that the Umami demo sites or initial demo theme is something that needs to be supported over 10 years or so. I'm not sure if it's... Like, I think it's wonderful that you're thinking so much about PC, but maybe it's limiting yourself too much. Yeah, I personally don't really... Like, if we are fine with that, I'm fine with that. I just would like to make a decision where everyone understands what it means. It's not really anything other than that for me. We don't have a strong opinion about that. Yeah. It also feels like, let's assume we would base upon, like, how's the thing core? Like, instead of classy and stable, I think the additional work we would have to do in the future, it's basically just moved into the now, I guess. And like, we can also just do the work in the future instead of now, and we get something nice out of it earlier. The other question is, where's the future of standard? The use case of minimums, like, you don't have anything, you start from scratch. Is there a future for standard, or would we just stay the same, or do you have any idea about that? I don't think I have any idea about that. I think standard is just someone else's opinion about how the experience should be when you install Drupal, and it could potentially be moved in some of the future major releases. But I don't think there's anything that we really necessarily want to do in Drupal 8 for that. Coming from Drupal 7 teaming, and the last couple years now with Drupal 8 teaming, I've got very used to kind of default classes that come out of Drupal. And I think pretty much anyone else that would be doing teaming would be expecting .field, .fieldtype, .fieldname, and things as classes are the same with regions and nodes and that. And I think basing on classy, for that reason, would help us have more people working on it, and not have to be wondering what class we're going to decide to add ourselves. Any work I've done so far on the style guide is all based on the classes that are output by a class. That's not a huge... If we decide not to use classes, we've got backwards compatibility break with the style guide at the moment, but we'll fix that in two hours or thereabouts. So I wouldn't let that pull us up. But for that kind of a reason, I think my preference would be to say we go with classy, and we do what the contemporary best practice for Drupal is and show it in that way. Okay, so it seems like there is no one who is against using classy. Yeah, I mean, we... I'm not a front-end developer, but I'm pretty sure we only ever use stable as our base theme. And we're doing style guide driven development, that kind of thing. Yeah. I don't think the base theme will limit the way you do your front-end, the way you write your CSS. The only thing it really affects is the backwards compatibility. That's really the only thing that we... In this context that we have to care about, because basically everything we get out of classy, we could get even if we go just extend core, because classy is not allowed to change. So we could technically copy all of the templates from classy as a starting point. Okay, so no one else is against this, so I guess we can move to the next question. So in Drupal Core at the moment, we don't have tools for building component-based teams. Are we fine with the fact that the team will not be component-based? Are we okay with that? Like, is that something we can agree as a community that we don't have these tools in Core? We are not proposing them as part of the initiative to be added in Core. Can we then make it as a non-component-based team? Yeah. Yeah, I was one of the people working a lot on the component-based stuff a year ago. I think it makes sense. Like, you shouldn't expand your scope to something enormous with tackling lots of very, very difficult problems while doing something very tangible and useful for a big part of the community. So I would say go with whatever is the smallest scope and the most sensible, impactful. Yeah, the interesting thing actually about this is most of the front-end developers are only familiar with component-based teaming. That is kind of like, can any of us unlearn doing component-based teaming and build this? Like, how are we supposed to do that? Maybe we need to hire some back-end developers writing the team. Okay. In what sense is it not component-based? Because again, it's certainly from the work I've been doing the last few weeks on the style guide. I've got a directory called style guide. I've got a directory called components. And each view mode is an individual item component in that with its own JavaScript, with its own CSS, with its own template file. And the same for the regions, and the same for the page layer, and same for columns and sidebars and all that kind of stuff. The only problem I do have with it at the moment is that index.php or anything.php is disallowed to be accessed because of the hgaccess rules. But we do have all those being developed, let's say, as components. And then for the Drupal team to work, what I've done is I created a library from every single component, and then add those as a global item in the .info file, if we want it globally, like say the header and filter and things like that. And each individual component gets added by its own twig file. Yeah, so we don't have most of the, we don't have any of the tools from components module in Drupal Core. So we don't have any additional namespaces, we only have to template namespace. Yeah, I'm not sure that we need the components module then. I guess the one problem we do have is that we're not using a twig file, let's say, within the style guide. We're just using an index.php file. So we got a duplication of code then to make sure that the node hyphen hyphen teaser template matches the output that's in the index.php inside the node component that's called it. But we don't have the node hyphen hyphen teaser saying that it extends from a different area. But we still have each individual component can be built on its own and viewed on its own, and then merged into lists for views and things like that. Yeah, I think I get what you're proposing. So it's basically you're proposing a workaround of the limitations of Drupal. Yeah, we'd be rendering each thing with php rather than with twig and then we'd merge the HTML that we want to see, let's say. Based on the HTML I'm writing, let's say, in the style guide is what Drupal is outputting at the moment based on the class. And that's basically the same that we're going to get from the default templates. So we wanted to have the change if we need an extra class in it. Okay, so, but it looks like to me that we have a component-based team. We just don't have components module to fulfill it with twig. Okay. Yeah, I think what Marcus is describing is basically using the infrastructure that Drupal 8 does provide, as well as possible to do component-like things, but not have everything as beautifully and elegantly and architecturally componentized as it would in an ideal system. So it seems like a pragmatic approach to have some component aspects, but maybe not as great as it otherwise. Yeah. Seems very pragmatic and sensible. Yeah. I don't know enough about the components stuff to know if this is the right approach or not, but I do want to make sure that we're thinking about whatever we build and we put in Drupal Core is what other people are going to look at as like this is the way that we should do it. And so you shouldn't, even if you could hack around the way that Drupal 8 does something, we should be really cautious when we do that, because as soon as we do, it's going to become the new standard for how people build themes. And for better or worse, like people do what Bardic does already because it's the first thing that they have and they can copy and paste it. And so we need to be aware of that. Yeah, that's a very good point, I think. Yeah, on that note, I was also, I was nodding along until I heard the part about multiple index.php's and then I became terrified and my heart skipped a beat. So let's please not put anything that does that in core. I'm just setting a ground rule right now for that, but if the design is, if there's a way to build the theme in a way that it's like future compatible to, so that it could be converted to an actual componentized theme when core has support for that, then that would be beautiful, I think. Yeah, so I think, do you have still? Yeah, so it sounds like we, what we actually want is we, so we want to find approach that is, as component-based as possible without hacking around, trying to get the benefits out of component-based teaming, but by not taking the cost of making people hack around this. How much slower would that be than thousands lines of ugly CSS? Will it slow us down? I think on the implementation part, it doesn't have a drastic impact to one way or another to make it slower or faster. The problem is that once we start finding bugs and once we have to maintain what we've built, then it's going to be drastically easier to maintain it once it's component-based. So that's the benefit we get, but on the implementation part, there shouldn't be a big difference to one way or another. I'll remember that. Is the issue then that, okay, so what I'm doing with index.php files at the moment is, like we said, it's a pragmatic thing, it allows us to at least see some sort of a rendered page so we can start writing HTML or CSS and JavaScript. So we take out all those index.php files because we don't want that stuff in. Can we do that with Twig then instead? And if we can do that with Twig, I don't see the problem then with extending from a component template, let's call it, because it's not outside the directory root of the team itself. So we've got, say, two directories, one called templates, one called styleguide. We're just going to tell the templates to, you know, we'll say, add include directory till whatever it is. If we can get my index.php files to be index.html.twig or something instead. We possibly could but we don't have the namespace in core so we will have to, again, kind of hack around the limitations because the namespaces come from the components module for the Twig templates allowing to include without Pat. But why, I mean, include the relative to the current directory? Yes, so you can. So why can't we, I mean... Yes, you can. And then, like, use attach to, like, add to CSS and JavaScript and that's it, but then that's what he's doing. Yeah, right. But don't get the discussion about the index.php things. I think he's generating a overview of all the different Twig templates with an index.php file and there's an individual index.php file for every single Twig template so that you can view them all. That's how I understand it, but I'm not... I think nobody is exactly certain how you've done what you've done. I think that's part of the confusion. Yeah, so I think it's an unnecessary implementation detail that we're discussing here. I think the whole point is do we want to embed the work of making Drupal better at supporting component-based teaming in this initiative? I think the answer to that is no. I think that's enough for this conversation. Yeah, so the Mark's approach is not actually to do anything with the components itself, but it's to do exactly what Wim said, to allow rendering a style guide, to allow rendering a single Twig templates. Yeah, so that's why he was talking about the index files. So that's another problem that we have. So another thing that we've been thinking about is that what is the difference between the core provided distributions or installation profiles and the contributed distributions and like how could we promote the contributed installation profiles further because it would make sense to promote the contenta inside the out-of-the-box initiative somehow. Maybe as part of the installer, maybe inside the site itself. I don't know, they are very related. They are something that different user groups are interested in, but if we promote this use case, doesn't it make sense to also promote another use case because I would see it as almost as common? Is there something that we would like to do to promote the related installation profiles and what is the difference between these? So I have a related question basically. Driz was talking today about Drupal moving away from blog and static sites and these kind of smaller examples to more complex things. Are you planning also to showcase the work that other initiatives are doing like layout media workflows and these kind of things? Yes, actually the plan is that we would like to extend the demo from node module, block module to the more advanced use cases, but I think we need more experiences from how building demos works for us. Like what kind of different tools do we have to build these demos because it's like if you just install workflows, it's not enough to really give a demo out of workflows. So we need a better way to build demos than just like installing the module. So for node module, it is creating default content. For blocks, it's like creating default blocks. It's simple and that's what we've got figured out now. But for workflows and other things like the more advanced use cases, we have to figure out another way to demonstrate them. And we don't have a solution for that yet but we have discussed about it as part of this initiative and it is on the future roadmap once we've got the first bits figured out. And I think it's very important that we will be able to build demo of those as well. We can go together. Yeah. So for this question, two things. First, I think it's a very important question but it feels again like your expanding scope to a very big problem space. Maybe it's a separate initiative of its own, the discoverability of distributions. So I would personally say be pragmatic again and don't start tackling this problem. However, I do see your point about content being related and so on would be creative. It could be surface but content in particular and actually most distributions to be able to surface it in the regular installer, you would have to have the ability to download additional code which is an unsolved problem. If we had that, we could do automatic updates to some degree as well. So it's a kind of worms that I would say that's not start tackling that as part of out of the box. Yeah. By promoting them on Installer doesn't necessarily mean that it would have to be a download. It could be something else as well. The way you describe it in science and me like in the installer you get standard minimal and out of the box are you mommy and then there's also content and so you click content or radio and then it starts downloading. That's why maybe... Yeah. That's, I think that's the obvious way but I think there is simpler ways to solve it. Like it could be just a link to the distribution as well. Like we have... These are the ones that we ship with. These are the ones that you can download. Like if you're interested about open atrium, go to this link. If you're interested about content, I go to this link. And you feel that that is related to... So the reason why this is related is because a lot of people are asking why are we focusing on this one thing is that we actually... So it's about the out of the box experience and we are solving it for one... These user personas that we have but to solve it fully in the long run we need to be able to promote... We need to be able to make other demos than what we are building at the moment and to maybe make it faster at this point to kind of... Because it's really slow to build these demos in Drupal Core. There would be a faster way around it if we could just promote the examples that we already have out there even if they are not necessarily on the grade that they could be included in Drupal Core automatically. Yeah, that's the same example with the default content. I mean, we didn't create the default content architecture and how to build everything they built it and we are going to use it. So for example, if we work together with the installation profile that it's something that it's also part from this initiative working together we will figure out different uses cases and so on. Yeah, I think you should really not focus on that as well. It's just so much of a problem. Like many distributions like currently don't really host on Drupal.org for example, because they don't have composer support or it will come so I really want to invite people to go to the meeting conversation at five tomorrow about installation profiles where all those problems are talked about and I think that is probably something which will happen in parallel and you should not. In this very room. Yeah, I assume so. What else do you want? I think the solution to like link it from the installer is amazing but how do you like select which things you want to promote? Yeah. Another version of let's start pragmatic. This is the one case we defined so that we may learn how we can do this. It's the first demo we make to find out how we should what we need to make it a repeatable process. Yeah, so this is a special case but with a focused goal right which is a strategic goal so it answers it provides value in its special case and let's use the special case to find out what we need for a generalized approach. But keep track of that don't make it a topic. Yeah, sort of the piggyback on that. I think also once like I feel like very few people as far as people use to actually know about what you guys are doing but obviously like once it's released is like all of a sudden tons of people will know about it and maybe also more people would be willing to work on it because obviously it's promoted if it's right there on the triple installation page and you can do it. So some of the more ambitious stuff could maybe do round two because now everybody knows there's an out of box experience that's different from standard whereas like it's really hard to get that message across until it's every single person who downloads Drupal has this experience and I feel like that'll be a game changer. I don't want to open the can of worms but it kind of feels like to keep it in context you could add like banner space down the size of your theme. I mean I haven't looked at the theme in detail so I can't see if you've got the real estate there you could have rotating banner images that essentially link off to the kind of distribution pages module pages and you can have interlinking things that are actually in context but it feels like it might be a solution to that. Yeah so we have a about umami page actually on the designs where we will explain something about this theme we haven't decided yet I don't know maybe that's the place where we could promote other examples other demos. Yeah so I just want to really touch on your point so I'm relatively new to Drupal I've only been working it for like six months and I think like having it in that sort of option where you can you know just install it straight away would be really beneficial because from my perspective when I started six months ago first going to Drupal like the base theme and I'm like what is this just like full stop like no idea so it wasn't until I worked on you know five six sites where I was like oh okay I understand content types views blah blah blah you know and you start to get the bigger picture but right now I don't think it's going to be that helpful if we don't give beginners like myself some clear indication of this is a good example of what you can do now go back and do your own thing I think we are running out of time I'm pretty sure someone's going to kick me out off the stage soon so we have plenty of questions left that we would like to discuss with you so so here's the details of the of the buff room see you there thank you