 Okay, a little audience poll. Stand up if you haven't found a seat yet. Welcome to Semantic Site Architecture. In Semantic Site Architecture, we will be talking about how to name things and how to think about the way things are already named and what the definitions mean in order to make actual architectures that are easy to understand. That's me, I'm Jody Hamilton. I set this up like a dictionary so that we can really think about words because I think that words are the way that we think for many of us and a great way to communicate. And when you're making something like an architecture plan, it's really naming words and definitions that are the most important. I'm the CTO of ZipTech, which is a company in Philadelphia. I'm a Drupal architect, developer, site builder, trainer, contributor, generalist. And a lot of my work I end up picking up, and I'm sure it's true for most people, that we spend a lot of time fixing other people's messes. And I think that's because it takes a lot more time to fix a mess than to make a mess. So you end up in this career where you're fixing messes more than you're actually building new things. And that's sort of the nature of messes. So I started to think about what are characteristic of these messes of Drupal sites that I call lemons? And what can we take away from that to teach people to not make these messes? And I think I found that one of the things that really makes for a bad Drupal site is when people didn't put a lot of thought into how they name things. They built things without thinking about whether those things had a good name, or they built things that didn't make sense with the definitions of the words that they were using when they built those things. And I'm gonna give some bunch of examples of what I mean by that. So semantic is a word that gets thrown a lot. Even in Dries's talk today, he was talking about semantic HTML, the semantic web. And it's really just a word that means thinking about meaning and linguistics. And it's just a way of being more thoughtful in sort of any field. So I thought we could apply this to site architecture and site building. Because I think site building is something that Drupal makes very easy. That's the whole idea of Drupal, is site building is now very easy. But it doesn't help you to do it well. It just makes it fast and easy. But the planning part and the thinking part is still the hard part. It doesn't do that for you. I also have this guy, Drew Plippi. If you go to DrewPlippi.com, you can download this DrewPlippi module and he will give you my tips while you're making your sites. So to remind you to take an extra thought before you just fill in those forms and just label things whatever you want. So the first part of my talk, I'm gonna talk about naming. As site builders and as site architects, and a lot of you might be site builders that don't have a site architect. That means that you are the site architect. You are constantly naming things. So what kinds of things are we naming? Content types, menus, views, themes, field groups, fields, image styles, modules, regions, et cetera, et cetera, et cetera. You're constantly being given this text field where it says name, title, label, human readable name, machine name. What are you putting in those fields? How much thought are you giving to what you're putting in those fields? One thing that's really important when you're naming things is consistency. And this should be pretty, I think it's very easy to be consistent as long as you know that it's important and that naming actually matters. And that's the main thing that I really want to express to people, is that naming actually matters. It's not just, oh, just put anything in that label and move on with it. When I talk about consistency in naming, it means within the category that you're naming and also between categories. So if you're naming a content type, you want to be consistent to all your names of different content types are consistently named, but you also want to be consistent between other parts of your site. So maybe some of your views should be using similar terms that you're using when you name the content type. So you want to kind of have a vocabulary for your whole site that everyone on the project can speak clearly. Some of the ways that Drupalipi thinks you should be consistent in naming is whether you're being singular or plural. What's the case? Spelling things consistently correctly, instead of consistently incorrectly, using punctuation consistently, deciding on whether you're abbreviating something or not abbreviating it and being consistent. And in all different parts of the Drupal interface, it's easy to maintain consistency because there are some things that are already there out of the box. So when you're making new content type, there's already article and page. So be consistent with the way those are, what the case is, what the singular or plural is, et cetera, et cetera. That's pretty easy. Redundancy. Don't bother adding things that don't add any meaning, right? They are just meaningless. So an example is news, a content type for adding news. Sometimes I tell people, some of my advice for people is, always put in that description text when you're adding a content type because that will be consistent. All of the other ones have description text. Make sure yours does too. But that doesn't mean just put in some words in there that make a description text. Make sure it has some actual purpose to it. You see this a lot, people would name their theme as like my client's name theme, and then all the functions are like, client's name theme theme, this is that, you know? Or they make a link field and they call it link field and then you have to like go look up data from field data, field link field, field data or something. That's called redundancy. You don't need that when you name things. When you name your baby, you don't name them Tom person, okay? Extensibility is something that is a real part of Drupal and it's something you have to keep in mind when you're naming something. Sometimes people will name something for what they are building right now without remembering that everything really just needs to be a bucket where you're going to be adding more things in the future. So this example is that some developer made a new module for the ticket that they were assigned and their modules name is custom staff page filters. Well, great. So now when we have to add something else to the staff page, I guess we'll just add another. How many modules are we gonna have? I would name that module maybe staff, you know? And I could add everything in there or maybe I would call it views extras or something like that. Of course, name space it for your particular project but the idea is be ready to grow. An example of a failing example of this would be the name organic groups. It used to be for organically added groups. Now most people use it to create departments that are not added organically at all, right? So groups would have been maybe a better name. Another example would be you go to a site and you're looking for where to edit a certain view of news. You can't find it. Where's the main news view? Oh, I finally found it. It's one of the displays in the homepage news view because they started out making a view called homepage news and then every time they added a new display of other type of news, they just added to that view because they were not thinking ahead. Similar to extensibility is the need for malleability when you're naming things. In Drupal, things can be easily changed but machine names are not one of those things. So when you're making a machine name, you have to really think about not naming that the machine name based on a property that might possibly change. And a big example of that is when you name image styles. So people like to name their image styles by the dimensions of the image style. But that's a property that you can change. So you end up having an image style called 100 by 100 that's now actually 80 by 80. This is going to be confusing every time anybody deals with this image style for the whole future of this website. But the image styles are actually really smart the way they handle this in core and it's a model you can continue. They use the labels have both like a human name and then they put the dimensions in parentheses and then in the machine name, they don't put the dimensions because the human name can easily be changed. It's not being referenced by your views and your content types and all other parts of your site. So sometimes it's okay to make the human name a little bit more specific but be more careful with the machine name. The reason that you want things to be consistent and malleable and extensible is usability. And you only need to be concerned with usability if your website is looked at by humans or managed by humans or maintained by humans. If it's not, it's not a big problem. Maintainability is pretty much the same thing as usability but it's really more for the developers and maybe the assisted men that's dealing with the site. But it's just another kind of usability and having things well named is a huge benefit for all of these people who are going to be working on the site and every single time something is confusingly named, it creates confusion after confusion after confusion. I had a client once that had some kind of a term that they would use as they would say we need to change the fields on engagements and we would say okay, what are engagements? And there was never like a good answer but if we really pushed it and tried to get it in writing the answer was certain things from this content type plus these three other content types but not if they have this term on them and not the things that we added last year but the new thing like, so every time they would say this term that didn't map to anything on their site it turned into this half an hour conversation like over and over and over again where we would say what does that mean? We can't process it, our brains would explode, we would then not be able to work for half of the day then we would be drunk. I mean the problems that escalate from like one bad naming thing are pretty unreal. So how do you make sure that you're doing good naming? I think the answer to this is to have an architecture plan. So the problem is there's different frames of mind when you're doing work and even one person can switch frames of mind. It's difficult to be in all of them all at the same time. So there's like a site building frame of mind where you're clicking the forms and you're going through and you're doing everything. There's a writing frame of mind, there's a planning frame of mind, there's a designer frame of mind. It's difficult to be doing all the clicking and also at the same time be thinking about how to write the help text, right? It's easier if all that planning is done at once and it's better if the planning is all done in one place because then you can see the consistency. You can create that consistency ahead of time. Instead of having like five people all building different parts of the site and making their own decisions, it's much easier to get this straight. So what I like to use is for an architecture plan, okay, sure, I will ask for a template to get me started. I like to use a plan that I got from this blog post on Palantir and I've adjusted it a little bit but you should read this blog post if you don't have a great architecture plan template. They call it the build spec. So I just use a version of that. You should read that blog post and this is the architecture plan template and what it does better than, you know, you just kind of writing your own little outline of how the site should be built is it reminds you about a bunch of important things and gives you a place where you have to fill those all in. So the first tab is for content types and it gives you like some demo stuff that you can remove but like it has a field for description. So you can put in the descriptions for all the content types right then and there and make them all be grammatically similar. You can figure out what your machine names will be and then there's a whole separate section on fields because of how fields can be used in multiple entity types and if you figure out everything that you will need to tell your site builder to put in there, then you figure out your view modes for your entity types and you can when you're doing this you can come up with naming systems that work across parts of your site. For example, I could make a view mode called micro and then I could create an image style where's the image style section that was also called micro and then it would be really obvious that the micro image style was used in the micro view mode and you wouldn't have to do one of those weird hunts where you figured out which image styles were being used where. So I really recommend filling one of these out for every project and then this lets the site builders not have to be quite as thoughtful and they can build the entire site super fast and make it really great and really consistent. So second part is going to be about respecting the names. So this is about thinking of the names and vocabulary that already exists in Drupal and honoring those names. So instead of just saying to yourself, well, I know how to use taxonomy. So I'm gonna use it for things that have nothing to do with categorization. I'm just gonna use it for creating one-off pages with access control to them. But I'm not actually categorizing anything. When you don't respect the names, you create a system that other people can't make any sense of and that's not a good thing. So the first concept in sort of Drupal architecture world is the entity. And this is a sort of like a non-word and Philly we just call it John. But it means a defined chunk of data in Drupal. I'll get this from the Drupal glossary. Every type of entity has its purpose. There are nodes, users, files, taxonomy terms. And there's a bunch of contrib modules that also add their own entity types. If you're creating a chunk of data that might have fields on it, and it doesn't match what any of these things are, what their definition is, you shouldn't just save yourself at least in Drupal 7 land, Drupal 6 land, everyone just said, forget about it, it's a node, it's the best we can do, but we can do better now. And so if your thing that you need to make is not content and it's not a user and it's not a category, it's not a file, think about making your own entity type. Because ultimately that might make your site just make more sense, instead of just saying, yeah, some of our content types aren't really for content, let me explain that to you again. It'll make a lot more, your site will be much nicer if everything's organized by what they actually are. And it's really not that hard to have a Drupal developer create a new entity type for you. And then the next sort of most important thing after an entity type is a content type because we are a CMS. So content is still king. And these are three definitions for a content type. The first one is sort of a site builder's definition. And the second one is more of a developer's definition. Technically it's a bundle of the node entity. Let me show you add a content type. So, oh, you're too big, Drupalippy. Yeah, if you get the Drupalippy module, he'll come and tell you while you're doing things. So yeah, you should make the title capitalized and singular and include a helpful description for editors. So obviously if what you're creating is not a type of content, don't make a content type. If what you're creating is not a set of fields and settings appropriate to a set of content, don't make a content type. If you can't figure out what you should do instead, take the time to plan and talk to other people. Don't just try to get this done as fast as possible. Remember, you're creating the data structure for an organization. Ultimately, a data structure should last much longer than a website because this will influence how the data gets migrated and how clean it is when it finally goes into a new system. The data structure is all they have. It's the most important thing. Yeah, they might be very focused on the design, but it's the data structure that is really the deliverable on one level. The word node, I don't know how much they thought about it when they called it that. It might have just been another John type of word. But I think it's interesting that what a node actually means, it's a point with connections, right? So one point where things branch out and connect to other nodes. And that's like the internet itself. And I think that word is really interesting because it really points to one of the biggest strengths of Drupal as a content management system, which is that the content is there to interconnect. So every time you create a node, you're automatically creating connections with the author of the node and with other content of that same type. Maybe you're connecting with through taxonomy to other content. Maybe you have entity references they're connecting it. If it's inorganic groups, it's connected to the group. Maybe you're using flags or node queue to connect it to other things. But ultimately, this idea of connected content is what makes websites so good. Nobody wants to go to a website where they just see one node and it doesn't connect to lead them to see anything else. This is the internet, it's about connections. So I think that's interesting to think about that word. But really the main way nodes get abused is by people who think that a node means a page in Drupal. Nowhere on here does it say a node is a page in Drupal. If that's the only way you know how to make a page in Drupal, you should learn about page manager and panels. Those are great ways to make pages that aren't just a piece of content. View modes are becoming more and more popular over the last couple of years. Every entity can have multiple view modes. So like full and teaser are really popular ones. DisplaySuite is a pretty popular solution to having additional view modes. I prefer a module called entity view mode, which is a lot simpler than DisplaySuite that just lets you add additional view modes. The nice thing about adding view modes is you can name your view modes and you can make them work across all of the different bundles. So you can say, I'm gonna make a view mode called search result. And I'm going to create that for every bundle, but all of them might be a little bit different. Some of them might have an image, some of them don't have an image. They might have extra fields depending on what the content type is. And then when you make a view, like your search view using search API, then you can just, instead of putting in a whole bunch of fields and worrying about, oh well, on that content type, I actually wanted to see the date, but on that one I didn't, you can just put in which view mode you want to see by picking, instead of fields, you pick like full rendered entity. And that's a lot easier to maintain and be consistent and make things nice across your site by naming these view modes and building everything up by that. Role in Drupal is the whole purpose of a user role is that crazy permissions page. If you're just trying to categorize your users, you need to come up with a different way to do it. Because you're going to add all of these extra roles onto that permissions page, that's gonna make it really difficult to securely maintain your site. The word role means the function played by a person in a particular situation. So think about that when you're naming your roles. So that there says right there that if you're naming a role, Margaret's role, it's not a very good name. A good name for a role is editor, blogger, administrator. Now let me show you the adding of roles. Another in roles, somehow you make things lowercase. A really important thing that Drupal is saying is you should drag these roles into a logical order. And if you do that, then when you go to the permissions page, you can kind of do a security audit of your site in like five seconds because you can just see what is on the left versus what's on the right. I'm super interested in paths, breadcrumbs, and menus. And that's often called like paths or what are they called like semantic URLs. So the whole idea of a semantic URL is that you can actually read the URL. And Drupal's always been great at that because there's the path module and path auto. So people always make nice semantic URLs that is good for SEO. But not everybody makes sure that their paths are actually traversable. It's really important to make your paths traversable. So they should pretend that your files are in a directory system and that people could take away parts between the slashes and get to a real page. If you've ever been on a site and you're kind of a little bit lost and you're trying to look for a landing page, so you take away part of the URL to get to one and that's not there, that's very irritating. And I really believe that a site should be treated as a single tree. So if you picture your whole site as a directory that then has subdirectories inside of it, just what they used to be. I think that that one single tree should be just one single menu. And that way, if you have a single menu, your paths can then be totally matching your breadcrumbs and your breadcrumbs can be in line with the menu tree and everything is just one to one. And I'll give you an example of that, which by the way, I don't think Drupal really does that well out of the box. What I do is I put my default path pattern to node menu link parents join path slash node title. And what that does is when you create a node and you put it in the menu, it will automatically make the path match the menu position that you put it in. So if you did it manually, then the path will just match where it is in the menu. And then you have a lot of content types that you don't usually put in the menu. So usually landing pages and regular pages, those people have to put in the menu. But something like events, those aren't put in the menu. So you make patterns for those, but you think about those patterns too. And this is something else you do in the architecture planning document. So you make sure that there is a page at news dash events and that there is a page at news dash events slash events. And then when you create your events, now their pattern matches a place in the menu. On top of that, I really like this module, breadcrumbs by path. You turn on breadcrumbs by path and then as long as your paths are thoughtful and work, your breadcrumbs now will be thoughtful and work. So I don't use those on certain core pages that mess things up, but I'll show you an example of these two things working together. So here's a page. The path is admissions slash graduate. The breadcrum is admissions graduate. And then the reason that it has that path is because it was put in the menu at that place. So all you have to do is put the thing in the menu at the right place and the path in the breadcrumm work themselves out to all make sense. And then this is a page that was not put in the menu. It's a research center. So it's path is research, research centers, name of the research center. Same thing as the breadcrumm and they didn't do anything when they made this because the path auto settings were set to do that. So I think resourcefulness is not a great skill in building Drupal sites. And that's because Drupal code is not really a finite resource. So when you see people being resourceful, a lot of times that's not for the best. When I say being resourceful, I mean that they're taking the blocks that they have, the Lego blocks that they have and no. Instead of asking around and researching and seeing what other blocks might be out there, they come up with a tricky way to build something with the blocks that they've already got. When you do that, you end up creating a Franken site that is just never going to be as good as it could be. So I think one, I'm not against creative solutions to problems. I think when you, I think the way to tell whether your creative solution is a good one or not is whether it semantically is consistent and makes sense and is easy to explain to others with actual words. If your plan is sort of impossible to explain quickly, it's not a good plan by definition because other people won't be able to understand it and work with it. So the problem with, the reason I think this stuff is very important is that it takes a lot more work to fix these problems than it does to think about them in the first place. And I think that some of the reason that we see bad work being done in site building is that as a community, we value it lower than development and some of the other skills that people have. I mean, I think there's definitely this sort of bit of a culture in our community where people who are like web performance experts, they're like, super awesome, right? And people who are really into making a really well-configured WYSIWYG, it's like, okay, whatever. But actually it's totally unfair. Every single discipline you can become an expert in and every one is super important to having a great site. And so site building, I think because it's easy to get started in, it's really just clicking through. A lot of people like to move out of that instead of becoming truly an expert in creating good architectures and doing good site building. Even though it's actually probably the most important part of building these sites. So my example is, and I really see things like this. The people when they create content types, they just create them, and you know what? It's very easy to create them, isn't it? It takes about five seconds. It takes a lot longer to remove them. Removing them consists of a couple of conference calls, creating a backup plan for what happens if they change their mind after I removed it so I can bring it all back. How are we gonna merge all of the fields into this other content type? We're gonna write some scripts. We're gonna test them. We're gonna deploy them. It's a big project that's created in only a couple of seconds. And so I do a lot of site cleanups. And they are pretty crazy because almost always you can guarantee at the beginning of the project that it would cost much less and give you a much better result to start over. And that is how serious building things badly can be. And I think a lot of times things are built sloppily because somebody asks you to build something that isn't really, you're not really able to do it and you don't know how to do it and maybe the tools out there are actually not available for the budget that they wanna spend on it. But you say yes anyway and you build them something that now is impossible for anyone to maintain and now they're still in Drupal 6 because they can't get out. Nobody even knows what that thing was that you built anymore or what it's doing or whether it's okay to turn it off. And it's a serious thing. We're working on a project now that has been close to a million dollars and it's on Drupal 6 and we haven't built the site. We are just trying to keep it from blowing up their entire business for a million dollars that we've had to put into work that is fixing a pit of bad decisions that was made in a much shorter amount of time. So I think it's important to treat this stuff even though it's just click, click, click, okay this is really fast and easy, treat it a little bit more like surgery. Measure twice, cut once, I don't know if that's what surgeons do, I'm not a surgeon. I don't know if they have a ruler or what but keep your environment clean. And yeah, you can't solve your problems on the same level you created them on unfortunately. So even though Drupal doesn't have a super quick and easy module that fixes everything. And so the way that I really advocate for an organization like a Drupal shop to make sure that they're doing good work every time is by having quality standards. My background is as an analytical chemist before I came into the web and so quality was our entire department, that was all we did and I always find it odd that in development, even though we hear all the time about disasters, I just told you about one and of course healthcare.gov was the first major engineering disaster to hit everyone's attention even though we knew for a long time as engineers that this is always happening, so this is very common. I always find it very odd that in this field quality isn't a huge deal. There is no quality con for development even though it's very critical and it causes serious losses of money. It's sort of something that nobody spends a lot of time on. So one of the ways that I enforce quality standards with my team is with review. So all the work that happens happens in a ticket and everything that's done goes into a Git commit that's associated with that ticket and everything gets reviewed by the development leader on that project or by someone else who knows the area well. And so we don't just think of that as code review like they do on Drupal.org even though it's sort of a similar model because we're also reviewing things like just site building decisions and naming and just anything that is going into the process is being reviewed to make sure that everything is consistent, that the quality is there, that nothing was spelled wrong, that because the sooner you catch these problems, the less expensive they are because what happens is you build around problems and you build into problems. And so catching them early and stopping them is way less expensive than skipping this kind of review in order to allegedly save money and then kind of having a huge unknown mass later on. So I would really recommend that to everyone to just make it non-optional that everything in your organization has to get reviewed before it's just part of the process. Questions from the audience at this time? I think you have to use a mic, but okay, there you go. Hi, I have a question. If you're using an existing field between many content types, is there semantic advice? Do you keep the same label across the name or is it okay to sort of change it? So it's a little more specific to that content type, to the content editor. And thanks for the talk, it's really... So that is a really interesting question and one that I don't have a definite answer to. So how do you deal with fields that you're sharing between content types? And a lot of people also ask the question as should I even share fields between content types or between entity bundles or shape? Just make a separate field for each one. And it also has to do with how you organize your features if you're using features module and I'm sorry for everyone because everyone is. And which is probably why DevSeed had to leave. It's kind of like they farted in the room and then they had to leave. So the... Some people don't like to share their fields because they like to keep their features so they can be reusable. I have never in my life seen anyone reuse a feature which is the whole point of features. So I think a lot of times in Drupal we do a lot of work in order to meet a goal that's not one that our clients care about or we ever use. It's just sort of like best practice but nobody ever even needs that feature. So I usually just give fields a name that makes sense for that field and then just share them if they're really the exact same thing. And it's much easier to figure that out when you're making the architecture plan than when you're just building a content type and you have to try to figure out what's going on with the other ones. Hi, I think this is great. I'm always, I'm a site builder and I'm always sitting in my head against the wall because I'm being told hurry up and build the site, hurry up and build the site and I'm trying to do architecture at the same time and be smart. And I'm curious if you have advice about how to communicate the value of this to your information architect. And so this kind of process can be happening and even to the client because at the end of the day they're the ones entering the content type. So here I am guessing at what might make sense to the client but I was just wondering if you had advice on that. I guess I haven't run into that that much. What we do is when we find something that really benefits our clients we just add it as a deliverable in the next project and we just say, hey, one of our discovery deliverables is going to be this architecture plan and we're gonna be working with you and we're gonna walk you through our draft of it and try to get some feedback from you at that point. A lot of times clients don't really understand the architecture plan and they don't like to refer back to it later. But yeah, I think by having a specific budget for it and putting it in a discovery sprint and not letting yourself get into a situation where it's like, okay, we're just building the site but we never had the time to do a plan. I mean, one of the things that we do is two week sprints so we can say, hey, we're having a discovery for two weeks. We're not touching the site until that's over and then for the next two weeks we're gonna do this and then this and this and that way you can't get into this situation where it's like, okay, just build the whole thing really fast, you know. Thank you. Hi, my name is Mario, I'm a front end developer and also a site builder who shares your feeling about making sure that your URLs match your breadcrums and I like to keep that kind of thing that way. But one of the challenges that I had with the project is that our main navigation didn't include all the main categories that our site needed so we were forced because of management decisions to create a sub navigation for the site. However, I wanted that sub navigation which was very important to be part of my breadcrumbs and the only way I was able to accomplish that is by adding that sub navigation to my main menu by hiding it from view so I could at least get the benefit of the breadcrumbs and I'm wondering whether there is a better solution to be able to include that kind of navigation in a way that makes more sense and the way that it's not hacking it the way I did. I think Drupal's core menu system is insane and the breadcrumbs are even crazier so it creates all kinds of problems like if you have multiple menus or if you have what happens a lot is you have one page that's in more than one place in the menu and then you're like, oh, the breadcrumb isn't in the right place and all kinds of things like that. I find that using that breadcrumbs by path module it doesn't care which menu something was in, it just looks at the path so that way you don't have to worry about all the menu nonsense and you can just give things the right path and then they'll have the right breadcrumb and I also have a patch, I didn't mention yet, I have a starter kit distribution that I use for every project that's called Bear, it's a Drupal award project, Bear and it has in it a lot of my, it's just kind of like the way I think core should be out of the box, it has a nice whizzy wig, like obviously Drupal 8 does but it also has a bunch of patches in it and one of the patches that it has is helps a lot with dealing with menu positions if something's in the menu more than once so what all it does, and this is a patch that's on Drupal.org just how things take years to go in, when you put something in the menu, when you're editing a node, it makes that the canonical menu position because you can only put a node in one menu position when you're editing the node but when you get a menu administration you can put it in as many times as you want well since you can only put it in once here I said well let's make that the canonical position that we base the breadcrumbs after and that way if you want to change which one's the canonical position because your breadcrumbs aren't right just change this. We don't need to make a new UI for that and where we can say which one's canonical, right? So yeah that would be my advice on that it's okay to have a second menu but just base your breadcrumbs off paths and things will be simpler. Is it a problem if you have semantic machine names to have them be too long as they're descriptive and also is it overkill for a single project to prefix all your machine names for everything with a short code for the project or name for the project? Okay so for the first question it can be a problem to have your machine names be too long because there just isn't enough room in the database field it just won't even fit in there and then they'll truncate it for you. Other modules like I think a lot of the Earl Miles views panels modules what they'll do they'll hash up the whole machine name and then you'll end up being like trying to theme something you're like well why is my ID called views dash H499 because it like hashed up your machine name because your machine name was too long for it. That can be kind of annoying but I think overall you always want things to be as small and few as you can while still having enough descriptive information to get the job done. As far as putting a prefix on everything I think maybe some people read an article recently that came from Stanford I think about how to name your features and how to organize everything in your features so the features can be reusable between different departments and I think they were talking about how naming your fields that way but in general I don't think that you need to put prefixes in your field names unless you're doing something really complicated where you're sharing between things. The only thing that you really need to prefix consistently are your modules and the functions that are in there so that you don't like create a naming conflict. All right you may have spoken a little bit to it a moment ago but one of my biggest problems that I've had from the technical side of it for building the architecture plan is maintaining it throughout the development process especially if you're using an agile process where different iterations change it. So what are some strategies you use for that? Well that is definitely a problem and I definitely have that problem. Sometimes I just say you know what now we've got the thing going and everything kind of the main architecture is done and now we're just doing tweaks just don't worry about the architecture plan anymore. It started us up let's not keep maintaining it because now it's just slowing us down that we have to like maintain two things. Hopefully it gets you to a place where your site has a good structure and it's making sense and people can just kind of maintain that as they're adding little changes because it does kind of become like this burden like do I really have to change it in two places? Sometimes I'll just because a lot of times I'm just assigning something to a site builder and then in there doing I'll just tell them hey you have to maintain the architecture plan as you make those changes but ultimately I feel like everything sometimes gets in the way at a certain point and it's like are you really gonna maintain this for posterity and put it in a frame later like at a certain point it's like okay that got us that did its job. It's sort of like the same thing with the design like you don't keep going back and revising the wireframes forever. So building on that then probably from that discovery sprint you talked about having early on then that would build the bulk of your architecture plan and then probably not too long after that once you have all your content types to find and everything that would probably be when you abandoned that. Yeah but then if there's another sprint where you're building a major new feature you might do like a little mini architecture plan just for that part. That makes sense. Thanks and you made some good points. Thanks. This is somewhat of a related question but do you have any ideas or strategies for dealing with the unknown unknowns when you're coming up with an architecture plan? You know let's say that you have a vast body of product documentation that you're trying to organize for a particular group of people and over time those expectations change. They're new things that come to life as far as what they want, how they want it structured. How do you accommodate that sort of thing from the very beginning or can you? Yeah I mean that's always super challenging and sometimes what I'll do if there's just if there's one or two areas of the project that are super sticky and the rest of it you can kind of get into shape well. I'll just say well look during the discovery we're gonna do all of these things but these other areas are gonna need more time to figure out so we're going to have a whole separate section of the project just on those areas because otherwise they're gonna take away all the attention from everything else and then if it's something that isn't well defined yet but a lot of people care about it's going to need a lot of planning and a lot of discussions and maybe if some of the people involved they might not really understand what they're doing when they're doing this architecture planning work with you until you're six months into the project and now they're starting to understand. Or they don't care until six months into the project. Right so yeah I mean you have to kind of go with your gut instinct that if something feels like it might become a problem it definitely will be and just try to keep on hitting it head on as much as that might be difficult. But that's the real hard work of these projects. Appreciate it thanks. Two things one if you wouldn't mind switching back to the screen that showed us your default breadcrumb path in case some of us did not finish copying it. And then also I have a situation that I think is what you alluded to a few minutes ago where I have sets of nodes on a site that I'm building that I wanna have them appear as if they really exist in two different places and I've of course assured my client I can do that and I'm thinking how do I do that? Is there a way that you know of other than the patch that you were referring to that where you can designate what's canonical? Do you understand what I mean? Do you need the path to be different depending on where they are or? I want the breadcrumb to make people feel like they're still in section A where in fact this content perhaps really exists in section B. That's a big problem and that's fairly common that people want that or they kind of want their breadcrumbs to act like the back button and they want it to be like well however you got there that's how you wanna get back but ultimately these structures kind of just wanna fit into a single tree and it's one of those things where I'm sure you could come up with a solution for it but the solution will be so time consuming and so possibly brittle and bug inducing that I feel like if they could just live with it it would be better for their site. Yes actually perhaps I could convince them that it's so important this content that we should make it a freestanding section of its own maybe that would be the problem. Another thing that you could do is you could sort of the content could be in one place but you could have a separate page like a that brought in that piece of content like it I don't know how you would architect if it was I wouldn't make a view of just one thing but you can do maybe a panel's page that just brought in that one node for some special reason. Okay thank you. Sure. What modules? Krumbs module. I haven't used that one I've used a lot of different breadcrumbs modules always looking for sanity but I think I've finally settled in this breadcrumbs by path one. Could you switch over to the architect Excel or spreadsheet there? Yeah. So there is a sandbox module called Merlin that will automatically take these fields and these elements and develop the site using the hat. It's called Merlin? Merlin. So it's pretty cool. It's using the palettes here template you're saying? Or is it? You can use an Excel template and it will read the Excel template then use automated testing techniques using the hat to go into your site and literally build it for you instead of you having to do it manually. I like that. It's pretty cool. It's a sandbox. Yeah. Looking for maintainers as well. Okay. Thanks. You gotta use the mic. Talking about that architecture plan template is that something that you care to share with the group? Yeah, if you, it's actually, mine is just a slightly changed copy from Palantir's and they shared this on their blog. If you just look up Palantir build spec they have a link to it. All right. Thanks everybody.