 I think we're gonna get started. So just before we jump in, Mike created a Google Doc for us. So if you go to bit.ly slash goldie docs, that's gold-i-d-o-c-s, you can add your own notes and participate. What? Don't, the notes? Okay. All right, you folks can sort that out. All right, so this is just right. Goldilocks and CMS theme systems. Thanks for coming. We want to get a discussion going. So we're gonna have about a roughly 20 minute presentation just to kind of frame things and talk about some different concepts. And then we'd like to hear some ideas and get talking. So yeah, Mike is in the middle of the room there. David is kindly closing the doors for us. Thank you, David. So yeah, let's jump in. We also have these, oops, okay, that was fun. We have the, these slides are at another bit.ly link. So it's bit.ly slash gold-nola-2016. So if you want to follow along, you can also get to this from the session note if that's easier. By the way, can you hear me okay, everyone? Okay, thank you. Okay, so let's start by introducing who we are in case someone doesn't know already. So my name is Lauri Eskola. On Drupal.org, you can find me with different variation of my first name, Lauri with three eyes. And the number of eyes is not variable. It's always the same. People tease me about that. I'm a Drupal developer working for Android. I'm also a Drupalite theme system co-maintainer. All right, I'm Scott Reeves, known as Kotzer on Drupal.org and Twitter and some other places. And I don't have any other variants either. Kotzer. So also Drupalite theme system co-maintainer along with Lauri and Joel and Fabian and I think that's it. No, no, there's other people, but anyway. Devilgenzia. I saw his face on a stick earlier, so that was fun. Webchick has like a little, anyway. I also maintain the stable base theme in Drupal 8 and I more recently am a provisional co-committer for Drupal 8. Thank you. Mostly focusing on theme stuff, front end things and just helping out where I can. Also a team lead at Digital Kidna, 50-person Drupal shop out of London, Canada and let's jump in. Yeah, so more than uses hot pink, this is deep pink. So let's start with the problem that we are discussing today. So we have some personas that the theme system has to deal with. So this is the base for the complexity that we have. So the first and the most obvious persona, these are by the way developer personas, so a end user of a site is not one of the personas of a theme system. They don't know that theme systems exist. So the front end developer slash teamer is the most obvious persona. They have the most power of using the theme system. They have the last word, how things are gonna go to the browser. So they can change basically everything that is coming from the backend or whatever the site builders has decided. The second persona that we have recognized is a backend developer. In Drupal backend developers usually use theme system so that they simply just input data into the theme system to be rendered in a way. There is other type of theme systems which don't have this kind of a workflow, but this is how most of the opens are CMSs work with. And the third persona which is way different from the two previous ones is a site builder because site builders may change the visual look of a page by using let's say color module or they might use panels to create layouts for pages or they might use views and create classes in the markup. So these three user personas are very different as you might imagine and accommodating these different personas is sometimes very, very difficult. Also the decision making between these three people is very difficult. Who should be prioritized over another? And different CMSs do prioritize these user personas differently. We are gonna talk more about that in a bit. So in preparing this core conversation we looked at some other open source projects just to see what they're doing for personas. Not necessarily from like an admin UI, UX kind of thing but just in general for the project. So we looked at Mozilla. So there's a link here to what they have and they basically documented probably about a dozen or so personas and each one has a name and a description of kind of what they would do and also sort of a title. So we're just gonna kind of breeze through a handful of those. So they have like George who is a designer. They have Denise who's a lightweight JavaScripter. We didn't really look into what that means but anyway it's pretty specific right? So they have almost like for us it's like we could have different types of themers maybe but we also have Emily who's a corporate web app developer and Alexander who is a Firefox add-on developer which we thought was kind of interesting because it's like module developer for us which we don't necessarily separate from backend developer but maybe we could and we should. So like Lori was mentioning like the prioritization of these different roles or personas can really affect how you work with them, how you work with something like the theme system, maybe how flexible it is, how much control you have. Perhaps it's also kind of how usable it is for you as that type of user. And what we've, what our opinion is anyway is that often this prioritization is not explicit when something is being built. Often it's whoever is driving a certain change, whatever their kind of persona is like they're at the top of the list like they're number one priority because they're like yes I want this thing and there's nothing necessarily wrong with that but I think we should be a bit careful with that because it can get us into situations that might not be the best. Just to add on this that we're gonna show some priorities of different CM assets. The idea is not to compare them as which one is better than another but instead to explicitly show that it is possible to give different priorities. And this is just a screenshot of a team that we built on WordPress. It is Bartik, visual on WordPress. So we wanted to prove that we actually did use the other team systems of different CM assets. Yeah, Lowery gets all the credit for this one and it's got some like Finnish hockey texts or something in there so it's pretty fun. And yeah, so what's gonna follow, it's definitely not scientific. It's just opinion, it's based on our knowledge of Drupal and then based on almost like a first impression of some other systems because we haven't really worked extensively with any of these other ones but we kinda looked into them, we played around with them, looked at the code, looked at the templates and so on. So yeah. So for Drupal, this is what we landed on. Site Builder is usually kinda gets quite a lot of power and then back in there's a lot of kind of API things that you can do in Drupal and there's form API and things like that which we'll talk about a little bit later. And then the themeer kinda gets like the short end of the stick sometimes and this actually, we didn't really mean this but for this to happen but this did actually line up with Dries Slides from this morning where he was showing the survey results of who do you think we should be prioritizing? So at least based on our opinion, we're doing okay-ish but again it's our opinion that we should probably have more fine-grain personas than just these to really figure out what we may be missing and what we can improve and potentially even pull in new people into Drupal that are not using it yet and maybe they have their reasons. And WordPress, themeers tend to like WordPress. It's maybe not as clean per se but it's very flexible. You can do quite a lot in the theme and to the extent that certain things are almost hard coded but you have the ultimate control and site builders can do it quite a bit in WordPress as well and we kinda put back in last because there's not as much of an API like intense like Drupal has in WordPress. And we looked at Joomla, I guess I should, I don't know if it has the exclamation mark anymore but yeah. It'll always have the exclamation mark. It'll always have the exclamation. Yeah. It's in the trademark. It's in the trademark. So yeah, this was not the real Joomla apparently that I was trying. It was a counterfeit Joomla maybe. Anyway for Joomla we found that there was quite a lot again that the site builder could do. One interesting thing that I noticed is that blocks, well they call them modules which is confusing for us but blocks, I'm just gonna call them blocks. Blocks in Joomla you can do things like you can schedule the publishing of a block or the unpublishing a block and I thought that was really interesting and I was like that's a cool feature and you can do some really intense stuff where you're really like affecting the markup from the UI. We mostly looked at the block UI but I'm sure there's other things you can do too. And the theme is it's sort of in a similar position to WordPress from what we saw. It's not necessarily super clean. From our perspective if you open up the template file it's like they have almost the entire theme layer at the top of their template file. It's like they have setting up some variables and then preprocess and then output the HTML all in one file. So yeah but it's very flexible. You can change it if you're a theme or you just be like oh I can just mess with this especially if you know a little bit of PHP but that could get dangerous. And then back end we honestly don't know too much about the back end but it just again it seems similar to WordPress in a way that it maybe wasn't quite as powerful in Drupal in terms of integrations and things like that. And concrete five the site builder can do a lot of cool stuff. You can drag around the blocks visually and things like that. And then the back end stuff there's quite a lot of cool like there's like helpers to build forms and stuff like that. Like they have like a helper class where you can output form elements and form labels and it seems more geared to like a hardcore PHP developer. And so the theme are like you can do stuff but if you need to change things specifically like you might run into trouble because they're using like these form helper classes and things like that. Like it might be sort of hard coded the markup that you get out of that. So in the end we landed on the same prioritization as Drupal for this one which we're not sure that maybe that's something that we can talk about is like should we be looking at systems that are similar or should we be just saying like no they've already made the same decisions that we made we should be looking at something that's radically different and see if that inspires some ideas. So good for thought. Yeah so now we've talked about the possibilities of prioritizing. So let's take a little bit into the problems that this has caused that we have the different user personas and we have been trying to fulfill the needs of all of them. So the first problem that we have is security. We had a huge fight with the auto escape in the past couple years. We had to do it twice to get it right. And that illustrates how complex system we are talking about. It was huge effort. The problem in auto escape and the security that the team system tries to manage is that there is a lot of user-generated content and there is content markup generated by the backend developers and there is markup generated by the teamers. And we have to always be identifying where the markup is coming from in order to escape the right things the right way. So maybe if we would allow less things happen in less places it would be simpler to build things like this. The backfired compatibility was also another thing that we have been fighting with. So we created stable into the team system to support backfired compatibility. Like in general backfired compatibility is simple. It's just that you can't change a thing. But in order to allow changing things without breaking things, without changing them you have to create a system that allows you to do so which creates the complexity. And this is maybe just one of the features not only that we have user personas that we need to fulfill. Maybe if we would have more fine-grained user personas we could figure out that maybe this is something that we don't really have to consider. And when we were making this decision of adding stable we actually had to create ourselves in that meeting the different teamer personas in order to be able to make the decision. That it was never documented anywhere publicly that in a way that it would be used to make order decisions that it might affect. Another problem that the team system has is always that it has the power to train things. The teamer can basically do anything they want to. And that creates sometimes a false image of how flexible the system is because you might be breaking something in some other place. So let's say if you're building a site for a hairdresser you might be able to compromise some things. Let's say you might be taking data straight from a node object in your node template which breaks the field UI totally. But on that one specific site which is a small site you might be able to make that trade-off that okay I might not need to field the UI because I can do this this way and it's so much simpler but when you're building something in Drupal Core or something in a module you can't really do that and then you see the real complexity that is over there. So all of these things are proving that because we try to fulfill everyone's needs we end up having a lot of complexity. Yeah and on that note while we were exploring this like we kind of landed on the idea of frameworks too and just the idea that frameworks are so and to be specific I'm talking about things like symphony framework probably also to a certain extent front end frameworks but tough to say let's we can probably just keep it to PHP frameworks just for the sake of this discussion. But like frameworks are quite different from CMSs like you would often have something like a content editor but typically there's not someone who's like a site builder who's like rearranging the whole site that's usually hard-coded into a template because you're building like a custom application or something that's pretty much from the ground up and you're just getting help you have that framework to help you. One of the things that I've kind of noticed over the years is that not to knock them or anything but like sometimes people that are coming from the symphony community kind of look at what we're doing with Twig and say like you're doing it wrong like what are you doing? Like that's not how you use Twig but it's a totally different context right? Like Twig is just a tool so the fact that we are a CMS the fact that we have site builders I think has to change how we use things like Twig at least to a certain degree. So that's just kind of what my thought is on that anyway and the other kind of interesting point too is that frameworks don't typically come with a lot of templates and styling like they might have like a really bare bones thing but like you know Drupal and WordPress and stuff like they come with like themes and templates and CSS and that can be kind of off-putting to someone who actually wants to build in the framework way and start from nothing like that's kind of the dream of a lot of Drupal themers is like I don't give me any markup like I want to specify every line of markup but that becomes really hard when you have site builders. So just let's point out a few of the specific examples of a complex use cases in Drupal Core which could be simplified if you would just simply leave out some of the user personas. So let's practice with the logo. So how logo works right now is that you upload a logo into your team settings on the appearances section of the admin interface in order to show it on the page you have to have a region in your team you have to output in a template that region and you have to place a block on that region. So that's how logo which is the most simplest thing you can think of on a site is being input in Drupal. So that's quite a lot of complexity for a very very small thing. If you would say okay if we allow if we accept the fact that site builders are not able to modify a logo we could simply just add the logo in the template which is what many other systems are doing and that would make other edge cases very simple let's say if you need to localize your logo or if you need to translate it or if there is something more complex happening with the logo because right now it's prepared for the base use case it's complex and if you wanna add these new features it's gonna become even more complex and this is again like what are the personas that we are building Drupal to who do we wanna help with these features? And also the problem again is that you can do this in a template if you want to but it will break the UI which is kind of limiting for some use cases because you can't really do it in an installation profile or a module or a theme. So again it depends what is your context well how are you using Drupal what how can you do this feature. Another a little bit more complex example is forms which clearly illustrates like how are we making these decisions who are we prioritizing. So forms are they are pure markup they are nothing to do with the backend but the backend developers has the full authority over forms and what is gonna be printed what kind of markup is gonna be outputted for the forms. It is great for the backend developers it is great for the site builders because there is very well specified components in the backend that they can simply just drag and drop somewhere you just have to have a glue code that will tell which components are gonna be show and where. But for the teamers they don't have any authority over the forms they can modify the markup of a form. So the main user of a form or one of the main users of a form who is gonna team the form in the end is not able to modify what kind of markup is gonna be output for that. And that was actually one of the interesting differences that we saw between different systems that many of the other systems simply just had a hard coded forms they didn't have something as compasses form API. Also another interesting point is that form API is one of the things that there has been discussion for a long time to renew it. But I haven't even heard a single thing in that conversation about how can we make forms more teamable. It's about all the other things about form API. So when someone is renewing form API if it would have the different user personas it might help them to think about that specific feature from another perspective than their own. And yeah, this is basically what we wanted to show to you today. Now we would like to ask you to join the conversation. So we have some predefined questions here. The first one is does anyone have any examples in other systems that you think are valuable? Like does any other system do anything like this? Do they prioritize different user personas or do they have written down them well? Or yeah. Hi. Can you just say who you are please? Hi, my name is Joel Patet and I'm one of the theme system maintainers for Drupal 8. Thank you. Yeah, subsystem. Anyways, so Panels has an interesting idea for themers that I've kind of grown to love. I didn't see that first. But they have a builder which most themers wouldn't really use most of the time. But they actually have a builder that allows you to create your layout and then you can put the stuff into the layout. And that's kind of nice for those people that use it. Most themers I would assume wouldn't use that because they want to give that control, they want to take that control away a little bit because they're laying out the page. So what they do is you can actually provide template styles that can be shown in there and then it's more like a choice. And so that gives me as a themer, the opportunity to set the areas of the page where I could put different fields and then I'm probably gonna come back in as a themer and put those fields into those buckets but at least gives me the opportunity to structure that page. And I really like that kind of thing whereas in Core we have the, just here's the drag and drop order that is gonna come out and then we spit it out on the page in the order that the theme builder did. It's not out of the different system, it's inside of our system and we have a, we have a contrib module for that that can do that kind of thing and I really like that one. Like I've used SilverStrike for a long time and they do the kind of same thing too is if I can provide the fields to, if I can provide the field values to the initial page template or the one that I'm laying out then I can actually write the mark around it and I know like that's kind of what you're saying. I was like I wanna be able to control the markup around those values. I just need the values and do with them as I will. So yeah and I'm sure there's, well actually, yeah. I think yeah, no I think that thanks. I think that's valuable and I think to me that kind of comes back to what we were talking about with perhaps finer grain personas where I think we've talked before in the community about kind of some themers they just wanna write everything in code. They don't wanna click where other people are okay with. Yeah, I'll click together a panel layout or whatever or like you're saying, like you're describing like add the fields to the different panel panes and then write your CSS. So like perhaps those are two different personas that we need to consider but yeah, I think that's worth considering at least. Hi, my name's Chris Weber. I'm a Drupal enthusiast. I really feel that you missed an excellent educational opportunity by not reviewing the Kraft CMS system because it is a system that ships with no theming layer. It ships with no theme in fact that makes the basic assumption that as a site builder you'll wanna organize content, you'll wanna create content within the admin but you don't want to have the system have any influence on the actual theme. And the API that they provide is very much one that you would expect when you're dealing with the content repositories. So you would write actual code to get lists of content. Instead of using views, you would write a one-liner or two-liner in order to say from the content repository I want this cut of the content and then iterate over that loop to generate things on a page. But the basic idea is that you would be coding your theme every time you do a project and perhaps that is both its benefit and its detriment. But it'd be interesting to look at how we look at Persona's in comparison to that perspective. I added a video to the notes where I did a deep dive about that. Awesome, yeah, thank you. Do they provide examples of themes? Well, they have a demo. They basically have the demo available for you to take a look at how they would do that. But when it comes to other guidance like having a theme repository or something like that, that's up to the different vendors and stuff. So it sounds like you're saying like instead of clicking a view together you would just write PHP, is that correct? It's Twig. What's Twig? Yeah, so they say- They had to override Twig to create some craft-specific API functions in order to get access to the repository but then that set up Twig. Interesting. That's a very interesting point because it makes me think again how can we make these kind of decisions because we would need to know who are we creating this system to and who should we be prioritizing? Like with the current priorities that we seem to be having we wouldn't be really able to do that because it would take authority away from the side builder instead of giving it to the teamer because teamer is right now the least priority that we have on the system. And unless when you click together a view that then generates a Twig template that you can go and edit because we can do things. Generate. Ha ha ha. Mark. So I'm a big fan of style guide driven development from the front end side of things where you have a system. Pattern Lab is one really good example. There's another new one called Fractal. KSS Node is another really good style guide system where it's empowering the teamer to think about how would I make a design work? So it's kind of like a design first rather than necessarily a side builder first system putting together and then coming up with the various components of how that all works and then breaking those down into individual chunks of the page. And so I just wanted to point out one other aspect of our theme system is that it's not only driven by side builders right now but Drupal's superpower is content modeling. We're super good at coming up with relationships between different content and allowing people to structure that within our system. Our theme system is very, very tightly tied to those data models that we create. Our primary model of outputting our theme is to start at one piece of content, typically a node and build out from there to go down through fields and then go out through blocks. And there are some things like views and panels that have slightly different models but that's like a really important aspect right now to how our theming system works which is very different from the themeer layer of that. Like when we're thinking about how to implement a design the component-based approach to things. So Dries kind of mentioned the whole component-based theming system and the keynote this morning but I just kind of wanted to note that there may be some ways to bridge some gaps and enhance things that by getting real components into our system we could empower front-end developers to be able to have a component-based approach to how you theme things but also components really map very well to how site builders think about putting together a page. Like I think it maps very well to say, hey, I wanna, here's the header, I wanna put some chunks of things into the header like one particular component or another component. That works really well versus right now we have so many different areas to define those things whether it's on a view mode page or a views or a block page and a more unified system based around components might help improve everybody's lives. Yeah, the component point is very interesting and we both agreed when we were preparing this session that the wall discussion around components that's been as opened is, it's gonna help this a lot. It's gonna make the theme system a lot better most likely but it's gonna be a one-time reset and we might end up in the similar situation where we try to fit a system for all these different kinds of user personas that we don't know and then it will be bloated again into something else than what it was designed first. Yeah, like in other words, like it would be nice to, not that we wanna hold things up or anything but it would be nice to maybe incorporate some of this discussion of and maybe define some personas as part of that discussion. And we probably gonna use some of the things that we created in Barcelona last fall as a base. They are different team of personas but I believe it would be useful if we could specify these things even for site builders and backend developers even from the theme system perspective. This is David. So the persona stuff is really interesting and we discussed this a lot at mid-camp and Mark who just spoke before me had a blog post discussing all different kinds of things for personas that we were discussing there and working on which is even a lot of it is more granular than what you guys are discussing here. But I think the biggest problem that I always see is trying to understand in our theme system where the sort of separation of concerns is so that tax on to some of what Mark was talking about as well, like the logo is actually a really good example what owns the logo, right? It's not just what's producing the markup of what owns it. Is it part of the content? Is it part of the site configuration? And is it owned by the theme? And that's why we seem to get into these problems and there's lots of things in a system or in any site that are like that that we always encounter things like the menu, right? Like is the menu owned by the site configuration or is it owned by content and like what can control it? We can figure out the menu. That's usually the one thing that causes the biggest problem because it's the one component that actually can change as opposed to a lot of other things. Like how often are you gonna change the markup for how like an image tag is produced? It's still just an image tag, but menus can be unordered lists, they could be divs, they could be other things so someone might wanna like redesign how that works. But we always run into these issues where it's like, are it something produces that markup or what should be producing that markup? Can we create clear lines of separation between the backend and the theme system and the theme itself and the CSS and all that kind of stuff? Do you think we ever get to the point where we actually can do that? Yeah, I don't know if we can really answer that, but I agree and menu is actually one of the ones that we considered including, but it's a little thornier than like something like the logo, so glad that you mentioned it. Yeah, it was interesting to see that even a menu has so many different ways to be implemented in all these different systems. And it was one of the things that we believed that we could easily show that by defining user personas, when we wanna build a system, we could probably make different kind of decisions that we might have made without the user personas. Hi, Chris, triple nerd. About forms, it's such a big enough problem that it sounds like it's its own separate, it needs its own separate focus. I don't know if you've looked at things like form IO, Travis did well, Drupalert, working for form.io, it's another way of creating like a form building experience, works with APIs, just another suggestion and something to research. Yeah. Thank you. Hi, Boleon, UX maintainer. One thing I'd like to, well, just throw out there as an ID. So in my professional job, I work with a lot of clients where we do persona projects and sometimes a couple of month projects where we research what their personas are for their products and then we try to help them out in actually using those personas. And one of the things that we found works pretty well is once you actually have defined like a set of personas, like in this case, we would have three. It's actually do exercises like scenarios where we say like in this scenario, how would you apply these personas and which things would prioritize how? Because at the end of the day, you're always gonna have competing priorities and it's never gonna be like a gray or a black and white where you can say like, oh no, we're gonna do the cycle thing. No, you always have those competing priorities and doing those scenario exercises. It's also something you can then have as like an example for when something similar comes up. And that's something that seems to work pretty well. Yeah, thanks for that. Like I think we can really use your help, like not necessarily use specifically, like definitely use specifically, but just UX in general. And I have a question for you though. So don't run away. So can you just describe that a little bit more, that exercise, like are you getting different people or are you just kind of simulating in your head what that persona would do? Like, or are you getting someone that fits that persona and asking them questions? Yeah, so well, this is different because it's different. Okay. But so for example, for one client, we have this process of like two months where we did like 40 interviews with four basically archetypes that they thought were their customers. And out of that, you get the profile, right? Of what that person finds important, like what the ways of interacting with the product and basically how that impacts like key parts of the product. Right? Like so how the team system should be in this case, like ideally positioned to cater to his or her needs. The exercise is then to actually just have a scenario, which in this case could be anything like the component thing, for example. And to then have the discussion ideally with like people that represent that persona. So in general, that's like certain customers. Yeah. In our case, that could just be, yeah, people that actually have that role in any type of group or organization to kind of play that role and then to have that discussion with the people in the room. Because the most, the biggest part about personas is actually trying to make the arguments of a certain persona more like. Cool, thanks. That's very helpful. Probably related question for that. So in the context of triple, how should we prioritize the different user personas? Should it be always the same user persona or like how should this kind of decision making happen? So generally it's a top-down problem on the sites that this is the persona that's most important. The vision that was laid out, for example, this morning, but to be honest, hope the last like 10 years. I think there's some obvious personas. But what we really haven't done quite well yet is actually fill in the personas, is figure out like what are actually the behaviors that these people do and what are their preferences and things that they don't like. So I think that would be a good point. Cool. And kind of one question that I want to throw out there just is like to me, is it possible to make all these people happy or do we need to kind of give someone the short end of the stick? Like that's just kind of, might be a hypothetical question, but. It doesn't have to be the theme or always. And does it have to be the theme or always? Yes. Just to that, I think it's always been an issue that just because you have priorities doesn't mean that everything goes to the top priority, right? I mean, you have to consider them the most but it is possible to spread the love a little bit, I think. Something, a priority that's the last priority is still a priority. It's just not the top priority, right? Yeah. So I think maybe sometimes you can make small sacrifices for your top priority in order to have some bigger wins. Right, so try and spread it out a little bit more. Yeah. Yeah. You also, right now, because we don't have that well-specified personas, obviously we don't have a decision-making process happening on these things. Like who is gonna lose in this and who's gonna win in this? So having the more fine-grained user personas might help as to think about the specific users that we have. Mark Fulmer, I'm a backend Drupal developer and I think this is a really interesting conversation because it applies to a specific instance of commerce because I think a lot of what we're talking about here is forms, single pages, usually they might have JavaScript, but in commerce there's often times multiple pages that you have to move through and it's not just a question of what should it look like but in what order should things happen and what should it be the feedback given and so I think that that's a particular challenge between backend design, front-end design and even the UX there, so I don't know what the answer is but it's a challenge. Yeah, for sure so I guess and so what you're saying as well is that you want some flexibility for someone to be able to kind of move steps around and stuff like that, right? Is that part of it or okay? Yeah, I guess the site builder there to be able to have a role there. Yeah, okay, cool, thanks. Hey there, I just wanted to sort of follow up on. Where are you? I'm Tobias, T. Stoeckler also a Drupal core developer and mostly I guess backend developer. Yeah, just to sort of follow up on the sort of conflicting interests of the different personas. Basically expanding on what you said, Lowry. I think actually if we do get to the point where we actually have defined or have actually made that decision on what we want to allow and what we want to sort of like what we want to be as a product and what we want to support, what kind of personas we want to cater for. Obviously we will never like make everyone 100% happy but I do think we can actually achieve like we can actually make all people reasonably happy like just to go into that example where you have like the manage fields page where you can order your, drag around your fields and then have like a theme or just override it completely. If we wanted to actually support that we could totally like build in a flag that in the UI then shows the person like instead of showing the table, just says like this doesn't exist because the theme is overriding this page. But on the other hand, if we don't want to support that we could also like somehow discourage the theme or explicitly in some way because it's not always like the evil theme or that's trying to like destroy the site builder's life but it's also just like someone seeing a template, seeing a node object and just playing around with it. So I think if we can actually like clearly define where we want to be and where we want to go I think we can just enhance our tools in our toolkit and actually make everyone at least reasonably happy. I agree with that. And I think in the process of making decisions it would be wise to have the user personas so you could make the decisions based on the user so that the user personas that makes the most effect would be happy. Yeah, and like bigger effect on teamer might be bigger effect in the total happiness than having a small happiness effect for the backend developers. Jess, I'm XJM, I'm a Drupal 8 release manager. The part of the past couple of questions that I find interesting and that I'm interested in how we would solve is how we actually implement taking, if we define these personas how we actually make sure that they are a part of the decisions that we make. And so I think the current point, the place that we're starting to try to do that in core is in our core governance process we have a design designated flow where if a change requires a significant change for X then someone who's responsible for maintaining that needs to sign off on it before you make that change. So for minor changes that don't have significant impact on anything, that isn't required. But for example, if something has, introduces new user interface patterns then the site builder personas, if it's multiple personas, we kind of lump that under like there would be a usability sign off that was required to make sure that the site builder's use case was met. And then a combination of that and with a particular subsystem, the part of the site builder's interaction that that subsystem is responsible for providing would also need to sign off on it. So it's like a domain of two separate responsibilities having that list to refer to be really interesting. And I think we also, aside from if it will significantly affect the theme system we don't really have any point of sign off for if it, what would be the theming personas there. So that's interesting. And I'm not sure at what point, like at what point in issues is it every single, every single issue that affects markup period or every issue that affects the way markup is built? The form API is a great example of like that absolutely has to be something that all of the different concerns like are reflected in if we change that. But in smaller issues, like at what point are we missing the boat when we make decisions? And that's only for the core issue, Q obviously doesn't even apply to the whole country of ecosystem. Yeah, I think that's really valuable and kind of one of the questions that we put down is kind of like who decides and also like do we always need to prioritize? So it's yeah, I think that those are really relevant and something that we need to think about. I guess my initial opinion is that things like maybe minor markup changes and things like that, like it would be good to consult the markup maintainer kind of thing, but we probably don't need to bust out the big like manual of personas for something like that. Yeah, that person, yes. But I think the WIMS component issue is a great example of a issue where we should really consider what are we building this for? Because it has a huge effect on all of these different user personas. I forgot to clarify something which is that right now the process for this actually is have Scott commit the patch? That's the way we've solved that thing. So right now as a core committer, Scott is kind of filling the absent role of the markup maintainer sign off. So to some extent, but it's not really a sustainable strategy to pin all of the hopes for the future of solving all of course problems on only on the fact that Scott will commit patches. Also, I agree. I don't have anything against Scott, I love Scott to be honest, but that decision making process is based on Scott's priorities in his head instead of the priorities and user personas that we might come up with a larger audience. Yeah, like I think given that I am, that's a good way to put it, because yeah, I am kind of filling that role right now. And there's definitely cases where I would probably be really happy to be able to consult the old manual of user personas to be able to think about things a little differently. So the first time I... Who are you? I'm sorry. I'm Cathy, I'm the SCT. Hi. I work on core, I guess. And the first time I heard about personas was maybe at like a year and a half ago when I was part of the Drupal.org software working group. And we did an exercise to think about prioritization for Drupal.org changes. And for a while that group did the prioritization. It's a little different right now. But it seemed like then that other people in the room were familiar with the process of making personas and doing prioritization. And it was new to me because that's not my job because I was just working on core issues and I had no idea. So if I was one of the last people in the room to know what a year and a half ago, why are we not already using it in core? Like what is changed now, right? Like why didn't this happen a while ago? What happened now that we're really thinking about putting this in place? Well, I think to me anyway, Laura, you can feel free to disagree. But for me anyway, part of it is that I don't feel like this is not my domain of expertise. Like UX, let's say, let's call it UX. Like I can use the words and I can sort of talk about it, but I don't really, oh cool, we got a software update. That's right. You know, I can throw around terms like personas but I've never done like one of those exercises that you're talking about. So it's kind of an abstract concept to me. So I'm like, you know, when we were putting this together we didn't really know that we were gonna be talking about personas, but as we were kind of exploring this, we're like, okay, like we were basically trying to like fix the theme system. Like that's kind of the lofty goal of this core conversation. So it just seemed like it could be a useful tool but I don't really know how to use it. So I think if we can get people to kind of teach us, like you could probably got taught, then I think that would be good. That's David again. So my opinion, so I can't necessarily prove it, but I suspect that some of what, why this persona stuff started coming up has been the way there's, the community has changed slightly in who's doing contributions. So I think it was years and years ago so much more back and not just focused, but because it was largely back in developers that they didn't think about the personas as much and that there's, there are a lot more voices I think is involved. Like the thing, the twig team is much larger than it is now and has a much larger voice than it has now previously. So there's a lot more people saying like, oh, there are all these different persona types and we should think about like what's affecting these front end people and these site builder people and these back end people because of the voices that are actually there now as opposed to what was there before. So that might be part of it. Yeah, I think that's a really good point and I think that kind of, the whole kind of front end united idea that we're bringing together like the front end and the themers and the UX and stuff like that. I think that is partially at least explains that because I've definitely had more exposure to those ideas just by kind of being in that cluster of people. So I can add also that with history. So I've been semi-involved in like Drupal 6 and quite involved in Drupal 7 and it seems to be that at the beginning of a cycle we always go like, oh, we need our fundamental tools to make decisions better. Then once we start running, we go like, no, we were running. We don't have time to like do all of these steps that are part of general product management type activities. But I think what's different now is we're gonna have that cycle every six months, like at the beginning of those six months, we're gonna have those questions. And I feel like now is a better time to start doing that because yeah, we're gonna need that all the time. Every six months, we're gonna have these discussions like why are we now prioritizing this over that? So that's an awesome point. Thank you. So it's a combination of on purpose prioritizing things and an effort to work smarter as a community, right? Because I think a lot of the time that we spent in the last couple of years was figuring out like how we use our resources appropriately and prioritization turns out to communicating priorities. Turns out to be one of those nice ways. So maybe since we've been trying to communicate priorities, now we're like, maybe we should figure out how to figure out what the priorities are. And because there are a lot more different voices involved, there's a lot more conflict and extreme differences of opinions. And in a traditional Drupal way, we might be trying to figure out like a process and to do things like politely and fairly and objectively and not personally. And so perhaps these personas are coming as a way to solve this desire that we have not to have personal conflict. Yeah, like I kind of really like the idea of actually having real people to hopefully multiple people for like these hypothetical personas that we've come up with. Like kind of like Boyan was saying where we could actually be like in this situation, like what would you want? What would you do and things like that? I think that's probably pretty good unless anyone has anything else. I don't know if there's a session after this. Is that? Yes. Sorry. If you have any interest in contributing to the discussion of what processes we should use for how we make decisions in minor releases, you should stay in this room. Oh, awesome. In the next session. Thank you, Jess. Which is five to six. Which is, okay, yeah. The potential in Drupal 8x and how to realize it, which will be presented by Webchick, Angie Byron, and Gattle Oishi who are not here yet. Amazing, okay, that's perfect. So, thank you everyone. I think we can wrap this up. So I just want to remind everyone that there's sprints on Friday. We can also just discuss things. That's cool too. And please take a minute and just give us a quick evaluation. That really helps us. I don't know about you, Laurie, but this was my first core conversation. So let us know. My second. His second. There you go. You can just go to the DrupalCon New Orleans site if you don't want to write that down, but node 9676 on events.drupal.org. Thank you everyone.